The collision of strategic project management & business analysis


Senior Consultant, Management and Leadership, Management Concepts


The turf wars of project management and business analysis are heating up. Project management is instituting program and portfolio management under the area of strategic project management. Business analysis is expanding beyond the area of requirements to a much broader role including areas outside traditional project boundaries. Can they co-exist? This paper looks at the two organizations, their guidelines, and their conflicts and potential futures. The first part of this paper examines the roles and the responsibilities of the strategic project manager. The second part of this paper explores the roles and responsibilities of the business analyst. The final section looks at how the two roles can best be used in a successful project and a successful organization that is focused on its mission and vision.


The project management industry has been in tactical mode for most of its existence. In the last few years there has been an emergence of program management and portfolio management as indicated by the recent publication of standards from the Project Management Institute (PMI®). As a result strategic project management has been added to tactical project management. This has evolved into more of a “cradle to grave” approach for organizations and their projects.

This move has evolved more awareness in today’s project manager for the organizations vision/mission rather than just delivering a specific result. It has also made the project manager more responsible for documenting and delivering the business value for which the project was undertaken. This, in turn, has resulted in the need for the project manager to have more business acumen and be able to read and understand the organization’s financial reports.

Enter the role of the business analyst as prescribed by the International Institute of Business Analysis (IIBA™). The business analyst role is taken beyond what years ago would have been the systems analyst, and rightfully so. However, this expanded role has now been enlarged to include the same territory that the strategic project manager is claiming. The role is advocating the strategic pre-project activities of the portfolio manager. The role is also looking at the operations and maintenance (O&M) arena and the fulfillment of the business case for a given project.

In the terms of the “Old West,” who filed the claim, and who is the claim jumper for this territory? Will both sides be able to find a common ground for the betterment of the organization?

Project Management

Evolution of Strategic Project Management

Project management began as a tactical tool to facilitate the execution of individual projects and programs such as building a new facility, installing new hardware, or implementing a new software initiative. These early days of project management coincided with the business schools’ push toward Management by Objectives, first popularized in 1954 by Peter F. Drucker in The Practice of Management (Drucker, 1954). It is a process of agreeing upon objectives and obtaining buy-in from management and employees.

While Management by Objectives required a precise written description of objectives and timelines for their monitoring and achievement, it did not enable organizations to evolve over time by accomplishing strategic objectives, such as entering a new market, increasing revenues, reducing costs, or returning greater value to shareholders. Soon the new rallying cry became Management by Projects, evolved after Tom Peters launched a management revolution with his book, In Search of Excellence (Peters & Waterman, 2004) . Even Peter Drucker, in his later years, jumped on the bandwagon as he realized that moving an organization forward required project management skills. Organizations then adopted project management as a tactical tool to execute projects, but it was not enough.

The next step was the application of project management as a strategic tool. Since all projects proposed by an organization’s departments and divisions compete for resources and support, strategic project management views all of the organization’s projects together as components of a portfolio and makes strategic choices in their support. “While project management and program management have traditionally focused on ‘doing work right,’ portfolio management is concerned with ‘doing the right work,’” states the Project Management Institute’s The Standard for Portfolio Management (PMI, 2006, p. 3).

PMI® and PMBOK® Guide Standards

The following are definitions from the Project Management Institute (PMI®) and it’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (2004):

Project – A temporary endeavor undertaken to create a unique product, service, or result. (p 368)

Project Management – The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. (p 368)

Program – A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program. (p 368)

Program Management – The centralized coordinated management of a program to achieve the programs strategic objectives and benefits. (p 368)

Portfolio – A collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives. The projects or programs of the portfolio may not necessarily be interdependent of directly related. (p 367)

Basics of Project Portfolio Management

The Project Management Institute (PMI®) released The Standard for Portfolio Management in June 2006, to fulfill the need for a documented set of processes that represent generally recognized good practices in the discipline of portfolio management. According to PMI®, “Portfolio management is the centralized management of one or more portfolios, an approach to achieving strategic goals by selecting, prioritizing, assessing, and managing projects, programs, and other related work based upon their alignment and contribution to the organization’s strategies and objectives. Portfolio management combines (a) the organization’s focus of ensuring that projects selected for investment meet the portfolio strategy with (b) the project management focus of delivering projects effectively and within their planned contribution to the portfolio” (PMI, 2006 p. 5).

