Symbiosis

project managers and business analysts living together

“Symbiosis: a cooperative relationship (as between two persons or groups).” (Merriam-Webster’s Online Dictionary, 2008)

Introduction

“Even under the best of circumstances it is very difficult, if not impossible, to identify and document complete requirements. The reasons are many and well known to both professional groups [project managers and business analysts]. Underlying it all is the need for more collaborative efforts.” (Wysocki, 2008)

Research indicates that many of the inherent problems in projects can be traced to requirements-related activities:

  • 70% to 85% of all project rework costs are due to errors in requirements.
  • 30% to 50% of the total effort expended on a software project comes from rework.
  • Approximately 50% of defects in software projects can be traced to errors in requirements.
  • 71% of failed software projects suffer from poor requirements management (Bartholomew, 2006).

Once a decision has been made to proceed with a project and resources have been committed, the project manager must focus on delivering the expected scope, at the expected cost, in the expected time. Managing the triple constraints is hard enough without the added difficulty of identifying, analyzing, documenting, and controlling the sum of the requirements that make up the scope of the project. And, while the project manager is working with the project team, vendors, resource managers, and functional groups to get things done, there is the challenge of keeping a sharp eye on the most important expectation of all: achieving the expected benefit to the stakeholders.

Using the combined skills, competencies, and knowledge of the business analyst and project manager, stakeholder requirements become more manageable and achievable “so that the project will satisfy the needs for which it was undertaken” (Project Management Institute [PMI], 2004, p. 179).

Project Manager

“Do it right the first time.” (Crosby, December 2000)

From the beginning of history, there have been projects. Only recently, in a historic sense, has project management been formalized as a profession. Unfortunately, the responsibilities of that profession vary across applications, companies, and industries. A quick review of some current job listings reveals that a project manager alternatively is, and is not, responsible for planning and managing the following: scope, change, schedule, budget, quality, resources, communication, risk, and procurement. Without a clear set of guidelines this can be confusing, to say the least. There is, however, one clarifying definition that makes the job easier to understand and infinitely more difficult to accomplish.

“The project manager is the person responsible for accomplishing the project objectives” (PMI, 2004, p.8). These 12 words say everything and nothing all at once. The definition tells us everything, in that it is clear where the ultimate responsibility for project success lies. In general, the project manager can use the triple constraint model as a guide, knowing that by using all of the knowledge, skills, tools, and techniques at their disposal, delivering the right thing at the right time for the right amount of money, the needs and expectations of most stakeholders will be met.

Where the definition gives us nothing is in the phrase “project objectives.” For many projects, there are major objectives, minor objectives, financial objectives, quality objectives, client relationship objectives, risk objectives, and organizational objectives. For each of these objectives, there are varying but specific requirements expected by stakeholders. How is one person expected to manage all that and still deliver each of the requirements of the project? In other words, how do we know what “it” is that Crosby says we are to “do right the first time”?

Business Analyst

“Do the right thing right the first time.” (Crosby, June 2000)

Although the idea that a project would be undertaken without a clear business case and specific requirements defined seems ludicrous, this is the unfortunate truth in many organizations. The speed at which businesses change today creates an atmosphere in which shortcuts are taken, key questions are not asked, and work is executed without knowing the problem to be solved or the desired end state. In this atmosphere, time, money, and resources are wasted on efforts that have little hope of satisfying stakeholders’ expectations. When practiced effectively, business analysis can lead to the reduction of overall costs, more efficient use of resources, and improved stakeholder satisfaction.

“A project is not formally chartered and initiated until completion of…some form of analysis that was separately initiated” (PMI, 2004, p.81). Who conducts the preliminary analysis? How are the results communicated to the assigned project manager? In short, how can project objectives be validated unless someone related to the project works with the stakeholders to understand how they define success?

“A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems” (International Institute of Business Analysis [IIBA], 2006). Those who perform business analysis are known by a number of titles, including business analyst, systems analyst, business systems analyst, functional analyst, and even project manager. The title is not important, but the function is. Each of these individuals is conducting business analysis when analyzing the business needs of the stakeholders in order to help identify business problems and propose solutions.

