Chapter 2 Project Life Cycle and Organization PDF

Document Details

ToughJasper4524

Uploaded by ToughJasper4524

2008

Tags

project management project life cycle organizational structures management

Summary

This chapter, Project Life Cycle and Organization, provides an overview of project life cycle, and how projects impact operational work, the influence of stakeholders, and organizational structure. It describes the basic structure of a project, various characteristics, and how projects relate to operational work.

Full Transcript

2 CHAPTER 2 PRojECT LifE CyCLE And oRgAnizATion Projects and project management take place in an environment that is broader than that of the project itself. Understanding this broader context helps ensure that work is carried out in alignment with the goals of...

2 CHAPTER 2 PRojECT LifE CyCLE And oRgAnizATion Projects and project management take place in an environment that is broader than that of the project itself. Understanding this broader context helps ensure that work is carried out in alignment with the goals of the enterprise and managed in accordance with the established practice methodologies of the organization. This chapter describes the basic structure of a project as well as other important high-level considerations including how projects impact ongoing operational work, the influence of stakeholders beyond the immediate project team, and how organizational structure affects the way the project is staffed, managed, and executed. The following major sections are discussed: 2.1 The Project Life Cycle—Overview 2.2 Projects vs. Operational Work 2.3 Stakeholders 2.4 Organizational Influences on Project Management 2.1 The Project Life Cycle—Overview A project life cycle is a collection of generally sequential and sometimes overlapping project phases whose name and number are determined by the management and control needs of the organization or organizations involved in the project, the nature of the project itself, and its area of application. A life cycle can be documented with a methodology. The project life cycle can be determined or shaped by the unique aspects of the organization, industry or technology employed. While every project has a definite start and a definite end, the specific deliverables and activities that take place in between will vary widely with the project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 15 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2.1.1 Characteristics of the Project Life Cycle Projects vary in size and complexity. No matter how large or small, simple or complex, all projects can be mapped to the following life cycle structure (see Figure 2-1): Starting the project, Organizing and preparing, Carrying out the project work, and Closing the project. This generic life cycle structure is often referred to when communicating with upper management or other entities less familiar with the details of the project. This high-level view can provide a common frame of reference for comparing projects—even if they are dissimilar in nature. Starting Organizing and Carrying out the work Closing the preparing the project project Cost and Staffing Level Project Project Project Accepted Archived Management Charter Management Plan Deliverables Project Outputs Documents Time Figure 2-1. Typical Cost and Staffing Levels Across the Project Life Cycle This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 16 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 The generic life cycle structure generally displays the following characteristics: Cost and staffing levels are low at the start, peak as the work is carried out, and drop rapidly as the project draws to a close. The dashed line in Figure 2-1 illustrates this typical pattern. Stakeholder influences, risk, and uncertainty, (as illustrated in Figure 2-2) are greatest at the start of the project. These factors decrease over the life of the project. Ability to influence the final characteristics of the project’s product, without significantly impacting cost, is highest at the start of the project and decreases as the project progresses towards completion. Figure 2-2 illustrates the idea that the cost of changes and correcting errors typically increases substantially as the project approaches completion. High Stakeholder influence, risk, and uncertainty Degree Cost of changes Low Project Time Figure 2-2. Impact of Variable Based on Project Time Within the context of the generic life cycle structure, a project manager may determine the need for more effective control over certain deliverables. Large and complex projects in particular may require this additional level of control. In such instances, the work carried out to complete the project’s objective may benefit from being formally divided into phases. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 17 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2.1.2 Product vs. Project Life Cycle Relationships The product life cycle consists of generally sequential, non-overlapping product phases determined by the manufacturing and control need of the organization. The last product life cycle phase for a product is generally the product’s retirement. Project life cycles occur in one or more phases of a product life cycle. Care should be taken to distinguish the project life cycle from the product life cycle. All projects have a purpose or objective, but in those cases where the objective is a service or result, there may be a life cycle for the service or result, not a product life cycle. When the output of the project is related to a product, there are many possible relationships. For instance, the development of a new product could be a project on its own. Alternatively, an existing product might benefit from a project to add new functions or features, or a project might be created to develop a new model. Many facets of the product life cycle lend themselves to being run as projects, for example, performing a feasibility study, conducting market research, running an advertising campaign, installing a product, holding focus groups, conducting a product trial in a test market, etc. In each of these examples, the project life cycle would differ from the product life cycle. Since one product may have many projects associated with it, additional efficiencies may be gained by managing all related projects collectively. For instance, a number of separate projects may be related to the development of a new automobile. Each project may be distinct, but still contributes a key deliverable necessary to bring the automobile to market. Oversight of all projects by a higher authority could significantly increase the likelihood of success. 2.1.3 Project Phases Project phases are divisions within a project where extra control is needed to effectively manage the completion of a major deliverable. Project phases are typically completed sequentially, but can overlap in some project situations. The high level nature of project phases makes them an element of the project life cycle. A project phase is not a Project Management Process Group. The phase structure allows the project to be segmented into logical subsets for ease of management, planning, and control. The number of phases, the need for phases, and the degree of control applied depend on the size, complexity, and potential impact of the project. Regardless of the number of phases comprising a project, all phases have similar characteristics: This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 18 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 When phases are sequential, the close of a phase ends with some form of transfer or handoff of the work product produced as the phase deliverable. This phase end represents a natural point to reassess the effort underway and to change or terminate the project if necessary. These points are referred to as phase exits, milestones, phase gates, decision gates, stage gates, or kill points. The work has a distinct focus that differs from any other phase. This often involves different organizations and different skill sets. The primary deliverable or objective of the phase requires an extra degree of control to be successfully achieved. The repetition of processes across all five Process Groups, as described in Chapter 3, provides that additional degree of control, and defines the boundaries of the phase. Although many projects may have similar phase names with similar deliverables, few are identical. Some will have only one phase, as shown in Figure 2-3. Other projects may have many phases. Figure 2-4 shows an example of a project with three phases. Different phases typically have a different duration or length. One Approach to Managing the Installation of a Telecommunications Network Monitoring & Controlling Processes Initiating Processes Planning Processes Executing Processes Closing Processes Figure 2-3. Example of a Single-Phase Project There is no single way to define the ideal structure for a project. Although industry common practices will often lead to the use of a preferred structure, projects in the same industry—or even in the same organization— may have significant variation. Some organizations have established policies that standardize all projects, while others allow the project management team to choose the most appropriate for their individual project. For instance, one organization may treat a feasibility study as routine pre-project work, another may treat it as the first phase of a project, and a third might treat the feasibility study as a separate, stand-alone project. Likewise, one project team might divide a project into two phases where a different project team might choose to manage all the work as a single phase. Much depends on the nature of the specific project and the style of the project team or organization. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 19 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION.1 Project Governance Across the Life Cycle Project governance provides a comprehensive, consistent method of controlling the project and ensuring its success. The project governance approach should be described in the project management plan. A project’s governance must fit within the larger context of the program or organization sponsoring it. Within those constraints, as well as the additional limitations of time and budget, it is up to the project manager and the project management team to determine the most appropriate method of carrying out the project. Decisions must be made regarding who will be involved, what resources are necessary, and the general approach to completing the work. Another important consideration is whether more than one phase will be involved and, if so, the specific phased structure for the individual project. The phase structure provides a formal basis for control. Each phase is formally initiated to specify what is allowed and expected for that phase. A management review is often held to reach a decision to start the activities of a phase. This is especially true when a prior phase has not yet completed. An example would be when an organization chooses a life cycle where more than one phase of the project progresses simultaneously. The beginning of a phase is also a time to revalidate earlier assumptions, review risks and define in more detail the processes necessary to complete the phase deliverable(s). For example, if a particular phase does not require purchasing any new materials or equipment, there would be no need to carry out the activities or processes associated with procurement. A project phase is generally concluded and formally closed with a review of the deliverables to determine completeness and acceptance. A phase-end review can achieve the combined goal of obtaining authorization to close the current phase and start the subsequent one. The end of a phase represents a natural point to reassess the effort underway and to change or terminate the project if necessary. A review of both key deliverables and project performance to date to a) determine if the project should continue into its next phase and b) detect and correct errors cost effectively should be regarded as good practice. Formal phase completion does not necessarily include authorizing the subsequent phase. For instance, if the risk is deemed to be too great for the project to continue or if the objectives are no longer required, a phase can be closed with the decision to not initiate any other phases..2 Phase-to-Phase Relationships When projects are multi-phased, the phases are part of a generally sequential process designed to ensure proper control of the project and attain the desired product, service, or result. However, there are situations when a project might benefit from overlapping or concurrent phases. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 20 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 There are three basic types of phase-to-phase relationships: A sequential relationship, where a phase can only start once the previous phase is complete. Figure 2-4 shows an example of a project with entirely sequential phases. The step-by-step nature of this approach reduces uncertainty, but may eliminate options for reducing the schedule. An overlapping relationship, where the phase starts prior to completion of the previous one (see Figure 2-5). This can sometimes be applied as an example of the schedule compression technique called fast tracking. Overlapping phases may increase risk and can result in rework if a subsequent phase progresses before accurate information is available from the previous phase. One Approach to Cleaning Up a Hazardous Waste Site Facility Decommissioning Waste Removal/Cleanup Landscaping Monitoring & Controlling Processes Monitoring & Controlling Processes Monitoring & Controlling Processes Initiating Planning Executing Closing Initiating Planning Executing Closing Initiating Planning Executing Closing Processes Processes Processes Processes Processes Processes Processes Processes Processes Processes Processes Processes Figure 2-4. Example of a Three-Phase Project Figure Potential Approach to Building a New Factory Design Phase Monitoring & Controlling Processes Construction Phase Monitoring & Controlling Processes Initiating Planning Executing Closing Processes Processes Processes Processes Initiating Planning Executing Closing Processes Processes Processes Processes 2-5. Example of a Project with Overlapping Phases This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 21 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION An iterative relationship, where only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can reduce the ability to provide long term planning The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases. For multi-phase projects, more than one phase-to-phase relationship could occur during the project life cycle. Considerations such as level of control required, effectiveness, and degree of uncertainty determine the relationship to be applied between phases. Based on those considerations, all three relationships could occur between different phases of a single project. 2.2 Projects vs. Operational Work Organizations perform work to achieve a set of objectives. In many organizations the work performed can be categorized as either project or operations work. These two types of work share a number of characteristics as follows: Performed by individuals, Limited by constraints, including resource constraints, Planned, executed, monitored and controlled, and Performed to achieve organizational objectives or strategic plans. Projects and operations differ primarily in that operations are ongoing and produce repetitive products, services, or results. Projects (along with team members and often the opportunity) are temporary and end. Conversely, operations work is ongoing and sustains the organization over time. Operations work does not terminate when its current objectives are met but instead follow new directions to support the organization’s strategic plans. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 22 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Operations work supports the business environment where projects are executed. As a result, there is generally a significant amount of interaction between the operations departments and the project team as they work together to achieve project goals. An example of this is when a project is created to redesign a product. The project manager may work with multiple operational managers to research consumer preferences, draw up technical specifications, build a prototype, test it, and begin manufacturing. The team will interface with the operational departments to determine the manufacturing capacity of current equipment, or to determine the most appropriate time to transition production lines to produce the new product. The amount of resources supplied from operations will vary from project to project. One example of this interaction is when individuals from operations are assigned as dedicated project resources. Their operational expertise is used to carry out and assist in the completion of project deliverables by working with the rest of the project team to complete the project. Depending on the nature of the project, the deliverables may modify or contribute to the existing operations work. In this case, the operations department will integrate the deliverables into future business practices. Examples of these types of projects can include, but are not limited to: Developing a new product or service that is added to an organization’s product line to be marketed and sold, Installing products or services that will require ongoing support, Internal projects that will affect the structure, staffing levels, or culture of an organization, or Developing, acquiring, or enhancing an operational department’s information system. 2.3 Stakeholders Stakeholders are persons or organizations (e.g., customers, sponsors, the performing organization, or the public), who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project. Stakeholders may also exert influence over the project, its deliverables, and the project team members. The project management team must identify both internal and external stakeholders in order to determine the project requirements and expectations of all parties involved. Furthermore, the project manager must manage the influence of the various stakeholders in relation to the project requirements to ensure a successful outcome. Figure 2-6 illustrates the relationship between the project, the project team, and other common stakeholders. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 23 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION Project Life Cycle and Organization Project Stakeholders Other Operations Stakeholders Sponsor Portfolio Management Functional Manager Managers Project Team Project Other Manage- Project Sellers/ Program Project Team Business ment Manager Manager Members Team Partners Project Manage- Customers/ ment Users Office The Project Figure 2-6. The Relationship Between Stakeholders and the Project Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project life cycle. Their responsibility and authority may range from occasional contributions in surveys and focus groups to full project sponsorship, which includes providing financial and political support. Stakeholders can have an adverse impact on the project objectives. Stakeholder identification is a continuous process and can be difficult. For instance, it could be argued that an assembly-line worker whose future employment depends on the outcome of a new product-design project is a stakeholder. Identifying stakeholders and understanding their relative degree of influence on a project is critical. Failure to do so can extend the timeline and raise costs substantially. An example is late recognition that the legal department is a significant stakeholder which results in delays and increased expenses due to legal requirements. A project can be perceived as having both positive and negative results by the stakeholders. Some stakeholders benefit from a successful project, while other stakeholders perceive negative outcomes from a project’s success, for example, business leaders from a community that will benefit from an industrial expansion project by positive economic benefits to the community. In the case of stakeholders with positive expectations from the project, their interests are best served by helping the project succeed. The interests of negative stakeholders are served by impeding the project’s progress. Overlooking negative stakeholders can result in an increased likelihood of failure. An important part of a project manager’s responsibility is to manage stakeholder expectations. This can be difficult because stakeholders often have very different or conflicting objectives. Part of the project manager’s responsibility is to balance these interests and ensure that the project team interacts with stakeholders in a professional and cooperative manner. The following are some examples of project stakeholders. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 24 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Customers/users. The customers/users are the persons or organizations that will use the project’s product or service or result. Customers/users may be internal and/or external to the performing organization. There may also be multiple layers of customers. For example, the customers for a new pharmaceutical product can include the doctors who prescribe it, the patients who use it, and the insurers who pay for it. In some application areas, customers and users are synonymous, while in others, customers refer to the entity acquiring the project’s product, and users refer to those who will directly utilize the project’s product. Sponsor. A sponsor is the person or group that provides the financial resources, in cash or in kind, for the project. When a project is first conceived, the sponsor champions the project. This includes serving as spokesperson to higher levels of management to gather support throughout the organization and promote the benefits that the project will bring. The sponsor leads the project through the engagement or selection process until formally authorized, and plays a significant role in the development of the initial scope and charter. For issues that are beyond the control of the project manager, the sponsor serves as an escalation path. The sponsor may also be involved in other important issues such as authorizing changes in scope, phase-end reviews, and go/no-go decisions when risks are particularly high. Portfolio managers/portfolio review board. Portfolio managers are responsible for the high-level governance of a collection of projects or programs, which may or may not be interdependent. Portfolio review boards are committees usually made up of the organization’s executives who act as a project selection panel. They review each project for its return on investment, the value of the project, risks associated with taking on the project, and other attributes of the project. Program managers. Program managers are responsible for managing related projects in a coordinated way to obtain benefits and control not available from managing them individually. Program managers interact with each project manager to provide support and guidance on individual projects. Project management office. A project management office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of a project. The PMO can be a stakeholder if it has direct or indirect responsibility for the outcome of the project. The PMO can provide but is not limited to: This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 25 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION ○ Administrative support services such as policies, methodologies, and templates; ○ Training, mentoring, and coaching of project managers; ○ Project support, guidance, and training on how to manage projects and the use of tools; ○ Resource alignment of project staff; and/or ○ Centralized communication among project managers, project sponsors, managers, and other stakeholders. Project managers. Project managers are assigned by the performing organization to achieve the project objectives. This is a challenging, high-profile role with significant responsibility and shifting priorities. It requires flexibility, good judgment, strong leadership and negotiating skills, and a solid knowledge of project management practices. A project manager must be able to understand project detail, but manage from the overall project perspective. As the person responsible for the success of the project, a project manager is in charge of all aspects of the project including, but not limited to: ○ Developing the project management plan and all related component plans, ○ Keeping the project on track in terms of schedule and budget, ○ Identifying, monitoring, and responding to risk, and ○ Providing accurate and timely reporting of project metrics. The project manager is the lead person responsible for communicating with all stakeholders, particularly the project sponsor, project team, and other key stakeholders. The project manager occupies the center of the interactions between stakeholders and the project itself. Project team. A project team is comprised of the project manager, project management team, and other team members who carry out the work but who are not necessarily involved with management of the project. This team is comprised of individuals from different groups with knowledge of a specific subject matter or with a specific skill set who carry out the work of the project. Functional managers. Functional managers are key individuals who play a management role within an administrative or functional area of the business, such as human resources, finance, accounting, or procurement. They are assigned their own permanent staff to carry out the ongoing work, and they have a clear directive to manage all tasks within their functional area of responsibility. The functional manager may provide subject matter expertise or their function may provide services to the project. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 26 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Operations management. Operations managers are individuals who have a management role in a core business area, such as research and development, design, manufacturing, provisioning, testing, or maintenance. Unlike functional managers, these managers deal directly with producing and maintaining the saleable products or services of the enterprise. Depending on the type of project, a formal handoff occurs upon completion to pass technical project documentation and other permanent records into the hands of the appropriate operations management group. Operations management would then incorporate the handed off project into normal operations and provide the long term support. Sellers/business partners. Sellers, also called vendors, suppliers, or contractors, are external companies that enter into a contractual agreement to provide components or services necessary for the project. Business partners are also external companies, but they have a special relationship with the enterprise, sometimes attained through a certification process. Business partners provide specialized expertise or fill a specified role such as installation, customization, training, or support. 2.4 Organizational Influences on Project Management The organizational culture, style, and structure influence how projects are performed. An organization’s degree of project management maturity and its project management systems can also influence the project. When a project involves external entities as part of a joint venture or partnering, the project will be influenced by more than one enterprise. The following sections describe organizational characteristics and structures within an enterprise that are likely to influence the project. 2.4.1 Organizational Cultures and Styles Cultures and styles may have a strong influence on a project’s ability to meet its objectives. Cultures and styles are typically known as “cultural norms.” The “norms” include a common knowledge regarding how to approach getting the work done, what means are considered acceptable for getting the work done, and who is influential in facilitating the work getting done. Most organizations have developed unique cultures that manifest in numerous ways including, but not limited to: Shared visions, values, norms, beliefs, and expectations, Policies, methods, and procedures, View of authority relationships, and Work ethic and work hours. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 27 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION The organizational culture is an enterprise environmental factor as described in Section 1.8. Therefore, a project manager should understand the different organizational styles and cultures that may affect a project. For example, in some cases the person shown at the top of an organization chart may be a figurehead who is not truly in charge. The project manager must know which individuals in the organization are the decision makers and work with them to influence project success. 2.4.2 Organizational Structure Organizational structure is an enterprise environmental factor which can affect the availability of resources and influence how projects are conducted. Organizational structures range from functional to projectized, with a variety of matrix structures between them. Table 2-1 shows key project-related characteristics of the major types of organizational structures. Table 2-1. Organizational Influences on Projects Organization Matrix Structure Project Functional Projectized Characteristics Weak Matrix Balanced Matrix Strong Matrix Project Manager's Low to Moderate High to Little or None Limited Authority Moderate to High Almost Total Resource Low to Moderate High to Little or None Limited Availability Moderate to High Almost Total Who controls the Functional Functional Project Project Mixed Manager Manager project budget Manager Manager Project Manager's Part-time Part-time Full-time Full-time Full-time Role Project Management Part-time Part-time Part-time Full-time Full-time Administrative Staff The classic functional organization, shown in Figure 2-7, is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level. Specialties may be further subdivided into functional organizations, such as mechanical and electrical engineering. Each department in a functional organization will do its project work independent of other departments. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 28 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Project Chief Coordination Executive Functional Functional Functional Manager Manager Manager Staff Staff Staff Staff Staff Staff Staff Staff Staff (Gray boxes represent staff engaged in project activities.) Figure 2-7. Functional Organization Matrix organizations, as shown in Figures 2-8 through 2-10, are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization, and the project manager role is more of a coordinator or expediter than that of a true project manager. Strong matrices have many of the characteristics of the projectized organization, and can have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding. Table 2-1 provides additional details of the various matrix organizational structures. Chief Executive Functional Functional Functional Manager Manager Manager Staff Staff Staff Staff Staff Staff Staff Staff Staff Project (Gray boxes represent staff engaged in project activities.) Coordination Figure 2-8. Weak Matrix Organization This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 29 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION Chief Executive Functional Functional Functional Manager Manager Manager Staff Staff Staff Staff Staff Staff Project Manager Staff Staff Project (Gray boxes represent staff engaged in project activities.) Coordination Figure 2-9. Balanced Matrix Organization Chief Executive Functional Functional Functional Manager of Manager Manager Manager Project Managers Staff Staff Staff Project Manager Staff Staff Staff Project Manager Staff Project Manager Staff Staff Staff (Gray boxes represent staff engaged in project activities.) Project Coordination Figure 2-10. Strong Matrix Organization At the opposite end of the spectrum to the functional organization is the projectized organization, shown in Figure 2-11. In a projectized organization, team members are often co-located, most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 30 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Project Chief Coordination Executive Project Project Project Manager Manager Manager Staff Staff Staff Staff Staff Staff Staff Staff Staff (Gray boxes represent staff engaged in project activities.) Figure 2-11. Projectized Organization Chief Executive Functional Functional Functional Manager of Manager Manager Manager Project Managers Staff Staff Staff Project Manager Staff Staff Staff Project Manager Staff Project Manager Staff Staff Staff Project B Coordination Project A Coordination (Gray boxes represent staff engaged in project activities.) Figure 2-12. Composite Organization This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 31 2 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION Many organizations involve all these structures at various levels, as shown in Figure 2-12 (composite organization). For example, even a fundamentally functional organization may create a special project team to handle a critical project. Such a team may have many of the characteristics of a project team in a projectized organization. The team may include full-time staff from different functional departments, may develop its own set of operating procedures, and may operate outside the standard, formalized reporting structure. 2.4.3 Organizational Process Assets Organizational process assets include any or all process related assets, from any or all of the organizations involved in the project that can be used to influence the project’s success. These process assets include formal and informal plans, policies, procedures, and guidelines. The process assets also include the organization’s knowledge bases such as lessons learned and historical information. Organizational process assets may include completed schedules, risk data, and earned value data. Updating and adding to the organizational process assets as necessary throughout the project are generally the responsibility of the project team members. Organizational process assets may be grouped into two categories:.1 Processes and Procedures The organization’s processes and procedures for conducting work include but are not limited to: Organizational standard processes such as standards, policies (e.g., safety and health policy, ethics policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization); Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria; Templates (e.g., risk, work breakdown structure, project schedule network diagram, and contract templates); Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project; Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention policies, and security requirements); Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria); This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 32 CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION 2 Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking; Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated; Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix; and Procedures for prioritizing, approving, and issuing work authorizations..2 Corporate Knowledge Base The organizational corporate knowledge base for storing and retrieving information includes but is not limited to: Process measurement databases used to collect and make available measurement data on processes and products, Project files (e.g., scope, cost, schedule, and performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact), Historical information and lessons learned knowledge bases (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort), Issue and defect management databases containing issue and defect status, control information, issue and defect resolution, and action item results, Configuration management knowledge bases containing the versions and baselines of all official company standards, policies, procedures, and any project documents, and Financial databases containing information such as labor hours, incurred costs, budgets and any project cost overruns. This copy is a PMI member benefit, not for distribution, sale or reproduction. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA 33

Use Quizgecko on...
Browser
Browser