CHAPTER 3
ORGANIZE PROJECT
3.1 Introduction
Organize Project is the process of developing a detailed description of the project and products subdividing the project deliverables into a hierarchy of defined work packages.
Project management depends on understanding and planning the project's goals and objectives. One of the first steps in planning a project is defining the scope. This chapter provides a process to define the project scope and discusses the key elements that comprise that process. Inputs and outputs are provided in Figure 3-1.
3.2 Inputs
3.2.1 Project Charter
The project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides a project manager with the authority to apply organizational resources to project activities. The project charter provides the high-level project requirements and high-level product or service description of the project. It establishes a partnership between the performing organization and the requesting organization or customer. The approved project charter includes information from a signed contract if one exists. The charter formally initiates the project. The charter gives the project manager the authority to apply organizational resources to accomplish the objectives of the project. The project charter typically contains the project purpose, the objectives, and related success criteria, high-level requirements, project description and risks, as well as a budget estimate and critical milestone schedule. For purposes of this standard we will assume the charter incorporates relevant information from a customer contract.
3.2.2 Stakeholder Management Strategy
The stakeholder management strategy is designed to engage the project stakeholders in the success of the project. For each stakeholder, it includes areas of interest, type and degree of influence on the project, and strategies to increase support for the project.
3.2.3 Requirements Documentation
After the charter is approved or the contract is signed, the high-level requirements are further decomposed and documented. Stakeholder needs are refined into project requirements and product and/or service requirements. Product/service requirements define the features and functions that describe a product, service, or result and include information on technical requirements, security requirements, performance requirements, etc. The project requirements include information on business requirements, project management requirements, delivery requirements, etc. In other words, the requirements documentation defines the condition or capability that must be present in a product, service, or result to satisfy a contract or other formally proposed specification.
3.3 Description
3.3.1 Product Analysis
Product analysis is a method used to translate product and/or service descriptions and requirements into deliverables. A cross-functional group of stakeholders takes information about the features and functions and determines the deliverables and components necessary to meet the product or service requirements.
3.3.2 Alternatives Analysis
Alternatives analysis is used to ensure the best approach for meeting project objectives and stakeholder requirements. There are numerous solutions or approaches to accomplishing any given project. Performing cost, schedule, and performance analysis on each of these alternatives will help to better define the most efficient and effective solution to meet the stakeholder's expectations. This analysis needs to be thorough and take into consideration the expected performance and associated risks of the product or service, the cost to develop it, produce it, and maintain it throughout its life cycle. For each alternative, the cost-benefit trade-off and the effectiveness of that solution is documented. Without the alternative analysis, the chosen alternative may meet the stakeholders’ end needs, but may not be affordable. Or conversely, the chosen alternative may be affordable, but may not meet one or more of the stakeholders’ end needs/results.
3.3.3 Decomposition
Decomposition starts with the end deliverables and continuously breaks them into smaller components. The upper levels typically reflect the major deliverable work areas of the project or major phases in the project's life cycle. The content of the upper levels may vary, depending upon the type of project and the industry involved. These levels provide logical summary points for assessing team and individual performance, communicating accomplishments, and measuring cost and schedule performance with respect to individual deliverables as well as the overall project.
The upper levels of the WBS are normally used for reporting purposes. The lower-level WBS elements provide appropriate focus for project management processes such as scope and schedule development, cost estimating and budgeting, and risk assessment. The translation of the requirements necessary to meet the needs of the principal stakeholders into the WBS essentially forms the scope of the project. The WBS becomes the centralized structure for the communication of project information. Figure 3-2 provides an example.
The WBS divides the project scope into hierarchical, manageable, definable elements of work that balance the control needs of management with an appropriate and effective level of detailed project data. The various levels of the WBS also provide support for focusing communication with stakeholders and aid in clearly identifying accountability to a level of detail necessary for the effective management and control of the project.
The WBS includes all of the work defined by the project scope and captures all deliverables—internal, external, and interim—including project management. The WBS is structured on the concept of “parent” and “child” relationships (see Figure 3-3). That is, the next lower-level elements of detail for any single WBS element are referred to as the “children” of the “parent” WBS element. Thus, no “child” element of the WBS can summarize into more than one “parent” element. The sum of the work contained within a “parent's children” must equal 100% of the work of the “parent.”
Figure 3-4 is a sample WBS designed to capture the scope of work required to construct a bicycle. To keep the graphic simple, this particular WBS assumes that the detailed requirements for a specific type of bicycle would be provided as further decompositions of the illustrated WBS elements. This example of a project to build a bicycle will be used throughout the standard to demonstrate the principles introduced in the remaining chapters.
Specifically, this example illustrates each element of work, the various levels of a WBS, and the relationship between WBS elements. Figure 3-4 represents only one example of the possible decomposition of the elements. It is not intended to be comprehensive or definitive.
3.4 Outputs
3.4.1 Scope Management Plan
The scope management plan is a component of the project or program management plan that describes how the project scope will be defined, developed, monitored, controlled, and verified to the project team and stakeholders. This document is used to control what is in and out of scope. The scope management plan is a component of the overall project management plan.
3.4.2 Project Scope Statement
The project scope statement helps to enhance an understanding of the scope for the project, whether a product or result is being developed or a service is being delivered. It describes the project scope, major deliverables, assumptions, and constraints, and a description of the work that provides a documented basis for making future decisions, and for confirming or developing a common understanding of the project scope among the stakeholders. With a clear project scope statement, responsible and performing organizations can better plan, organize, and execute the work and deliver the desired product.
3.4.3 Work Breakdown Structure
The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives. It organizes and defines the total scope of the project. Each descending level of detail represents an increasingly thorough definition of the project work. The WBS is extended by establishing control accounts with appropriate work packages associated with each control account.
The WBS translates requirements into elements of work, product, and deliverables. The WBS includes the project management work necessary for communications and meetings required for effective integration management to ensure all deliverables are explicitly identified.
3.4.4 Work Breakdown Structure Dictionary
The work breakdown structure dictionary provides detailed deliverable, activity, and scheduling information about each component in the work breakdown structure. Other information includes: responsible organization, resources required (by skill level), cost estimates, basis of estimates, assumptions, contract information, contract constraints, quality requirements, acceptance criteria and technical references. Figure 3-5 provides an example of a WBS dictionary.
3.4.5 Scope Baseline
The scope baseline is a document or plan officially signed at the sponsor level against which delivery will be compared. It can only be changed with explicit agreement at the original sign-off level or higher. The scope baseline includes the scope statement, the WBS, and the WBS dictionary, and is a component of the project management plan.
3.5 Considerations
3.5.1 Constructed with Technical Expertise
Understanding and organizing the project work is the first step in developing a realistic project management plan so that earned value can be deployed as a planning, executing, and monitoring and controlling technique. The WBS is the foundation for all other planning processes, and, as such, it is must be a collaborative effort with participation by all appropriate stakeholders. The WBS enables definition and management of technical requirements and deliverables to meet the project objectives. In addition, the WBS supports technical and project management documentation as well as the change control process.
3.6 Summary
In order to plan, manage, and control a project effectively, there must be a clear description and understanding of the project and product/service scope. The project charter or customer contract, stakeholder needs, and project requirements are the foundations for defining and elaborating the project scope. The scope statement, WBS, and WBS dictionary comprise the scope baseline and will be used by numerous other processes to fully plan the project.