Skip to main content

Tag: Team

The Business Analyst Facilitator Role in an Agile Software Development Team

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question – “Is there a need for a business analyst role in an agile software development team?”

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, “but we are doing fine on my agile project without a BA role.” To you I ask, “Have you examined your expanded role of directly interfacing with stakeholders?” For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

  • Facilitation Techniques for Identifying Solution Features
    • Creating a Solution Vision and Scope
      • Brainstorming – discussing of ideas
      • Brainwriting – submitting written ideas for discussion
    • Eliciting Features and Associated Business Rules
      • Focus Group Meetings – soliciting opinions
      • Joint Application Design – resolving conflicts
    • Analyzing Features – Assumptions, Constraints, Risks, and Issues
      • Root Cause – five whys, Ishikawa Diagrams
      • Force-Field – listing negative and positive influences
      • As-Is and To-Be Gap
    • Making Decisions on Features and Priorities
      • Multi-voting – subjective paring down a long feature list
      • Criteria-Based Grid – weighting feature value criteria
      • Impact/Effort Grid – comparing feature benefits versus effort
  • Emotional Intelligence Skills for interfacing with stakeholders
    • Active Listening and Paraphrasing
    • Generating Participation
    • Neutrality – focus on meeting process instead of solution content
    • Questioning – seeking answers rather than posing solutions
    • Maintaining Focus – use a parking lot and issue log for off agenda topics
    • Obtaining stakeholder feedback
    • Summarizing and synthesizing Ideas
    • Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

  • ensuring the correct participants attend
  • accounting for meeting risks
  • arranging for an adequate facility conducive to collaboration
  • setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through “questioning” that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor – chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

  1. Select vision and scope features from prioritized list
  2. Develop a solution for this iteration within a time-box
    1. Conduct workshops producing prototypes
    2. Hold status meetings on progress
  3. Validate final prototype and implement with project sponsor approval
  4. Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor – ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

  • User and system functional requirements
  • Associated business rules
  • Information needed to be managed
  • User Interface
  • Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items….etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

  • Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
    • Activity Workflows with Swim Lanes – manual processes
    • Use Case – user / system dialogue – system functional requirements
    • Storyboard – user / system interface – screen flows
    • Entity-Relationship – organizing information used by the system
    • State Change – information changes as it proceeds through processes and systems
    • Class / Object – use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates “just enough” documentation as needed by the software development team to code the prototypes.

Conclusion – Formal BA Facilitator Role “Just Ensures”

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don’t forget to leave your comments below


Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

This article first ran in the IIBA newsletter February 2009.

Stronger Together; Cultivating the Business Analyst and Project Manager Relationship

Strongertogether1Much has been written about the potential for a contentious relationship between the project manager and business analyst. If you have been a business analyst or project manager for any length of time, then you have probably experienced some of this tension for yourself, particularly if you have previously performed both roles. It can be difficult to find a happy medium when so many of the tasks seem to overlap between the BA and PM role. For example, PMs are used to managing relationships with customers and sometimes delve into requirements during status updates when the BA is not present. BAs can overstep their bounds by adding scope without the knowledge of the PM, thereby impacting project resources and timelines. It doesn’t have to be like this.

This article is the tale of two professionals – a BA and a PM – and how we learned to work together to form a strong partnership to deliver superior results for our customers. Our goal is to provide tips that worked for us that may work for you. This way you can recognize when you are in the storming phase and quickly take action to move you into the norming and performing stages so that you can excel in your work relationships.

Group Development Model

First, let’s start with the basic premise that all teams go through a similar pattern when learning to work together – as illustrated in the Group Development Model developed by Bruce Tuckman in 1965. The Group Development Model states that there are four phases of team development: Forming, Storming, Norming and Performing. As a team comes together they enter the forming stage where team members are introduced and get to know each other. This phase is usually brief and leads to the storming phase where team members jockey for position and test the boundaries of authority. In the storming phase conflict comes to a head and usually leads to a make it or break it point for a team. In fact, many teams don’t successfully navigate their way through this stage. For teams that can navigate these stormy waters, they find themselves entering the calm waters of the Norming stage. This stage is where team members dig in and focus on getting the job done. A leadership hierarchy is firmly established and teams can concentrate on the task at hand. Most teams stay in this stage for the remainder of the project. Some teams are fortunate enough to enter the Performing stage where true team synergy happens. Team members are inter-dependent and are able to handle the decision making process with little direct supervision. Of course, teams will move back and forth through the different stages of team development as circumstances change: new leadership, loss of a key team member, or project completion.

