Skip to main content

Building the Business Case

Written by Cynthia Low on . Posted in Articles.

What Is a Business Case?

Business cases are arguments for or against making a specific decision based on economic considerations. They are tools for decision-making. A business case describes the economic consequences of a business decision and makes a recommendation.

An Issue of Economics

Business cases are focused on financial issues. The term “case” refers to an argument. The term business implies that the considerations are economic rather than something like legal or moral. The arguments for or against a decision revolve around cash flow projections. These projections model (forecast) the financial results associated with a recommended action or investment.

In order to be convincing, the assumptions, rationale, and data used to make the cash flow projections (forecasts) must be fully explained and be believable by the target audience. Economic impact is measured using financial metrics. The metrics that are used differ between business cases. The core consideration is discounted cash flows which are used to determine payback period, net present value, and internal rate of return.

Building a Case

One can think of business cases as being similar to court cases. The objective is to present information so as to create a convincing and compelling case for the recommendation that follows. Like lawyers presenting a case in a courtroom, authors of business cases have tremendous flexibility in how information is presented. As with legal cases, business cases must tell a story that demonstrates clear logic, supported by facts, evidence, and sound reasoning.

Ingredients of a Business Case

Well-crafted business cases have a number of essential ingredients. Authors have flexibility in how these ingredients are presented, but must ensure that each broad category of information listed below is included. The more effectively each of these subject is addressed, the better the business case.

  • Title page
  • Forecasts
  • Methods
  • Executive summary
  • Conclusions
  • Assumptions
  • Introduction
  • Recommendations
  • Sensitivity analysis
  • Disclaimer
  • Reasoning
  • Risk analysis
  • Metrics used
  • Actions and next steps
  • Appendices

Title Page

The title must be descriptive. It should identify the nature of the analysis and the decision under consideration. Subtitles are meant to add clarity to the main title. They explain the context of the decision in terms of dates, data, or other considerations. The title page must include the authors, their qualifications and the distribution list. Be as specific as possible. Include titles and names of committees and chairpersons, or even members of the committee. Anyone picking up a business case should understand who the intended audience is.

A business case should never be anonymous. Receiving an anonymous business case would be like receiving an anonymous stock tip: there is no way to judge its validity. The credibility of a business case is completely dependent on the credibility of the author.

Dates

A lot of time-related information is included in a business case. Data goes stale. In order for the audience to understand the relevance of a business case, it must include:

  •  The date of original completion (when analysis ended)
  •  The latest revision date

Within the document, be sure to include reference dates on data used in the analysis. Sales patterns that are five years out of date may not be considered relevant to the reader, even though the author chose to include them.

Executive Summary

The executive summary is what most people read first and is the only thing that many people will read. The executive summary tells readers whether the information in the report is worth their time. It deserves careful crafting.

The executive summary gives the essence of a business case in a few terse sentences. It serves as a proposition (recommendation to act) that is supported, or justified, by the contents of the business case.

The executive summary is a summary of the report. It tells the reader the document’s purpose: what will be proposed, what information is presented, and what action is expected from the reader. And all this is, of course, from the perspective of the author. The executive summary should include both a verbal description and numerical information summarizing high level metrics (return on investment statistics) that support the recommendation. Although an executive summary appears first, you always write it last, after you know which recommendation the analysis supports.

Introduction

Business cases must begin by being put in context. It is necessary to explicitly describe what the case is about and why it is being undertaken.

The introduction must include a reference to the subject and purpose of the business case, as well as a brief background. After reading the introduction, the audience should understand the scope and objectives behind the decision under discussion. The subject or purpose of a business case must be presented in terms of business objectives, that is, with reference to business outcomes that follow from the decision being proposed.

Disclaimer

Disclaimers are a little bit like confessions. The longer you delay them, the less valuable they are. If a business case is being presented to an audience outside your company, then a disclaimer of some kind is a good idea. Use wording recommended by a lawyer. Include the disclaimer near the beginning of the business case, on its own page. Do not hide it.

Metrics Used

Explain early in the presentation which metrics will be used to judge results, and why. If, for example, the deciding organization’s hurdle rate for investment is an internal rate of return of 25 percent or a 3-year payback period, it is important to state this at the outset. Let the readers know why the analysis is focused toward these metrics.

Forecasts

The executive summary warns the reader of what to expect. The forecasts section outlines the principal data used to come to the recommendation given. This is where many readers start their reading; it is where the justification for a recommendation is revealed.

Cash Flow Analysis

The heart of a business case is the cash flow analysis. This analysis models the projected inflows and outflows of benefits, which are quantified in terms of dollar values.

Cash flow projections are created for each scenario under discussion. It is not necessary to include reams of data. Include a chart only for the most likely scenarios; include only the summary statistics for the remainder of your analysis.

When preparing a cash flow analysis, it is necessary to provide a reference point. The “business as usual” or “no decision” scenario is used as a base case. Cash flows in other scenarios are then compared to the base case.

Financial Metrics

Cash flow analyses lead to a series of net cash flows. These net cash flows are then used to determine a variety of metrics that relate to performance. It is through these measures that it is possible for readers to judge the merits of each scenario relative to standards established by the company, or to the results of other investment decisions being considered.

Non-Financial Results

Business cases are all about numbers. Any benefits that cannot be quantified in dollar terms are likely to be ignored or undervalued. It is best to assign a valuation to “soft benefits.” When that is not possible, these benefits must be included by way of descriptions. The descriptions should be in the context of tangible, business-related impacts that can be reasonably expected to occur. Non-financial benefits should be discussed at length in a section labeled as such and should be referred to in the executive summary and conclusions so as not to be overlooked.

Conclusions and Recommendations

