Tag: Success

Bad-Ass BA Lessons. Part 1.

Written by Cecilie Hoffman on June 16, 2009. Posted in Articles.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply “intelligent disobedience” and judicious audacity to your environment to earn those bad ass stripes.

The term intelligent disobedience comes from guide dog training. Blind people who live in cities listen for the auditory cues from a traffic light turning green to tell them it is safe to step off the curb into an intersection and walk across the road. Their guide dog is trained to watch for cars that aren’t showing signs of stopping. When the dog sees danger to their human, the dog is intelligently disobedient, and stays in a “sit” position, letting the human know that they shouldn’t step into the path of danger.

Judicious audacity is the intelligent application of aggressive boldness; that is, taking control of the situation in a fearless fashion because it is the effective and efficient thing to do.

Caveat emptor: there is a significant amount of risk inherent in many of these actions, though the payoff is high. Buckle up tight, fellow BAs, here we go.

Step 1. Exploit the Hidden Power in “Menial” Tasks
Step 2. Delegate!
Step 3. Compose in Real Time
Step 4. Define Gonzo Success Criteria
Step 5. Ask the Crazy-as-a-Fox Stupid Questions
Step 6. Get Their Attention
Step 7. Schmooze those Stakeholders
Step 8. Rat Out those Underachievers
Step 9. Speak Truth to Power
Step 10. Put on Your “Facilitator Flak Jacket”

We’ll cover the first four steps in this article. The remaining steps will be revealed in subsequent articles.

Step 1. Exploit the Hidden Power in “Menial” Tasks

We think that as we advance in our role, we shouldn’t have to do menial work. Tasks like taking notes or writing the first draft of a document or process may feel like they should be beneath us. Wrong perspective! Menial tasks aren’t always low brain power tasks; below are two examples of hidden power for the BA who can leave their ego at the door.

#1: Note taking and the power behind it

When you are the person recording the meeting minutes, you are in control of the official record of the decisions, action items, and open issues. Is the speaker making pronouncements in sentence fragments? You can stop the meeting and request that the speaker give you a statement that can be recorded. Does it appear that a decision has been made but you aren’t sure exactly what was decided? You can stop the meeting and request that someone give you a summary so that you can record it properly. Has an action item been agreed to? You have the power to suggest who should own that action item and what the due date should be. Is note taking a menial task? Hardly. You’re actually running the meeting and finalizing the decision making.

And, of course you are taking these notes directly in electronic form. Pen and paper is a luxury reserved for CEOs and poets; the rest of us have to be more efficient.

Before sending out the meeting notes, you should summarize the key points and decisions. Was there some fuzziness around a particular topic? Clarify it based on your business understanding or by contacting the Subject Matter Expert (SME). This is like stealth direction setting. And think of the visibility you have when you send around the meeting notes for comments and correction. Just be sure to have “recorded by ” in the meeting notes.

#2: Seize the moment: Draft the initial process/doc yourself

Do you ever get impatient with the lack of progress, or the inability of some people to get past a blank template? Start the document yourself and send it out to the team as a “suggestion”. The trick is to influence the process by presenting your ideas to kick-start everyone else’s thinking. Your natural BA instinct will be to try to get everything right before you show the document to anyone. In this case, though, you don’t need to get everything right because you are influencing, as opposed to analyzing; you’re pointing people in the general direction that you think is best, and encouraging them to build on top of your suggestions.

Step 2. Delegate!

Delegate? How am I supposed to delegate? I’m a single contributor, I can’t delegate; I get tasks delegated to me!

True. We BAs are single contributors, we don’t have the authority to delegate, but we have earned the right to suggest that a particular person or group should perform a task. In Step 1, above, there are two methods of “stealth delegation”:

You can delegate by recommending a person to own an action item from a meeting. If a person has special knowledge or interest in a particular area, it is appropriate to suggest they bring their expertise to bear on a task in that area. Minimally, you could ask them to draft a few slides or a couple of paragraphs outlining their ideas or concerns, which you can incorporate in the deliverable. They are likely to come up with some points you wouldn’t have thought of as well as being more invested in the success of the effort.

Delegate by putting a comment in a draft implicitly assigning a section by asking a question of a specific stakeholder, e.g., “Stakeholder A, do you have anything to add here?” Then follow up with that stakeholder both privately and publicly.

There’s also delegating by trading tasks – what can you do for the individual that you want to do something for you? This sort of “horse-trading” is a great way to leverage your own skills to obtain something you need, but can’t accomplish on your own.