Our Story: Lessons Learned on the Front Lines

Forming a Relationship: Our relationship began when we were assigned to work together on a large, strategic IT project. Joan was assigned as the project manager and Renee was given the responsibility of the lead business analyst for the project. Throughout the year, the project team consisted of one PM, three to five business analysts, and numerous development and Quality Assurance resources.

Renee’s Perspective: The beginning of a project always brings uncertainty, ambiguity, and many questions. This project, with its strategic significance, was no exception. Joan and I were acquaintances but had never worked closely on a project together. In fact, the one brief time we had worked together, I was a complete emotional wreck that Joan had to talk off the ledge to get the job done. I was sure she considered me to be a complete flake! I didn’t know how much lee-way she would give me as a lead analyst and we didn’t formally define our roles and responsibilities. Our biggest mistake! This lack of definition, of who was responsible for what, led us right into the storming phase of the project.

Joan’s Perspective: Getting to know the team leads is a significant task. When forming a new team, I try to understand the leads. What makes them tick, will they follow through on tasks, are they growing into this role or are they experienced, will they truly be dependable leaders that I can rely on or will I need to help them along? Of course, the answers to these questions develop as you begin working together. In the beginning I may assume a more dominant role to be sure the team is heading in the right direction. This may mean setting up and facilitating sessions to determine and lay out scope. Now, if you are a trained PM, you know scope management is a key responsibility. However, BAs also assume this responsibility.

Stormy Seas Ahead

Renee’s Perspective: Being a business analyst lead on a team can mean different things to different people. To me, it meant taking responsibility for all of the analyst tasks on the project, ensuring analysts were meeting their milestones, working with analysts on the team to facilitate problem solving, addressing business needs, and, of course, writing requirements. During the beginning of the project, I noticed that Joan would often approach each analyst, discuss requirements approach, follow up on open items, and sometimes hold meetings where requirements were discussed without me. I felt like I was not being given the opportunity to lead the requirements effort. To address the issue, I pulled Joan aside after a meeting and brought forth my concern. I wanted her to be aware that I needed more of a leadership role and that I would like to work together as more of a partnership. While it is sometimes difficult to bring forth concerns that may cause conflict, I stuck with the approach of addressing the issues by bringing up specific situations and how I felt about them – not by accusing or blaming Joan. I knew her intentions were good – she wanted the project to be successful. I also knew there were two possible outcomes – Joan would either hear what I had to say and suggest a better approach to our relationship or she would become offended, defensive, and potentially make my life miserable. Fortunately, Joan is a level-headed person and listened to my concerns and suggested some actions we both could take to make things better.

Joan’s Perspective: Realizing that I needed to move the project ahead, I quickly set up scope planning sessions. On prior projects I had also coordinated the work assignments for the BAs on the team, discussed and helped set approach and, in some cases, I would be the primary contact back to the business sponsors on key requirements and scope changes.

I was genuinely concerned when Renee confronted me on my leadership role and how it overlapped with how she perceived her role. I knew we couldn’t be productive and have a solid team if we continued bumping into each other by trying to assume the same responsibilities. I was glad she felt comfortable enough with me to be open and honest and I welcomed her willingness to take on more responsibility by managing the tasks of the other analysts on the team.

Wanting to develop a solid, strong working relationship, we discussed in more detail what she wanted out of this project, as the lead BA and how we each picture our roles. I also expressed the concerns that scope management was a key factor to my role. So, we agreed that Renee would lead the scope meetings, but that I would be invited to all meetings. This way, I would be in touch with decisions, understand the project and be able to actively create a Statement of Work, maintain risk, issue and change logs and put together successful project plans.

I also suggested that we have weekly lead status meetings. This would give us an opportunity to connect one-on-one to openly discuss any issues we had with each other, project concerns, or just to get to know each other. Simple questions such as, ‘Renee is there anything you are expecting from me or roadblocks you are encountering that I can help remove?’, or more simply, ‘What do you have for me this week’ went a long way in building a strong relationship. We started understanding each other and how we can best work together and with others on the team.

The New Normal

Joan and Renee’s Perspective: As the year progressed we applied the solutions we agreed upon in storming.

We were very committed to our lead status meetings. Even though we did have to move them on occasion, we always had a weekly update. Through open communication we brought forth concerns without fear of repercussion or accusations. We began to understand each other and what makes each us tick, which led to trust and assurance in each other’s role.