A conclusions section is included when you are reporting on findings, but no specific follow-up action is required. Recommendations are presented when the reader is being asked to agree to or approve some form of action.

After reading the conclusions, the reader should understand your interpretation of the data and the significance of the results. After reading the recommendations, the reader should understand the plan of action proposed, why it is proposed, the benefits, and the specific actions required of the reader.

Make the recommendations as clear and concise as possible. You are asking the reader to do something; make sure there is no ambiguity about what the request involves.

In complex reports, it may be appropriate to have separate sections for conclusions and recommendations.

Reasoning

The reasoning section immediately follows the recommendations and provides justifications for the recommendations. This is the section that explains the logic behind your recommendations or conclusions. It details the separation between facts and reasonable assumptions. It might also be referred to as “rationale” or “key findings.”

The reasoning section is the persuasive part of a report. It explains in simple terms why the author is right. There should be three to five key points. More than five key points is too many, and fewer than three suggests a degree of uncertainty on your part. Each point needs to be a narrowly focused aspect of your rationale, and it should comprise a sentence or two.

Organize your points in descending order, with the most significant first. Do not smother your message in numbers. Simple graphics (charts and tables) are helpful, but complexity is not. Summarize everything and put the data and complex information in appendices that the reader can refer to if desired. All material appended to a report should be referred to, at least once, within the document. If information has not been referred to, it is not needed to support the body of the report and can be eliminated.

Actions and Next Steps

In the action section, steps are outlined that will be followed if the plan or recommendation in the report is approved. The reader has been asked to agree to some activity, and this section explains exactly what the immediate response will be. Action sections are typically written in point form, in order of sequence. Each activity, or step to be taken, is described in terms of timing, people, and method.

Data and Approach

Readers must know how data was developed. If data has been extracted from another source, this must be explained. When data has been generated by assumptions, explain how and why. Be especially clear in describing the methods used to assign values to soft benefits. Let the reader know your reasoning.

Additional Information

Sometimes you just need to include more information or explanations than can be included in the body of the report. The “additional information” section is the place to include this extra information. The beauty of the additional information section is that it allows the author to include less detail in earlier sections of a report. If a recommendation does not make sense, and the reasoning section does not adequately

explain it, then the additional information section will. It is all part of the pyramid of information – the most important and briefest at the top with more and more detail as you move toward the bottom of the pyramid.

Scope

The boundaries of analysis should be clearly stated. If the analysis considers data from only one operation, or one segment of a complex organization, this needs to be explained. There are always limits to the data included in an analysis. Explain what the boundaries are. What information was included, what was not, and why?

Assumptions

With business cases, numbers (metrics) tell the story. How the numbers were derived is critical to the credibility and persuasiveness of the case presented. In the assumptions and approach section, readers are given an unambiguous explanation of the background of the numbers. When making predictions on such things as sales patterns and expense streams, it is best to follow accepted practice. If other business cases have been approved by the same decision-makers, then use the same type of assumption when making your cash flow projections. Simplifications are almost always necessary. Make them logical and their implications apparent.

Soft Benefits

Business cases are all about numbers. However, in many situations the benefits of a decision are not limited to easily-measured financial gains. In the case of soft benefits, it is necessary to assign values to the soft benefits and include a detailed explanation of the methods and reasoning employed.

Valuation of intangibles is difficult at the best of times. Before including intangible valuations in a business case, get agreement with the readers. Find out from the audience what they consider to be an acceptable method for assigning values. Doing this first can save a lot of time.

Sensitivity Analysis

Business case scenarios are financial stories. They are like a movie that has a number of different endings. The business case creates a financial model that tells a story (illustrated by a cash flow forecast). Scenarios are different endings (outcomes). Each scenario represents a particular set of assumptions and provides a prediction of the impact of those assumptions. The tendency of authors is to include too many scenarios. Readers are much less familiar with the subject matter than the author and cannot digest more than three or four variations. Choose the most illustrative.

A common mistake made in business cases is to omit the “business as usual” scenario.

This is the baseline case that serves as a reference for doing nothing. It is an important part of putting the implications of various decisions into perspective.

Risk Analysis

Risk analysis is all about “what if.” Projections are used to predict the financial implications of various decisions based on assumptions of what the outcomes will be. What if those assumptions are not correct? What is the worst case scenario? What is the best-case scenario? How likely are the projections to be correct?

Within a business case, only a few separate scenarios can be discussed. However, in deciding which to present the author will have studied dozens of scenarios as part of the process of sensitivity analysis. In sensitivity analysis, variables are adjusted up and down to simulate the effect of changes in assumptions for such things as sales and costs of goods sold. The effect of adjusting one variable at a time is related to financial

results. Through these simulations, the analyst is able to determine what the major factors are in relation to the financial results. For instance, the cost of capital goods might increase by 100 percent from predicted and have only a one-percent effect on the rate of return. However, a five-percent increase in labor costs might have a 20-percent effect on the rate of return. Clearly, labor costs are a major factor, while capital goods are not. All the major factors deserve special attention. The discussion of risk centers on an analysis of how robust the predictions are for those major factors that have the greatest potential to affect overall success.

Risk Discussion

Every proposal carries risk. A business document is not complete without a discussion of uncertainties. The obvious risks do not need to be addressed, such as the loss of the whole investment, should the entire plan fail. Instead, include only a limited number of significant risks. Include those that may have a significant impact, have a high degree of probability, or are unusual and may not be immediately obvious to the reader. When describing the risks, it is important to explain how the risk has been quantified (given a sense of magnitude) and what measures are possible to eliminate the risk.

Significant risks should be discussed in terms of their impact on the project. What is the worst-case scenario if the risk comes to fruition? What is the worst that might happen?

