The business case is used to gain management approval to enter the development stage. Watch out for 4 fact errors.
If your business uses a stage-and-gate process, the most important gate review occurs just before development begins. Our Golden Rule of Investment is “make your decision when you have
gathered the most facts and spent the least money.” Since the development stage is very expensive, the Business Case is the mechanism for ensuring teams don’t enter it unless they’ve gathered lots of facts.
Problems can arise if each team starts with a blank PowerPoint presentation, makes up the most favorable story it can about their project… and management tries to guess “what’s wrong” during the stage-gate review meeting. We can do much better with these approaches:
- Agree on the Business Case content at the beginning of the project. As Steven Covey said, “Begin with the end in mind.” The team will work much more efficiently this way… and management knows they won’t have to guess what’s been left out.
- Let the team build the content at each step of the process. This way if the project is a dud, the team can kill the project as soon as this becomes obvious.
- Incorporate Business Case development into the team’s natural Much of the Business Case should “build itself” as the team gathers outside-in information. Writing the Business Case shouldn’t feel like a big project, but rather a reflection of the team’s work.
- Use a standardized format, with identical metrics such as Market Satisfaction Gaps… so management can compare one project against others. Include just what’s needed, nothing extra. Use highly visual content, with graphs & charts for rapid processing of dense content by a busy management team.
A well-conceived project avoids four fact errors before the business case is presented. Unfortunately, some companies never understand them—even after a failed product launch. Your team will be well-served to seriously consider if your project could suffer from any of these.
Wrong Fact. It starts innocently enough. Someone thinks customers will love this product feature. After being repeated at several meetings, this untested assumption is accepted as fact by the team. When these errors slip into the development stage, disaster can occur.
Missing Fact. This can be just as deadly. For example, the team might have missed the fact that a competing product already does what their new product proposes to do. An important question that should have been answered was not… usually because the question was never asked.
Misinterpreted Fact. This is common in inexperienced teams: “We’ll capture 75% of a 100 million dollar market.” Yes, that’s the right market size, but the penetration rate is unrealistic. The leading cause is insufficient challenging by experts on the team and in the review board.
Undiscovered Fact. This is quite different than a Missing Fact… which results from failing to ask a key question that should have been asked. An Undiscovered Fact might be a blockbuster outcome you didn’t realize customers wanted… until a competitor uncovers it later.
The Blueprinting process has been carefully designed to minimize all these fact errors. And if some do sneak through, the Business Case is designed to make them transparent and obvious.
For more on business cases, see e-Learning Module 30: Business Case at www.blueprintingcenter.com > e-Learning. You may also want to check out this 2-minute video from our B2B Organic Growth video series.
Keywords: Blueprinting Step 7: Business Case, end of front-end, gate to development stage, business case presentation, wrong fact, missing fact, misinterpreted fact, undiscovered fact