The International Institute of Business Analysis (IIBA®) is an international organization of business analysts that has established common standards for the knowledge that all business analysts should master. The IIBA’s A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) identifies currently accepted practices, describing areas of knowledge along with associated tasks, techniques, process steps, and skills (Exhibit 1). The BABOK® Guide contains six knowledge areas: Enterprise Analysis, Requirements Planning and Management, Requirements Elicitation, Requirements Analysis and Documentation, Requirements Communication, and Solution Assessment and Validation (IIBA, 2006).

BABOK® Guide Knowledge Areas (adapted from IIBA, 2006

Exhibit 1 – BABOK® Guide Knowledge Areas (adapted from IIBA, 2006)

Doing “It” Right

Why Do “It”?

(Exhibit 2) Business leaders select projects based on whether they support strategic goals and objectives. The project manager should understand how projects are derived from business problems and opportunities, and how the approved project, and the team’s work within it, supports the entire enterprise. The Enterprise Analysis knowledge area places a given project within the context of the organization’s strategic plan. Enterprise Analysis describes the activities that a business analyst uses to collect and document facts and data concerning proposals to assist the selection of projects. Many of the associated activities are preproject, while others continue until the benefits of the project can be measured and analyzed in a post-implementation review.

Hierarchy of Objectives and Strategies

Exhibit 2--Hierarchy of Objectives and Strategies

One critical output of Enterprise Analysis is the business case. The business case document introduces the problem or opportunity addressed by the project and includes objectives, scope, benefits, costs, risks, assumptions, issues, and recommendations. According to PRINCE2, “the business case is a description of the reasons for the project and the justification for undertaking the project, based on the estimated costs of the project, the risks and the expected benefits and savings” (Office of Government Commerce, 2005, p.197).

Through Enterprise Analysis activities, organizational strategies are refined into proposals for new projects. Key stakeholders and subject matter experts give management the information that they need to select and prioritize projects. Whether or not business analysts (or project managers) are involved in preproject activities depends on the organization. The skills and knowledge that the business analyst brings to preproject activities are:

  • Identifying, understanding, and prioritizing problems and opportunities
  • Determining the risks and exposures to the business
  • Investigating alternatives and selecting those best aligned with the organization’s goals
  • Relating the above items to each other so that decisions can be made with regard to the project portfolio

Whether involved directly with the strategic planning processes or not, the project manager must understand the strategic goals of the organization in order to ensure that new projects fit the long-term strategy and/or mission of the organization (IIBA, 2006). The business analyst provides the organizational context to the project team.

How Will “It” Be Controlled?

No project organization can be effective unless its products, both interim and final, are closely managed. Scope creep and uncontrolled configuration changes can potentially ruin a project. The Requirements Planning and Management knowledge area involves determining, planning, and executing a project’s requirements activities (IIBA, 2006). In this knowledge area, the business analyst:

  • Determines the set of requirements deliverables and activities that are most appropriate
  • Determines the team roles in each requirements activity and deliverable
  • Ensures that the requirements work is coordinated with the other work being done for the project
  • Ensures that the requirements team has a common understanding of what activities they are undertaking
  • Conducts a stakeholder analysis
  • Selects appropriate tools for executing requirements techniques
  • Uses a requirements baseline and several traceability techniques to manage requirements scope
  • Ensures that the tools, resources, and contributors to the requirements activities are available when needed
  • Captures requirements changes correctly and consistently

The business analyst works with the project manager to identify the requirements activities that will be performed, along with the roles in each process, select the techniques to be used, and evaluate the standards to which the processes should comply (Exhibit 3). As requirements are elicited, the business analyst should trace the requirements back to the business objectives. A requirement that does not map back to an objective should be considered “out of scope.”

Traceability (Boston University Corporate Education Center [BUCEC], 2008)

Exhibit 3--Traceability (Boston University Corporate Education Center [BUCEC], 2008)

Requirements Planning and Management focuses on selecting and planning the requirements tasks, defining processes to manage requirements and their changes, and documenting these in the requirements management plan. Research show that risks related to requirements, such as scope creep and requirements gaps, are among the primary causes for project failure (The Standish Group, 2003). By taking a structured approach, the business analyst can minimize risks related to requirements.

What is “It”?

To make business strategies become a reality, project managers need guidance in exactly what they need to do. One of the principal responsibilities of the business analyst is to elicit requirements. During Requirements Elicitation, the business analyst coordinates activities and techniques in order to elicit requirements from stakeholders. It is the project stakeholders’ role to provide requirements. The business analyst supports this process by:

  • Asking questions to expand on ideas in greater detail
  • Motivating stakeholders to formulate requirements based on a wide range of inputs
  • Using the techniques that best fit the needs of stakeholders involved
  • Negotiating with stakeholders to resolve conflicts and reach consensus

The business analyst should understand the commonly used techniques for gathering requirements, the applicability of each technique, and that requirements gathering is not an independent activity. Requirements Elicitation, Analysis and Documentation, and Communication are iterative and connected processes. The business analyst continues these iterative tasks until requirements are determined to be complete, correct, and consistent. Of course, the project manager and business analyst recognize that requirements evolve as the understanding of stakeholders’ needs improves, and that requirements will normally change during the project life cycle. The project team should realize that once a final set of requirements is documented and approved, change management processes will deal with the inevitable changes that arise as the project unfolds.

Elicited requirements fall into a range of usefulness, ranging from poor to excellent. Poor requirements result in project failure (Exhibit 4). Many studies by the Government Accounting Office (GAO) and others have come to the conclusion that the cost to repair a software error grows significantly as the project progresses into later stages (Thayer & Dorfman, 2000).

Typical Repair Costs by Project Stage

Exhibit 4--Typical Repair Costs by Project Stage

The Requirements Elicitation knowledge area has numerous techniques that may be applied to gather requirements from stakeholders. By selecting appropriate techniques, iteratively gathering, analyzing, and documenting requirements, and applying best practices, the business analyst can ensure that defined requirements are necessary, correct, concise, clear, complete, feasible, appropriate, prioritized, verifiable, and traceable.

Who Needs to Know About “It”?

“Identifying the informational needs of the stakeholders and determining a suitable means of meeting those needs is an important factor for project success” (PMI, 2004, p. 225). Although the responsibilities of the project manager and business analyst are distinctly different, this knowledge area has the greatest potential for either conflict or convergence. There is no doubt that communicating with stakeholders is a large portion of the project manager’s job, but using project management resources for the detailed requirements is not feasible. The Requirements Communication knowledge area includes presenting, communicating, verifying, and gaining approval of the requirements from the project’s stakeholders and implementers.

(Exhibit 5). As part of initial requirements planning, the business analyst develops a communications management plan that details communication inputs and outputs, document formats, and presentation formats. The plan also addresses the diverse needs of various stakeholders, strategies for using communication to resolve conflicts, and procedures for managing and securing the approval of key stakeholders. The potential for conflict occurs if the project manager and business analyst do not coordinate their communication planning to make the requirements activities a subset of the overall project communications plan. The potential for gained efficiencies is enhanced as the business analyst and project manager unite to coordinate meetings and other vehicles for stakeholder communications. Together, the business analyst and project manager consider when communications needs to take place, as well as the communication method and forum for each audience.

Example Communication Plan (adapted from BUCEC, 2008)

Exhibit 5--Example Communication Plan (adapted from BUCEC, 2008)

Making “It” Equal “The Right Thing”

“The detailed project scope statement includes…project requirements” (PMI, 2004, pp. 110-111). If that were all the scope statement needed, the project manager could probably put it together without assistance. However, a project is so much more than its deliverables; the project manager must rely on business analysts to work with stakeholders to elicit, analyze, and document the requirements (Exhibit 6). Techniques for Requirements Analysis include graphic, textual, and matrix modeling and documentation. These techniques can be grouped into three broad categories: business process analysis, object-oriented analysis, and structured systems analysis. The primary focus of documentation is to refine the models derived from stakeholder feedback and, through iterations, to make sure that the proposed requirements are feasible and support the business and user needs and objectives.

BABOK® Guide Modeling Techniques

Exhibit 6--BABOK® Guide Modeling Techniques

Requirements documented by a business analyst should add value to the project, not just an accounting of what project stakeholders have stated. When executing the tasks of the Requirements Analysis and Documentation knowledge area, the business analyst ensures that requirements contribute to the business case. The knowledge area describes how the business analyst:

  • Defines the methods, tools, and techniques used to structure information collected
  • Identifies gaps in the information
  • Defines the capabilities of the solution
  • Ensures that there is a consensus among all stakeholders regarding the behavior of the system
  • Ensures the proposed requirements’ feasibility for meeting business and user needs, goals, and objectives

Checking “It”

“Quality is the ‘degree to which a set of inherent characteristics fulfill requirements.’ Stated and implied needs are the inputs to developing project requirements” (PMI, 2004, p. 180). The chances of managing a successful project by relying on implied needs are very slim. Solution Assessment and Validation includes tasks for ensuring that a solution meets the stakeholders’ objectives, is thoroughly tested, and is implemented successfully (Exhibit 7). This knowledge area includes tasks that support the quality assurance and implementation of a solution while it is being developed, ensuring that the solution realizes the requirements.

Solution Assessment and Validation Tasks (adapted from BUCEC, 2008)

Exhibit 7--Solution Assessment and Validation Tasks (adapted from BUCEC, 2008)

Conclusion

“Symbiosis: a cooperative relationship (as between two persons or groups).” (Merriam-Webster’s Online Dictionary, 2008)

Hiring a project manager and a business analyst with the skills and experience commensurate with the importance of the project is the best way to ensure its success. Working together from the beginning of the project, and sometimes even preproject, the two create an environment for success by working with stakeholders to define expectations clearly. Both positions are necessary because their responsibilities rarely overlap, their knowledge areas are distinct, and their skills are complementary. A project led by a strong project manager and a strong business analyst, working with a competent project team, will be assured of meeting stakeholders’ expectations.

Bartholomew, D. (2006). Prescription for better projects. Retrieved June 15, 2008 from http://www.borland.com/resources/en/pdf/company/news/08_10_06_requirements_management.pdf

Boston University Corporate Education Center (BUCEC). (2008). Core competencies for the business analyst (Vol. 1.3). Tyngsboro, MA: Boston University Corporate Education Center.

Crosby, P. (2000, June). Phil’s journal. Retrieved June 23, 2008, from http://www.qualitydigest.com/june00/html/crosby.html

Crosby, P. (2000, December) Phil’s journal. Retrieved June 23, 2008 from http://www.qualitydigest.com/dec00/html/crosby.html

International Institute of Business Analysis. (2006). A guide to the business analysis body of knowledge (BABOK® Guide ®) (release 1.6). Retrieved June 10, 2008 from http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge

Merriam-Webster’s Online Dictionary (2008). Retrieved June 11, 2008 from http://www.merriam-webster.com/dictionary/symbiosis

Office of Government Commerce (2005). Managing successful projects with PRINCE2 (4th ed.). London, England, UK: The Stationery Office.

Pearce, J.A., & Robinson, R.B. (2007). Strategic management (10th ed.). Boston: McGraw-Hill.

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA: Project Management Institute.

Standish Group International, Inc. (2003). Chaos chronicles. http://www.standishgroup.com

Thayer, R., & Dorfman, M. (Eds.). (2000). Software requirements engineering (2nd ed.). Los Alamitos, CA: IEEE Computer Society.

Wysocki, R. (2008, May). Is it time for the BA and the PM to get hitched? Business Analyst Times. Retrieved June 23, 2008, from http://www.batimes.com/index.php?option=com_content&task=view&id=211&Itemid=162

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2008, Rick Cusolito
Originally published as a part of 2008 PMI Global Congress Proceedings – Denver, Colorado, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.