The benefits of this led to a strong leadership team who weren’t in conflict with each other, and this helped the rest of the team focus their energy on getting the job done. In the end, the entire project team delivered what the customer needed when they needed it. Success!

Taking Care of Business – Performing at Our Best

Joan’s Perspective: A year has passed since Renee and I stormed through our first project together. We have grown together, learned from each other and trust one another. We are now on another large initiative together, where Renee is the lead BA and I am the PM. We continue to implement our key lessons learned:

  1. Roles and Responsibilities defined: We held a team kick- off where the first thing we did was put together and agree upon roles and responsibilities. The matrix contained stakeholder, PM, lead BA, lead developer and other key roles.
  2. Meet Regularly: Renee and I continue to have weekly status meetings. These have become instrumental in being in tune with the progress of the project from both of our perspectives. The one-on-one status has instilled trust, respect and friendship between the two of us.
  3. Collaborate: We have learned to collaborate on key aspects of the project. We talk about approach and agree on it together, at the onset of a project. We facilitate and partner on the initial scoping meetings, discussing who will do what, when. We continue to bring forth concerns without blaming each other and creatively work out our differences.
  4. Trust: Renee has completely taken over the leadership and work assignments for all BAs who are assisting her on the project. Through working closely together, I know we share the same goals and I trust her ability to see things through.

The greatest benefit is the fact that we truly enjoy working together and often request each other on projects.

Learning to work together is no easy task. The common denominator is communication and accepting the fact that you cannot take the storming process personally. You need to work together to resolve healthy conflict and work to a resolution that is acceptable for everyone. If you cannot do this, you will not be able to reap the benefits of the norming through performing process.

Don’t forget to leave your comments below


Renee Saint-Louis is a Sr. 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. Contact:[email protected]

Joan Demuth, PMP, is a Senior Project Manager with a subsidiary of The Schwan Food Company where she leads numerous continuous improvement initiatives as well as serves as the lead project manager on several multi-million dollar IT projects. Prior to becoming a Project Manager, Joan served as a Business Analyst for more than 7 years. Joan has a Master’s Degree in Business Administration from the University of Sioux Falls. Contact: [email protected]

Unsticking Your Team’s Potential

The ‘team’ is probably the most complex and irritating relationship in an organization.

As individuals, we seem to be able to work with most people one-on-one, perhaps in groups of threes, and also as an entity of hundreds and even thousands. Where we struggle most is when there is a medium-sized group of us clustered together in a room, meeting once a month, with the purpose of, at least theoretically, doing something together.

Teams have the most trouble when there is a power differential (i.e., there is an appointed leader), and when their purpose is more strategic than operational (i.e., they make decisions vs. work on products). Most advice to teams is aimed at the leader, and what he or she can do to build a better team. Below are three membership dysfunctions that can get in the way of team effectiveness and suggestions on how team members themselves can help.

1) Team members believe the problem with the way the group is working (or rather, not working) is someone else’s fault.

Let me be clear on this point: responsibility for effective team functioning and dynamics sits squarely with the leader. However, he or she does not bear the responsibility alone. Each and every person who sits around the table is responsible for how they contribute to the dynamic. I sometimes ask people ‘what is one thing you could do differently that would help the team work together more effectively?’ and then throw up my hands in despair when I get a blank stare. The way a team member can make the team experience more positive is to reflect, answer that question, and then set about making a personal change in how they interact with their peers and leader.

2) Team members expect their leader to manage the team in a way that is consistent with the way they personally prefer to be led.

Those who want to be consulted and have decisions emerge through participative consensus-making have a difficult time with a team leader who manages in a more decisive and directive way. Team members who like direction, structure, and discipline have a tough time with leaders whose style is relaxed, opinion-seeking and open-ended.

A solution to this problem is to relax your expectations that your boss will always adjust his or her style to accommodate your preferences. While some leaders are adept at understanding and adapting to the needs of the group and the situation, not all are. The problem becomes more complex when you stop and realize everyone sitting around the table prefers something a little bit different: there is no way to make everyone happy all at the same time. Recognizing this and your leader’s limitations (and strengths) can help to elicit more empathy, and perhaps motivate you to adjust and temper your own expectations.

3) Team members expect their peers to defer to them as experts on functional issues and regard them as smarter than average on everything else.

One of the most common complaints I hear from people is that no one asks their opinion or listens when they offer it. The trouble is I hear this from every member of the team, suggesting that not only are they not being heard, they are also not listening to others.