The worst-case scenario is the downside. It is considered unlikely that these events will occur, but not inconceivable. They are presumed to have less than a 10 percent chance of occurring. The best case scenario is the upside. This is the best that can be hoped for. It is presumed to have a 10 percent chance of occurring: unlikely, but possible. The most likely event is the reference point that the author uses in general discussion. It is the best forecast that the author can offer about what will occur. The most likely scenario is presumed to have a 50 percent probability of occurring.

Appendices

Supporting data and analyses that have led to the recommendation or conclusion are made available through appendices. Do not include materials just to make a report look more significant. Only information that has been referred to within the main report should be included in the appendices. Each type of datum should be separated and labeled within the appendices. Think of sections in the appendices as chapters of background information. Arrange them in a comprehensive order that relates to the body of the report.

Presentation Style

Reports are written in terse business style. Reports should use short sentences, small words, and tiny paragraphs. Many authors get bogged down writing reports because they try to link sections and paragraphs with descriptive prose. Do not bother. It is perfectly acceptable to use point form anywhere and everywhere. Business reports are not poems.

Another common mistake made by authors of reports is to write one featureless paragraph after another. No one likes to read page after page of black text. Mix it up.

Every page should have at least three headings. Use bulleted lists instead of paragraphs to make the material more visually interesting. Be consistent with heading styles. Make sure that the same pattern is maintained throughout the document.

Writing Style

Be realistic, but sound optimistic. An upbeat report is much more pleasant to read than a deadpan treatise. Use the active voice. It reads better. (A passive voice version of the previous paragraph is: An active voice is the preferred style. Many people prefer to read it). Try to be gender-neutral. Do not assume that the audience is male, female, or indifferent to issues of sexual nuance.

As a matter of practicality, be sure to number pages and to include the title and author’s name on every page by way of headers or footers. If the report is dropped, or taken apart by the reader, make sure it can easily be put back together.

What Goes Wrong?

There are two ways that business cases can go wrong. One is for them not to be funded.

The other is for a case to be funded when it should not have been. Both are bad news.

The key to quality is practice. Companies with a long history of preparing and appraising investment proposals have a far better track record than novice investors.

Experience provides standards of accepted practices. It is not that these practices necessarily represent the ideal approach to preparing business cases, but rather that they allow separate cases to be judged against each other. Standards allow an organization to gain experience. Without standards, each business case is an experiment in creative writing. With standards, business cases can

be compared side by side. A problem that caused the failure of one investment can then be used to highlight potential problems in another proposed investment.

Experience teaches investors to be wary of certain kinds of assumptions. Standards in the analysis of business cases allow the implications of those assumptions to be highlighted.

Conclusion

To be effective, business cases must meet the decision-making needs of the audience for which they are intended. There are common ingredients in all business cases; however, the weight and emphasis of the various components depends on the target audience and their particular preferences.

If you do not know what the target audience wants or needs to make a decision, then ask them. Guessing can waste a lot of time. State your arguments in the context of metrics and considerations that the audience considers important. The core of all business cases is net cash flows and the statistics related to them.

Emphasize Economics.

You may feel that network dependability is a critical consideration but the audience may be concerned only about market share. If you cannot explain your concerns in relationship to what the decision-makers consider important (such as how network dependability affects market share), your business case will not be approved.

Remember that a business case is an argument based on economics. Plan what argument you are going to make and then support it with data.

Write in a Pyramid

Business writing does not follow the rules of literary writing. Do not save anything for the end. Write in a pyramid with the most important information (concisely presented) first. After that comes all the supporting details in descending order and increasing volume.

A well-written business case makes the best use of the reader’s time by providing targeted information and by making that information easy to find. Good luck! 

Brian Egan is the President and owner of a giftware manufacturing company. The Book Box Company Inc is the world’s largest manufacturer of hollow-book gift products.

Brian has graduate degrees in Oceanography (MSc) and Finance (MBA) as well as PMP certification. In addition to professional development training, Brian provides project management services to companies wanting to improve their performance by incorporating the best of management science methodologies into their operations.

Brian lives with his wife and four children in rural British Columbia. Global Knowledge is the worldwide leader in IT and business training. More than 700 courses span foundational and specialized training and certifications. For more information, visit www.globalknowledge.com

Glossary

Disclaimer: An explanation about the limitations to information contained in a document; a warning that a business case involves an unpredictable forecast of future outcomes

Financial metrics: Performance measure used to determine the costs and benefits of an investment option

Non-financial results: Also known as soft benefits; benefits gained from an investment that cannot be put into strictly financial terms, such as employee satisfaction

 Assumptions: Simplifications used to help predict future outcomes of a business investment; include such statements as “labor rates will remain effectively unchanged throughout the forecast period”

Risk analysis: A review of what might prevent the predicted outcome for an investment from coming true

Copyright ©2008 Global Knowledge Training LLC. All rights reserved.

The Lost Art of Business Technology

Written by Cynthia Low on . Posted in Articles. 1 Comment on The Lost Art of Business Technology

The importance of technology architecture, that is the relationship which exists between hardware and software used to produce the end result desired, continues to elude the 21st century company. This is unfortunate, as it is a fact that the proper implementation of technology architecture can help business skate over the new and extremely challenging dynamics, such as cost cutting, global demand, and the fierce competition we all face.

Unfortunately, somewhere along the way, architecture has been, for the most part, completely overlooked, underappreciated or even entirely misunderstood by those companies most in need of the discipline which results from its implementation. Furthermore, because of their lack of understanding of its merits and purpose, some companies actually overspend on technology architecture rather than spend wisely.

