Author: Cynthia Low

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

Written by Cynthia Low on April 14, 2009. 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:

A new condition (a change) is created, introduced and transmitted.
The pre-frontal cortex region of the brain receives the transmission through one or more of the physical senses.
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.
If a difference between the new condition and the existing condition is detected, an “error” signal is produced and sent throughout the brain.
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.
The amygdala places a value to the changed condition and sounds an alarm, producing the emotion of fear.
The pre-frontal cortex receives the fear signal from the amygdala and creates what it believes to be a necessary response.
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

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

Written by Cynthia Low on April 14, 2009. 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.

Tools of the Trade Part 1; Selecting a Requirements Management Tool

Written by Cynthia Low on April 7, 2009. Posted in Articles.

Have you ever experienced this? Management attends a trade show and discovers the greatest requirements tool since the bread slicer. It will solve all your requirement issues and produce happy, satisfied business customers – or so the vendor claims. The manager purchases the tool and suddenly it’s your job to implement it throughout the organization. “Go forth and do great things.” your manager mandates. You walk away dumbfounded wondering, “Where do I go from here?” Experience tells you there is more to it than just purchasing the software; some analysis is necessary in order to successfully launch a new tool at your organization.

This two-part series describes a tried and true approach to selecting and implementing a new requirements management tool within an organization. Based on experience implementing tools at several organizations, this first article describes a method to successfully prepare, plan, and select a new requirements tool. Part two will describe how to successfully implement the selected tool as well as some lessons learned along the way.

Assess Tool Readiness

“Assessing is theory, facts, and art form.”
~ Jim Murphy

Through my years of experience I’ve seen the obsession some organizations have with implementing a tool in order to enforce a loose, poorly followed requirements gathering process – believing that a tool will solve all of the requirements management issues in an organization. However, if poorly implemented, a tool will only exacerbate a poor or non-existent process and wreak havoc on the organization.

As an example, one organization had little to no requirements processes in place. Management was determined to implement a tool in order to enforce a process across the organization. Elaborate rules and regulations were devised by teams of people who were not requirements practitioners. These rules did little but enforce the nomenclature utilized within the tool. Little thought went into the intent of capturing requirements, determining stakeholder goals and needs, and managing requirements over the development lifecycle. What ensued was mass chaos throughout the analyst organization. Analysts were angry at the need to capture requirements in the tool, saw little value in the process, and out-right refused to utilize the tool. The result: the use of the tool was discontinued. Thousands of dollars were wasted on license fees, training, and implementation. Analyst productivity declined and there was a feeling of ill-will throughout the organization!

Don’t let this happen to you! Before embarking upon a tool implementation, one should begin by understanding what is expected from the tool and then assess the organizational readiness for a tool. This can be as formal or informal as needed for your organization. The point is to actually look at your organization, determine why a tool is necessary, and asses the readiness for adopting a tool.

Know the Theory

First, have a clear understanding of what the expectations are of the tool and what problems your organization is looking to solve by purchasing a tool. It is a good idea to attack this project with the same analysis skills you would a typical IT project. Begin by writing the vision statement and problem statements. These will give you a clear direction for selecting a tool and guide the team when rolling out the tool across the organization. Some points to consider:

Determine what pain points you are trying to eliminate by implementing a tool. For example:
- Problem: Requirements are captured in disparate Word documents and continually change without stakeholders being alerted.
  Solution: Providing a repository to house all requirements
- Problem: Once a project is launched, requirements are difficult to find and rationales for requirements are often forgotten.
  Solution: Providing a tool which captures discussion, rationale, and decisions for project requirements.
- Problem: Projects are routinely launched with major re-work after the implementation due to poorly defined requirements.
  Solution: Providing a tool which illustrates requirements in a manner meaningful to stakeholders – through models, screen mock-ups, use cases etc.
Determine what goal the organization is trying to achieve by implementing a tool. For example:
- Reduce the amount of money spent on re-work after a project is installed by generating models and written use cases from screen mock-ups to aid in eliciting higher quality requirements from stakeholders.
- Increase speed to market by creating prototypes and generating requirements based on the prototype.
Document what the vendor has promised (if one has been selected for you).

Get the Facts