There are two ways to address this problem. The first is to spend more time talking to each other one-on-one so you have time to fully express yourself, get a reaction from others, and evolve your thinking before you tackle the entire team with your good ideas.

The second is to be prudent around what opinions you express, how, and when. Does the team really need your personal opinion on everything? Is your input so different or so critical that it will change the direction of the conversation? Is it core to the issue or just an interesting aside? The more relevant and poignant your input, the more likely people are to stop and listen.

Teams are as unique as individual relationships. Sometimes they work like magic. Sometimes they stumble along clumsily. Most shift back and forth between these extremes. It should always be our goal to lead an effective team when we are in the position to do so. And it should always be our goal to be a member of an effective team when we are not.

Don’t forget to leave your comments below


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.

Six Steps to a Strategic Situation Analysis with SWOT

Creating a Company Strategy: The Challenge

Jack, a new senior vice president, had been tasked with preparing a situation analysis report that senior management would use to help form company strategy. Since Jack had never contributed to company strategy before, he reviewed his predecessor’s analysis. He discovered that the previous year’s report did not capture the information that senior management would need, nor did it include a way to present that information in a manner that management could use to create a clear strategy. Additionally, the analysis did not reflect his team’s capabilities or ideas.

It became apparent to Jack that his predecessor hadn’t used the situation analysis report as an opportunity to create a collaborative exercise that involved all the team members. This explained something else he had observed when he had taken over: his team didn’t know anything about the previous situation analysis and had no idea how it had contributed to the company’s strategy. Not surprisingly, his team felt disconnected from the company’s current strategy and goals.

Assessing the Situation

Jack realized the necessity of acquiring tools to elicit and articulate his team’s contributions and also present them effectively to management, otherwise it was unlikely that his input would be incorporated into the company’s strategic plans. Without that input, Jack’s team would lack the focus, commitment and buy-in essential to the success of any strategic overhaul. And, if the process didn’t motivate and energize his subordinates, involvement in preparing the report would be viewed as one more task imposed on them that would negatively impact their day-to-day responsibilities.

The Solution: The Six-Step SWOT Analysis

The team adopted the SWOT Analysis framework as part of a series of collaborative work sessions that would effectively prepare their current situation analysis report. SWOT analysis is a strategic planning method used to evaluate the Strengths, Weaknesses, Opportunities and Threats involved in a project or business venture, indicating where opportunities and risk should be pursued, where certain threats or risks should be avoided, and if resources are allocated properly. With my help, Jack implemented the following six-step process:

Step 1. Organize Teams of Four to Six Individuals

Once the teams are divided, designate a facilitation team that will be responsible for orchestrating the multiple meetings of the other teams, including coordinating the logistics (meeting rooms, pens, flip charts, etc.) for the meetings.

Step 2. Provide Pre-work to Prepare the Participants

Create detailed event information and send the package to meeting participants in advance. Include listings of all the meetings, agendas for each of those meetings, and the purpose and objectives of the process. Recommend document sources that staff can use to augment their individual thoughts on internal and external factors influencing the business (e.g., analyst observations on industry environment, reports on macroeconomic conditions, market segmentation data, internal performance metrics). Ask participants to group key factors under categories that you provide (e.g., resources, competencies, managerial deficiencies, inadequately skilled resources). This prompts the participants to identify broader categories that specific factors fall into.

Step 3. Conduct Round-robin Meetings to Collect Input on Internal Factors

A facilitator for each team will ask each participant to provide a list of internal factors. Write the internal factors on individual sticky notes or 3×5 cards and place them so they are displayed clearly. Group the factors that enhance the company’s situation under Strengths and those that weaken the situation and competitive position under Weaknesses. Facilitate a discussion that generates more factors, deepens understandings of the factors and uncovers relationships between them. Record the results of these discussions on the related notes or cards.

Step 4. Conduct Round-robin Meetings to Collect Ideas on External Factors

Have the teams repeat the round-robin exercise looking at external factors. Group these under the headings of Threats and Opportunities. Threats are those factors that are possibly detrimental to the organization’s competitive position in the marketplace; opportunities are factors that enhance the company’s position. Make it clear that some factors can appear on more than one list. For example, an opportunity can also be interpreted as a threat (if, for example, the opportunity is seized by a competitor).

Step 5. Vote on Top Strengths, Weaknesses, Threats and Opportunities

Collate the lists from the individual teams and put them in a central location where all of the teams can review them. Schedule a time for participants to vote on the top three strengths, weaknesses, opportunities and threats.

Step 6. Prioritize Strategic Alternatives

