Collaborating with stakeholders

The success of any project depends on understanding what is needed and addressing that need. It is usually not the technology. Needs equate to requirements. Most projects don't dedicate enough time or resources to requirements, resulting in our grand success rates of about 37% (Standish Group, 2012). Studies have directly linked 60% of software defects to incorrect or incomplete requirements; however, most projects spend less than 8% of their time on requirements (Wiegers, 2003). Doesn't it stand to reason that projects need to spend more effort on requirements to save the rework associated with bad requirements?

Other studies (Atkins, 2013) have found that more successful projects spent between 20 and 30% of their time on requirements definition, elicitation and management. Other sources have stated that the magic number is 27%. Whatever the number, it's significantly more than the 8% that most of us are spending.

Let's clarify what we mean by requirements. In my experience, requirements have three definitions for project needs:

1. The Charter – The first step in defining successful projects is to identify the underlying problem. In Project Management Institute's (PMI) world, the charter is the document that should define the problem and any other information related to the issue at hand (like justification, benefits analysis, case study) that may shed light on the real need for the project.
2. The Project Scope – The scope addresses the things that the project will deliver that will address the problem uncovered in the charter. There are very high levels of requirements that must be uncovered prior to even scoping the project. These are usually business and stakeholder requirements with parts of functional requirements as well.
3. The Requirements – After the project scope is defined, the project team must dig into more detail about the things they are expected to deliver. These are what most people call the requirements. These requirements may be broken down into several levels of detail and contain the business, solution, stakeholder and transition requirements.

In this context, the term requirements involve all three levels of needs.

The Challenges

There are inherent challenges with understanding the real needs for each of the levels of requirements.

1. The Charter – If a charter is done at all, it may state the goal and objectives of the project, not the real need or the underlying problem. Or worse, it may define the solution. Too often the project is kicked off without understanding why the business chose this project (or solution) in the first place. “It's just what we want to do” is the mantra. Often the charter (or business case) focuses on justifying the solution rather without knowing what the underlying problem is.
2. The Project Scope – Many the scope statements I've seen address how the project intends to address the needs, rather than defining what should be delivered. The integrated plan and the design should specify how the project would address the needs.
3. The Requirements – The business analyst (or person responsible for the requirements) focuses much more on the technique, structure and style of the requirements than the content or validity of the requirements. I've seen projects that are expected to deliver a solution without access to the right stakeholders, subject matter experts (SME) or users. Also, too frequently the requirements are cut short and the technical team fills in the gaps, resulting in a product that doesn't meet the business's needs or expectations.

The list goes on for challenges related to requirements at any level. Most of the challenges have to do with getting the project stakeholders involved in the requirements process. According to PMI, a stakeholder can be the sponsor, customers, users, business analysts, SMEs, core technical team… everyone that has a stake in the project.

I've used some techniques that help encourage creativity, structure, or participation; but all of them fell short in helping to uncover requirements and ensure they are the right requirements. I always thought there should be a better way to uncover requirements in order to avoid many of the challenges. During my career and studies of many different techniques, our team has developed a great technique that encompasses ideas from:

Collaborative techniques

Compression Planning^®

Brainstorming

Joint Application Design (JAD)

Multi-voting and Analysis

Agile development principles

PMI's Project Planning Processes and IIBA's Business Analysis Processes

Storyboarding

This is a long list because it took several long careers to learn and use all these techniques. We've given it an acronym to simplify its name: C-MAPS. Since Compression Planning, Brainstorming and JAD are a type of collaborative technique we included them with the C for Collaborative. We named it that for this paper since we didn't know what else to call it, it is not exactly like any of its parents, so we gave C-MAPS its own name.

The C-MAPS Technique

First of all, I want to clarify that this technique is as flexible as you are. It can be used for just about any group session, from strategic planning to creating a work breakdown structure. This paper is going to concentrate on using it to elicit and validate requirements.

C-MAPS sessions are very structured, visual group sessions, which allow participants to have some fun while brainstorming and analyzing project requirements.

Too often, when in a brainstorming or requirements meeting, we believe we all know the topic and the project. The topic and the project purpose are a given, so no one debates or wastes time going over it. The team jumps right into the session with little preamble or introduction. This tendency to jump in and start quickly usually results in an unproductive meeting that either:

