OTOBOS – On time, on budget, on scope – is the mantra of software project managers everywhere. So many IT projects fail on one or more of these three factors that project management 101 takes great pains to ensure that aspiring project managers learn how to stick to all three (or at least two).
But being OTOBOS is only the first hurdle to cross. Fail at OTOBOS and you fail, for sure. But there is a much, much bigger picture than simply being on time, on budget and on scope. You can be OTOBOS and still, from a business perspective deliver a big FAIL.
There are a host reasons why this can happen. Here’s one fairly common one, in enterprise software at least.
The project team has forgotten the real objective behind the IT system
There is a subtle, but important, difference between a requirement and an objective.
Here’s how the scenario plays out: A senior individual makes a proposal for an IT system to be built/implemented in order to achieve a particular business objective. Once the proposal is approved a project team is convened to implement the IT system. The team assiduously collects requirements from stakeholders and carefully manages any changes to those requirements. Eventually a shiny new system is unveiled that meets all the requirements … but which fails to deliver the business objective.
It could just be a simple breakdown of communication somewhere along the line from the business objective to the requirements to the developed code. Usually any project objective is hidden in a project initiation document or a project charter never to be seen again by anyone until after the project has finished.
Or it could just be that business objectives have shifted since the project was initiated and no-one remembered to tell the project team. As projects get longer this risk becomes more real.
Here’s a story I heard a while ago – and I’m sure those of you in enterprise IT land won’t find it surprising. A software product was supposed to streamline a procurement process by empowering end users to place purchase requests themselves, thereby avoiding paper trails and manual approvals. The system was duly delivered, on time, on budget, on scope. It met all requirements. But it turned out that the system was too cumbersome for end users to use. They continued to place their orders on paper and have them approved on paper, and then it was someone else’s job to input the approved orders onto the new system. Far from streamlining the process you could argue that the system had ended up adding a new step and more time to the process.
How to avoid this issue?
Have a clear, simple business objective for your project that everyone, from the sponsor to the intern knows and uses every opportunity to repeat. This helps people remember what they are really trying to achieve. Team members can identify early any threats that might prevent delivery of the objective. And when business priorities change (as they surely will) these can be filtered to the project team early enough that you stand a chance of doing something sensible.