Projects in Name Only (PINO) | Black Swan Farming

When people talk about “projects” it’s sometimes hard to nail down what they actually mean. Some seem to refer to any loosely organised or directed effort toward a goal as a “project”.

Using this dictionary definition, something as simple as writing this blog post could be deemed a “project”. Indeed! A project to write a blog post about projects. (So meta.)

Or, a project to make a coffee ☕️. A project to take a shower 🚿. A project to make a sandwich 🥪. A project to take a breath. All of these could be deemed a “project” if one uses the dictionary definition and interprets it broadly – and the whole world is full of projects, millions and trillions of them. I find this definition so loose and broad that it’s not particularly useful. So, if this is what you mean by “project”, then what I’m about to say doesn’t apply to your extremely broad definition of project. You can happily continue doing your project-ing all over the place.

Others, however, will attempt to adhere to a more formal definition – one that excludes a whole range of basic tasks that require little to zero thinking or anything that might resemble Project Management. Like the one provided by the Project Management Institute (PMI). (You’d expect them to know, and to be able to provide a useful meaning/definintion.)

Here’s how the PMI define it, and I’ve highlighted a few pieces that jump out at me as being important.

So, using this as a starting point, we can narrow the possible interpretation to something more useful.

A project is temporary – it has a defined start and end, a defined scope and specific resources
Often includes people who don’t usually work together
Must be expertly managed to deliver on-time, on-budget results, learning and integration as needed by an organisation.

The curious case of the PINO

What I find curious is that those three points that the PMI defines above – well they tend to be largely missing from the things that a lot of organisations who use continue to use projects do. At least not any more. Which brings us to “PINO”: Projects in Name Only.

Specifically, we tend to have more stable teams now – we don’t form a team and then disband them at the end of a project. The organisation isn’t temporary, and the beginning and end are generally quite fuzzy. And with flexible scope and flexible start, it makes me wonder, why do projects persist?

Antiquated Funding methods?

My theory as to why we see so many PINO: Projects in Name Only? “Projects” is how the Finance team tend to see the investments and allocation of budgets – and a project is therefore the only way to fund software teams.

Luckily, there are alternatives to the PINO-funding approach:

(More on that here)

Boss-level Digital PMO: Fund the teams (i.e. the strategic capability to deliver change) NOT the individual items of work.

Then, empower and trust your Product Managers to guide the teams in running the most valuable experiments. Make them small: No need to “approve” them. The overhead of approval is probably more than the potential wasted time and effort, especially when you take into account the Cost of Delay that an approval process incurs.

The analogy I like to make for this is looking at how an America’s Cup team operates. Collectively, Team New Zealand put massive investment into capability (boat and team) – and *trusted* Peter Burling to steer it. You can’t put the CEO or CFO behind the wheel, or have them second guess and approve each and every turn of the wheel. It’s just far too slow. Yep, sounds ridiculous in that scenario, but this is effectively what lots of organisations do with their product development capability.

TRUST makes the difference between the hull of your organisation sitting in the water, dragging along (with politics and bureaucracy) and flying above the surface, up on the foils. Without trust, you’ll never fly.

For a lot of orgs using Projects as a delivery vehivcle, they don’t believe that “flying” on hydrofoils is even possible. So of course they aren’t optimising for that. They’re mostly worried about smashing into the rocks. The value of *speed* and in particular *faster learning* is invisible to them.