Mobilizing
Change
Part Two: The Case for Action Method
Featured
Author - Bronwyn
Evans
- October 2, 2003
The Approach
The
best way to develop the projected benefits is to workshop these, then to prepare
your case for action document and have it reviewed by the contributors.
Some people
conduct interviews and analyses of operations. The problem with this approach
is that it takes a lot of effort and generally results in conflicting opinions
in some areas. This approach also involves looking at what is done now and the
analyst then determines how it could be done better. It doesn't involve the
participants in the development of the result. Involvement, engagement and contribution
are all critical to gaining buy in and commitment to an endeavour.
Our experience is that a workshop is the best means to develop a case for action
because information gathering by other means takes a lot longer and doesn't
deliver a proportionately greater amount of value. Thus spending laborious hours
interviewing and analysing is not necessarily going to deliver a greater return
on investment.
The session is best facilitated by an independent facilitator. This can be someone
from an independent part of the organization, e.g. human resources, or can be
a third party. This is an important distinction, because someone with vested
interests may attempt to influence the discussion or may be focused on their
own particular pet peeves. Most importantly, if they truly facilitate, then
they are unable to contribute and this may detract from the end result.
Who To Involve
For an enterprise software solution, the benefits that are likely to accrue
will probably have an end result of reducing costs or increasing sales. If you
quantify the benefits in detail, the odds are that someone will always be able
to find a hole in one of your assumptions or projections.
We find that the most credible benefits are identified by the people who are
in the hot seat. What they are prepared to commit to has much greater credibility,
because they know how things operate. They might not know the full potential
of the new solution, but if you involve the right people, they are able to consider
what might be possible.
So, when
preparing a case for action, we recommend involving a broad group of people
from across the business. We want people who know how it operates, who might
have experience of how competitors operate, and people who are influential and
respected.
This is
Part Two of a two-part article.
Part
One presented the problem.
Workshop Structure
Our
experience is that it's important to understand the rationale for the project
at two levels—the strategic and the tactical. By focusing on both, you are better
able to create a compelling argument for the initiative and better able to build
a case for the different audiences.
The general structure of a case for action workshop is as follows:
-
Understand strategic issues
-
Understand tactical/operational issues
-
Brainstorm potential benefits, agree, and prioritise
-
Gather specific information relating to the main benefits
Strategic
Issues
We find that it is most useful to start with the strategic perspective and understand
the strategic positioning of the organization. For software evaluation projects,
this could be that competitors are moving to new technology and achieving operational
and service efficiencies. It could be that suppliers or customers are forcing
the adoption of collaborative technologies as a prerequisite for doing business
with them.
There are a number of models that can be used to uncover the strategic issues.
One that we have used quite successfully is the market forces model from Michael
Porter's book Competitive Strategy. It takes only a few minutes to explain the
model and people can quickly relate to it. A little preparation to consider
a couple of examples in each of the five areas to consider is helpful to get
the group started.
If there is a particular strategic model used within the organization, or a
recent strategic plan has been prepared, then this should provide the basis
for the strategic analysis.
In considering strategic issues, don't try to solve the problems. At this point,
the objective is to build awareness of the issues in the minds of the participants.
It's really a focused brainstorming analysis session.
Tactical/Operational Issues
Having
gathered information relating to the "big picture," it is appropriate to look
to the tactical side and seek contributions on current frustrations and opportunities.
This can be done in one of two ways:
-
Focusing on specific functions and the associated issues
-
Focusing on the subject of the change initiative (in our example, we would
focus on the current system)
In
considering things from a functional perspective, all can still contribute.
Those who are not in the function "under spotlight" are able to contribute their
observations "from the outside," If this approach is taken, it is most effective
if the functional focus is at a reasonably high level to avoid minutiae. In
an evaluation project, we would look at areas such as sales and marketing, operations,
customer service, finance, etc.
If the approach is to go with the subject of the change initiative, then explore
a series of issues. In our example, these are likely to include:
-
What are the strengths of the current system?
-
What are the frustrations with the current system?
-
What improvement opportunities exist?
-
How is the business constrained by the current system?
-
How could a system support new business opportunities?
Again,
this part of the workshop is focused on gathering information, not on developing
solutions.
Potential Benefits
With
the benefit of all this information gathered, the group is ready to focus on
specific benefits that can be anticipated from the change initiative, in our
example, the implementation of a new enterprise application system.
It
is important to get a good understanding of what the group means by each benefit
and then to agree on a statement for each and prioritize them.
In
some instances, we have agreed a series of benefits (e.g. reduce costs, improve
revenues, reduce risk, improve customer satisfaction, improve productivity,
improve employee satisfaction) and created some specific business drivers that
were the central theme of the case for action. In this case, the business driver
(e.g., manage the supply chain more effectively) was considered from the perspective
of each potential benefit.
Alternatively, the benefits can be expressed as the issue to be resolved (e.g.,
the awkward user interface and lack of documentation repels casual and new users)
or the benefit to be achieved (e.g., access to timely, accurate costing information
will facilitate better decision making and closer management of the business,
resulting in a direct bottom line improvement).
The approach taken to presenting these benefits is largely dependent on the
group and what is comfortable for them.
Benefits Drill Down
The culmination of the workshop is the benefits drill down. This provides the
"meat on the bones" that helps in communication of the case for action. To do
this, we look at the benefit or issue as it currently is and how it will be,
helping the audience to visualise and experience the difference. We identify
characteristics of the benefits, what will enable achievement of this benefits
and relevant risks.
Putting It Together
After the workshop, a document is created to communicate the thoughts of the
workshop team. We generally prepare it using MS PowerPoint, to appeal to a broader
range of people than a potentially dry MS Word document. Good practice involves
creating the document and seeking feedback from the workshop participants before
publication.
Communicating the Case for Action
Having
created the document, its power is when it is used as a tool to mobilize change
across the organization.
The
first step is to provide a copy of the published document to each workshop participant.
If the workshop has been successful, the participants will have become enthused
about the potential of the change initiative. Provide them with the collateral
to allow them to share their enthusiasm with their work colleagues.
Actively
share the information further across the organization through a "roadshow".
The most effective one of these that we have been involved in had the project
sponsor presenting interactively with staff in an interstate branch. Instead
of a dry presentation, the project sponsor reviewed the business strategy, seeking
opinions and contributions from the staff and then progressed to building the
case for the implementation project. The document itself was supporting material
handed out after the session.
This
stage, communication, is the most important of all. Most people recall only
minimal amounts of what they hear. Don't expect that because you send them a
document that they read it, understood it, and remembered it! Some say that
it takes hearing a message seven times for it to sink in. The bottom line is
that you should continue to communicate your message and when you think it's
been communicated well enough, start again!
Different
people respond to different communication media. For some, a formal presentation
is suitable, for others an interactive presentation works best, and still others
prefer to read. A printed document is good for some, an e-mail gets the attention
of others and some are happy to find their own information on the company intranet.
The learning is to provide the information in many ways and to remind people
where it is and how they can access it.
Keeping the Case for Action Current
A
final word on the case for action. It is intended as a living document, to be
updated and referenced by the business and the project team. In the case of
a software project, once a vendor has been determined, the case for action should
be reviewed in conjunction with the vendor to make it more specific to the vendor's
offering. The case for action should be referenced during the implementation
to ensure that the focus and anticipated outcomes are still on track. After
implementation, it is a tool to use to assess the success of the project.
About the Author
Bronwyn
Evans has worked in the IT industry for over twenty years, working
with vendors and in IT management roles. Most recently, she is a principal at
Tethys Consulting and has authored the Software Evaluation Methodology, a step
by step approach to enterprise software evaluation. Contact Tethys Consulting
on +61 2 9416 0423 or via info@tethys.com.au.
For more information, please refer to www.tethys.com.au