The next step is to assess the readiness of your organization. Consider not only how it will impact the analysts, but also the other stakeholders involved. Some points to consider when assessing your organization:

Is a tool necessary?
What impact will implementing a tool have on the organization?
What development methodology is utilized by analyst groups? Is it the same across the organization or do some follow waterfall while others follow agile development processes?
How mature is the requirements process across all analyst groups?
1. Are some stronger than others?
2. Are processes similar across groups?
3. How disparate are processes across groups?
Are there additional organizational changes occurring that may impact a successful tool implementation?
1. If so, what is the time frame for implementation? Will it interfere with a tool implementation?
What format are requirements typically gathered in? (e.g. Word document, Excel, e-mail, napkins, hallway conversations, dreams)
What is the maturity of the PM, Development, and QA organizations?
How will the stakeholders perceive the change? Are they open to receiving requirements in a new format? Will the process be seamless to them?

During this exercise, capture the risks and issues that may occur if a tool is implemented. Record the response to the risks and issues so that they may be resolved during the tool rollout.

Remember that a tool is exactly that – just a tool. Its implementation will have significant impact on the organization and any tool that is selected needs to be thoughtfully considered and carefully planned.

Based on your assessment, it may be necessary to recommend deferring the purchase of a tool until any process issues are shored up. It is fundamentally necessary to have solid requirements practices in place before implementing a tool. Get your facts in order and make recommendations on how to improve your processes before a tool is implemented. For example, if documenting requirements is sketchy (at best) in your organization, recommend to management that all of IT, not just analysts, be trained in best practices for correctly documenting requirements within your software methodology. Training all of IT sets expectations on what is acceptable requirements deliverables and holds analysts accountable for producing quality requirements.

Create a plan for addressing the issues encountered during the assessment and recommend a time frame for improving the requirements practice, including an appropriate time for implementing a tool. Generally, management will appreciate a well thought out plan, rather than a haphazard approach to implementation.

Select a Tool

A fool with a tool is still a fool.
~Anonymous

Hopefully you find yourself in the situation where you and your team have the ability to evaluate and select a tool, rather than management dictating which tool you must use (or worse yet, one they have already purchased.) If you are able to select a tool, then you are in luck. If not, know that most tools on the market offer sufficient improvement over capturing requirements in an ad hoc manner that some benefit of implementing the tool will certainly follow.

When beginning the selection process, start with the problem statements that were created during the assessment phase. Any tool that is selected will need to address the pain points of your organization. This will help ground you as you begin your search, and keep you from being distracted by the many bells and whistles that companies offer. When it comes to selecting a tool, the most important criteria is that it addresses the pain points you are experiencing. Bells and whistles will only encumber your process rather than enhance it. At its most basic, a tool should enhance your existing process, not detract from it.

As a part of your selection process, determine the criteria which are most important and evaluate the tool according to these criteria. A simple spreadsheet that ranks the criteria for each candidate vendor will help in objectively evaluating a tool. Have each team member rank the features/needs for each vendor which are determined necessary for the tool to succeed at your organization. A scale from 1-10 may be used, where 1 is least favorable and 10 is most favorable. Do the same for the priority column and calculate the total value for the features, and in turn, the vendor’s product. Here is a sample:

Feature/Need	Product Ranking	Priority	Total Value
Integration with MS Word	3	7	21
Visual depiction of requirements	1	9	9
Traceability	4	8	32
Integration with development tools	3	2	6
Integration with test suite	4	3	12
Ability to define custom properties	5	1	5
		Vendor total:	85

Once you have narrowed the field down to a few choice vendors, evaluate the products thoroughly. The best way to do this is to try before you buy. If at all possible, negotiate a trial period with each vendor where you can put the tool to the test on a real project. The only true test to tell if the tool will work in your organization is to try it out in real life. No demo projects, no smoke and mirrors, just good old fashioned writing your own requirements in the tool in order to learn its quirks and limitations. This may add some extra time and produce some redundancy in your project documentation as you will want to continue to store whatever you produce within your own directories, but the small pain up front will alleviate pain on the back end once the tool is implemented. Complete the ranking process again once you have completed the trial run. This should produce a clear winner.

Next up: Implementing a tool without causing mass chaos in your organization.

