The level of process maturity varies greatly from one company to another. Some organizations need to have all steps followed and documented. Meanwhile, others have more flexible processes where only some steps are followed some times.

In these environments one of the temptations I have often observed is to skip a real business case. However, I would argue that this is a huge mistake.

The two most common situation where the business case is skipped are:

• ‘Minor releases’ where the development teams feel they have a solid handle on the tasks to be done. In such a situation it is tempting to skip the business case in favor of just doing what “everyone” knows is the “right thing” or by relying on the expertise of the product manager.
• Executive driven projects where the framework has come down from the the Sr. Execs. Since it is just presumed that it will be done, nobody builds the formal business case.

However, skipping the business case step is a lot like the problem of an unfocused release. While it often works under ‘normal’ circumstances, it too fails when the allocation of resources, content or schedule comes under fire. Gee, will those same execs remember the justification used when the doo doo hits the fan later?

What the business case does for the process is provide an agreed-upon framework for evaluating the merits of the project. In the business case, you can identify the potential benefits as well as planned costs to achieve those benefits. These can be quantitative but they can also be qualitative, particularly for strategic or competitive efforts. With these objectives clearly documented, the other decisions fall into place and it is easier to ‘rally the troops’ around the ‘right thing’ to do.