The business analyst should be playing a big role in the planning the project, at least from the perspective of the business analysis activities and organizational readiness. The business analyst is focused on making sure that the plans allow for a solution to be accepted and used by the end users so that the solution can bring value to the organization. The project manager is more focused on the activities of the project team to support development and implementation of the solution. Some of the planning activities will roll up into the project management plan, whereas others will represent a joint effort with the project manager. The business analyst is an active participant in planning, not a recipient of someone else plans. This will set the project up for a greater chance of success.
Conduct Stakeholder Analysis
Here is one activity that is seemingly the same for project managers and business analysts. While not specifically called out in either “body of knowledge”, the intent is that the business analyst is responsible for stakeholders of the solution, while the project manager is responsible for stakeholders of the project. Stakeholders of the solution are also stakeholders of the project, but the communication and risk mitigation strategies will be focused on the use of the solution. The project should have only one stakeholder analysis document, but will include both project and solution stakeholders. Don’t worry. There is plenty of stakeholder communication to go around for both.
There are many questions we need to answer with our stakeholder analysis.
• Who are stakeholders?
• What is their stake in the project (what do they care about)?
• What type of influence and impact can they have on the project?
• What do they expect from the project and/or the project team?
• What risks do they present to the project?
• What risks do they perceive for the project?
• What is the best way to keep them apprised of project status and information given their stake, interests, and communication preferences?
• What other groups or individuals do they know that have a stake or interest in the project?
I initially developed this list when I was responding to a Request for Proposal (RFP). The RFP requested information on how the project would be managed throughout the various aspects. About the fifth time I referred to stakeholder analysis I knew I was on to something. I published one of my first blog articles17 as a result of this epiphany.
Answering the above questions about the project stakeholders will help the project succeed in many ways. However, the most obvious advantage to a thorough stakeholder analysis is to reduce the risk of missed requirements. Think back to a project where requirements were missed. Why were the requirements missed? Was it because a stakeholder was missed or not adequately engaged? This is huge on projects! A thorough stakeholder analysis will also help the project in identifying risks, assumptions, and constraints on the project that may not be obvious. The key to great projects, aside from a top-notch business analyst, is a thorough stakeholder analysis. Let us take a look at our stakeholder analysis for the Requirements Management Tool project.
Liz and Mary each spent some time identifying project stakeholders by brainstorming with project team members and talking with stakeholders that have already been identified. They took this information to have a lengthy discussion about stake-holders including understanding their stake in the project, communication preferences, and such. The stakeholder register shown on the following pages represents what they know about stakeholders today. They have agreed to review the register every two weeks to determine if there are new stakeholders to be considered or if anything has changed with the stakeholders and needed changes in strategy for engaging the stakeholder.
Plan Business Analysis
The work of the business analyst affects the work of all project team members. Designers, developers, and testers are dependent on what the business analyst delivers, when they deliver it, and the quality of the work. Planning is needed to make sure all of the work supports a smooth transition from one role to the next. The business analysis plan will feed into the overall project plan and schedule for a cohesive understanding of what it will take to complete the project.
We often see in projects where the business analysis planning is limited to “getting requirements done in one month”. This is an arbitrary constraint that will ultimately put requirements and the project at risk. Don’t do it! Instead, give the business analyst time and resources to plan the business analysis activities they need in order to get good, complete, quality requirements. The level of effort and leeway for business analysts to plan their activities should equal that of the developers or testers in project estimation. Without these, the project will fail! The time given to a business analyst to complete their activities should be based on the real need, and not an arbitrary deadline. Got it? Good!
Use senior business analysts familiar with business analysis frameworks,18 education, and experience to develop a plan specific to the project for the best results. It is important to understand the difference between a framework and a methodology. The story on page 46 provides an example of when one organization attempted to create a stringent methodology for business analysis within the organization.
Figure 12 Example of Stakeholder Analysis
I once worked in an organization that had identified a need for better business analysis practices. They took a slightly different approach to address the issue.
First, they assigned a special project to a very capable senior staff person. This person was not a business analyst, but was well versed with research and discovering best practices. She proceeded to develop what she called a “cookbook” of how to perform business analysis within the organization complete with templates. It was a very stringent methodology designed to take any person through the business analysis steps regardless of experience. The “cookbook” did not stand the test of time. There were several factors that kept it from being a sustainable solution.
1. Each project is unique, and a one-size-fits-all approach will never meet every need.
2. Business analysts were given the final processes to follow without having been adequately consulted in developing the processes.
3. The “cook book” was used in lieu of training and developing competent business analysts.
Support junior business analysts with the right support, mentorship, education, and opportunities to develop into your next generation of senior analysts.
The best way to come up with a plan is to first identify what must be delivered. The business analyst should develop a work breakdown structure of the items they must deliver to the project manager, the project team, and to the end users of the solution. From there they can begin to evaluate what activities they must do in order to create those deliverables. They can further spend time looking at whether there are any constraints or other needs in order to completely develop those items. Other things to consider when developing the business analysis plan are the sequence of the activities and the level of skill needed to complete each. One result of the plan may be an indication of additional business analysis resources and/or time needed. While it is prudent to look for ways to reduce the effort needed, avoid arbitrary constraints that will limit the ability to get great requirements for your project.
Liz knew there was a lot of work to be done in order to get a complete set of requirements to support the new RMT tool. She wanted to make sure that she didn’t miss anything, so she opted to use the BABOK® Guide v.3 tasks (see Appendix E—BABOK® Guide v. 3 Knowledge Area/Tasks) as a guide to planning her effort. She created a checklist based on these tasks to help her in identifying and estimating the tasks she needs to complete to support the project. The stakeholder analysis contained information on some of the activities she should need to plan for in order to manage stakeholder engagement and ensure their requirements were considered.
Mary was able to use the information Liz provided to plug into the project schedule. This provided a big advantage in her resource planning. She was able to negotiate for developer and tester resources with much more certainty on when requirements would be available and would be needed.
Figure 13 Example of Business Analysis Schedule
The business analysis plan with schedule is a great tool to track the work required for business analysis and its progress, but also serves as information to project stakeholders, especially the core team members, on what to expect and when.
Another benefit of the business analysis plan is that it provides business justification as to the time and resources needed to complete the business analysis activities and provide great solution requirements to the project team. Oftentimes, business analysts are given that constraint to “just get the requirements done in the next two weeks”, and this is not realistic. In order to have great requirements for your projects you need to ensure that proper planning takes place and that the time and resources needed are given. This idea speaks directly to the PMI and the PMI-PBAMSM credentials and reason for it. If 65 percent of projects are challenged or failed because of poor requirements, let’s spend more time planning how we’re going to elicit, analyze, communicate, and manage those requirements.
Plan Communication
The business analysis and project plans contain plans for communicating with project stakeholders. The stakeholder analysis done earlier will also play a huge role in this planning effort. The goal of the communications plan is to determine who needs what information, when, and how. It may seem simple at first until you consider the information that there is to communicate and the multitude of ways there are to communicate.
The plan serves two functions. The first is a way to work with project stakeholders to confirm that their communication needs will be met. A documented plan can be reviewed and adjusted as needed to support his or her needs. The second is it provides a structure to follow for communicating, a structure that the stakeholders have agreed to and will be expecting. This way nobody is surprised and nobody is disappointed.
Figure 14 Communication Considerations
Liz wanted to make sure that she understood the communication needs of the requirements of stakeholders and would have a document that would tell her to whom, when, and how she should be communicating. She referred to the Stakeholder Analysis in order to start documenting some of the communication needs. There were several people that she decided to talk with to get a better understanding of their communication preferences and needs. She feels she now has all that she needs for a solid communications plan that will keep stakeholders engaged and informed, which will in turn reduce the risk of missing requirements.
Mary liked the format of Liz’s communications plan and decided to add her own communication needs to the matrix for the overall project communication plan. An example of communication plan is given below.
Figure 15 Example of Communication Plan
Plan Requirements Management Process
There is a lot to consider when it comes to planning on how to elicit and manage requirements. Think of the following:
• Whom do you need to talk to?
• What do you need to research or review?
• Do you need focus groups?
• How do the requirements need to be categorized?
• How will the requirements be prioritized?
• Who needs to approve the requirements?
• How should the requirements be presented for approval?
• What does the development team need to use the requirements?
• Where, what tool will be used, to store the requirements?
• Will you use a Requirements Management System?
• What supporting documentation is needed for the requirements?
This is just an outline of considerations when planning for the elicitation, analysis, and communication of your project requirements. If you don’t answer these questions and thoroughly plan the requirements management, what you will end up with is a 200-page list of requirements without organization or coherency. Remember those business analysis pitfalls we discussed earlier. Many pitfalls can be avoided by sufficient planning. The stakeholder analysis and business analysis communication plan will provide insights into what will work best for your stakeholders on your project.
Consider two scenarios.
Scenario One
Your business analyst has elicited, analyzed, and presented a requirements package for approval. A response to the requirements package is due at the end of the week. A delay in response will have a negative impact on the project timeline. You find a few minutes and start to look at the document. There is a list of requirements with some information whose purpose you are unsure of. You call a meeting with your business analyst. After discussing the challenges with the package, you both decide that she will create a new package that provides a simpler view of the requirements grouped and ordered by system requirement. She estimates it will take her a week to prepare the new package, and you still need a week to review the results for approval. This creates a two-week delay in the project schedule and prevents staff from moving forward on the solution.
Scenario Two
You have just had a meeting with your business analyst to discuss the plans for eliciting, analyzing, and presenting solution requirements. She comes prepared with a list of items she plans on recording with each requirement along with a communication matrix by stakeholder type, and samples of what each will receive. As you review the samples, you notice that there is not a way to understand where each requirement came from, a stakeholder group, or documented policies, or processes. You also notice that there seems to be a lot of stuff in the report she is planning to present to you for approval. As the discussion progresses, she makes a note to add a new “source” field to her collection and hide several fields from the package she presents to you. It also comes up that you will best understand the requirements if they are grouped by user groups for the new solution. She schedules a “requirements review” meeting with you and several key stakeholders as a follow-up to this meeting as you had requested.
You receive a final draft copy of the requirements package two days prior to the schedule requirements review, and are thrilled to see how the final package came together. It comes time for the review meeting, and you note that half of the reviewers have printed copies and have been taking notes. The business analyst hands out hard copies to the others. The group walks through the printed document. The business analyst is recording notes and changes in the Requirements Management Tool with the screen displayed so the team can confirm the changes. The group prioritizes the requirements as they go, using the MoSCoW19 method that the BA has described in the plan and at the start of the meeting. The day following a meeting, you receive a new copy of the package, ready for approval.
The requirements management plan provides a means to organize how requirements will be gathered and shared with stakeholders. It provides a way to give stakeholders a preview of what to expect, and get their feedback to make any needed adjustments. As the questions at the start of the section indicate, we are taking many things into account such as who can modify requirement, where requirements will be stored, what technology or tools people use to record to update and manage our requirements, what type of requirements reports stakeholders can expect, and more. This little bit of planning upfront can save you a lot of headache on the backside. Think for a moment about what takes the majority of your time. Is it following up on and completing the activities that you have planned for your projects? Or is it, instead, responding to fire drills, those things that were not planned that need your immediate attention? The reason they are fire drills is that there were no plans put in place upfront. Someone doesn’t know how to find a requirement, someone doesn’t know how to read the requirements report produced, someone is looking for information that you have not yet provided, and someone does not have access to the requirements repository. To avoid fire drills, we do more planning at the beginning, and then we can spend our time in the project doing the activities as the plan indicates. This is the basis of the Lazy Project Manager by Peter Taylor. Check this book out if you ever need to be convinced of the benefits of planning.
For the selected project …
1. Were all of the necessary stakeholders identified early in the planning? If not, why?
2. Did the project suffer any setbacks due to a missed or inadequately engaged stakeholder?
3. Was the project given the time needed that the business analyst indicated was needed for completing the business analysis. If not, why?
4. Did project communications regarding the solution and requirements meet the needs of the project stakeholders including the project team?
5. Would you manage requirements differently on your next project? How?
17See also Do You Have the Key to Success for Your Project on my blog at—http://project-pro.us/2011/07/29/do-you-have-the-key-to-successfor-your-projects/.
18BABOK® Guide v. 3 and the PMI-PBAMSM Examination Content Outline provide two such frameworks.
19MoSCoW is a business analysis tool for prioritizing. Each requirement gets a rating of Must, Should, Could, or Won’t be included in the solution.