From the perspective of a skilled craftsman in architecture, the typical ‘troubled company’ is one which states upfront that, for example, it is considering ‘virtualization,’ with its resultant need for an infrastructure plan.

Before adding new infrastructure to achieve its goal, however, a company should ask itself: have we taken all of the necessary steps to ensure we implement the new infrastructure in a way to minimize the need for new software? Can we collapse systems we no longer need for prime-time operations?

This is where the value of technology architecture comes in, but unfortunately has not been embraced by the technology sector.

Of course, in some cases, the problem lies in the fact that some of those who call themselves architects are very vendor specific, and we can argue that they are not architects at all. A core value of being an architect lies in being ‘agnostic,’ that is, embracing any vendor and product set as long as it matches the needs of the business. The last thing we need is three different databases and three database administrators, each trained specifically in a particular vendor’s product. And, let’s not forget that the aim is to actually deliver on tangible, measurable, and realistic metrics, and not just wishy-washy ROI.

My experience is that companies will often spend capital and operational budgets to solve each problem individually, with the result that, before long, the infrastructure is three times what is required.

The benefits of technology architecture are wide reaching, and measurable. For example, the utilization of an architecture roadmap keeps businesses better informed on IT progress, or at least its goals and priorities. As well, risk identification and aversion and the ability to become agile when a critical business need erupts are very much the goal of architecture.

Architecture achieves its goal by linking definitive information in an accurate and timely fashion. Now, when you define a business problem and approach outside vendors for the solution, you will have dramatically reduced costs, even eliminated them outright, because you made the effort to inventory, document and control your infrastructure. Again, when you want to integrate a number of disparate systems, your roadmap will radically lessen the time it takes for implementation.

It is time for businesses to take a more serious look at technology architecture. CIOs and CFOs should seriously consider empowering technology architects with the authority to match their responsibility and lay out the expectations and guidelines they require to measure the benefits expected.

There is an impression, however, held by many in business, that architects are Ivory-Tower dwellers, dictating technical direction. It is important that architects acquire business acumen, and respect the demands, challenges, and budgetary constraints of the business. Architects must be on-side and in tune to each development within the business, whether marketing, sales, products/services, or other areas. Finally, they must remain ‘agnostic’ for the sake of both the profession and the business they represent

Long gone are the days of technology being about the sizzle . . . it’s now all about the steak! Long gone are the days where we implemented a technology for the sake of the spin. Businesses now demand solutions linked directly and accurately to their true problems. They also expect them to work as advertised, on budget and as planned. It is technology architecture that will ensure businesses no longer spend for the sake of spending.

Roger Glasel is a technical and executive architect with Syscom Consulting (www.syscom-consulting.com), Telus Communications in Vancouver, British Columbia.

The Change Management Life Cycle; Involve Your People to Ensure Success

Written by Cynthia Low on . Posted in Articles.

Every organization is affected by change. Still, organizational change initiatives fail at an alarming rate. This is because most initiatives fail to consider how changes affect the people in an organization.

To successfully implement change initiatives, organizational leaders must identify the need for change and communicate it throughout the organization. They must also engage people at all levels of the organization by involving them in the design of the implementation strategy. Lastly, leaders must actively involve the people most affected by the change in its implementation. This will help ensure employees at all levels of the organization embrace the proposed changes.

This article introduces a three-phase Organizational Change Management Life Cycle methodology (Identify, Engage, Implement) designed to help organizations successfully manage a change initiative. For each phase of the life cycle, the article describes valuable techniques for involving the people within an organization. It also discusses the importance of developing a flexible, incremental implementation plan.

Introduction

The statistics are undeniable-most organizations fail at change management. According to the Wharton School of the University of Pennsylvania Executive Education Program on Leading Organizational Change, “researchers estimate that only about 20 to 50 percent of major corporate reengineering projects at Fortune 1000 companies have been successful. Mergers and acquisitions fail between 40 to 80 percent of the time.” Further, they estimate that “10 to 30 percent of companies successfully implement their strategic plans.” (Leading Organizational Change Course Page).

Why do organizations have such a poor track record of managing change? According to the Wharton School, the primary reason is “people issues” (Leading Organizational Change Course Page).

The consulting firm PriceWaterhouseCoopers supports that finding. In a study entitled How to Build an Agile Foundation for Change, PriceWaterhouseCoopers’ authors noted, “research shows that nearly 75 percent of all organizational change programs fail, not because leadership didn’t adequately address infrastructure, process, or IT issues, but because they didn’t create the necessary groundswell of support among employees”

Without understanding the dynamics of the human transition in organizational change, change initiatives have a slim chance of success. If organizations, whether private or public, cannot change and adapt, they will not thrive or worse, they may not survive in today’s dynamic environment.

This article looks at the critical role that people play in the three phases of the
Organizational Change Management Life Cycle-Identify, Engage, Implement-and offers guidance on how organizations can minimize “people issues” during change initiatives.

Why Change?

Today’s business environment requires continuous improvement of business processes that affect productivity and profitability. This, in turn, requires organizations be open to and ready for change. Some of the common drivers of change include:

  • Adjusting to shifting economic conditions
  • Adjusting to the changing landscape of the marketplace
  • Complying with governmental regulations and guidelines
  • Meeting clients needs
  • Taking advantage of new technology
  • Addressing employee suggestions for improvements

Organizational changes happen regardless of economic pendulum swings. In an economic upswing, for example, organizations examine different ways to extend their capabilities to maximize previously untapped revenue streams and look for new opportunities for greater profitability. Conversely, an economic downturn or recession creates the need for more streamlined business processes within an organization, and a right-sized staff to implement those processes.

The Elements of Change

In every organization, regardless of industry or size, there are three organizational elements that both drive change and are affected by change:

  • Processes
  • Technology
  • People