In all these cases, be very clear about what you need from the person and when you need it. Follow up with them approximately half way through the time you have allowed for the deliverable to make sure it’s still on their radar. Be sure to emphasize that their special knowledge and input is vital to the success of the project and thank them for taking the time to contribute.

Step 3. Compose in Real Time

Whether you are doing a structured walkthrough of your BRD, or real time process development, when you have a live audience for work that is happening in real time under your fingertips, the pressure is on. This is one of the stages on which you earn your Bad-Ass BA performance award, if you are truly a master of your craft.

Let’s say you are using one of the many application sharing tools that allow people to see what is on your computer screen, no matter where in the world they are physically located and that you are revising the phrasing of a requirement that is giving people heartburn. Three people are talking at once. While you retype the offending requirement before everyone’s eyes, you get to say,

“Folks, let’s agree on who is the actor, here. Do we agree on that it’s the system? Good. Now, what was the exception condition that someone identified? Wait, what has to happen to trigger this requirement to come into play. One at a time folks! One at a time! Any conditions? No? Okay. Let me read this out loud to see if makes sense…. I think we want a different word, here, how about “configuration”? Any disagreement? Good. Now give me a moment to tune up the action … okay, please read this to yourselves. (count from one to five silently) Does anyone feel this does not express what we are trying to capture? Great. What’s the next one we need to work on?”

You own the stage, you clearly own the material, you are in the driver’s seat and you are getting the job done. Furthermore, you are putting pressure on the people who disagree to get their issues out in the open and resolve them by asking if anyone disagrees and explicitly making silence equal consent. The key is to determine when you’ve captured the meat of the idea and not let people wordsmith themselves to death.