Seven Tips to Ensure Requirements Management Success

Written by Cynthia Low on March 24, 2009. Posted in Articles.

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software. Software operates the cars we drive, the planes we fly in, the cell phones we can’t live without and the tools we use every day to get our jobs done. Software is everywhere.

As a software professional, you know all too well that software development isn’t easy. A software product is never completed. There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:

Lots of people involved in the process
Customers have difficulty articulating their real needs
Requirements constantly change
Teams are spread across multiple geographies
There’s growing pressure to release products faster
The complexity of software doubles every 2-3 years
More projects fail than succeed

Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success. And, the path to building great software goes through requirements management. Organizations that embrace this concept enjoy greater results. They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.

What You’ll Learn: The goal of this article is to provide you seven essential tips to help you be more successful with requirements management. For some, these tips might be new. For others, these tips will serve as a good reminder of the fundamentals that are easy to lose sight of during the heat of a project.

Tip #1. Stay Connected

You can eliminate most issues by keeping everyone connected.

Much attention is placed on the high failure rates of software projects, and for good reason. Any time there’s billions of dollars at stake and failure rates ranging between 60%-80%, people are going to pay attention. But, what you don’t hear as much about is the root cause. Last year, in The State of Requirements Management Report we polled over 200 professionals about the top challenges they faced in eliminating project failure, and the resounding theme boiled down to one thing – communication. If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.

Terminology	Simple Definition
Collaboration	Keeping your entire team connected throughout the development process
Traceability	Keeping all the requirements, artifacts and other related information connected

There are two parts to staying connected. First, there’s the connectedness of your team, which has been popularized recently as “collaboration” – new buzzword, same meaning. Analysts, project managers, developers, testers, product managers, executives, stakeholders and customers – is everyone on the same page about what you’re building and why?

Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project. Depending on the size and location of your team, you can do this manually through meetings, phone calls and documents or you can use a tool to help keep your team connected. It depends on your situation and the complexity of what you’re building. See Tip #7 for the tipping points when a tool might be valuable.

Second, there’s traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects and even user documentation – all the details that are related to each other within a project. For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream.

For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can immediately assess the impact it has on any downstream functional requirements, tasks and defects that a developer or tester might be working on. This helps minimize errors and costly rework because the team members affected are aware of the specific change and its impact.

Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success. As a simple first step to establishing change control, you can use a change request form manually to document changes right now.

Tip #2. Take Action Now

Don’t wait for your process to be “perfect.”

Doing something is better than nothing. It’s easy to fall victim to what you might call “process perfectitis” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software. How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ” Is any process perfect? More importantly, should that really be your team’s highest goal?

Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress. Don’t get us wrong, optimizing your process is important, very important. We’re constantly tweaking our process. However, if you have a better process and no product, you still have nothing to show your customers.

Doing something is better than nothing. Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat. Then, with each release cycle you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them. If you think your team suffers from process perfectitis, look for these symptoms:

•· Requirements definition phase seems to drag on and on and on

•· In the last month more time when spent talking about process, while your product stayed the same

•· Lack of a decision-maker to make the call when to move forward with development

Tip #3. Eliminate Ambiguity

Successful requirements management begins with writing good requirements.

One of the things you can do immediately is make a “do not use” word list and post it up on the walls in your office. Visual reminders will help you to avoid using ambiguous terms when writing requirements. Karl Wiegers, a well-respected requirements management consultant, in his book Software Requirements provides a good list of ambiguous terms to avoid in requirements specifications. Here’s a snapshot of a few them.

Ambiguous Terms	Ways to Improve Them
fast	Specify the minimum acceptable speed which the system performs some action.
flexible	Describe the ways in which the system must change in response to changing conditions or business needs.
acceptable, adequate	Define what constitutes acceptability and how the system can judge this.
simple, easy	Describe system characteristics that will achieve the customer’s needs and usability expectations.
shouldn’t	Try to state requirements as positives, describing what the system will do, instead of what it won’t do.
robust	Define how the system is to handle exceptions and respond to unexpected operating conditions.

Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

Tip #4. Reconnect with Your Customer

You don’t have to be an expert to capture the voice of your customer – just committed.

This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution. Keep in mind, we use the word “customers” to refer the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers.