Technology supports the processes designed to respond to changes in market conditions. Ultimately, however, it is the people who must leverage these processes and technology for the benefit of the organization.

Let’s look briefly at how each of these elements is affected by organizational change.

Process

Business processes are defined by process maps, polices and procedures, and business rules that describe how work gets done. These processes are redesigned or realigned as new prospective customers or better ways to provide service to existing customers (both internal and external to the organization) are identified. This drives the adoption of new technology.

Technology

Technology ensures greater organizational efficiency in implementing the changes. It is a means to process data with greater accuracy, dependability and speed. Therefore, essential to any change process is a plan for introducing and systematizing the technology required to execute the intended changes.

People

Generally, organizations excel at designing new or improving existing processes. They also do well at identifying or developing technology to realize the power of new processes. However, most organizations fail to focus sufficient attention on the role people play in the processes and technology used to accomplish the desired organizational change.

As noted in the introduction to this paper, the overwhelming percentage of organizational change efforts fail because people are not sufficiently considered at the outset of the initiative. It is the people within an organization, after all, who are responsible for developing and implementing new processes, which will in turn require new technology. It is also the people who must specify, recommend, purchase and use the new technology.

At the most basic level, people must acknowledge and buy into the need for change. An organization cannot even begin to introduce change unless its people understand and support the reasons driving the change. This acceptance of change is known as the first step in human transition.

The Change Management Life Cycle

Change management is a cyclic process, as an organization will always encounter the need for change. There are three phases in the Organizational Change Management Life Cycle (Figure 1): Identify, Engage and Implement.

The elements of change (processes, technology and people) and the phases of the Organizational Change Management Life Cycle are closely linked, and their intersection points must be carefully considered. By paying close attention to how people are engaged in each phase, an organization can manage that change to adapt to any business or economic condition.

Phase 1: Identify the Change

In the Identify stage, someone within an organization-typically a senior executive spearheads an initiative to change a current process. A single voice at a very high level is often the first step in establishing the need for change. This need is then presented to the organization with a general description of the current state of affairs, offset by a high-level vision of the desired future state.

While it seems obvious, identifying the change is an absolutely fundamental first step in successful change adoption. It is important that the changed condition be described in a common, consistent language. However, organizations often fail to identify and communicate the need for change in a way that is understood and embraced by people working at all levels of an organization-from the executive suite to the individual workstation. Many leaders do not adequately consider how a proposed change (or even the rumor of one) may be received-at an intellectual, emotional and neurological level-by the people it will impact the most.

The Neurological Roots of Resistance to Change

The prevailing contemporary research confirms that, while change is personal and emotional, it is neurological as well. Here’s what researchers now know about the physiological/neurological response that occurs when an individual encounters change:

  1. A new condition (a change) is created, introduced and transmitted.
  2. The pre-frontal cortex region of the brain receives the transmission through one or more of the physical senses.
  3. The pre-frontal cortex compares the new condition to the current condition by accessing another region of the brain, the basal ganglia, which stores the data we receive and contains the wiring for the habits we have.
  4. If a difference between the new condition and the existing condition is detected, an “error” signal is produced and sent throughout the brain.
  5. The “error” signal is received by the amygdala, the prehistoric part of the brain that tells us to be wary of a saber-toothed tiger.
  6. The amygdala places a value to the changed condition and sounds an alarm, producing the emotion of fear.
  7. The pre-frontal cortex receives the fear signal from the amygdala and creates what it believes to be a necessary response.
  8. The new condition is resisted by the pre-frontal cortex and, by extension, the person.

(Schwartz and Rock, 71-80)

If the disturbance that is produced by a change isn’t adequately addressed through some alignment intervention, this resistance to change is prolonged and can be damaging to the change initiative.

To ensure successful change, organizations should introduce a change effort during the
Identify stage using the following techniques:

Get Their Attention: Since change is disturbing and distracting to human beings, it’s important to get their attention about the change. Getting people out of their daily routines-at an off-site location, if possible-helps them create a shared sense of urgency for change and concentrate on the change message, thereby internalizing it more deeply.

Align Their Disturbances: Neurologically speaking a disturbance is a conflict between a person’s current mental model (the way they think about something) and the mental map needed to operate in a changed state. To align disturbances means to create a common disturbance among the minds of the people in the organization-to create agreement between the gap that people have between their individual current mental model and the mental model needed to operate in a changed state. When these gaps aren’t in alignment, everybody will respond to the change differently, and won’t be able to agree on the direction and intent of the organizational response needed. An important technique for aligning the potentially broad spectrum of disturbances is for leaders to craft and continually communicate a compelling vision of what the future will look like when the change is implemented.

The best way for leaders to make a compelling case for change is to consider the need for change at every level in the organization, not just at the top tier. The top-level need for change is almost always driven by bottom-line goals, and does not touch the day-to-day work experience of the organization’s staff.

For instance, a financially oriented statement, such as “our organization must realize a
20 percent reduction in operating expenses” will likely be met with fear, uncertainty and skepticism in some levels of the organization, and with ambivalence and apathy in other levels. Ultimately, it is imperative to align these varying disturbances with a clarifying vision.

Some additional people-related items to consider when identifying change opportunities include:

  • Possible frustrations in performing (new) work
  • Clear job definitions
  • Job definitions and metrics that match the process
  • Understanding of the end-to-end process
  • Cultural dynamics within the organization that may inhibit people from moving to a new, changed state
  • Life Cycle

Phase 2: Engage the People

Once the need for change has been identified and communicated, the next critical step is to engage people in planning for the organization’s response to the change. Successive levels of the organization must be included in a dialogue to help design an implementation plan. People within an organization must be allowed an opportunity for intellectual, emotional and psychological reaction to the desired change. Providing this opportunity enables people to become accustomed to the idea of change and to align their thinking in ways that will help both identify potential problem areas and contribute substantively to process improvement.

