The Myth of Successful Projects
Everyone loves a good project.
I was going to start this entry with the total number of projects I’ve worked on so far to make a point about there being generally too many projects going around. Turns out, this is where problems start already — what is a project, really? And what does it mean to “work” on one? I’ve owned some, managed many and happened to do some actual work on a select few over the years. Suffice to say, there is no number. But if there was, it would be in the 30 to 120 range. With some degree of certainty.
Which brings us nicely to something I’ve encountered on 99.99% of those projects, and it is not the fact that it is difficult to even count them. Something equally important is just as difficult to quantify: their impact. And I’m not talking about the numbers swirling around in impact calculations and business cases without which bigger projects in more stringent companies will never get off the drawing board. Or even on it. As the old saying goes “excel will take anything”, and in fairness oftentimes genuine effort is made to get those numbers right. Sometimes they even are, to the extent to which any forecast can be accurate in the first place.
More importantly, I’ve found it to be exceedingly difficult to isolate the actual real-life impact of any project after go live. This is particularly true for self-service oriented digitization projects, which more often than not have some kind of contact deflection target attached to them. On paper, these look decent enough, but if I add up the expected contact deflection numbers assumed on all the self-service projects I’ve worked on, then a number of contact centers would have had to be closed a long time ago. Which, of course, never happened.
The list goes on, typically the bigger and more complex a project, the bigger the difficulties in attributing any kind of impact. Add to this the fact that quite often projects running in parallel hope to impact the same drivers, and total confusion starts creeping in. Of course, people typically don’t care, mainly because the next project in line is already waiting to be kicked off. However, another reason for not caring is that deep down, everyone involved can feel whether any given project was a successful one and if that feeling is not a resounding “yes” then transparency is not everybody’s friend.
Many times, a successful project is still defined as one that made it to “live”, with limited accountability for anything that happens afterwards. And God forbid if anyone manages a project that is cancelled halfway through implementation, even if that would have saved hundreds of thousands or even millions of euros down the line. Not a great career booster.
I have the faint suspicion that this interpretation of project success has contributed more than a little bit to the shift towards rapidly launched, lower complexity projects. Contrary to the fashionable narrative, not everything can be broken down into 2-week sprints (although many things can and at Pattern we are using rapid prototyping and implementation wherever we believe it makes commercial sense, but only then and not as a gimmick) but it is true that shorter projects mean more frequent cause for celebration and less chance that someone pulls the plug before go live.
What to do then?
There is no one size fits all solution of course, but some interesting initiatives I’ve seen that can help foster a more sensible approach to measuring project success in any organization include:
- Running less parallel projects. Sounds simple but is actually quite difficult to enforce — impact isolation will be more straightforward if there is nothing to isolate from. What works for scientific experiments deserves a shot in more practical areas, too.
- Having valid impact calculations for each project…
- … and making owners care about the target numbers. A good way to make sure this happens is to (a) introduce regular reviews and (b) link target fulfillment to budget allocation for upcoming projects. This one is especially difficult to pull off in a way that it doesn’t stifle the willingness to take risks, but that is a topic for another time.
- Rewarding cancelled projects. Don’t get me wrong, the good ones should still happen, but killing projects that should not have been started in the first place is a good thing.
Bottom line, try to bring transparency into your project and portfolio management, even if it isn’t popular at first.
