A business case comes between a bright idea for a software project and the creation of the software project.
- 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
Not all ideas for software projects make sense. In the yellow zone above, between idea and project being initiated, some due diligence on the project idea should occur. This is where you do the business case, even if only informally on the back of a napkin.
The business case is where you pause and and estimate whether the project is worth it, i.e. 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.
Projects that do not improve skills or the bottom line are a failure.
Out of 10 software projects (see Understanding your chances):
- 3 are successful
- 4 are challenged, i.e. over cost, over budget, or deliver much less functionality
- 3 will fail, i.e. abandoned
This means that the base rate of success for any software project is only 3 out of 10. Yet executives routinely execute projects assuming that they can not fail, even though the project team may know that the project will be a failure from day 1.
Business cases give executives a chance to stop dubious projects before they start. (see 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
When there is a moderate amount of uncertainty in any of these three areas then a formal business case with cash flows and risks needs to be prepared.
Requirements Uncertainty
Requirements uncertainty is what leads to scope 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.
For all other software projects the requirements uncertainty is moderate and a formal business case should be prepared.
Projects new to you have high requirements uncertainty.
Technical Uncertainty
Technical uncertainty exists when it is not clear that all requirements can be implemented 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
Therefore technical uncertainty is high when you are doing a project for the first time and requirement uncertainty is high. Technical uncertainty is high when you are using new technologies, i.e. shifting from Java to .NET or changing GUI technology.
Projects with new technologies have moderate to high uncertainty.
Skills Uncertainty
Skills uncertainty comes from using resources that are unfamiliar with the requirements or the implementation technology. Skills uncertainty is a knowledge 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
Every other project requires a formal business case that will quantify what kind of uncertainty and what degree of uncertainty exists in the project. At a minimum project managers facing moderate to high uncertainty should be motivated to push for a business case (see Stupid is as Stupid Does).
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
Projects with moderate to high risks and no business case are doomed to fail.
Related articles
- No Experience Necessary!
- Surprisingly there is no correlation between years of experience and productivity. This has been verified over 40 years.
- Stop it! No, Really Stop It!
- 5 worst practices that software organizations commonly practice that they need to stop right away