1. Very few ideas are discussed. Because someone in the group brought up a topic and everyone “ran down the rabbit hole” right behind them. A lot of times, not understanding the big picture causes tunnel vision on the part of the team.
2. Way too many inappropriate ideas are generated because the brainstorming got out of control.

As a project manager I've seen the same thing happen to my projects if the team is not clear on the goal and scope of the project. The C-MAPS process was designed to prevent either of the above scenarios.

Frequently there is not enough time to get all the requirements, or they are just so big and complex that they are difficult to organize and explain using more traditional techniques. C-MAPS has inherited a number of great features from its parents to help eliminate a lot of the problems associated with requirements elicitation and validation.

1. The technique is great at helping teams generate great ideas, given a short amount of time. We inherited these concepts from brainstorming and compression planning.
2. C-MAPS provides a clear background and prepares the participants for the session and project to follow, as with JAD, collaborative techniques and compression planning.
3. It is a very visual tool like story boarding.
4. Keeps the team focused on the project and requirements for a particular area as with JAD and Compression Planning.
5. Allows the team to decide the BEST ideas generated through multi-voting and analysis
6. C-MAPS is disciplined to ensure outcomes while being flexible-enough to allow participants to drive the progress and content of the session. We get a lot of these concepts from our more agile parents.
7. Through this entire process, we use many of the Project Management Processes to scope, plan, communicate and ensure all stakeholders of the session are clear about the expected deliverables.

Planning the Session

The C-MAPS plan is extremely important to the success of the session. The session should be planned with the project sponsor or senior project team members to ensure that the session produces the necessary deliverables (or outcomes.)

Each session plan should have these key components:

1. Project Goal: Describes the issue to be addressed. Be as clear as possible so that everyone in the meeting has the same picture. The tough part is to get it into one line. For example, I will use an example from a volunteer organization I worked with recently that changed its entire board and the new board was not sure where to go. The project goal card said, “To define annual projects for our organization”.
2. Project Background: Facts that support the goal. Ensures that everyone in the C-MAPS session has the same understanding about the project. It explains, “How we got here” and describes critical bits of information that each participant should know. Spend some time with the sponsor developing this area. You want to be specific to prevent anyone from assuming everyone has the same vision just because they have worked together in the past, or are from the same company. The truth is, they probably don't. For example, this section of the plan described the organization's mission and some of the projects the organization accomplished in the past.
3. Project Objectives: Don't just cut and paste the objectives right out of the scope statement. It should answer key questions like “Why are we doing this project?”, “What do we want to change and by how much?”, “What do we expect to accomplish with this project?” For example, “We want to restore the organization to its former glory, increase our revenues and provide better support to the park”; another objective was: “We only have so many people, we need to make sure we're putting our energies into the RIGHT things.”

Some groups meet for hours, doing stuff with no clear idea of what they are really there to accomplish. Even though it may take a little while to perfect the goal, background and objectives while planning for each session, it will save even more time and reduce confusion during the session.

The following sections of the plan focus on the C-MAPS session at hand.

