Choosing which projects to fund
Given we live in a 'resource constrained' world, before anyone gets started with setting up a project team, senior management has got to give the project idea to go-ahead, the green light, the budget to proceed. How does senior management make that call?
A project idea is first articulated in the mandate document. The mandate has to describe the problem the project is going to address, the business value to the enterprise of solving the problem, and the magnitude of the cost of making the solution a reality. We could term the calculation the Value to the Enterprise (VttE) of each project and it could be expressed as:
Business value/Estimated cost.
A project that could reduce costs by £500,000 and which has an estimated cost of £250,000 would have a VtttE of 2. Another project that could produce £2 mil and cost £500,000 would have a VttE of 4. Where it was necessary to choose one project over another the VttE calculation would favour doing the second project.
Calculating VttE for each project initiative requires an estimate of the business value and an estimate of the cost; neither of which is easy, but both are possible. It's important to remember that estimates may be relatively accurate or inaccurate. Over time the objective is that the calculations improve and accuracy increases.
Estimating the target for revenue generation that a project may yield is something the Marketing department should be able to provide. Estimating potential cost savings should equally be something Operations should be able to help with.
Estimating the cost of delivering a software solution is notoriously difficult, but it is possible to do it in a systemic way provided the appropriate metrics are defined, measured analysed and fed back into the equation. The Mandate describes the project in the Feasibility stage, and it must contain an early lifecycle representation of the functional requirements to get a measure of functional size. The trick is to ensure that the functional representation of Project A is comparable with the functional representation of Project B. Apples must be compared with Apples. At this stage of the project, the user story practice has not kicked in to provide the functional picture (and story points) that might be used as part of effort estimation. (Story points are not designed for this - they are designed to discuss relative complexity at the Release level). Instead it is necessary to rely on some other measure. I advocate use case points. An early lifecycle representation of the system can be produced quickly based on analysis patterns. Points systems exist for complexity measures (such as function points) but I prefer use case points. This is the subject of future publishing under the auspices of Enterprise Value Analysis.
The important point to take from this discussion is that projects should be prioritised based on Value to the Enterprise.