Welcome to the BPR Tutorial Series
Return to INDEX
The Business Case - Friend or Foe?
(Part one of a three part series on business case development)
by Nancy Maluso
Oh no, you have to write a business case. Why? Most rookies and
veterans of any business process reengineering (BPR) effort view the business case as a
necessary evil, an exercise far more painful than doing taxes. Unlike our taxes, however,
the business case can result in more than just a tax refund. In fact, there are a number
of valid reasons for writing a business case in any reengineering effort even if the
effort has already been funded. This article will address the role a business case has in
the reengineering effort, and help your team put the business case into it's proper
perspective so that the business case can be viewed as another important, but not evil,
step in the BPR effort.
Why Should A Business Case be Written?
The most obvious reason for putting together a business case is to
justify the resources necessary to bring a reengineering effort to fruition. However, this
implies that the business case is simply a financial document. While all business cases
should include financial justification, it should not be the only purpose of the document.
The BPR business case is the one place where all relevant facts are
documented and linked together into a cohesive story. This story tells people about the
what, when, where, how and why of the reengineering effort.
The writing of the business case forces the BPR team to sit back and
reflect on all of the work they have so diligently completed. It is far too easy for the
team to continue to plug away toward the end result and fail to document the work they've
already accomplished. This is especially true during the concept and design stages of any
BPR effort. Therefore, the business case serves as a wake up call to the team to cause
them to capture the knowledge they've developed about how the business will function both
with and without the BPR project. This is by far the most valuable role the business case
can play in the BPR effort.
The second most important role of the business case is to verify
that the solution substantiates or meets the needs of the business. It provides a vehicle
for the team to step back and subjectively review their facts and assumptions. In
addition, it is vital that the BPR team document what would happen to the business if the
BPR effort is not undertaken. This base case or do nothing scenario is the foundation upon
which all benefits from the BPR effort are derived. By documenting everything together in
one story, it is easy to link the issues to the solution and the benefit, and identify
where the business would be without the BPR project. The development of the overall
business case simplifies the development of the financial justification, and will usually
identify holes or problems with the solution. Moreover, you now have a way to measure your
success.
The final, important role that the business case plays is to provide
a consistent message to many different audiences. It is a high level view of the entire
project and enables all organizations affected by the effort (customers, management,
operations, research & development, service, sales, accounting, finance, etc.) to be
cognizant and knowledgeable about the effort.
Who Should Write the Business Case?
The business case should be viewed as a story, your team's story.
Therefore, everyone on the team should contribute to its development. This does not mean,
by the way, that everyone will write a section of the business case. In fact, my
experience tells me that only one or two people should actually write the final document.
However, all of the information used in the business case should come from team members
themselves.
My preferred method for the actual writing of the business case is
to have each team member document the details of their own aspect of the reengineering
effort into a separate plan. For example, a team member who researched customer
satisfaction issues may write a plan about customer needs (the customer needs analysis
plan). Each plan contains the details behind the business case and can be written in
multiple styles and formats since they are standalone documents.
The team should not feel trapped by formality or grammar in writing
their plans. In fact, I often suggest that each team member keep a log or book of all of
their activity from the start of the BPR project and maintain files with the information
they've developed during the project. Then when it's time to write their plans they can do
a stream-of-consciousness dump by following the activity log. I then have them refer to
their files for substantiating facts to fill into the plan.
If the team is not well organized or does not do a thorough job of
substantiating facts throughout the project then these plans will be hard to put together,
and the business case development even harder.
The business case writers should be team members who have an overall
understanding for the entire project and can synthesize the multiple and varied plans into
one document. Keeping the actual writers of the case to a minimum ensures a consistent
style throughout the document.
When Should the Business Case Be Written?
BPR methodology typically provides some break points where a
business case should be completed. For example, BPR projects following a concept ->
definition -> design -> development-> implementation model should write a
business case at the completion of the concept phase and the design phase. Am I suggesting
two business cases here? Yes, however, the first forms the foundation for the second. The
concept phase and definition phase provide good breaks because they represent the
completion of important work and occur at the time the team needs to request additional
resources. In addition, these breaks are important milestones in the development of a
sound solution, so writing the business case at these points allows the team to
substantiate their assumptions.
Every milestone in the activity of the team should result in a
contribution to the business case. For example, at the conclusion of the needs analysis
phase all of the issues that have been uncovered should be documented in the business
case. Appendices should be created to hold the detail of the analysis - customer
satisfaction survey's for example.
How Long Should It Be?
You must remember that someone, many persons probably, will have to
read and understand the business case. Therefore, it should be as short as possible while
still providing enough detail to give the reader the whole story. I've seen an effective
business case summarized in one page with the full business case taking only 32 pages. It
did of course reference other documents for details that supported the assumptions made
within the business case.
Overall Goals
While one of your primary goals may be to get funding, your chances
of success will be greater if you keep the following goals in mind as well:
When your team is done, you should throw a business case party. The entire team should feel a wonderful sense of accomplishment, after all, the business case contains a complete record of the great work the team has completed and demonstrates the value of the work yet to be done.
The benefits obtained by your team from the writing of the business
case are many, but minimally they will have gained:
Module Questions:
1. How easily can your team locate information developed in the early stages of the project? Find:
2. Try a simple exercise:
Put together a two column list. In the first column, write down the
issues and goals the change initiative is trying to address. In the second column, list
the solution elements that your team developed. Now draw a line from every issue or goal
to the solution element that fully or partially resolves that issue. Are any issues left
unaddressed? Are there any solution elements that do not impact the issues or goals? Were
you able to do this exercise without researching any material? Effective business cases
concisely state the issues, goals and solution elements (the proposed changes), and
clearly communicate their interrelationship. When presenting your business case you should
be able to do the same, quickly and without referring to documentation.
About the Author - Nancy Maluso serves as a consultant
to businesses and reengineering teams. Her expertise focuses on helping businesses create
marketing, operational and business plans. In particular she has assisted many BPR efforts
in the development of sound business cases that have enabled her clients to secure the
necessary resources for their BPR projects.
Related Toolkits and Workshops
Reengineering Best Practices
Reengineering Toolkits and Document Templates
Business Process Reengineering Implementation
Change Management Strategies and Action Planning
Process Management and ImprovementAbout Prosci. Prosci is a registered trademark of the
Quality Leadership Center, Inc. Copyright 1996-2003, All Rights Reserved.
Tutorial Series | Bookstore | Articles | Books | Benchmarking | Mailing lists | Yellow Pages
Register | Search Other Sites | Comments | Home Page