Capturing the voice of the customer isn’t a one-time effort. Most project teams do a thorough requirements gathering session at the beginning of a project, but rarely does the customer interaction carry through to the end. Successful requirements management practices include constant communication with customers. Otherwise you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.

There’s definitely an art to eliciting feedback and requirements from customers and clearly some people are better at it than others. There’s a plethora of books and courses out there to provide training for this specific skill. However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment. Commit to picking up the phone every week and talking to customers. Commit to getting out of your office and sitting down with customers in their real environments. These are things everyone on the team can do, and should do. Even in Agile it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback other ways.

Here’s a quick list of Dos and Don’ts to follow as reminders for how to stay connected to your customers.

Dos	Don’ts
Be a journalist – ask open-ended questions	Think you know best what customers want
Talk to your customers every week	Assume past experience is representative of current needs
Be open and flexible to change	Assume customer needs are static
Just pick up the phone and call customers	Elicit requirements & feedback only at the start of a project
Listen with an open mind during elicitation	Sell customer on your idea for how a solution should work
Sit with a customer and watch how they work	Assume customers know how to articulate their exact needs
Close the loop with customers when their feedback has been implemented in the product	Forget to capture and share the evidence you gather with your team

Tip #5. Prioritize Objectively

Avoid building functionality that customers don’t need and may never use.

Development time is so valuable. There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.

This is where requirements prioritization is essential. You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need. Too often, requirements prioritization happens subjectively. The team holds a meeting and in a debate over the requirements the loudest voice wins; or a request comes in from a salesperson who just spoke to a customer and the most top-of-mind request becomes the hottest priority du jour. With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:

What percentage of our customers will benefit from it?
Does it fit our brand values and enhance a competitive differentiator?
What is the trade-off if we prioritize this ahead of other requirements?

It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against. That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively.

Tip #6. Minimize Overhead Select the right tools to get the job done.

If you’re a small team in the same office developing a fairly straight-forward product, you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements. A specialized tool in this case could create unnecessary overhead. Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine.

As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync. It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate with everyone on the team.

Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.

Variable	Tipping Point	Benchmarks
Complexity	The more complex the project, the greater the need. If you have over 100 requirements.	72% of teams have projects that on average have 100+ requirements.
Team Size	The bigger the team, the greater the need. If you have over 25 people involved.	Over 40% of teams have at least 25 members and stakeholders.
Location	The more geographically distributed the team, the greater the need. If 10%+ are virtual.	Over 60% of teams have at least 10% of their team working in different locations.
Change	The more changes, the greater the need. If you spend 10% or more of your time managing changes to requirements.	Over two-thirds of teams spend 10% or more of their time managing change.
Traceability	If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history.

Benchmarks: The State of Requirements Management Report by Jama Software and Ravenflow, 2008

Tip #7. Don’t Reinvent the Wheel There are many existing templates and resources you can leverage right away.

Even though every company, project and team is unique, the resources needed to help you be successful, in most cases, already exist. In minutes you can do a search on Google and find a wealth of best practices information. As a starting point, here’s a link to more resources from Jama Software and Karl Wiegers for free companion resources to this article: http://www.jamasoftware.com/requirements_management_resources.php

Eric Winquist is CEO and founder of Jama Software. In March 2006, Eric founded Jama with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur, business analyst and project manager with over 14 years experience working with a wide range of organizations. Previous to Jama, Eric founded Redside Solutions, a software development consulting firm.

John Simpson is director of customer outreach, Jama Software. John represents the voice of the customer and leads Jama’s product strategy and communications. John has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. He has contributed to several books, whitepapers and presentations.

They can both be reached through the following: 503.922.1058 [email protected] I www.jamasoftware.com 3/09

The Latest Bad-Ass BA Techniques

Written by Cynthia Low on March 17, 2009. Posted in Articles.

Demystifying “Return on Investment” (ROI) and Business Benefit

One of my managers, Denny Brown, used to say to me, “It’s all analysis”. He was talking about projects, so I was confused. It took me years to figure out that he was talking about “end-to-end” execution of a project. First we analyze the business need, then we determine the requirements, then we design a solution, then we implement the solution, then we measure the results to analyze how well the solution is meeting the original need.