Have the teams brainstorm, using the “top three” lists created in the previous steps. For each opportunity, have participants identify the company’s relevant strengths and weaknesses. Repeat the process for each threat, identifying the strengths that the company can use to defend itself from the threats and the weaknesses that leave the company exposed. When the company has corresponding strengths and few weaknesses, this opportunity should be pursued vigorously. On the other hand, the company should consider exiting those areas where it has many threats and many weaknesses (especially if the threats target the company’s weaknesses). Where it makes sense for the company to stay in threatened areas, the teams should recommend how existing strengths can be redeployed or acquired. Where there are opportunities worth pursuing, but the company lacks strengths, recommendations can be prepared that include partnering with other organizations or acquiring the necessary skills or resources through other means.

Final Assessment

Jack personally orchestrated the process, setting up a series of half-day work sessions that involved his direct reports and several members of the functional areas reporting to him. He had the groups use SWOT analysis as a key job aid in their work sessions, supported by facilitators who understood the process. Jack also brought in outside facilitators to elicit objective opinions and discussions.

The teams, which in previous years dreaded the paperwork demanded in creating a situation analysis, were now energized by the interactive work sessions. Furthermore, they left the meetings feeling their ideas would be used in the strategic plan that the corporation adopted and that any resulting strategy was going to be their strategy. They weren’t disappointed, either. Because the resulting report summarized key factors and tied them directly to strategic alternatives, the document had a significant impact on the development of the company’s strategic plan.

Don’t forget to leave your comments below


Ramana Metlapalli is author of Learning Tree Course 252, “Strategic Planning for Organizational Success”. Ramana specializes in advising high-technology companies on their strategic initiatives. Learning Tree International is a world leader in hands-on training for Management and Technology Professionals. Since 1974, over two million course participants from over 65,000 organizations around the world have enhanced their skills through intensive hands-on exercises under the guidance of expert instructors with real-world experience. Visit us at www.learningtree.ca.

Managing Risk the Tour de France Way

ManagingRisk2It’s the third mountain stage in the Tour de France (TdF). A few riders are in the lead as they wind their way up a mountain. The number of riders in the lead group starts dwindling – 12, 10, then 8. All of a sudden, around a hairpin bend, Jan Ullrich weaves across the road accelerating, pulling away from the pack. What will Lance Armstrong do? Chances are good that the US Postal team has thought about this risk and planned for it. This means that Armstrong will know exactly what to when Ullrich pulls this move, and the team has responded to many other risks up to this point to get Armstrong in the lead group.

Before I “race” into what Armstrong does and how the TdF teams manage risk, I figure that I should discuss risk analysis. Risk Analysis is technique 9.24 in the BABOK v2.0 that you should become familiar with. If you’re not familiar with risk analysis, this is the article for you.

A risk is an uncertain event or occurrence that can have a negative or positive effect on the project team’s ability to achieve an objective.

How do you plan for uncertain events? Through creation of a risk management plan!

The risk management plan includes a list of the possible risks that you may face during the project. You should create this at the beginning of the project, and update it as the project progresses. Each risk should include a description of the risk, the likelihood that a particular risk will occur and its impact, and how the team is going to respond to the risk should the risk become reality. Now because risks are really uncertain events, and uncertainty is just, well, uncertain, you can’t possibly plan for every risk so concentrate on those that are more likely. For instance, if one of your stakeholders suggests that you hold your requirements workshops in the building’s new outdoor garden courtyard, a reasonable risk would be that it might rain forcing cancelation of the workshop; while pieces of Skylab falling out of the sky would not.

Another thing that you need to include in the plan is your team’s Risk Tolerance. This is how much risk can be tolerated, and it may be different at different points in the project. Tolerance levels are: Risk Averse – will seek to reduce negative risks and accepts reduction in potential benefits in return for a more certain outcome; Risk Neutral – the benefit of the risk response must outweigh the “costs”; and Risk Seeking – willing to accept high risks in order to maximize chances of success.

Let’s look at the relationship between probability and impact. Suppose that we come up with a risk that it might rain on the day of our requirements workshop. The probability would be the chance that it would rain. The impact could be high or low depending on the availability of a tent or shelter. Our response could be different depending on how we plan to respond. For instance, we might avoid (hire a company to erect tents in the courtyard), accept (oh, well, we’ll just get wet), or mitigate (negotiate with the stakeholder to host the meeting in the company boardroom instead to lessen the chance of the impact). How do you determine probability? Look at the weather report, or if it’s too far into the future, look at the region. If you’re in Seattle, rain probability is High – Arizona? Low.