Consider this example: In a recent process change effort, an external consultant developed a new process, down to a very detailed level (with little input from the organization, and many requirements from executives), and proudly handed over the process design and documentation to the team responsible for implementing the new process.

The results were not surprising. The user team passively accepted the process, then aggressively refused to implement it. The user team had neither the energy nor the enthusiasm to implement something in which it had no emotional buy-in. In fact, team members told executives in the project post-mortem that they actively sabotaged the new process because “the consultants developed the process, even though we are the experts.”

Insights-The Antidote to Resistance to Change

An important contribution of modern neuroscience to helping us be more effective as leaders concerns the phenomenon of insights-sometimes called an epiphany or an “ah ha” moment. Here’s how insights help overcome resistance to change:

  • During change, the disturbance an individual feels is produced by competing mental models (a conflict between various parts of the brain).
  • Individuals can either allow the conflict to continue, producing resistance to change (the old model wins out over the new model), or they can take active steps to move past the dilemma.
  • If individuals (or their leaders) choose to move beyond resistance, reflection-quieting external stimuli and using the unconscious brain-will help prepare them for insights.
  • When an insight occurs, new neural connections are made across the brain and adrenaline is released, producing a surge of energy. This energy creates the momentum to overcome the resistance circuit, and allows an individual to commit more readily to change.

(Rock, 105-107)

General George Patton of the U.S. Army is quoted as saying, “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” Wise leaders know that successful change adoption depends on engaging the hearts and minds, as well as the bodies, of the people facing a changed condition. Organizational leaders need to engage the energy and enthusiasm that comes from people having their own insights, for this is where true commitment to change comes from, and where the ownership of results are truly developed (Koch).

One technique to encourage people’s adoption of a change is to conduct organization-wide response/adoption alignment workshops. When practiced effectively, these sessions allow people to contribute their own ideas about how a deliverable should be used within the organization. Once these contributions are aligned-through multi-party conversations (where much thrashing may occur!)-an aligned approach for managing and adapting to the change will emerge.

When reactions have been aligned and individuals within an organization are asked to be involved in responding to change, typical human behavior moves to addressing the problem-creating a desired direction to facilitate change.

The implementation strategy for responding to the change is then developed at a high level. The people who will be executing the strategy, as well as the people who will be impacted by the strategy, should be included in the strategy development. This high-level strategy is important for aligning and clarifying the intent of the change, as well as for establishing a direction that the change implementation will take. The strategy needs to be seen by all as a flexible plan so that the organization can adapt to changing conditions once implementation of the strategy is initiated.

Phase 3: Implement the Change

In the Implement phase, change strategies developed during the Identify and Engage phases are translated into tactics, or actions, for moving toward the desired future organizational state. Here again, people are critical of how processes and technology are created and implemented. They have direct, daily experience with these processes and technology and, consequently, they are most knowledgeable about how these components must be customized for the best results.

Most organizational change failures occur because insufficient time and attention was given to the first two phases of the life cycle: Identify and Engage. On the other hand, most organizations spend the majority of their time, effort and attention here, in the Implement phase. But, as we’ve already discussed, without the proper alignment of people’s disturbances and their response to a changed condition, successful adoption rarely occurs.

During implementation, employees throughout the organization need to remember why they are working so hard on implementing a change. Therefore, change leaders should continually remind people, using multiple media (formal e-mails, progress celebrations, informal conversations) what the change is and why it is so important.

Additionally, organizational leaders should ask themselves the following people-related questions to help ensure successful implementation:

  • Does the individual have the ability or desire to work in the new environment?
  • Are additional skill sets needed to transition to the new job?
  • Are changes to job descriptions needed?
  • Are job grades or pay impacted by this change?
  • Does the change impact short-term productivity? If so, will additional support be needed to ensure business success?

If organizations successfully complete the first two phases in the change management life cycle, the implementation phase becomes essentially a monitoring activity for leaders.
They should assure that:

  • Change-oriented tasks are being accomplished as planned
  • Energy and enthusiasm are present
  • Alignment still exists among the people

Prototyping: A Fluid Implementation Strategy

As previously noted, for change efforts to be successful, the implementation strategies must be fluid. Instead of a grand plan, sufficient flexibility in process and execution tactics must exist to respond to shifting circumstances such as market or business conditions. These mid-course corrections often take the form of rapid prototyping or alternative responses to “what-if” scenarios-considerations that are not typically included in a detailed master plan.

Prototyping monitors the thinking and activities of people-both users and implementers-as processes and technology are put into action. Its purpose during the implementation phase is to help organizations avoid getting mired in highly detailed plans that have the potential to stall change efforts.

Essentially, prototyping is another way to get people involved in the change as opposed to being recipients of the change. It gets the change underway, in small increments, rather than waiting for the master plan to be identified. Prototyping is critical to successful change management. It is virtually impossible to plan for all contingencies in the development of an overarching strategy and, yet, any successful strategy for change must be able to accommodate unforeseen challenges.

The benefits of prototyping can be seen at every level within an organization. Executives benefit from a greater likelihood of adopting change (through incremental buy-in), while staff members benefit because, as a result of prototyping, the best approach will likely be used in implementing the change. Overall, an organization’s people will have greater ownership of the change because their insights, ideas and actions are used in building the response to the change.

At the very least, an organization should adhere to the spirit-if not the letter-of prototyping to ensure that the organization is adequately equipped to handle new developments and make adjustments on the fly.

Conclusion