How many of us work on projects where we actually get to do the “measure the results?” And notice I said, “is meeting,” not “has met.” How many of us actually work with business teams who are prepared to track the performance of the business after we “toss the solution over the wall?”

The Business Requirements Document is often the first deliverable that a BA contributes to a project. If the project is following best practices, then there’s a Business Case document that feeds the BRD, and in that Business Case document there should be a description of the benefits anticipated from no longer having the problem that is the reason for writing the BRD. A key metric for business benefit is Return on Investment, or ROI.

We’ll look at what the components of ROI are so that when you start writing the business requirements for reporting on business benefits, you’ll know what is needed.

Return on Investment

Project funding committees always want to know when a project will “pay for itself”, or return 100% of the money spent to solve the problem. ROI is a time measurement, e.g., months, quarters, or years. To calculate annual ROI, or the number of years it will take to obtain 100% return on investment, you would use this equation:

(<business problem cost per year> + <project cost per year>) /
<anticipated savings or revenue gain per year>

For example, let’s say we have a business problem that costs $100,000 per quarter in lost productivity. The project to solve the business problem will cost $150,000 (completed in 1 quarter). The expected increase in recovering productivity plus an increase in revenue resulting from that productivity is $250,000 / quarter. The return on investment for this example is 100% in one quarter.

In our BRD, we want to write requirements that enable collecting the data that will be the source for the report that will show progress towards a 100% ROI in the expected time period. Just think, if the time period is one quarter, even hitting a 95% ROI is pretty darn good. Being able to show that the actual result was 101.45% ROI in one quarter is even better.

We BAs want to provide the evidence of benefits that will give our customer bragging rights. The Business Case must articulate estimated benefits that are measurable and assessed over time. In the BRD we want to write requirements that will validate that the benefits were in fact achieved.

Let’s take a look at these components in detail:

cost of the business problem
project cost
anticipated savings or revenue gain

Cost of Business Problem

Most business groups have already figured out what the business problem is costing them. If the business context is manufacturing, then a problem can result in a product recall, which is both costly to administer, and has a huge impact on brand image, which results in a dip in revenue until the brand image is restored. Senior executives wish they could forget the business cost of a product recall – they shudder just thinking about it. If the business context is service delivery, then any delays in being able to provide the service to the customer give the customer an opportunity to find a vendor who delivers faster. Most product managers have the competitive information that enables them to calculate the cost of not being able to do business fast enough. Just ask the sales person who lost a major account to a competitor because her company couldn’t guarantee a particular service delivery time.

If the business problem cost can’t be measured in direct terms, e.g., loss of revenue, then use this heuristic method which focuses on productivity:

Number of people who spend time compensating for the problem
Number of hours each of those individuals spends per week compensating for the problem
Hourly rate for those individuals
For a quarterly estimate: use 12-13 weeks; For an annual estimate: use 50-52 weeks

If the business problem is poor data quality, then the business cost of the problem can be formulated based on the effort needed to compensate for the poor data.

For example, If 5 people each spend about 2 hours a week revising spreadsheets to correct the poor data quality, then an estimation of the quarterly cost of the problem would look like this:

5 people * 4 hours/week * $150/hour * 13 weeks/quarter = $39,000 / quarter

The hourly rate will vary according your industry. The $150 hourly rate is a burdened rate for high tech workers in Silicon Valley.

In our BRD, we want to describe the current business situation in a brief quantifiable manner. Something else to consider is the cost of the “work around” the business may be using right now while they are waiting for a real solution. What is the cost of the workaround? There may be some short-sighted people who will try to say that the work around is good enough, and there’s no need to spend the money for the real project.

Here’s where clever articulation of benefits and metrics really can save the day and prevent a short-term work around from becoming cast in concrete and causing a much larger headache in the future. Use the method above to quantify the cost of resources being used to perform the work around. As the volume of the work increases, will the work around be sustainable or will more resources be needed? When will it be more cost effective to solve the root problem?

Cost of the Project

Some projects use Net Present Value (NPV) to determine the cost of a business problem. NPV applies when the bulk of the cost savings generated from the project occur more than a year in the future. We aren’t going to cover NPV here.

The method provided here is an estimation of the cost of the project provides:

An understanding of the value of a solution to the problem
A means to estimate the project’s Return on Investment

Convey the estimate of the project cost as a range, for example, < $US100,000, < $US100,000 - $US499,000, <$US500,000 - $US999,000, <$US1M - $US5M. Be sure to include service provider, e.g., IT and third party service providers, and costs the business customer may incur.

Our BRD should have ROI reporting requirement(s) enabling us to produce a report that shows the proportion of the investment recovered and the time periods.

In the BRD we need to articulate the following:

The estimated cost of this business problem
How we calculated the estimated cost of this business problem
The estimate cost range of the project is –
The estimated ROI period is

Anticipated Savings or Revenue Gain

To determine anticipated savings or revenue gain we need to indentify the business benefits. There are two types of benefits:

Direct benefits are quantifiable and therefore measurable.
Indirect benefits are not directly quantifiable, but still need to be assessed. It may be possible to estimate indirect benefits from other quantifiable measures.

Direct Benefits

Direct benefits are quantifiable benefits that will be appreciated as a direct result of the business problem being solved by the project being undertaken. Describe these benefits in measurable terms, as compared to the current business situation, such as:

Revenue – expected revenue increase quarterly/ annually
Cost Savings – projected savings in consolidating licenses/ hardware/ decommissioning of systems.
Cost Avoidance – cost not incurred if the problem is solved, e.g., doubling the number of resources needed. Cost avoidance (time savings, fewer errors) can result from automating workflow, if the alternative is adding headcount.
Productivity / Efficiency – Efficiencies that result in headcount reduction
Compliance – ability to demonstrate compliance with

Questions to ask for Direct Benefits are:

What metrics will be used to report on progress towards achieving the benefits and at what frequency (monthly, quarterly)?
How will each benefit be measured? Can data be collected automatically or will a manual effort be needed?
What is the length of the time anticipated to achieve the goal? (duration)

Indirect Benefits

Indirect benefits are efficiencies that result in time savings without headcount reduction. Indirect benefits may be realized indirectly as a result of the project being undertaken. They also include benefits that cannot be easily measured. Indirect benefits may require informal or subjective analysis, but are required.

Examples of efficiencies are:

Reduction of errors
Increased reporting capability
Improved ease of doing business
Enhanced customer experience
Improved Decision Making (decrease margin of error, …)
Increase Customer / Partner Satisfaction (identify high visibility pain points )
Extra time available to multitasking resources to focus on other areas of their jobs

Questions to ask for Indirect Benefits:

What metrics will be used to report on progress towards achieving the benefits and at what frequency (monthly, quarterly)?
What subjective criteria will be used for measuring success?

Describe how the cost of the problem being quantified now. Is there a way to associate a metric with the benefits by comparing the metrics to the business situation / current state? Or is the goal 100% improvement in one quarter? What is an appropriate frequency and time frames for reporting on changes in the cost of the business problem? Monthly? Quarterly? We need a statement that says something like this, “The progress made towards achieving the benefits will be measured by and will be monitored by on a basis.”

The BRD should have requirements for validating the benefits but we will not go into that here. Our focus is on how ROI is estimated, which helps us write a requirement for reporting on success, that is, the achievement of the benefits that were anticipated in the first place.

Summary

Return on Investment tells the business how long it will take for the project to pay for itself. In order to calculate that time period, we need to know cost of the business problem, project cost, and the benefit to the business articulated as anticipated savings or revenue gain.

The role of the BA as described in the BA BoK describes a role that has a strategic relationship with the business customer. The better you understand the business context, and can articulate the benefits to the business, the more strategically valuable you are to your customer (read “the more you are a Bad-Ass BA”). A BRD documents “what” the business needs. In addition, a BRD should include requirements for reporting on the success of the project. If our customer is expecting $8M uplift in revenue in the next fiscal year and 100% ROI in less than 12 months after project completion, then we want to build requirements into the project to generate a report that demonstrates the accumulation over time of that uplift, and, as claimed by the customer, that the 100% was achieved in less than one year.

Remember,” it is all analysis.”

Thank you, Denny Brown, President, Expert Support, Inc., for 26 years of guidance and encouragement. Thank you, Rebecca Burgess.

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding. She can be reached at

[email protected].