The steps of portfolio project management are applicable to any enterprise: assess the merits of the organization’s various proposed projects, weigh them against each other, and select and support those projects that will deliver the greatest value to the bottom line when executed. The drivers of a portfolio of projects are:

  1. Where the company wants to go and what it needs to do to achieve the goal (e.g., improve its return on investment, increase shareholder value, or gain market share).
  2. Tactical concerns, such as improvement projects individual departments need to undertake in order to become more efficient or effective.
  3. Problems that require correction through a project or program.
  4. The need for organizational change management initiatives that prepare people to move in the desired direction of the organization.

The application of portfolio management permits the sharing of goals and the allocation of resources among these drivers so that projects and programs can achieve their strategic intent. PMI®’s Standard for Portfolio Management defines the following flow of control (2006, Chapter 3):

  1. Strategic intent and prioritization provide direction for determining the financial resources that should be allocated to the portfolio.
  2. The strategic intent is mapped onto a set of portfolio components (i.e., projects and programs) including their resource allocations. These components are managed according to the portfolio management principles outlined in this standard.
  3. Each program corresponds to the delegated subset of the overall strategic intent, which it will deliver by means of the allocated resources.
  4. Each project is defined by its contribution to the portfolio’s strategic intent, and can then be managed according to principles published by PMI®.

Once the portfolio manager has authorized a component—program or project—management takes control of the component and applies the correct management processes to make certain the work is performed effectively and efficiently. The responsible project or program managers monitor planned-to-actual performance relating to time, budget, resources, quality, and scope, and communicate consolidated information to portfolio management. To remain effective and aligned with organizational goals, the portfolio management function depends on updates from the strategic planning process regarding any strategic changes. This ensures that any components no longer related to current goals can be discontinued rather than wasting resources. In return, the portfolio manager reports portfolio performance to the strategic planning process as it relates to achieving the organization’s planned strategy.

Roles and Responsibilities

The roles of the project manager and the program manager are clearly laid out and well understood in the industry. The role of portfolio manager is mentioned above and is usually filled by an executive body. This body looks at the vision/mission of the organization and determines the mix of projects in the portfolio. They will also decide which of the candidate projects will be placed in the portfolio and then which will come out for execution and when. They manage the portfolio.

Strategic Project Manager and Strategic Project Management

Product success should be the reason the project is valuable to an organization and it should be tied to the business case established for the project. Projects should add value or value creation ability to the organization and should be based on the vision/mission of the organization.

Strategic project management takes an overall “cradle to grave” approach to its projects. This starts with the establishment of a project cycle. The project cycle is the over arching framework under which a project is executed. The project cycle has two main components. The first component is the project management cycle with the prime person responsible being the strategic project manager. The other main component is the product cycle with the person responsible being the systems engineer. There are other names for this person. Examples of other titles include lead architect, lead engineer, and such. In addition, the product cycle itself has the two components development, and operations and maintenance (O&M). The person leading the product decisions will take a leadership role when those issues and decisions have to be made. They lead the product process. The strategic project manager has the overall responsibility of the project.

The project management cycle has the five processes of project management as spelled out in the Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide). They are: Initiating, Planning, Executing, Monitoring and controlling, and Closing. Generic terms that are commonly used in the development portion of the product cycle include requirements, design, build, verification and validation, and implementation. (PMI, 2004, p 38)

Some of the essential elements of the project cycle that many projects and project teams fail to understand are the operations and maintenance (O&M) considerations. The implications of cost of operations, including spare parts, training, documentation, and maintaining the built product should be considered in the build itself. The project management team should consider the expected life of the product and the process and costs of deactivation. Even though the original team is not likely to actually operate the product in a production environment it is their responsibility to consider the above issues when planning and building.

The costs of the operations and deactivation period should play a large role in determining the total cost of the project and its value contribution to the organization. It is not just the cost of developing the result of the project but the overall cost including those that occur after the build is complete. If the total cost has been properly computed then the operational period will return the value of the build to the organization within a predetermined life of the product. The monies for the build usually come from stockholders or other financial stakeholders. The payback of these funds and their interest are factored into the overall determination of the cost and useful life of the product.

Business Analysis

Evolution of Business Analysis