At the highest level, business leaders are driven by financial goals and government leaders are driven by legislative mandates. Their urgent need to meet these objectives may lead them to impose change unilaterally, rather than engaging the people to find the best way to meet a more generally understandable desired future state.

Executives who neglect the human transition required in change management will be less successful at implementing change. Successful change management boils down to improving the relationships between people in the organization in the attainment of a mutually desirable end state. An organization that is too focused on objectives runs the risk of losing sight of personal relationships.

For a change initiative to be successful, an organization must understand and address the three phases of the Change Management Life Cycle-Identify, Engage and Implement.

Organizational leaders must ask themselves these questions:

  • Has the organization thoroughly identified and communicated the impending change?
    • Are disturbances acknowledged and aligned?
  • Has the organization engaged all of its stakeholders-at every level of the organization-in the change that will need to be adopted?
    • Is the intent and direction of this change aligned throughout the organization?
  • Has the organization developed a flexible plan for implementation that allows for prototyping to move continually toward the desired future state?
    • Are the organizational responses aligned and institutionalized?

The human transition that is required to move from a historically acceptable way of working to one that is completely new or radically different is not to be underestimated.
Good leaders will make the reasons for change personal for everyone, not just for executives or shareholders. End-user benefits, down to the day-to-day experience of the individual worker, will create a more receptive environment for fostering new ideas-and a receptive environment is essential to creating any lasting, positive change.

If an organization can answer “yes” to each of the questions above, chances are good that its change initiative will be a success.

To download a PDF of this and other white papers by ESI International, please visit www.esi-intl.com/whitepaper

Jonathan Gilbert, PMP, Executive Director of Client Solutions for ESI International, has more than 30 years of experience as entrepreneur, educator, chief executive officer, construction manager, management consultant, project manager and engineer. He earned his B.S. in Civil Engineering from the University of Maryland at College Park, concentrating in project/construction management and environmental engineering. For more information, visit www.esi-intl.com.

References

Koch, Christopher. “Change Management-Understanding the Science of Change.” CIO 15 September 2006. 20 June 2008 http://www.cio.com/article/24975/Change_Management_Understanding_the_Science_of_Change.

Leading Organizational Change Course Page. 2008. Wharton Executive Education, University of Pennsylvania. 20 October 2008 http://executiveeducation.wharton.upenn.edu/open-enrollment/leadership-development-programs/leadingorganizational-change-program.cfm.

PriceWaterhouseCoopers. How to Build an Agile Foundation for Change. February 2008.
20 October 2008 http://www.pwc.com/us/eng/advisory/agility_foundation_for_change.pdf.

Rock, David. Quiet Leadership. New York: HarperCollins, 2006. Schwartz, Jeffrey and David Rock. “The Neuroscience of Leadership.” Strategy + Business
June 2006: 71-80.
www.esi-intl.com

ITIL for BAs – Part X; BAs and ITIL Service Transition (continued)

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs – Part X; BAs and ITIL Service Transition (continued)

In our last post we began reviewing the Service Transition phase of the IT Service lifecycle, specifically looking at the first seven of 14 policies:

3.2.1 Define and implement a formal policy for Service Transition
3.2.2 Implement all changes to services through Service Transition
3.2.3 Adopt a common framework and standards, and
3.2.4 Maximize re-use of established processes and systems
3.2.5 Align Service Transition plans with the business needs
3.2.6 Establish and maintain relationships with stakeholders
3.2.7 Establish effective controls and disciplines

Without further ado, let’s look at the remaining seven, keeping in mind the business/IT relationship and how these policies ought to be supported by your BA practice:

3.2.8 Provide systems for knowledge transfer and decision support
Constant change, the iterative refinement of a solution, traceability, test and acceptance activities – all of these, and many others, are underpinned by the need for information. Organizations that rely on knowledge retained in contributors’ heads are at a serious disadvantage and introduce significant risk, delay, and probable loss of business value. Furthermore, the requirements management and solution design/development team should ensure that the operations/support teams are equipped with all relevant knowledge about the requirements and the solution.

3.2.9 Plan release and deployment packages
IT organizations rarely rely on a one-to-one relationship between a solution and a release. For the sake of efficiency, releases frequently comprise multiple solutions, or even parts of multiple solutions. Solution developers and testers are not necessarily familiar with the tools and processes used in the release process, so a smooth transition to operation depends in large part upon the release team’s ability to plan, test, and document a specific release plan that minimizes disruption to the business.

3.2.10 Anticipate and manage course corrections
“The best laid schemes o’ mice an’ men/Gang aft agley.” Managing variations gracefully is of course a cultural challenge. With the BA in the middle of it all, the BA practices are a significant driver behind the nurturing of such a culture.

3.2.11 Proactively manage resources across service transitions
In other words, be not passive in the formation of the release teams. Formulate teams from individuals who specialize in the risks, procedures, and skills needed for smooth transition. Every glitch in a transition to operation takes a chink out of the business value of that solution.

3.2.12 Ensure early involvement in the service lifecycle
This is a really great policy for, and admonition to, the IT organization. Especially in organizations with software development teams hosted by the lines of business (LOBs), there is a tendency for those teams to operate independently and then initiate transition with the shared services organization to implement a solution. To remedy this, it is really important for the IT team to take the IT Service Management message to those LOB development teams and work together early. (Similarly, it is important for the BA to stay involved with the solution through its entire lifecycle, rather than handing the requirements off to the project team and then moving on to a different requirements effort.)

3.2.13 Assure the quality of the new or changed service
This is such a core part of BA that not much comment needs to be added here.

3.2.14 Proactively improve quality during service transition
In other words, do not ignore incidents, problems and other deficiencies detected during transition activities. It’s easy to recognize the sense in this, but when push comes to shove and a release deadline is looming, this policy is frequently disregarded.

