Projects go bad in multiple ways. And even when put through a project review, causes of failure can remain hidden. Scope creep is a good example. When it happens mid-project it’s usually obvious – changes to a project scope should be well documented and tracked through governance. But scope creep doesn’t just happen in flight. And when it’s baked into the very birth of a project, it can be just as devastating as in-flight change.
Launching with the right plan
From sponsors adding items to the plan and refusing to cut elsewhere, all the way to project managers too timid to challenge, projects that launch with an unrealistic plan are doomed to fail.
But that doesn’t stop it from happening – far too many projects get the green light with bloated scope. It’s a sure fire route to failure, with the hiss and a roar of a project launch only making the subsequent failure harder to manage. And when the project finds itself in front of the steerco explaining non-delivery and asking for cuts, launching with an unrealistic plan is unlikely to cut you much slack.
Rigour up front is the best way to avoid this fate. If your PM and delivery team are telling you it’s complex and high risk, take it onboard and cut your cloth accordingly. The alternative is a reputation shredding in-flight failure, along with the negative value creep and benefit erosion under delivery will drive.
Keeping your team on track
Another equally insidious form of failure is delivery creep. The worst thing about delivery creep is it often comes from your most passionate groups, the ones who care most about the business. These are the guys who always want to do more, improving on their delivery and execution. In doing so they run the risk of overreaching, and losing their North Star.
Recently I’ve been working with a cracking project team, alongside a first rate sponsor. Some of the stakeholders have asked for additional functionality, associated with a linked but future initiative. Here’s the problem – not only is this distracting the team, the additional functionality isn’t part of our agreed minimum viable product, and chasing it just adds complexity and increased risk, threatening our sacrosanct go-live date.
My job has been coaching and persuading them, with the help of the sponsor, that the project MVP is our North Star. Anything else is just noise.
You see, we’re not judged on whether we deliver the extra functionality or additional scope. Allowing delivery creep threatens the project and puts reputations at risk.
Whether it’s your own, or that of a project, reputations are hard earned. So why take the risk?
In this case we’ve kept delivery to our scope and managed to keep our North Star. But the threat to project delivery of scope and delivery creep are constant, and it’s your job as sponsor or PM to keep this under control.