How did you develop this skill? You’ve been taking notes in meetings (see Step 1, Point #1, regarding CEOs and poets) for years and doing the same thing; now you’re just doing it before everyone’s eyes and making it look easy.

Step 4. Define Gonzo Success Criteria

Slang: “gonzo” means conspicuously or grossly unconventional or unusual

As an exceptional BA, you should already have gotten all your project team members and stakeholders to focus on the success criteria for the project and the on-going process. Now take a dramatic step and get them to focus on the end customers’ success criteria for the on-going process. When you start doing this, the team members and stakeholders are likely to tell you that you are crazy and what you’re suggesting is impossible to do/measure/implement. Don’t worry, that’s a natural reaction to out-of-the-box thinking, and you are way out of the box.

The point of focusing on the customers’ success criteria is that we usually measure what is important to us, and what we feel is reasonable to measure. Too often, what we think is important is not what the customers consider important. Here are two examples to illustrate different aspects of this.

Scenario 1.

Airlines have determined that customers’ satisfaction is impacted by how long it takes to check in for a flight, so it makes sense to have a requirement that the flight check-in process be as efficient as possible, and to measure the time it takes to check in. It would be sensible and relatively easy to measure the time it takes for the counter personnel to key in the customer’s information and provide the customer with a boarding pass. If you are the customer, however, when do you start measuring the time to check in? Probably when you get in line at the counter.

So if there’s a 20 minute wait in line because the airline hasn’t staffed the counter properly, it may not matter to you that the time it takes the counter personnel to key in your information has been cut from 10 minutes to five minutes. Nor would you be impressed if they were able to cut it further to two minutes – you are still irritated by the long wait in line. The gonzo success criterion comes from looking at something that the airline doesn’t nominally control and may find difficult to measure: the amount of time spent waiting in line. Once you change your point of view to the customer’s, however, further improvement in the pieces of the process that you control may be wasted investment, compared to extending your control to other, more difficult to manage and measure portions of the process.

Scenario 2.

Software companies don’t want to give away support for their products so they generally require customer companies to pay for a maintenance license. When someone from the customer company calls in for support, the first thing the software company does is determine if that contact and company is entitled to support by checking that company’s “entitlement data”. It makes sense to the software company to make it as easy as possible for the customer companies to keep their entitlement data up to date, so the software company could have developed success criteria about how much time it takes the customer to update entitlement data. From the customer company’s point of view, however, there may be no reason to value entitlement data; the customer company just wants support, now. The customer’s success criterion is for the software company to “automagically” know that they are calling about a legal copy of the software for which maintenance has been paid.

Manual maintenance of entitlement data is just one possible way to meet that need. If the software company came up with another solution that led to the software itself automatically maintaining the entitlement data when it is deployed or updated, the customer would probably be delighted. But as long as the success criteria assumes that entitlement data must be maintained manually, the customers’ real needs are being overlooked. In this case, the gonzo success criteria requires ignoring the solution already in place and getting back to the customers’ underlying need.

As a business analyst, you are used to putting yourself in other people’s shoes to figure out what they want. Use that skill to add the end customer point of view to your requirements and metrics and you will increase your value enormously.

This is the first installment in a three-part series. The next installment will cover

Steps 5 to 8.

Installment 1 Business Analyst Times June 16/09	Step 1. Exploit the Hidden Power in “Menial” Tasks
	Step 2. Delegate!
	Step 3. Compose in Real Time
	Step 4. Define gonzo success criteria
Installment 2 Business Analyst Times July 14/09	Step 5. Ask the crazy-as-a-fox stupid questions
	Step 6. Get their attention
	Step 7. Schmooze those stakeholders
	Step 8. Rat out those underachievers
Installment 3 Business Analyst Times Aug 11/09	Step 9. Speak truth to power
Installment 3 Business Analyst Times Aug 11/09	Step 10. Put on Your “Facilitator Flak Jacket

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, 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 at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Five Ways to Do More with Less – and Be Successful

Written by Cynthia Low on June 2, 2009. Posted in Articles.

Do you find yourself suddenly being asked to do more with less? Was there once someone in the office beside you whose job responsibilities have suddenly become yours? Are you feeling pressure from your boss to deliver, deliver, deliver?

It isn’t as if you were slacking off before. Between the meetings, the email and just doing your job there wasn’t a lot of time left over. So how, exactly, are you supposed to manage now? Here are five success strategies for getting more accomplished with the time and resources you have.

Success Strategy #1: Clarify your role and responsibilities. This is the first thing you should do. If you are taking on responsibilities that are new to you, it is critical that you spend some time with your manager defining what they are. While it can be tempting to rush over this because there doesn’t seem to be time, making assumptions about expectations can slow you down later. Questions to ask include: Why did you give me these responsibilities? What do you expect me to accomplish and by when? How will my progress and success be measured?

Success Strategy #2: Establish priorities. There is a pretty good chance you now have too much on your plate. You will need to look at your tasks and deliverables and start putting them into three categories: ‘urgent’, ‘must do’, ‘maybe someday’. One thing I advise people to do is make a ‘not to do’ list for themselves and their organizations – it helps us focus and be efficient when we know what we don’t need to worry about. Make sure you also think across the system – whose work might be dependent on your getting something completed? Once you’ve categorized things it is time for another meeting with your manager. Making sure the two of you are in agreement around priorities will save you time and effort.

Success Strategy #3: Identify what you need to learn. If you are taking on things that are new to you, you will have to invest some time and energy into your own learning and development. You should identify your gaps in three key areas: knowledge, skills and practical experience.

Knowledge is usually the easiest to acquire but can be time consuming. Figure out who can help you get up to speed or point you in the right direction. This is where having a good network inside and outside of your company can help.

Skills are tougher than knowledge – you have to actually do something. Maybe there is a quick course you can take to accelerate your progress, but that may not be realistic or in the budget. Think about how you have acquired new skills in the past and what worked for you. Some people like to start with the theory before they try something. Others like to start by experimenting and learn on the fly.

Even if you have the basic skills already, doing something well requires practice. Watch for these opportunities and seize them. Warning: this could push you outside your comfort zone! Finally, give yourself a break. This is new to you – don’t expect to be perfect.

Success Strategy #4: Ask for feedback. One item that frequently gets a low score on employee surveys is, “I get timely feedback from my manager.” Turn that around. Instead of waiting for someone to give you feedback, ask for it. If there is something you can do to be more effective or efficient, don’t you want to hear about it? It is up to you to create the conditions where others can give you good feedback – be open, listen, ask clarifying questions, say thank you, and put good ideas into practice. There is no better time to ask for feedback than when you can honestly say, “I’ve never done this before, I’m trying, but I would really like to get your suggestions on how I can improve.”

Success Strategy #5: Keep things in perspective. Yes, there is a lot on your plate and so little time. This can lead to a lot of stress, particularly if you are someone who strives to do everything well (maybe even perfectly). You are only human. Remember that others are feeling exactly the same way. What you can do is focus on what is most important and strive to get it done. If others see you doing your best, they will respect you for it.

Dr. Rebecca Schalm, who has a Ph.D in Industrial/Organizational Psychology is Human Resources columnist with Troy Media Corporation and a practice leader with RHR International Company, a company that offers psychology related services for organizations worldwide.

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

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

Getting Back to Basics – Fifth Fundamental-Choosing the Best Modeling Technique for Success

Written by Cynthia Low on August 1, 2008. Posted in Articles.

In April, I began a series of articles devoted to the basic practices of business analysis. With so much information now available, I felt it was important to go old school and make a case for the core principles of the discipline and why they represent the best path to success.

Since beginning the series, I’ve talked about understanding business goals, creating a common vocabulary, identifying sources and choosing elicitation techniques. Now, in this final installment, I’ll be discussing which modeling techniques are most appropriate for a given situation.

Why We Model in the First Place

They claim a picture says a thousand words, but, in business analysis, it’s the opposite. The thousands of words you elicit from your stakeholders make up one picture representing a summation of disparate information. Modeling is essential for drawing a clear, accurate picture of a given project’s true business needs.

In addition, modeling helps you define your project’s scope and begin prioritizing the mountain of requirements you’ve gathered. A well-drawn model is a concise model, which will allow you to clear away the erroneous, redundant information that inevitably clouds your view of the path ahead. The types of models you use may very well address the different levels of knowledge and means by which a stakeholder can best articulate his or her vision or needs. For example, if you’re dealing with highly systematic thinkers and are eager to both elicit and validate requirements, you may likely choose to develop a variety of tables and checklists. Or, for more creative, big-picture, visually minded stakeholders, you’ll leverage story boards and use-case diagrams.

Four Classes of Modeling

Those new to business analysis-and, frankly, those not new-often confuse the terms model and diagram. A model represents information at the highest level, and diagrams are the tools that make up a model. Think of a model as a newspaper, and the diagrams as the many sections within.

Speaking generally, we could put all models into four categories. All four can and should be used to varying degrees for all types and levels of requirements. However, a trick for distinguishing them and determining when one is more appropriate than the others is to align the classes with five questions: Who? What? When? Why? How?

1. Structured Models
When the question is What?—as in, What is supposed to happen?–-developing a Structured Model is an effective modeling technique. An example of an applicable process could be: if an expense is approved via an online approval system, that request is then sent to a third-party payroll organization. The diagrams you could use to build your structured model in this case include a glossary of terms-which we discussed in the second article in this series-as well as domain and location diagrams. By using a glossary of terms, you can ensure the clarity of what is being used or what systems are involved.

2. Behavior Models
Behavior Models are the best tool for answering the Who? Who’s going to maintain a company’s Intranet site? Who’s going to act as a backup in the event that a technical expert is unavailable? Who’s going to be responsible for ensuring that monthly attrition changes are made to a company’s payroll system? This modeling technique can also answer a second question: How? How will a system be updated, manually or automatically? How will progress be reported up the food chain, by e-mail or directly during conference calls?

As the name indicates, we’re dealing with human behavior here, and, in the workplace, that usually translates to individual roles and responsibilities. Therefore, diagrams include behavior categories as well as process maps and use-case maps. Also, when creating a behavior model, don’t forget your stakeholder categories, which we discussed in detail in the third article in this series.

3. Control Models
Now, on to my three-year-old son’s favorite question: Why? Control Models tend to focus most successfully on justifying why something needs to be done, or why it is valuable to do something a certain way. And, quite often, the answers can be found in the business policies and rules that you’ve collected throughout elicitation. An organization’s individual policies, for better or worse, often determine the course of a project. For example: When an associate project manager makes a purchase request in excess of $10,000, that request will automatically bypass his or her direct boss and be sent to the head of the division. Why does this have to be done? Because, those are the rules, kiddo.

4. Dynamic Model
Finally, Dynamic Models, although not used as often as the other classes, are all about When? When will reports be generated? When will the first stage of the project be completed? When is this article due to BA Times? Dynamic Models will be made up of your most time-driven diagrams, which may include event tables or detailed timelines.

Best of Luck

And with that, our whirlwind back-to-the-basics tour has come to an end. I wish you luck in your future endeavors, and hope that you remember the value of our discipline’s basic best practices.

If, for some reason, you missed any of the four previous articles, don’t worry. The film version of the series starring George Clooney will be hitting theaters worldwide this fall!

Glenn R. Brûlé has more than 18 years’ experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.