A somewhat sensationalist title perhaps. And of course I’m not accusing all of you of having lost the plot. Only some of you. And you might not know who you are or you may not agree with me. Which is fine. What I’m talking about is the fundamental understanding of what a project actually is versus something that isn’t or doesn’t need to be.

I hear a lot of talk and read a lot of material about Product versus Project and the end of life as we know it for projects. And then there’s the endless jostle with Waterfall versus Agile, as though you have to pick one end of the spectrum. It isn’t even a spectrum actually. They aren’t opposites. Like gymnasts and 400m relay runners aren’t opposites.

Businesses, or rather the leaders and people that work within and for them face many different challenges and opportunities that need to be or are elected to be addressed and pursued. Screamingly obvious, as is the fact there are loads and loads of different types of companies in the hundreds of millions that exist. I looked that number up, just to be sure. Possibly approaching a hundred thousand that are in the $100M or £100M and over bracket. Some of them sell software. Some essentially ARE their software, Software as a Service companies and tech giants with ubiquitous apps. Many such companies will face very different technology, enterprise application landscape challenges and opportunities to those that sell food and drink, consumer goods, financial services, construction and engineering solutions, cars, boats, golf balls.

There aren’t just two types of change initiative or transformation. And yet some seem to harbour the notion there is even only one and apply Agile approaches to everything, at least in the world of IT projects. This is not an Agile-bashing article by the way. Far from it. Agile has its place. I picked the right-hand image with my tongue firmly in my cheek. There’s a lot of glitz and fireworks and zeitgeist around Agile. As though it’s the only way a business can be agile with a small ‘a’, whatever that actually means. A business is only as agile as the people that act for it. A business can’t be agile per se.

Frankly, is Agile synonymous with agile anyway? Or is it just a ‘brand’? A label? Those familiar with the Agile Manifesto will be aware of its principles and that it isn’t actually a project methodology. It’s a Software Development Lifecycle (SDLC) methodology. And because that front page of the Agile Manifesto states ‘Responding to change over following a plan’ as one of its principles, many seem to think that means you don’t need a plan. It doesn’t mean that. It simply means that responding to change and being flexible is considered more important than rigidly following your plan. I’ve worked in a number of companies where an agile approach has been adopted for everything, the plan has been forgotten as a concept and leaders scratch their heads when everything is late and when they don’t ever know when something is going to launch. Doesn’t sound very agile, does it? What’s agile is simply the method of designing and developing the software. That’s not the same as business agility. Of course if we’re talking about a business where the software is the company, it’s likely to represent a big part of business agility if it’s the mechanism by which you can release value in a flexible way.

Let’s talk about Waterfall. The notion that you have to gather all your requirements before you design, complete all your design before you build, finish build before you end-to-end test anything. Few projects I have worked on have adopted such an approach with absolute rigidity, albeit some haven’t been far off. Some think it’s dead. There’s no place for it in our brave new world. And yet it is an absolutely critical concept for large-scale technology landscape changes and for construction, civil engineering, energy and other non-IT specific projects.

I’ve worked for a client where they started designing, building and testing with only 20% of requirements gathered and fully validated. Three quarters through we faced major challenges because a requirement stated at the outset was in conflict with far more other requirements than it was aligned with, and it was too late to drop it. Why did that happen? Because it was a large-scale, highly complex full digital and back end enterprise landscape change, with impacts on target operating model, business processes and commercial go to market strategies. That’s extremely high risk. It demands a more structured and methodical approach, with plenty of checks and balances that everything hangs together.

Of course there’s no problem using an Agile approach to build any custom software that’s part of such a transformation if it makes sense to do so. Which isn’t always the case, by the way. Take a look at the rest of those Agile Manifesto principles. It has sweet-spots, and by inference, whatever the opposite of sweet-spots is. Sour-spots. It makes sense where there are requirements and design unknowns, opportunities for innovation and creative augmentation. Where it’s feasible and beneficial to release components and their value in a drip-feed. The much-talked-about minimum viable product (MVP) concept. It doesn’t make sense where requirements are in fact highly rigid. Not where there’s a strict timeline objective to get everything or ninety percent of it live by an imperative deadline. This isn’t just me talking. Scour the internet. Plenty of thought leadership material out there that says the same thing.

I mentioned Products at the outset. The notion of a structure that focuses around owners of landscape or process or value delivery (or all three) components. Teams that deliver across multiple changes (can’t use the word ‘project’) rather than forming separate teams for each individual change. This might make sense for ongoing, business as usual changes to your IT landscape and the solutions within it, where you’re prioritising the fulfillment of demand with a fixed capacity. But there comes a point when a change is simply too big to be absorbed by an ever-present team. Why would a company have vast resources at its disposal all of the time, so that it could deliver to any peak that may arise? I’ve heard people complain bitterly that Heathrow airport is useless when there’s a bit of ice and snow and how come Oslo and Stockholm do so much better with loads of the stuff? The answer’s in the question. They have to invest in the optimal level of resources and the right solutions to deal with their profile of conditions, and so they must be able to cope with it. Because there’s so much of it that if they couldn’t, they wouldn’t be able to operate a lot of the time. Heathrow just deals with the exceptions the best way they can. It makes sense.

So, projects are not dead. They are well-and-truly still alive, kicking and valid. You need a project when you have to do something that your normal level of change delivery simply and sensibly is not set up to deal with. Or when you’re a team formed purely to build something completely new. You might be able to deliver some elements of your change with Product teams. But if it’s too big to do that across the board, it’s a project. Or a program of course if it’s sufficiently large scale to justify that governance, structure and resourcing.

Where am I going with all of this? Well, I’m going to dial down the conjecture and pontification and get to the point. Agile and Scaled Agile (SAFe) and Waterfall and Product teams and Value Streams and no doubt many other names for ways to do stuff are constructs. Frameworks in which to organise people (and possibly robots and clever machines) for the delivery of… well… stuff. For the completion of tasks and the delivery of the… deliverables. The value. And every business out there is different, with different strategies, priorities, operating models, organisation structures, levels of across-the-board and technology resourcing, and technology and other change demands.

It’s just possible it may not be optimal to lift one of these constructs off the shelf and apply it to everything. Or indeed apply it to the letter to anything. Waterfall enforces dependencies that mean you can’t start phase B until you’ve finished phase A. But perhaps there are elements in phase A that can go to phase B whilst others are in phase A. In a tightly regulated industry such as pharma or financial services, greater rigidity may be a necessity. But outside of those hefty compliance demands, what we really need to do is identify, justify and honour the true dependencies, where not doing so is impossible or represents unpalatable levels of risk. And what we really need to do is identify the outcome we seek, the value we will create, the deliverables that will create it, the work that needs to be done to deliver it, the resources required to execute the work, and the leadership and governance requirements to support that execution. Yes we can apply known models. But fundamentally, we need to ensure the right structures are in place to get the right work done by the right people at the right time, to the right quality. There’s a real, real danger that leaders overthink this, perhaps because it seems pretty daunting when not broken down to its component parts. And you want to get started and not mess about planning and setting up and breaking it down into its component parts.

My closing thoughts. It’s not as simple as lifting one or more existing constructs off the shelf and applying them. Neither is it as complex as lifting one or more existing constructs off the shelf and applying them. It’s somewhere in between.