At this point, you have a list of events that may occur such as the table below.

ManagingRisk1

Risk Probability Impact Trigger Response
It may rain during the outdoor workshop High Low Begins raining Avoid – we will erect tents in the courtyard garden large enough to house all meeting participants

So how does all this risk management work in the Tour de France?

The TdF is a grueling 2,000 mile + stage race, with twenty teams and 10 riders per team. It takes place over three weeks in July, and the winner is the one with the lowest overall time across multiple individual day races (called stages). Very simple objective – tough to get there.

Each team has examined its own strengths and weaknesses, so they have their own way of approaching the risks that present themselves in the race (you have performed a SWOT analysis, haven’t you?). Let’s look at one team’s stage one risk management plan. No one has started racing yet, so there is no leader. It’s a flat stage so there will be a mass sprint at the end. Your team does not have a great sprinter (your team’s weakness), so you probably are going to consider yourself risk-averse at this point. You don’t want your riders to risk getting caught up in a big crash at the end, ruining those cyclists on your team that are really good in the mountain stages (your strength). So, let’s create a risk. The risk is that your team will likely not win this stage. The probability that this will happen is high because you don’t have a strong sprinter. The impact is low because in this stage, riders will only be seconds apart instead of minutes or hours, and that time will be easily gained in the mountain stages. Your strategy is then to accept the risk. There is no real effort to try and win this stage because you are going to win in the mountains with your climbers.

So, now we’re into week two of the TdF and in the mountains. Armstrong is in first place overall, but there are some challengers who are within striking distance and could challenge him for the yellow jersey (what the overall leader wears in the race). Lance also put in a very fast climb yesterday so he has a two-minute advantage over second place. Will we be risk averse or seek risks in today’s race? Generally, the strategy would probably be neutral – protect the yellow jersey and only attack if the opportunity presented itself. Let’s list some of the risks that may be on this day’s risk management plan.

Risk Probability Impact Trigger Response
Jan Ullrich attacks High High Ullrich accelerates on a climb Mitigate – Armstrong will hang on Ullrich’s wheel, making Ullrich do the work but will not let Ullrich gain time.
Stephane Heulot attacks on the mountain stage High Low Heulot accelerates or breaks away on a climb Accept – Heulot is 45 minutes behind Armstrong in overall time and will not be able to gain that much time on the climb. Armstrong will not win the stage, but will not lose the overall classification. Armstrong will let Heulot get away.
Richard Virenque attacks High Medium Virenque attacks on a climb Exploit – Virenque is an excellent climber, and if Armstrong can force Virenque into the attacking position, Armstrong can ride on his wheel, making him do more of the work while Armstrong still retains the lead in the overall classification.

These are just some of the risks that the race team managers and the riders face every day. They plan for some of these uncertain events and react based on the response that they have planned out. How can you use the lessons from the TdF on your projects?

Follow these three steps:

  1. Think about what uncertain events might arise within your project. Write them down. These are your risks. For instance, one stakeholder would like to hold the requirements workshops in the company’s new garden courtyard. A risk may be that it might rain during those sessions.
  2. For each one of those uncertain events (risks), determine what the likelihood is that each one will materialize and then the impact of that. In Seattle, WA, raining on outdoor events is a higher priority than it is in Phoenix, AZ.
  3. Determine what will trigger the realization of the risk (how you know that it’s happening), and how you will respond when it occurs. This is your risk response. For instance, if the rain starts, that will trigger your risk response. You then know exactly how your team is going to respond because you have thought it out ahead of time.

Remember, BAs should perform risk analysis because not everything will go as planned. By developing appropriate responses, you are effectively planning for some of those situations that may not go as you expected. You will be able to keep the project moving in order to accomplish your objectives and not stumble or stall because the team doesn’t know what to do.

So what did Armstrong do when Ullrich attacked? Armstrong accelerated right along with him. He knew the risk that Ullrich posed, but instead of thinking about his response, it was calculated and thought out that morning with the team director. But don’t worry about Armstrong coming into your company and taking over your job as a BA just yet – he’s training for this year’s TdF showdown with Alberto Contador.

Don’t forget to leave your comments below


Paul Mulvey, CBAP, is a Lead Business Systems Analyst at UPS. He currently rides a Merlin road bike and runs a 53/39 up front and an 11-21 in the back, although with that ratio, the climbs seem to get harder each year. He can be reached at [email protected].