I find it interesting to see how most businesses plan for IT projects. The most common approach is for the business to get a set of proposed projects together, but get IT to cost them. They then decide on which one to do based on this input and what benefits are talked about and estimated costs.

When I see the costing process, I see it as heavy weight – lots of predictive plans with lots of magic weighting and theoretical costs. Worse still is that it sets the expectation that the cost is actually predictable when, in reality the detail you get and what it cost you from the original plan are far apart and you just spent a bucket load on this additional lengthy process (the estimate starts to become a promise).

An alternative I propose is a lighter weight approach with businesses focusing on what they want to do and not what projects a particular group within the business proposes. It’s more important to focus on the business problem first and the implementation details last so that both are aligned as closely as possible. After identifying what the business want to do they should next define how much they would like to spend. The amount needs to be feasible and measuring existing project costs and benefits and getting IT involvement is definitely required. Magic numbers plucked from thin air are never useful but do need to be balanced in terms of value maximisation and technical feasibility.

The focus for the project implementation should also be different from traditional methods. The focus should no longer be ‘keep to the plan’. It should instead maximise the value the business gets while keeping aligned with the business objective. Agile projects provide a great way of doing this by splitting down the detail into chunks that have identifiable value, getting the business to continually identify what is valuable in relation to their business objective and then getting the value faster and earlier than a big bang approach.

I’d love to hear what you think about this so please drop a comment.