Daniel Stober, PMP®
Seasoned project managers (PMs) know that in addition to controlling costs and sticking to the project schedule, managing the scope of projects is one of the toughest tasks in project management. The view of what defines project success has progressed beyond management of the triple constraints. Managing for stakeholder satisfaction has become of paramount importance to the project manager. How does a project manager ensure delivery of a project that meets stakeholder expectations? Managing expectations and shaping perceptions through effective communication is important, but effective requirements collection at the outset of the project is the key step that will ensure that the project manager can deliver what is actually expected. In this respect, the
business analyst (BA) must become a key ally and advisor to the project manager. Most project managers are not trained business analysts, so taking advantage of the skill set that a business analyst can offer can greatly
enhance the possibility of project success.
When the PM Becomes the BA
There are many times in projects where the project manager takes on the role of the de facto business analyst. Since there are so many overlapping areas that touch both PMI® defined project management methodology and IIBA®
business analysis methodology, some people view the two roles as interchangeable. But these roles are not interchangeable. There are two distinct job roles for the BA and the PM. The project manager should be focused on the overall performance of the project; business analysts seek to understand the current state of the organization and recommend solutions that will take that organization to a desired future state.
In a functional or weak-matrix organization, this overlapping of responsibilities is more likely to happen. When the project manager’s role takes a backseat to operational responsibilities, managing a project can be tough. When that same PM is expected to also do the business analysis for the project, it becomes even tougher. In many cases where there is no dedicated BA for the project, the solution has already been defined and the project may just be about implementation of that solution. Normally, in functional or weak matrix organizations, the projects tend to be smaller than in strong matrix or projectized organizations. Since the projects are smaller, the project teams tend to be smaller, which makes it easier for the PM to carry out the BA functions.
What are the positives of the project manager being the business analyst on a project? If the PM is trained in BA skills, it can add to the synchronicity of the project by allowing the PM to do the essential BA functions. If he or she is not, it can lead to real problems. According to the CHAOS Report published by the Standish Group, in 2012, over 50% of projects failed or were challenged due to poor requirements development. So how can the BA and PM work together to achieve success?
Stakeholder Identification and Analysis
One of the primary areas where the BA and PM need to align is in stakeholder identification and analysis. Within projects, the project manager is concerned with satisfying key stakeholders, shaping their perceptions of the project, and managing their expectations. Usually, key stakeholders (or those that need to be managed closely), will be identified through an assessment of each stakeholders influence (ability to affect organizational priorities) and impact (active participation critical to project success) in relation to the project. Influence and impact are often assigned a score from one to five, multiplied together, and the product is the stakeholder’s importance score. The higher the score, the more closely the PM needs to manage that stakeholder. Those with high importance scores are deemed to be key stakeholders.
For the BA, it is important to consider all stakeholders and develop a plan to elicit their needs so that requirements are not missed. Practically speaking, it is much more beneficial for the BA to consider a more inclusive list of stakeholders in the discovery process than it is for the PM to manage to a highly inclusive list of stakeholders. BAs need to be concerned with both the business stakeholders who have a need for a certain product, service, or result, and technical stakeholders who will design and build the product, service, or result.
Whereas the PM is primarily concerned with satisfying stakeholders needs through stakeholder management and communication, the BA is focused on making sure all stakeholders are engaged in the requirements elicitation process.
Requirements Collection or Requirements Development?
In formal project management, collect requirements is one of the 47 processes defined by PMI. Once the PM collects the requirements from the BA, who does the requirements planning, elicitation, documentation, and
analysis, the project scope can be defined. From the perspective of the BA, scope management starts with two foundational documents: the requirements charter and the vision and scope statement. The requirements charter for the BA team serves several critical functions. The charter should first define the business need, which is the problem set for which the BA is trying to develop solution recommendations. The charter will also list what the initial scope of the product is and what features or processes are in scope and out of scope. This is important for the BA so that time is not wasted on features or functionality that are out of scope.
The requirements charter also needs to define the requirements development scope, or the work that the requirements team is responsible for. Deliverables, milestones, the makeup of the requirements team, the project manager, and the BA who is in charge of requirements development, all need to be spelled out in the requirements charter. The project charter, on the other hand, is the foundation document for defining project scope and serves as the project’s authorization to commit organizational resources. The vision and scope document for requirements differs from the project scope statement in that the vision (or future state) of the organization and how it will operate post-implementation is defined in the vision and scope document. Because so much of the work of the BA directly affects the overall project scope, it is essential that the PM and the BA work in synchronicity.
Requirements and Project Communication
Communication is vital within projects and contributes significantly to project success. Project managers know that they have to construct a robust communication management plan for the overall project. The communication management plan should be designed in such a manner that it defines how project information will be handled: how the project team collects, generates, stores, distributes, and disposes of project information. Considerations will include who gets what information, when, why, in what format, and how and where project information will be archived.
For the business analyst, communication management revolves around communicating requirements. A Guide to the Business Analysis Body of Knowledge® —Second Edition (BABOK® Guide) states that communicating “is essential for bringing stakeholders to a common understanding of requirements.” Of the primary underlying competencies of the trained business analyst, a thorough understanding of verbal communications, teaching skills, and written communications are among the most essential. Verbal communication skills are critical in requirements elicitation. The ability to conduct effective interviews, deliver presentations for stakeholders, and communicate in a simple, consistent manner are all important. Teaching skills are required to ensure that all information that is communicated is understood and retained by the audience. Customizing communications to the stakeholder(s) is an important element of teaching skills. Written communication skills allow the BA to document requirements and elicitation results effectively. Both the PM and the BA need to have well developed communication skills.
Requirements elicitation is the role of the business analyst. It is the BA who is responsible for developing the requirements elicitation plan and then getting the results of that elicitation to the PM. The PM has a responsibility to “collect requirements.” The reason that the PM’s job is to collect requirements and not to elicit requirements is that it is assumed by the use of the word “collect” that elicitation, analysis, and documentation has been done by the BA. Collection is simply gathering something that is ready to be gathered. That task falls on
While it is important for the PM to understand the different techniques and how they should be applied during elicitation, the PM should largely be focused on communicating overall project information to stakeholders, not with developing requirements. There are several ways that the PM can work with the BA to ensure that elicitation goes smoothly. Based on stakeholder analysis, the PM can assist the BA in developing a sound requirements elicitation plan. The PM needs to ensure that there is adequate time built into the project schedule
to accommodate the plan, and can act as a communication conduit for the stakeholders.
Project managers should ensure that the elicitation plan that was put together by the BA and the requirements team support overall project goals. Key stakeholders should be engaged in an appropriate manner, as should end
users and technical stakeholders. Knowing what elicitation techniques to use, when to use them, and why, will allow the PM to verify that the elicitation plan is well thought out.
Just as the PM is responsible for the documentation of all project plans and documentation, the BA is responsible for documenting all requirements and producing and accompanying supporting documents. This is another area where the soft skills of the PM and the BA come into focus. The ability to communicate effectively in writing is critical to ensure that all requirements and project information are fully understood. The BA must be proficient in technical writing practices since the requirements document(s) is a technical document. In requirements writing, there are rules and guidelines that must be followed if the documentation is going to be effective. A seasoned PM or BA should be able to read requirements and know from experience if they are well written.
Since the PM is responsible for the overall quality of the project, the quality of the written requirements falls under this domain. The BA should be on the front line in the defense against poorly written requirements. The PM needs to be the last line of defense. Sticking to a couple rules of thumb and best practices in requirements writing can reduce the amount of time that the BA and PM spend on quality control of requirements. First, stick to “the five Cs” of requirements: Clarity, Conciseness, Correctness, Coherence, and Completeness. The requirements must mean the same thing to everyone that reads them, state everything as simply as possible, represent what the stakeholder’s true need is, stick to information that is relevant to the product, and represent all of the stakeholders’ needs. All requirements must be written in the format of, “the product shall” or “the product must.”
Using language such as “the product will” suggests that it doesn’t have to possess that characteristic now, but it will at some future point. The words “could” or “should” must never be used in requirements, as well as intrinsic qualities like fast, slow, light, heavy, soft, or hard. Vague verbs like maximize, minimize, increase, or decrease must also be avoided. Additionally, phrases like “including, but not limited to,” “where appropriate,” and especially “etc.,” can never be used. The PM and the BA should discuss how the requirements will be documented before elicitation so that there is no confusion and no rework will be necessary.
When the requirements have been elicited and documented, they need to be analyzed in order to turn them into the required capabilities of the solution. One of the analysis activities that the BA will do is solution decomposition. Project managers do decomposition when planning for schedule and cost. Work packages and deliverables need to be broken down to a level that is adequate for estimating. Solution decomposition involves breaking down the overall solution into smaller components in order to achieve a better understanding of the solution and to re-validate it with the stated business objectives. This decomposition can be applied to a feature, function, or goal of the product.
The analysis done by the BA will also cover the stakeholder requirements in order to understand them from the stakeholder’s point of view. Especially here, the PM can assist the BA due to his or her familiarity of each stakeholder. Functional requirements are analyzed in order to ensure that the process is fully understood. Use case modeling can help to define additional functional requirements that may have been missed. Analysis of non-functional requirements (NFRs) can also help to identify where something may have been missed. One commonly missed NFR is training that will allow an implementation to be fully effective.
Assumptions and Constraints
Just like the PM has to ensure that key assumptions and constraints are listed in the project charter, the BA has to conduct analysis to determine key assumptions that have been made and constraints that the team faces. The PM and the BA should collaborate here because many of the assumptions and constraints that the PM identified during development of the project charter will apply to requirements as well. It is also important for the PM to understand the design and solution constraints that the BA is facing. Constraints also need to be analyzed to ensure that they are not restrictive to the point of making implementation overly difficult.
Traceability of requirements is vital to ensure that the scope of the product does not get out of control. The BA should be tracing requirements from the beginning of the process and not wait until all requirements have been elicited to trace. It becomes more time consuming and difficult if tracing is left until the end. The BA will trace requirements backwards to tie them to a specific stakeholder and business need. This satisfies two important functions: stakeholders can be held accountable for their stated requirements and the BA can validate that they support a specific business need. Tying a requirement to a specific stakeholder can assist in the requirements signoff process, and signoff can be done incrementally. Requirements signoff can be a laborious process if it is attempted in a single session with stakeholders, and therefore should be decomposed and done whenever appropriate. It is often easier to get signoff in smaller chunks than it is to get signoff on all of the requirements
Requirements also need to be traced forward and matched to an element of work on the work breakdown structure (WBS). Here again, the BA and PM can work together to ensure that all requirements that have been validated against a business now tie to a work package on the WBS. This task provides the BA and PM confidence in knowing that all of the work required to produce the deliverables is represented. If a requirement cannot be traced forward to an element of work, then something has been missed. When requirements are missed going forward, this contributes to cost and schedule overruns when the missing work is discovered.
Since project management and business analysis are both iterative processes, PMs and BAs should understand that several rounds of planning and analysis are required before execution begins. As the BA goes through requirements planning, elicitation, documentation, and analysis, he or she should be communicating constantly with the PM so that the PM can fully understand the scope of the project. The PM must collect the requirements from the BA or requirements team. Again, this is something that should happen incrementally and not be conducted as a single event. It is the role of the PM to define project scope, but this cannot be accomplished fully unless the requirements team has done the work on the front end. To reach that goal, the PM must support the requirements/BA team and the work that they have to accomplish. The BA will deliver the requirements to the PM, and they should work together to make sure that the defined project scope includes all of the work required to produce the product, service, or result desired.
Leadership in Projects
Within projects, both the PM and the BA serve important leadership roles. The PM is required to demonstrate leadership for the project as a whole. This involves defining roles and responsibilities for the project team, setting goals for personal and professional development for team members, identifying training requirements for team members, and providing performance feedback to and about team members. The BA is the leader of the requirements team, and also must provide leadership to that part of the project team. The requirements charter should describe the scope of work that is necessary to develop the product’s requirements.
When the scope of work needed to develop the requirements is understood, the BA that is in charge of the effort must define roles and responsibilities for the team members. Defining roles and responsibilities for each member of the team serves several important functions. First, it prevents duplication of effort and allows for an efficient process. If the members of the team do not understand who is responsible for doing what, then several team members may end up working on the same piece of work. Second, the BA leader has to prioritize the work of the team. If priorities are not set, team members could focus their efforts on the wrong work at the wrong time. Lastly, the hierarchy within the team must be established and understood. Hierarchies aid in the flow of information between team members and also allows for concerns and issues to be resolved at the lowest possible level.
Building Consensus on Requirements and Priorities
Both the PM and the BA need to be skilled in negotiation and consensus building with respect to scope and prioritization. Negotiation within the context of projects should not turn into a competitive, adversarial venture. Negotiations can occur for any number of reasons, but within a matrix or functional organization, usually negotiation involves securing resources. Having the ability to define win-win situations for all of the members involved in a negotiation and to avoid burning bridges will make the work of the team that much easier going forward. Thinking about the long term when negotiating is important; the value of relationships within and outside the organization or team will endure long after the project is over.
Consensus building is vital for both the PM and the BA. For the PM, consensus among stakeholders regarding priorities, budgets, and schedule are critical. For the BA, consensus must be built on what the true needs are in the product and also what the priorities are. The BA has to understand if stakeholders have differing or opposing priorities or needs. A project cannot move forward if the BA has stakeholders who cannot agree on what is needed in the product or on what the priorities are. The BA has to possess the skills needed to achieve consensus on the needs that drive the requirements and also on what should be worked on and in what order. If the BA cannot pin down priorities from the stakeholders, it is hard to define work priorities for the requirements team.
The Impact of Agile
When it comes to working together, nowhere is the PM and BA relationship required to be stronger than in an agile environment. The agile approach to project management is not simply a shift in how projects are managed and executed. It is a foundational shift in the psychology of an organization and should not be taken lightly. It takes the support of the organization as a whole for the agile approach to be successful and that support must be driven from the top down. Likewise, in a project, the PM must support the BA and the requirements development team in the agile environment.
Users of the agile methodology must understand and accept that there is much that is not known at the initiation of a project. The PM must appreciate that the requirements package that is collected will not be fully developed as it normally would be in a traditional or waterfall project management environment. Agile is a lean approach in that in order to begin, we only need “just enough” to get underway and we need it “just in time.” So during initiation, the “just enough” threshold is relatively high and there is going to be significant ambiguity. The planning and execution horizons are short, and the PM cannot expect that the BA or requirements team to deliver fully developed requirements for the entire project by the end of a traditional planning phase.
The PM has to understand that the requirements that have been developed can and often will change rapidly. This is not the “fault” of the BA; this is just a condition of the agile environment. The highest priority in agile is to satisfy the customer within the project’s constraints, not to understand everything at initiation. Working software is the measure of progress in the project, not producing plans or documentation. The PM can support the BA most effectively in the agile environment by ensuring open lines of communication between the business stakeholders and the development team.
Whatever environment you are in, the PM and BA/requirements team must work together in order to achieve success. The project manager cannot look at the BA and the requirements team as a separate entity that exists within the team; they must be integrated into the entire process. For the BA, open communication with the PM can ensure that the BA and their team are focused in the right direction. The BA can and should leverage the PM to build consensus and negotiate for resources and to keep the requirements development process within the scope of the project.
Peruse the list of project management courses listed below to learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge through training.
Project Management Courses - Visit www.globalknowledge.com or call 1-800-COURSES (1-800-268-7737) to speak with a Global Knowledge training advisor.
About the Author
Dan Stober is a PMP® certified project manager with over a decade of project management and business analysis experience. He has managed projects for the government in the US, Europe, and the Middle East. Dan is currently the principal consultant for project management and business analysis at Project First, Inc.