Hopefully this policy summary has adequately suggested that the BA/IT relationship can be greatly empowered through the development of and adherence to these policies, in order to drive desired business outcomes.

Next time we’ll look at the specific processes related to Service Transition.

Meanwhile, please leave your thoughts/comments: what does this all mean to you?

And thanks again for visiting!

Tools of the Trade Part II; Implementing a Requirements Management Tool

Written by Cynthia Low on . Posted in Articles.

Part one in this series described how to prepare, plan, and select a requirements management tool. Selecting the tool is usually the easy part. Implementing the tool without causing mass chaos brings a greater challenge. Now that a tool has been selected, what is the best way to gain acceptance and adoption of the tool within your organization? Change rarely comes without some resistance. This article will address how to maneuver through the resistance in order to successfully implement a requirements management tool by recruiting early adopters, marketing the tool, and communicating the change early and often. Finally, I will address some lessons learned while implementing a tool at several organizations.

Implement a Tool

Production is not the application of tools to materials, but logic to work.
~ Peter F. Drucker

Form a Team

Once the tool is purchased, implementation will take some planning, training, and mentoring in order to effectively rollout the tool. If you haven’t already, start with forming an implementation team. This team will represent the tool and its benefits to the greater IT department. The team will also help plan, create guidelines and best practices, and mentor analysts in their given departments.

Treat this implementation just like you would any other IT project. Start with a project plan, determine implementation tasks, and assign resources. Then execute on the plan.

Once the project plan is in place, get the team members completely trained and comfortable with the tool. At one organization we brought in the tool vendor to train the team members and a few key QA folks. We gave the vendor some samples of use cases from our own projects and utilized these as examples during the training. Team members then began using the tool on their own projects. As we met together we learned from our own experiences and utilized these experiences to draft best practice guidelines for the organization. Best practices included how to structure requirements within the tool, creating templates for different types of projects, naming conventions, and tips and tricks for some of the tool’s quirks.

Recruit Early Adopters

Once the team has established some guidelines and tested the tool out on their own projects, it is time to branch out. Find a few experienced analysts who are willing to be early adopters of the tool. Have team members train and mentor the early adopters on how to use the tool. Early adopters should then go through a complete project lifecycle while using the tool. Periodically touch base with early adopters to apply what they learned from their experience to the best practice guidelines. Also, gather feedback from the developers and QA team members on their perceptions of the tool. Since these groups typically consume the output of requirements gathering, they will need to accept the tool and perhaps adapt their work habits to accommodate a new method for managing requirements. Don’t underestimate this change!

Communicate Early and Often

As with any change, there will always be nay-sayers and skeptics. Implementing a requirements management tool will be no different. In fact, writing requirements in a tool rather than a Microsoft Word document requires a change in mindset. This change is easy for some to make and difficult for others. The implementation team can smooth this transition through communication. Hold forums where the tool is demonstrated, the benefits and limitations are discussed, and early adopters’ experiences are shared. Hold these forums on a regular basis so that teams are kept informed as to the progress, and reminded of the tools benefits.

Word-of-mouth advertising will go a long way to help encourage other analysts to adopt the tool. Have the early adopters talk about their experiences and spread the good news throughout their teams. After trying the tool on a few development projects, one early adopter expressed his enthusiasm for the tool stating “I want to write all of my requirements in this tool.” By trying the tool out on a few simpler projects, he became comfortable with the tool, its limitations, and saw the benefits gained from utilizing the tool. We harnessed his enthusiasm to help sell the tool during an analyst open forum. He also spread the word to his immediate team members and more people signed up to use the tool on their next project.

An Excuse to Celebrate

Finally, use the tool as an excuse for a party! At one organization, to gather excitement for the event, we hosted online trivia questions on our SharePoint site. We posted daily questions and the top five winners received gift certificates to the event establishment. At the event we re-iterated the benefits of the tool, provided links to training simulations, demonstrated examples of successful projects, and distributed the best practice guidelines. Once the formalities were complete, we broke out the entertainment and used the opportunity to socialize with our peers.

When it was all said and done, the tool implementation was really a non-event. There was no loud outcry, no grumbling amongst peers, no mass chaos, and no wasted money. We methodically went about our task of implementing the selected tool, sought help from our peers, and repeatedly delivered the same message throughout the organization which resulted in an easy transition to tool adoption. The complete process took about a year. We steadily increased user adoption during that year and by the time we held our event, most people had already begun using the tool. Compared with the previous implementation of a tool mentioned in part one, where little thought went into the needs of the user community, this tool implementation went off without a hitch.

Final Thoughts

Wisdom too often never comes, and so one ought not to reject it merely because it comes late.
~Felix Frankfurter

Despite the claims of many vendors, no tool is perfect. It is better to discover early on in the process the limitations of the requirements management tool. Once you know the limitations, devise a plan on how to work around the limitations and minimize the impact to your organization.

Test the performance of the application prior to purchasing. One of the biggest frustrations of a tool I have personally used is its inability to perform when multiple users are accessing the repository. Loading some projects will take 10 minutes or longer, while working in other projects completely freezes the tool. If at all possible, learn this before you buy! It will save you great frustration and keep analysts productive.

Never underestimate an employee’s need to resist change. It’s only natural. We all do it. Plan for it, accept it, and continue to communicate the benefits of the tool even when met with organizational resistance. Eventually people come around and the use of the tool will become a part of daily life within the organization.

Finally, learn from your experiences. Have an open mind and listen to the experiences of early adopters and implementation team members. Tout your successes and learn from your failures. Success will, undoubtedly, follow.

Renee Saint-Louis is a Senior Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years.