How you can be on time, on budget and on scope but still FAIL

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.

What happened?

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.


4 responses to “How you can be on time, on budget and on scope but still FAIL”

  1. In my organization there is a new classification of projects called “IT for IT”. If I asked for a business objective they would say that there is none. The problem I see in many organization is that the tail has started wagging the dog with the IT department dictating which projects get done and how.

  2. Hi David – I’ve seen a lot of IT departments and it does seem that they are best when they are doing projects to make themselves perform better (e.g. implementing agile development approaches) rather than doing projects to make the business perform better. My argument is that a lot of this is down to the fuzziness of objectives.

    Given that IT departments know how they operate inside out then they can be afford to be unclear about the objectives for their own projects – because everyone sort-of knows what the objectives should be, in some kind of unspoken way.

    It’s when they try to do projects to impact the wider business that having a clear objective can spell the difference between something that leaves the business in a better place or not. Simply because if you’ve spent your entire career in an IT department, how can you truly understand what a salesman (for example) really needs?

    I wonder whether in the future the centralised IT department will wither away to only providing core infrastructure services – e.g. PCs and Networks; all application development would be done by business functions who really know what their priorities and objectives should be?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: