NEW! The Project Manager & The Business Analyst by Barbara A. Carkenord, CBAP, PMP, PMI-ACP A White Paper from RMC Project Management, Inc. www.rmcproject.com
10953 Bren Road East, Minnetonka, Minnesota 55343, USA Main 952.846.4484 Fax 952.846.4844 E-mail info@rmcproject.com Copyright 2013 RMC Publications, Inc. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database retrieval system, without prior written permission of the publisher. 2
Table of Contents Meet the Author...4 Defining PM and BA Roles...5 Confusing and Inconsistent Terminology...6 Terminology Recommendations...7 Solution...7 Scope...8 Requirement...9 What are Project Requirements?...11 Most project managers have been doing business analysis work for years, assuming it was part of their responsibility - Barbara Carkenord A Note about Agile Requirements...11 A Note about BPI and BPM...12 Delineate Roles by Outputs...12 Business Analysis Outputs...12 Project Management Outputs...14 Shared PM and BA Outputs...15 Conclusion...16 About RMC...17 3
Meet The Author Barbara A. Carkenord, CBAP, PMP, PMI-ACP Practice Director and Trainer Business Analysis Barbara A. Carkenord, Director of the Business Analysis Practice at RMC Project Management, has over 25 years of experience in business analysis, and is one of the original founders of the Business Analysis training industry. Barbara has an MBA from University of Michigan, is a Certified Business Analysis Professional (CBAP )a certified Project Management Professional (PMP ), and an Agile Certified Practitioner (PMI-ACP ). She is also the author of the worldwide best-seller Seven Steps to Mastering Business Analysis, and is a frequent speaker at industry conferences and chapter events. Actively involved in the IIBA, she was a core team member of the IIBA BABOK creation committee and contributed to its book, Managing Business Analysis. In 2010, Barbara was named Small Business Woman of the Year by the Georgia Women in Technology Association. Barbara possesses detailed knowledge and experience in many analysis tools and techniques. She develops and delivers business analysis training using proven techniques and real-world experience. Barbara s areas of expertise include business analysis, software design, quality assurance, and project management. Her experience covers many industries including insurance, banking, and manufacturing. Her most current publications include the CBAP /CCBA Exam Prep textbook, PM FASTrack CBAP / CCBA Exam Simulation Software, and Hot Topics Flashcards all released by RMC Publications in 2012. Barbara A. Carkenord, CBAP, PMP, PMI-ACP Connect with Barb twitter.com/bcarkenord linkedin.com/pub/barbara-carkenord facebook.com/barbara-carkenord 4
Defining Project Manager and Business Analyst Roles Why Is This Important? Many organizations struggle to successfully differentiate the roles of project manager (PM) and business analyst (BA). There are good reasons for this challenge. Most project managers have been doing business analysis work for years, assuming it was part of their responsibility, and find it hard to see their work having two separate components. In addition, important project management skills such as strong communication skills, the ability to understand complex business needs, and the ability to elicit project requirements are also critical for business analysis. Professionals with this skill set often move into the project management profession because of its more visible profile and higher compensation. A study at http://www. project-skills.com/business-analyst-salary-range.html concludes BAs make an average of 20 to 30 percent less than PMs. But with the increasing complexity of organizations and projects, having a dedicated business analyst on the project team allows the project manager to focus on managing the work, while the business analyst concentrates on developing and managing the requirements. Project Manager Work Products: Project plans Acquisition of resources Team management Business Analyst Work Products: Business case Requirements Solution approach Business transition plans This article suggests that an effective method to differentiate between the roles of project manager and business analyst is to focus on the specific outputs or work products created by the role, rather than the activities performed or skills utilized. These concrete work results are truly what separates business analysis from project management. For project managers, these outputs include project plans, acquisition of resources, and team management. For business analysts, the outputs include the business case, as well as requirements, solution design, and business transition plans. The two roles represent equally important, but distinct, areas of expertise on a project. By focusing on the resulting work, rather than the activities done to complete them, it is easier to differentiate the work of the professions and more clearly make work assignments. A consistent focus on the outputs will give professionals clear direction and give managers a clear way to evaluate performance. To describe specific work products for each profession, a common language is necessary. The leading association standards guides serve as the foundation for this article s recommendations: A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 2 by International Institute of Business Analysis (IIBA ) A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition by the Project Management Institute (PMI ). 5
Confusing and Inconsistent Terminology: Solution, Scope and Requirement Careful use of terms is extremely important in both project management and business analysis work, since much of the work involves communicating. Before talking about the work products of PMs and BAs, we need to have a common language to describe them. Both PMI and IIBA are working to standardize terminology for their respective professions; striving to create a consistent language for communications. Some terms are welldefined and have been accepted and used consistently by both professions. Words like project and stakeholder have very clear, understandable meanings, although we must acknowledge that many organizations only use the term project when the size of work surpasses some predefined number of hours or budget. What is a project in your organization? The true definition of a project; a temporary endeavor undertaken to create a unique product, service or result, also allows for very small undertakings. Many small projects are performed by a BA without the involvement of a PM and require the BA to understand project management tasks. In my informal surveys of BAs, most spend about 75 to 80% of their time on formal projects. 6
Terminology Recommendations With respect to differentiating project management work from business analysis work, there are several important terms that are not well defined or used consistently between the two professions; specifically solution, scope, and requirement. Although they represent fundamental concepts for both the PM and BA professions, even within each of the bodies of knowledge there are inconsistent uses of these key terms, as these terms are still evolving and maturing. When these terms are poorly defined or used inconsistently, communication and ultimately, project success is compromised. Therefore, I would like to propose some refinements to the industry definitions. Recommended Definitions: Solution: A set of changes to the organization which addresses a business need. A solution may be created and implemented through a project. Project: A temporary endeavor undertaken to create a unique solution (product, service, process, change, etc.) Solution As used in this article, the term solution should be used to describe the result of a project. This definition acknowledges that projects are initiated to solve a business problem or take advantage of an opportunity. The BABOK Guide uses the term business need to include business problems and opportunities. A solution to a business need may include a new software or hardware component, a business process change, a revised organizational structure, or any combination of these (in business process approaches, the solution is referred to as the desired end state or to-be workflow). The result of a project is currently defined in the PMBOK Guide as a product, service or result. Using the term solution would encompass all three of these possible results in one word. The PMBOK Guide does not use the word solution, while IIBA defines a solution as a set of changes to the current state of the organization, made to enable the organization to meet a business need, by resolving a problem or allowing an organization to take advantage of an opportunity. A recommended definition that could be shared by both professions is: The BABOK Guide defines these terms as follows: Solution Scope: A set of capabilities a solution must deliver in order to meet the business need. Project Scope: The work performed to deliver the result or solution Solution: A set of changes to the organization which addresses a business need. A solution may be created and implemented through a project. I also recommend that we modify the definition of the term project to include the word solution: 7
Project: A temporary endeavor undertaken to create a unique solution (product, service, process, change, etc.) Building a product is only one of the possible results of a project and one of the ways we might address a business need. Both the PMBOK Guide and the BABOK Guide agree that a product is something we build, create, purchase or assemble as requested by the project sponsor or a customer. Sometimes the term product is carelessly used, implying every business need should be solved by development of a new product. The much talked-about agile development approaches are mainly product development processes, focused on building software. But the solution to a business need or customer problem is just as likely a business process change, an organizational change, or business rule or policy change. Because products are just one possible result of project management and business analysis work, solution is a more accurate term to describe the result of a project. Scope The term scope is used in both bodies of knowledge, but it is used inconsistently. The BABOK Guide mentions at least five different types of scope, while the PMBOK Guide uses this term on almost every page. Two types of scope are critical for the understanding of project management and business analysis role delineation: project scope and solution scope. The glossary definitions agree that project scope is the work performed to deliver the result or solution. The solution scope (called product scope in the PMBOK Guide) describes the features or functions which characterize a product, service or result, aka the solution. What is the difference between Solution Scope & Project Scope? Solution Scope: Description of Building Number of floors needed, dimensions of the foundation, number of rooms windows and doors The Solution Scope describes what will be created Project Scope: Create the Building Architecture, electrical work, plumbing The Project Scope describes how it will be created Most PMs and BAs understand this distinction, but other business stakeholders may not. PMs and BAs need to be careful to clearly identify which scope is being discussed at all times. Using a construction example, the solution scope is the description of the building itself. The number of floors needed, the dimensions of the foundation, the number of rooms and windows and doors. The project scope is the description of the work necessary to create the building. Things included in the project scope would be architecture, engineering, construction, plumbing, and electrical work. The solution scope describes WHAT will be created, while the project scope describes HOW 8
it will be created. This is one of the most important distinctions needed to clarify the understanding of the difference between project manager and business analyst responsibilities. The business analyst works with the business stakeholders to develop the solution scope (what will be created or changed) while the project manager works with the project team to develop the project scope (how the solution will be created or changed). Understanding this distinction leads to better communication and role delineation. When one person is filling both roles, having the ability to mentally segregate solution scope from project scope helps professionals better manage their time and responsibilities. Requirement The term that causes the most confusion for PMs and BAs is requirement. Use of the term requirement is confusing, not so much because of different definitions, but rather because of different understandings of its comprehensiveness. Requirement is defined in the BABOK Guide as a condition or capability needed by a stakeholder to solve a problem or achieve an objective, while the PMBOK Guide defines a requirement as a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification. These definitions are pretty close because they both were derived from the International Institute of Electronic and Electrical Engineering (IEEE) which, prior to IIBA, was the professional association attempting to define and provide standards for software requirements. Inside the Bodies of Knowledge: REQUIREMENTS PMBOK Guide: 25 different types of requirements referenced Uses the term 589 times BABOK Guide: Acknowledges the complexity and broadness requirements Identifies six main categories Uses the term 1,728 times While not used consistently, the term requirement is used frequently. Looking at the bodies of knowledge, the term requirement is used 589 times in the PMBOK Guide and more than 25 different types are referenced. The BABOK Guide has identified six main categories of requirements, but uses the term 1728 times. No wonder this word has become ambiguous in many of our conversations. Unfortunately the standard definition of requirement is inadequate for practical usage. A condition or capability is broad enough to include everything from a large initiative (we need a new payroll system), to a detailed feature of a product (the dropdown box on the screen should be blue and two inches 9
wide), to a small application change (please add a sub-total to the report). This broad definition allows for almost anything to be called a requirement, rendering the term meaningless. IIBA specifically acknowledges the complexity and broadness of the term requirement in the introduction to the BABOK Guide: The term requirement is one that generates a lot of discussion within the business analysis community. Many of these debates focus on what should or should not be considered a requirement, and what are the necessary characteristics of a requirement. When reading the BABOK Guide, however, it is vital that requirement be understood in the broadest possible sense. Requirements include, but are not limited to, past, present, and future conditions or capabilities in an enterprise and descriptions of organizational structures, roles, processes, policies, rules, and information systems. A requirement may describe the current or the future state of any aspect of the enterprise. - BABOK Guide V2, page 5 The six categories of requirements used in the BABOK Guide reflect commonly accepted practices of business analysis professionals and form a solid foundation upon which to build a common lexicon: business, stakeholder, solution, functional, nonfunctional, and transition requirements. In addition, according to the BABOK Guide, requirements can be defined at any level of detail, and can be specified in text, diagrams, or models. If the term requirement is going to be considered in its broadest sense, a categorization system is essential for allowing the term to be used with more specificity. The BABOK Guide categories provide a good starting point for organizations that do not have their own classification system. The latest version of the PMBOK Guide (Fifth Edition) includes the BABOK Guide categories along with project and quality requirements. Since the original publication of the PMBOK Guide, projects have become larger and more complex with hundreds or thousands of requirements. This growing complexity has resulted in the development of the business analysis profession. The project manager needs a requirements expert as part of the project team. Every assessment of project failure cites poor requirements as a key weakness. 10
The BABOK Guide categories should become the standard for both professions. This classification scheme is important to clarify the work products of BAs and help with project planning and execution. A modifier used with the word requirement makes it more specific. What are Project Requirements? The PMBOK Guide uses the phrase project requirements several times and it seems to refer to all of the things needed for the solution, or product, scope as well as how to get the work done, or project scope. Many of the references are actually PM outputs such as resource, schedule, and cost requirements, communication requirements, quality requirements, project approval requirements, and project closure requirements. Notice these requirements do not describe the conditions or capabilities needed by stakeholders to achieve an objective. Rather, they reflect how the project will get work done. These are PM outputs. Project requirements do not describe the solution, but rather than needs of the project. I would like to see the PMBOK Guide be more precise when using the phrase project requirements, or avoid use of the term requirement when referring to the outputs of project management. A Note about Agile Requirements It is important to acknowledge that requirements, as defined by the BABOK Guide, do not need to be formally documented. In change-driven approaches to software development, requirements are elicited, analyzed, communicated, prioritized, and used to develop working software with very little formal documentation. This approach to requirements does not make them any less important, but rather makes it even more important for business analysts to understand the differences between the types and know which types of requirements are needed at each level of agile planning and development. BAs facilitate the agile team s discussion of requirements to the level of specificity needed by developers to build the product accurately. 11
A Note about Business Process Improvement (BPI) and Business Process Management (BPM) The term requirement is not commonly used in BPI or BPM approaches to business analysis. These approaches use terms like current state, future state, as-is, to-be, and what-if scenarios for analysis and solution design. These descriptions are often represented in workflow diagrams and models. The BABOK Guide includes all of this analysis work under its broad definition of requirement. Delineate Roles by Outputs When project management and business analysis professionals agree on shared definitions and usage of key terms, their productivity increases significantly and their projects are more successful. I have worked with several organizations that measure project success factors and have seen significant improvements after PM and BA roles are clarified. Once a common language is agreed upon, defining outputs for each profession is possible. When we define the work products each role creates, it is easy to see the delineation of the work. The BA is a project team member like any other and the PM assigns tasks to the BA as appropriate. Frequently, a BA may be assigned to multiple projects and also maintain some business support responsibilities outside the scope of a project. These resource constraints are considered by the PM during project planning. Project Management: Scope of work: Project Scope (how the solution will be created) Example Output: Status reports of project progress Business Analysis: Scope of work: Solution Scope (what is needed by the business) Example Output: Transition requirements Business Analysis Outputs A business analyst s responsibilities should be defined in terms of his or her outputs. The BA is responsible for working with stakeholders to define the solution scope (description of the result of the project). Business analysis outputs should include a clear definition of the business need, an understanding of the environment within which the business operates, the goals of the business (business requirements). The BA is also responsible for descriptions of possible solutions to the problem (solution requirements) and determining how best to roll out the solution (transition requirements). For example: If the business solution is a new payroll system, its solution requirements describe how 12
it will process payroll, how many paychecks it must be able to create, how often payments will be made, etc. BAs are also responsible for creating business analysis plans to give to the PM as input into the overall project management plan. The requirements categories, as defined in the BABOK Guide, are shown below. Although it is impossible to design a requirements categorization scheme which works perfectly for every organization and every solution, the categories defined by IIBA are used by many organizations and address most business needs. Business Analysis Outputs Should Include: Clear definition of the business need Understanding of the environment within which the business operates The goals of the business Type of Requirement Business Requirements Definition Business requirements describe the business goals, objectives and core business needs. They may include a description of the business environment, architecture, business functions and processes, business policies and rules, and information needs (data). They may include a description of the current state (as-is). Stakeholder Requirements Stakeholder requirements are specific requests made by an individual or a group of stakeholders involving a change to an existing business system, or a new product or solution. Solution Requirements Solution requirements describe the capabilities of the solution or the change needed in the business to meet the business need. They may be subdivided into functional and nonfunctional requirements. Functional Requirements Functional requirements describe the behaviors, features, functions, characteristics of the solution (What does it look like? What does it do? How does it work?). Nonfunctional Requirements Nonfunctional requirements describe how well the solution must perform, how it needs to work in its environment, and how easy it is to change. These requirements are often developed with the help of a technical architect who has expertise in the technical limitations of the solution environment. Transition Requirements Transition requirements describe the necessary activities and a schedule for making changes to the business or capabilities which are needed to help smooth the transition of the business from the current state to a desired future state. They help implement the solution into the business. For example: If employees of the business area will need training to use the new solution, transition requirements define what that training will look like, how and when it will be delivered, and how it will be evaluated. Technical or Software Requirements Although this category is not listed in the BABOK Guide, it is implied and should be acknowledged. When the solution involves a product, software or hardware component, requirements developed by BAs are used by technical architects and engineers to design the solution from a technical perspective. BAs review these technical requirements to make sure business requirements will be met by the solution, but the technical requirements themselves are outputs of other project team members managed by the project manager. 13
Project Management Outputs A project manager s responsibilities should also be defined in terms of the output they are expected to produce. Obviously, the PM is responsible for ultimate delivery of the solution to the stakeholders. To plan and manage this work, the PM creates work products. The PM is responsible for the project scope (how will the project team create the solution). Important initial outputs are plans. Project management plans include detailed descriptions of the work that will be done, the level of quality expected, the time needed, and the communications involved. PMs also acquire resources: people, money, and materials needed to create the solution. Plans include schedules, budgets, risk management, etc. In addition to planning, the PM is responsible for making sure the project team executes according to the plans and reports progress to the stakeholders. These are all examples of outputs produced by the project manager. For example, if the business solution is a new payroll system, project management outputs would include the description (and acquisition) of the resources needed to successfully complete the project along with a schedule and budget. Project Management Outputs Should Include: Project Management Plans Project Team Execution Project Status Reporting PMs will benefit from acquiring a senior BA to assist with project initiating and planning, and by delegating requirements development to BA(s) on the project team. Business, stakeholder, and high-level solution requirements are needed by the PM as inputs to planning. Without an understanding of what the stakeholders need, a PM cannot know what resources will be needed or how long the work will take. This illustrates why a BA needs to be involved with the PM from the beginning of project initiating. The PM also needs the business analysis plans to incorporate into the project plans. It is important to recognize that not every detailed requirement will be identified during project initiating or planning. Detailed solution and transition requirements will be elicited and analyzed during project executing, as BAs work with implementation SMEs to design, build, and test the solution. 14
The table below shows outputs of each role within PMBOK Guide process groups: Role Initiating Process Group Planning Process Group Project Executing and Monitoring and Controlling Process Groups Project Manager Assess project feasibility Create measurable objectives Uncover initial assumptions, risks Identify stakeholders Determine resources needed Develop activity list, time estimates, budget, and schedule Create the project management plans Follow processes, facilitate conflict resolution, report progress Manage development and implementation of the solution Measure performance against the plan Business Analyst Verify completion of business case and business objectives Elicit high-level business, stakeholder, and solution requirements Determine solution approach and define solution scope Develop a business analysis plan Elicit and analyze detailed functional, non functional, and transition requirements Work with technical team members to design the solution based on requirements Validate solution against original business needs Shared PM and BA Outputs There are a few outputs to which both project managers and business analysts should contribute. The PM should work with the BA to develop the project plans, with the BA providing a description of the solution scope (with high-level requirements) and business analysis tasks. The PM works with other team members to figure out how to create and implement the solution. This collaborative approach to project planning will increase the likelihood of project success. Outputs to which both PM s and BA s should contribute: The stakeholder register (list of stakeholders involved with the project) The communications plans (how and when to communicate with these stakeholders) Risk assessment (project and business risks) 15
Conclusion When clear agreements are made about terminology and the desired outputs of project management work and business analysis work, role delineation naturally follows. As the BA develops the solution scope, the PM develops the project scope and together they produce a realistic plan for creating the solution needed by the business. Using the requirements categories defined in the BABOK Guide, I suggest allocating the responsibility for all requirements (except project requirements) to business analysts. The PM should look upon a BA as the requirements expert and assign him or her tasks related to requirements. The PM outputs should be the project management plans, acquisition of resources, and most importantly, management of the project. This allocation will clearly delineate the type of work each role delivers and give organizations a method for evaluating the effectiveness of each individual in his or her assigned role. Clear delineation of roles will reduce conflict and increase the likelihood of project success. IIBA, BABOK, and Business Analysis Body of Knowledge are registered trademarks owned by International Institute of Business Analysis. These trademarks are used with the express permission of International Institute of Business Analysis. PMBOK, and PMI are marks of the Project Management Institute, Inc. RMC Project Management has been reviewed and approved as a provider of project management training by the Project Management Institute (PMI). As a PMI Registered Education Provider (R.E.P.), RMC Project Management, an affiliate of RMC Publications, Inc., has agreed to abide by PMI-established quality assurance criteria. 16
About RMC Learning Solutions TM RMC Learning Solutions develops and trains project managers, business analysts, and Agile practitioners by helping them learn the skills necessary to succeed in their careers. We deliver a wide range of training in multiple learning formats across the globe. Founded in 1991 by Rita Mulcahy, the company continues to develop and provide innovative, real-world tools and instruction, delivered by professionals with extensive experience and a working knowledge of industry best practices. For more information visit www.rmcproject.com. Accelerate Your Professional Skills and Job Performance Educating Professionals with the Skills they need to succeed Find out more 10953 BREN ROAD EAST MINNETONKA, MN 55343 MAIN: 952.846.4484 FAX: 952.846.4844 E-MAIL: INFO@RMCPROJECT.COM 17