The function of Business Analysis has its origin primarily in the IT organization as a systems analyst. These individuals were responsible for looking at the applications being developed and determining the fit within the overall systems flow and architecture. In the early days of IT this was simply taking manual procedures and automating them exactly as they were. Little or no customizing or changing was done during the automation. Later this role took on new meaning as the IT processes and their applications took on a much more integrated and valuable role in the organization. The systems analyst was given more and more responsibility in the customization process. This involved much more interaction with the end users of the “system” to see what their wants and needs were. This interaction was complicated by the addition of sponsors and other key stakeholders to the mix. This gathering of information about the new product, service, or result would become more and more complex. Across many industries and disciplines this gathering of “requirements” has evolved into a major component of delivering the results of the project.

Most of the non-IT projects do not have the difficulty of getting the requirements right. The hard sciences of construction, manufacturing, and engineering seem to have a better understanding of the requirements process and its rigor. It is the IT world and other business processes that seem to have the most difficult time of this.

The systems analyst of today lives in a world that has seen the complexity of requirements grows at a very rapid pace. Yet they continue to live in the IT world becoming more and more concerned with the challenges of the new system and how it fits in the IT and non-IT environment.

The business analyst has emerged as the role that moves outside of the traditional role of systems analyst and focuses on the requirements of the customer in order to deliver a result that meets their needs. They are not so concerned with how it fits in the systems world, but more importantly, does it meet the needs and wants of the customer. They are also concerned with the value that the result brings to the organization.

An issue has become where does the business analyst live? Do they live in the developing organization as a service of that organization? Or, do they live in the customer organization and really have hard-core practical knowledge and application of the business systems of the customer organization?

IIBA™ and BABOK® Standards

The following definition comes from the International Institute of Business Analysis (IIBA™) and their Business Analysis Body of Knowledge (BABOK®) (2006):

Business Analysis – Business Analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change. (p 8)

Roles and Responsibilities

The business analyst role on a project team has lead responsibility for working with stakeholder representatives to elicit, analyze, specify, validate, and manage project requirements. In addition it includes the identification and documentation of business needs to help determine solutions to business problems. The business analyst elicits, analyzes, validates, and documents business, organizational, and/or operational requirements. The role of business analysis is distinct from financial analysis, project management, quality assurance, organizational development, testing, training, and documentation development.

The purpose of business analysis is to transform business needs into clearly articulated requirements and to develop effective methods, and tools and techniques for requirements identification, documentation, validation, and management. It also identifies business processes that can be optimized through enabling technologies. And, it establishes an agreed-upon process and method of collaboration between users and developers. It supports the development of the project plan, schedule, and budget.

The Boundaries


The selection of which projects will be executed, and at what time, are decisions made by the persons that are managing the portfolio of projects. Projects were allowed into the portfolio based on the vision/mission of the organization and the value that the project provides to the organization. Projects will exit the portfolio for execution based on their priority and the capability to staff them with the proper resources.


During the project, the project management processes of Initiating, Planning, Executing, Monitoring and Controlling, and Closing are being used. The product generic processes of requirements, design, build, verification and validation, and implementation are also being used. These processes are blended in an integrated project cycle.

Post Project Operations and Maintenance

Once a project has been implemented, the results are deployed to a support team. This team may be the same team that created the result or it may be a new team to support the result in an operations environment. During operations and maintenance the project results will be used and maintained by the user and its support team. This will extend for the useful life of the product.


At the completion of the useful life of the product it will be deactivated or taken out of commission. This is a planned process with a structured approach. The product might be discontinued or replaced. A value analysis will be conducted to determine if the product or service has provided the value to the organization that was intended and stated in the project’s business case. A lessons learned session will be held to determine what went right and areas for improvement in the overall project and its “cradle to grave” approach.

The Shared Arena & the Core Team

Key Roles on the Core Team

Project Sponsor – The champion of the project whose primary role is funding and being an advocate for the project in areas of politics, resources, and approvals.

Project Manager – The person assigned for the execution of the project from a strategic position of cradle to grave. The project manager has overall responsibility for the successful completion of the project. The PM has leadership responsibilities concerning the project management processes.

Systems Engineer – The person assigned for the product side of the project cycle. The SE has leadership responsibilities for the creation of the product and all processes related to the build.

Business Analyst – The person assigned for the requirements process. The BA has the responsibility of ensuring complete and accurate requirements for the proposed results.

Key Customer – The person assigned to speak for the end customer/end user of the product that the project was initiated to provide.

SME – The person(s) who will provide additional subject matter expertise as needed on the project.

The core team is the primary team of the project and is the decision-making group for the project. It should be 5+/ 2 for a team size of three to seven individuals. This is the optimum size for an effective team. They are assigned to the project for the entire duration.

