They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focused. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.

This defined end date is where the problem with projects lies. In reality, most of the things we treat as projects aren’t really projects. They have no real end date. Let's take software delivery as an example. A company develops a product, let's call it "Wonder Widget". They want to release a new version (WW 2.0) so they start a WW2.0 project with an end date that matches the desired release date. When the release date is reached, the project team is disbanded. Then when they want to release WW2.1, they start up the WW2.1 project and so on. Sound familiar? The industry does this all the time. So what’s the problem?

The problem is that these aren’t really separate pieces of work. Development of Wonder Widget doesn’t stop when 2.0 is released; it continues. But in a project-focussed world, the team that developed 2.0 is not necessarily the same as the team that develops 2.1. Project teams have a finite life. Some of the key members may be the same but many will be off on other projects (Super Service 3.5) so the new team has to learn about Wonder Widget from scratch.

Even worse, the Wonder Widget 2.0 team may have left things in a bad state. We all know how this happens - schedule pressure near the end of a project. The team feels stressed. There are still new features to deliver. Other things start to slip. Like testing and documentation and code quality. All the things that will make life really hard for the 2.1 team.  The 2.0 team won’t be judged on how clean they leave things for 2.1, or on how much technical debt they accrue. They will be judged on how successful 2.0 is – how many features it has, how well it sells. Everyone knows that 2.1 will have a hard time but hey, that’s their problem. 2.0 will be a great success.

Sound familiar? The problem with projects like this is that they aren’t really projects. Product development is a continuous activity. One release of a product shouldn’t mess up the organisation’s ability to deliver the next release. What we need is a Product focus rather than a Project focus. The team shouldn’t be  the 2.0 team, they should be the Wonder Widget team. They should be responsible for all the releases of the product. They should flow from one release to the next as a stable team.

Quite obviously this removes the learning stage from the beginning of each release but more importantly “that’s their problem” suddenly becomes “that’s our problem”. The team now has an incentive to keep quality high. This flows on to other organisational benefits like more predictable releases (as teams are’t blindsided by technical debt left behind by other teams rushing to finish).

Similarly for change management projects. Running change management as a project is a great way to ensure that the change fades away as soon as the project is finished. Change management is ongoing, with no real end date.

Projects are fine for things that are actually projects. But let's stop treating everything like one.