- To - idea to have a project is born
- Tcheck - formal or informal business case
- Tstart - project is initiated
- Tend - project finishes successfully or is abandoned
will this project leave you better off than if you did not do it. For those who want precise definitions the project should be NPV +ve. In layman's terms, the project should leave the organization better off on it's bottom line or at least improve skill levels so that other projects are better off.
- 3 are successful
- 4 are challenged, i.e. over cost, over budget, or deliver much less functionality
- 3 will fail, i.e. abandoned
Stupid is as Stupid Does) Understanding how formal the business case needs to be comes down to uncertainty. There are three key uncertainties with every project:
- Requirements uncertainty
- Technical uncertainty
- Skills uncertainty
Requirements Uncertaintyscope shift (scope creep).
The probability of a project failing is proportional to the number of unknown requirements when the project starts (see Shift Happens).
Requirements uncertainty is only low for two particular projects:
- re-engineering a project where the requirements do not change
- the next minor version of a software project.
Technical Uncertaintyimplemented using the selected technologies at the level of performance required for the project. Technical uncertainty is only low when you have a strong understanding of the requirements and the implementation technology. Uncertainty and risk are two different animals (see Uncertainty Trumps Risk in Software Development)
When there is only a moderate understanding of the requirements or the implementation technology then you will encounter the following problems:
- Requirements that get clarified late in the project that the implementation technology will not support
- Requirements that can not be implemented once you improve your understanding of the implementation technology
Skills Uncertaintyknowledge problem.
Skills uncertainty is only low when the resources understand the current requirements and implementation technology.
Resources unfamiliar with the requirements will often implement requirements in a suboptimal way when requirements are not well written. This will involve rework; the worse the requirements are understood the more rework will be necessary.
Resources unfamiliar with the implementation technology will make mistakes choosing implementation methods due to lack of familiarity with the philosophies of the implementation libraries. Often after a project is complete, resources will understood that different implementation tactics should have been used.
Formal or Informal Business Cases?An informal business case is possible only if the requirements, technical, and skills uncertainty is low. This only happens in a few situations:
- Replacing a system where the requirements will be the same and the implementation technology is well understood by the team
- The next minor version of a software system
Here is a list of projects that tend to be accepted without any kind of real business case that quantifies the uncertainties:
- Change of implementation technology
- Moving to object-oriented technology if you don't use it
- Moving from .NET to Java or vice versa
- Software projects by non-software companies
- Using generalists to implement technical solutions
- Replacing systems with resources unfamiliar with the requirements
- Often happens with outsourcing