Who Takes Leadership and When


Enterprise analysis involves pre-project activities. This provides context to requirements and functional design work for a given initiative and/or for long-term planning. In some organizations this work is treated as an investigative, feasibility, or business architecture effort and managed as a project. It is during this period that strategic goals are converted to programs and supporting projects. The business analyst leads the enterprise analysis activities involving other key subject matter experts, including business visionaries, technical leads, and project managers. This work is under the leadership of the executive management team responsible for the portfolio which is based on the vision/mission of the organization.


The project manager has the primary leadership role for the entire project. The PM is held responsible for the overall completion and success of the project. The systems engineer has the leadership role for all product related decisions. The SE is responsible for all aspects of the processes to determine, design, build, test, and implement the desired product. Other technical leads will assume lead roles under the overall guidance of the SE during the project. These will include but not be limited to the following groups: The BA has the overall responsibility for requirements. The test team will be leading the verification and validation process. The architecture team will be responsible for overall strategy and integration. Other groups will be used by the SE as needed.

Post Project Operations and Maintenance

The support or operational team has the primary leadership role in this area. This is the actual use and maintenance of the product in a production environment. These are the customers actually using the product.


When a product has lived out its useful life it is de-commissioned and taken out of production/service. Usually this is once again under the control and leadership of the project manager. In many cases a follow-up project will be started for this very purpose. The result may be a replacement product brought into operations or the existing product would be simply discontinued.

Another View

The business analysis world has suggested a much stronger and broader role for the BA during the project. In addition to the major role the BA plays during the requirements process, the implication is that they would also have a dominant role during solution design, construction, and test. Solution delivery and operations is another area of activity for the BA. De-commissioning is yet another area indicated as a major role for the business analyst. The emphasis from some in the business analysis world is that the business analyst is the major player over and above the project manager who is simply the caretaker of the schedule and budget. They also imply the business analyst is the major player on the product side and place all of the processes of the systems engineer under the leadership of the business analyst.

In the Business Analyst Times, Robert K. Wysocki has suggested that the role of project manager and business analyst be combined in projects. In other articles he goes on to define the combined roles and their characteristics. His position appears to be, once again, that the project manager is simply a caretaker of the schedule and the budget for a project.

The Blended Solution

In conclusion there certainly is a better solution than many of those that are currently in place. The roles of strategic project manager and business analyst do not have to conflict. They are both part of the overall core team of a project. They each, along with the systems engineer, have a leadership role to play in the cradle to grave approach to the project cycle. They each also have to play supporting roles as others step up and lead the project during their areas of expertise.

The role of the business analyst is primarily requirements management. This begins with the processes of requirements elicitation, requirements analysis, requirements specification, requirements documentation, and requirements validation. The responsibility continues with requirements traceability and requirements change management.

The future of strategic project management is very promising. Using the approaches outlined in this paper we can anticipate more successful projects that add value to the organizations they serve. Portfolio management of projects based on the vision/mission of the organizations will provide that value. It will be a blended approach with well trained and practicing project managers, systems engineers, and business analysts partnering together.


Drucker, P. (1954) The Practice of Management New York, NY: HarperCollins Publisher

Peters, T.J & Waterman, R. H. () In Search of Excellence: Lessons from America’s Best-Run Companies New York, NY: HarperCollins Publisher

PMI (2006) The Standard for Portfolio Management Newtown Square, PA: Project Management Institute

PMI (2004) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Newtown Square, PA: Project Management Institute

IIBA (2006 )Business Analysis Body of Knowledge® (BABOK®) Toronto, Ontario: International Institute of Business Analysis

©2008 Don Wessels
Originally Published as part of Proceedings PMI Global Congress 2008 – Denver, Colorado



Related Content

  • Eliciting project requirements with radiance member content open

    By Byrnes, Cathy So many tools have been designed to analyze and prioritize projects with alternative layouts to linear. The brain itself is the most sophisticated computer in the universe. Thinking the way the…

  • Business analytics for PPPM benefits realization member content open

    By Davis, David L. Program management does not end when a project is completed. The program manager's responsibilities continue until all projects are complete and the program is closed, which requires the need to be…

  • Seminars & Symposium

    Operational readiness – is your system more "ready" than your environment? member content open

    By Gardner, Donald G. How often have we heard that the project is ready to implement? Systems are all checked out, user acceptance complete, production environment is ready to roll! But the project somehow fails to…