1. Expected Accomplishments During This Session: This defines the scope of the particular session. It gives participants a clear idea of what they are expected to do during the meeting. It spells-out the things (or deliverables) that you will have at the end of the session. I've found that if you let people know what's expected they will live up to that, especially if they are very analytical or technical people. For example, “Generate ideas to revitalize our organization”; “Brainstorm new projects that will help us generate revenue and visibility in the community”; “Select the top 3 projects for this year”.
2. What's NOT Expected During this Session: This section of the plan clarifies what is out of scope for this C-MAPS session. It is a way to reduce the amount of scope creep during the meeting. Sometimes we have people (especially those that are analytical or technical) that immediately start putting time, effort or cost estimates on an idea. You can state, right up front, that we are not going to worry about cost or time estimates today. I've even seen people that try to always put off the decision and make it someone else's responsibility. You can prevent the “pass the buck” syndrome by saying, “Refer the issue back to…” By stating these things up front, you are not pointing the finger at anyone and the team will remember these “NOTs” and will police themselves and stay off that tangent. For example, “Debate how we will do these – we'll get there eventually!”; “Debate resources (if we need more volunteers, we'll figure out how to get them.)”
3. Agenda: Be specific about how much time is available and plan the session to stay well within that time. For instance, a 10-minute brainstorming session is a lot of time when you are brainstorming within the area that has been defined by the cue card.
4. Cue Cards: The purpose of the cue cards is to do two things: focus participants into an area while at the same time encouraging them to open up their minds within that area. The cue cards should be thought provoking and worded in a way to get participants talking. We all struggle with writing cue cards because the thought-provoking words don't come easily to us. Try not to just state a one-word fact or just convert your cards from # 4 above. The cue cards should be creative. Example: “What new projects do you think will be fun for the organization as well as people visiting the park?”

There are additional components of a good design:

1. Action Plan: Usually developed during the session. Be as specific as possible about what will be done after the session and who is going to be responsible for getting it done. Assign participants to follow up and define what they should do. You may even go so far in your initial brainstorming session to come up with an action plan for moving forward on your choices.
2. The Communications Plan: This part of the session may be part of the action plan. It's usually developed near the end of the session. The communication plan defines who needs to know about what is happening with the project requirements. This communication plan should complement the project communication plan.
3. Visual Creativity Gage: It resembles a speedometer. When it's set high, anything goes, meaning that we are looking for a lot of very creative ideas. When the gage is set low, it means that we're not looking for new ideas; we're at the stage where we are categorizing, focusing, and coming up with an action plan.

Exhibit 1 – C-MAPS Planning layout.

After the business analyst or project manager have planned and designed the C-MAPS session with the sponsor or senior project team members, the time comes to hold the session. There are several things to keep in mind before walking into the room though.

The facilitator: a facilitator should always run the sessions. That is, someone experienced in facilitation principles and who knows how to guide a group of people through a process to an agreed-upon end. The facilitator should never be a person that has a stake in the outcome. If they are a core project stakeholder, they probably have something to contribute. Let them contribute and not facilitate. Make sure you have a facilitator that is an unbiased third party.

Include the right people: The other major thing that should be accomplished prior to the C-MAPS session is to ensure you have the right people in the meeting. This is one of the biggest challenges facing projects today, to get access to the right stakeholders. So far we talked about the sponsor. They play a key role in demonstrating to the participants the importance of the project. It would be ideal to have the sponsor kick off the session and go through the goal, background and objectives. You may ask the sponsor to leave the meeting after they've presented the background and project objectives. Often, their presence can stifle creativity. You may want to invite the sponsor to close the session after you've reviewed the outcomes with them. It's up to the team, the project manager and the sponsor themselves how you will use their expertise.

In addition to the sponsor, you want to make sure you have the best people you can in the meeting. If this is a very detailed, analytical meeting, you want to have more of the people doing the work in the session. If you are having a brainstorming or idea-generating session, you want open-minded, creative and knowledgeable people there. If you are going to be making decisions on what to do, you need decision makers there (and people whose decisions will not be over-turned when senior management sees the decisions that were made.) If you are doing a C-MAPS session for creating a WBS, you want to make sure you have people there that are familiar with the deliverables, qualifications of those deliverables and the work that has to be done to create them.

Another key benefit to getting the right people is diversity. Having a diverse group when you're brainstorming or idea generating is necessary. If everyone has the same values or same experiences, their ideas will not challenge each other. The best groups for requirements include business SMEs, technical SMEs, analysts, managers from the affected areas, and the project manager. This diverse group will have different views of the same system and will have differing (often opposing) views of what is needed. Now, during the C-MAPS session, is the time to discover opposing views, not after things have been built.

Practice, Practice, Practice: The facilitator and the project manager or business analyst need to work together to make sure the C-MAPS session runs as smoothly as possible. You will need to complete the plan laid-out above, create story boards with the design using large sticky notes or printed cards. The team will need supplies like additional cards or sticky notes and pens. There should be a timer with a stopwatch (or timer app on their phone.) Also, when scheduling the room for this session, make sure you have lots of wall space for the team's ideas and room for participants to move around (creativity can often be spurred by physical movement).

In addition to providing the physical things needed for a smooth session, the facilitator needs to mentally role-play how the session will proceed. They know that these are people and it is impossible to predict exactly what they will do, but having a plan or idea of the progress will help keep things moving while at the same time allow the facilitator and team to be flexible as things come up in the session.

A general rule of thumb is to spend at least as much time designing as facilitating. However, I've found that the shorter the meeting the more precise the design must be, so more time needs to be dedicated to creating the design.

The actual session

This is where the “rubber meets the road” or where all your hard work will pay off. There are several things to be aware of during the C-MAPS session. They are facilitating and staying focused.

Facilitating the session

The responsibilities of a facilitator are huge. The entire session, no matter how well planned, can fall on its face if it is not well facilitated. A good facilitator knows that their job is to:

1. Ensure everyone participates. There are many ways to get total and fair participation from everyone. A technique that I really like is the Crawford slip: give blank sticky notes to the participants and they each write several ideas. The Crawford slip is a great tool for helping to get the quiet, shy person to give their ideas. It also is a way to prevent “grand standing” or having a dominant person in the group. It's also great for time-constrained meetings. You can get a lot of ideas out very quickly using this technique.
2. Manage dynamics of the team. The definition of dysfunctional behavior is any activity that is a substitution for expressing displeasure with the session content. Dysfunction in the group is one of the most devastating things that can happen to a C-MAPS session. The facilitator needs to look for even the slightest indication that there is conflict in the group. If any dysfunctional behavior is not addressed, it tends to worsen over time. It's easier to stop dysfunction early in the session than to try to address it later. A well-planned session (as defined above) may help to avoid some of the dysfunctional behaviors.
3. Gain consensus. Consensus does not mean it is always the best decision. It means that the entire group agrees with the decision and will support it. Often there are disagreements. A good facilitator will ask questions to encourage careful listening and slow the conversation to force the participants to really listen to each other. If the disagreement is caused by the solution that is under discussion, the facilitator will lead the group to find the cause of the disagreement. The key is to work with disagreement, not run away from it. Disagreement will often lead to a better solution in the end.
4. Know what the deliverables are for the session and keep the team moving toward them. The facilitator and group-leader must never lose sight of the outcomes of the session and the purpose of the session. In spite of the need to be flexible and have fun during these sessions, a good facilitator must still be driving the team toward the desired end for the session.

Reading books about facilitation techniques is great; there are a lot of good books available on the subject. However, it doesn't all come together until you actually facilitate several sessions. Start small, and then build up to larger, more complex sessions. In spite of the reading and experience, a good facilitator also has a caring personality. These are the characteristics that will be found in any good facilitator:

• Facilitators are people people. They value each participant and their views. A good facilitator wants each person to leave the session feeling that they were welcome, heard and understood during the session.
• Facilitators want to help. The origin of the word facilitate is the Latin word facilis, which means, “to make easy” or “help bring out.” Facilitators get pleasure from using their expertise to help others succeed.
• Facilitators put their egos aside. They understand that their presence is secondary to getting to the outcome. Facilitators believe that their personal views are not only inconsequential, but may actually hinder reaching the best solution for the group. They are willing to play as little or as great a role as necessary to help the group succeed.

Staying Focused

In addition to facilitating the session, staying focused on the purpose of the session is one of the most important things the team needs to do during the C-MAPS session. You've designed the session, spent time with the sponsor (or senior team) and determined what the deliverables of the session should be. Now, you just have to make sure you get there. The facilitator's role will help a lot in staying focused, but the project manager (or business analyst) need to help the team stay focused too. Allowing the team to run down “rabbit holes” or tangents is only detrimental to the C-MAPS session. With that said, there are times when the team really does need to investigate a “rabbit hole” to fully understand the consequences of their decisions.

Be flexible during the session, but make sure you come back to your primary purpose.

Conclusion

The C-MAPS technique is useful in many situations, especially in requirements elicitation and validation. If the technique is used correctly you can reap a wealth of benefits. The benefits include:

• Reduced time to generate requirements.
• Requirements are validated right in the session because participants argue, play with and vote on the requirements that are generated.
• Reduce the risk of scope creep from 80% to 10% (Gottesdiener, 2002) because the people that have defined and worked together for the requirements are not likely to change those requirements.
• Increases buy-in because key resources contribute to every aspect of the requirements and those same people go back to their departments, feeling good about the session. Their excitement about the new project carries over to other people in the department.
• Increases the quality of the solution. Fewer requirements-related defects are found.
• Improves the working relationship between the team members from different areas of the organization. They work together in the C-MAPS session to define, argue and analyze different areas of the project to agree upon one outcome.

We want to improve our project success from an average of 39% to over 80%. One of the biggest challenges to that dream is working on the right things, doing it quickly, staying within our budgets and delivering a quality solution. We can do it, collaboratively!