3.1. Loving the Project Management Processes (PMBOK, Section 3.1)
Before we get too deep into this chapter, learn this: You do not have to do every single project management process on every single project. The project manager and the project team must determine which project management processes are most appropriate for each project. Once the needed processes have been identified, the project manager and project team must also determine to what extent the processes are needed. The processes are tailored to their project. As a heuristic, larger projects require more detail than smaller projects.
The 44 project management processes have been recognized as good practices for most projects, but they are not a mandate for good practices on all projects. For your Project Management Institute (PMI) examination, however, you'll be tested on all of the project management processes in detail. Yep. Although you may not use all of the project management processes in the real world, the exam will test you on all of the processes as if you do. Why? Because there is, no doubt, more than one way to manage a project. PMI isn't stubborn enough to say it's our way or no way—that'd be unreasonable.
The approach that PMI does take, however, is based somewhat on W. Edwards Deming's Plan-Do-Check-Act cycle, as Figure 3-1 demonstrates. In Deming's model, adapted by the American Society for Quality, the end of one process launches the start of another. For example, the end of the planning process allows the launch of the doing process. Once the work has been completed, you check it. Based on the results of your investigation, you'd move right into the acting process, which means you're responding to the results of your checking process.
PMI's project management model, which we'll see throughout this chapter, is a bit more involved than the Plan-Do-Check-Act approach. Figure 3-2 demonstrates the big picture of project management. The components of the model are called the process groups. Process groups are collections of the processes you'll be doing in different situations within your project. You've experienced, I'm sure, that projects are initiated, planned, executed, monitored and controlled, and then closed. There are distinct actions that fit nicely within each one of the process groups—that's the gist of this chapter.
Figure 3-1. PMI's project management model is based on the Plan-Do-Check-Act cycle.
3.1.1. Examining the Process Group Interactions
At first glance, the project management model seems simple. With more study, however, you'll see how complex the interactions between the groups can be. First, project managers realize that there is more than one way to manage a project. Second, these processes and their interactions are the generally accepted best approach to project management. Having said that, there is no hard and fast rule as to the order in which a process should occur once the project is in motion. The nature of the project, the scenario, and the experienced conditions, along with the culture and maturity of the organization, will dictate which process is the best process at any given project moment.
The general consensus on the order of the process groups is as follows:
Initiating
Planning
Executing
Monitoring and controlling
Closing
Figure 3-2. All projects move through five process groups to reach their completion.
The caveat is that a project manager can move between planning, executing, and the monitoring and controlling process groups on an as-needed basis. For example, during project execution, a new risk could be identified. The project manager and project team move back into the planning phase to determine how to respond to the new risk, and then they'll continue to monitor and control the project for additional risks.
|
3.1.2. Choosing the Appropriate Project Processes (PMBOK, Section 3.2)
A moment of clarity: There's a bunch of processes in project management. Sure, we've already established that you won't need all of these processes for every project you manage, but you can be darned certain that you'll need all of the processes to pass your Certified Associate in Project Management (CAPM) or Project Management Professional (PMP) exam. Let's dive in and check out these process groups and all their kids—the 44 project management processes.
You've already learned the five process groups: initiating, planning, executing, monitoring and controlling, and closing. These groups are universal to all projects, from building the pyramids to rolling out the latest, greatest whiz-bang software over your IT network. It doesn't matter; project management is project management. Figure 3-3 captures all of the processes in the most likely order in which they should happen—if they're going to happen (remember, you don't need all of the processes on every project, every single time).
3.1.3. Working with Process Groups
Project management is more than just getting the project work done. It's the management, leadership, and execution of the project team. (And by execution, I mean the project team executing the project plan, not you executing the team—although that can be tempting at times.) As you agree to manage a project, you'll move through some logical activities to get your project moving along. These are the process groups that are universal to project management. Let's take a more detailed look at these process groups and the type of work that will be happening in each:
Initiating Management and/or your customer is authorizing the project or a project's phase to begin.
Planning You and the key stakeholders are defining and refining the project's goals and objectives. Once the project's objectives have been defined, you and the key stakeholders will plan on how to reach those objectives.
Figure 3-3. Process groups happen in the same order on every project; processes don't always.
Executing Now that you have a project plan, it's time to put the plan into action. You've heard the saying, "Plan your work and now work your plan?" This is the "working of the plan" part.
Monitoring and controlling Your project team is doing the work, but it's up to you to measure and monitor things to ensure that the project team is doing the work as it was planned. The results of your measurements—primarily in cost, time, scope, and quality—will show discrepancies between what was planned and what was experienced. These discrepancies are your project variances.
Closing Boy, howdy! There's nothing more fun, usually, than closing a project. This process group focuses on formal acceptance of the project's deliverable. The closing process group also focuses on bringing the project or project phase to a tidy ending.
Now that you've got the big picture on these process groups, let's take that in-depth look at each group and all the business that happens within each one. Hold your excitement!
3.1.4. Initiating Your Project (PMBOK, Section 3.2.1)
The initiating process group starts all the project fun; it's the formal processes that start a project or a project phase. These initiating processes, which I'll delve into in one moment, are often done outside of the project manager's domain of control. For example, a company's project portfolio management may not include any input from the project managers within their firm. The senior management could choose which projects should be initiated and funded long before the project managers get involved. In other organizations, the project manager may be involved from the project conception all the way through the project closure. As a general rule, the initiation of a project happens, to some extent, without the project manager, but the initiation process group is included as part of the project management life cycle.
|
The project manager is assigned during initiation, and the inputs from the original project initiator and/or the project sponsor are considered throughout the initiation processes. One of the first activities of the project is to document the project assumptions and constraints. Here's the difference between these two:
Assumptions are things believed to be true but not proven to be. For example, construction projects plan to complete their work during the spring and summer months because of cooperating weather. It's an assumption that the weather will be agreeable for their work during these seasons as opposed to the winter months, although this isn't always true.
Constraints are anything that restricts a project manager's options. For example, a customer must have the project deliverable by a specific date. Or the project must not exceed $2 million dollars. Or the software must be compatible with an Oracle database. Usually, any project requirement preceded by "must" is a good sign of a constraint.
Assumptions and constraints are documented in the project charter. The project charter officially authorizes the project and is authorized outside of the project boundaries. This means that the charter should come from some entity that is above the project manager and the functional managers involved in the project. Figure 3-4 illustrates this concept. While the project management team may help write the charter, the funding and authorization come from higher up in the organization or by the project customer.
At the start of each project phase, especially on larger projects, it's ideal to repeat the initiating processes to ensure that the project remains focused on the business needs the project is to solve. This includes the availability of the needed project resources (cash, people, materials, and equipment), and based on this discovery, the project should be allowed to continue on to the next phase, delayed, or (gulp!) cancelled. Another benefit of moving through these initiating processes at the start of each phase is that it allows the performing organization to determine if the original business need that the project was created to solve is still valid; if not, the project can be killed. Yes, killed; remember that the end of a phase is called a project kill point.
Figure 3-4. Project charters come from outside of the project boundaries.
When a project or phase is moving through the initiating phase, the project manager needs to include the key stakeholders in the processes. This is a "PMI-ism," but it's also some real-world advice: Including the stakeholders during the initiating phase accomplishes several things for the project:
It creates shared ownership of the project
It ensures deliverable acceptance at project or phase closure
It improves stakeholder satisfaction
It facilitates communication between the project manager and the stakeholders
Developing the Project Charter
The project charter is created during the initiation process group. Recall that the project charter authorizes the project or, in a larger project, the charter initializes the project phase. The charter documents the business need, defines the project deliverable, and names the project manager. In order to create the project charter, you'll need the following inputs:
Contract You won't always need a contract, but if an organization performs projects for other organizations, such as a consulting firm, the contract serves as a key input to creating the project charter.
Project statement of work This document defines the product, service, or result that the project will be creating.
Enterprise environmental factors Here's a new term that you'll be seeing lots of throughout the remainder of this book. Enterprise environmental factors are any external or internal organizational factors that can affect a project's success. Enterprise environmental factors include the culture, organizational structure, resources, commercial databases the project will use, market conditions, and your project management software.
Organizational process assets This is another term that you'll see throughout the Project Management Body of Knowledge (PMBOK) and during our time together in this book. "Organizational process assets" is a fancy way of describing how a company does business; it includes the processes and procedures unique to an organization, plans, guidelines, and knowledge bases, such as the lessons learned documentation from past projects and any relevant historical information.
Developing the Project Scope Statement
Technically, really technically, the project scope is not finalized until the project moves into the project planning process group. However, here in the initiation process group, a high-level, broad project scope is developed. This first edition of the project scope defines the project, project deliverables, product requirements, project boundaries, acceptance procedures, and scope control. If you're managing a project that includes multiple phases, this high-level document would address each phase as it begins. In order to create this project scope statement, you'll need some familiar items:
Project charter
Project statement of work
Enterprise environmental factors
Organizational process assets
3.1.5. Planning the Project (PMBOK, Section 3.2.2)
Projects fail at the beginning and not the end. It's up to effective planning, or the project will be doomed. The whole point of the planning process group is to develop the project management plan. The good news is that the entire project doesn't have to happen in one session; in fact, planning is an iterative process, and the project manager and the project team return to the planning phase as needed to allow the project to move forward.
Ask any project manager if changes ever happen in their projects, and they'll give you a sad yes (unless they lie). Changes, often the nemesis of a project manager, require the project manager and the project team to revisit these planning processes to consider the impact of the changes on the entire project. This may include, unfortunately, revisiting the initiating processes and making changes to the project charter, although this is a drastic and infrequent event.
One approach to project management that has gained fans in the past few years is rolling wave planning. Rolling wave planning, seen in Figure 3-5, entails iterations of planning throughout the project life cycle. Changes and conditions within the project require the project manager and the project team to revisit the planning processes and then move on to the project. Rolling wave planning can also be experienced in larger projects, where a project team plans in detail for the immediate work and leaves the future work less planned. As the project approaches each phase, detailed planning is experienced, creating iterations, or waves, of planning.
The project manager and the project team should create an environment where stakeholders can participate and contribute to the project's planning processes. A project manager wants to use the skills and knowledge of the stakeholders to help define the project scope and the product scope, as well as to ensure that the project work will deliver upon the stakeholders' expectations.
A frequent question that I get from students of my project management classes centers on project management planning. I'm asked, "If planning is so important and iterative, how does a project manager know when the planning process group should end?" Of course, planning cannot, thankfully, continue forever. There must be project boundaries and considerations of the enterprise environmental factors that dictate the amount of time a project team invests in the initial planning and the project work. As a project moves into execution and, by default, monitoring and controlling, the project team can revisit the planning processes as needed to allow the project to continue. For example, if new risks are identified within the project, then additional planning is required to evaluate and respond to the risks.
Figure 3-5. Rolling wave planning allows for iterations of the planning processes.
Developing the Project Management Plan
The project management plan is not one plan, but a collection of subsidiary plans that dictate how the project will operate within that knowledge area. It also defines how the project will operate within planning, executing, monitoring and controlling, and closing phases. In order to create the project management plan, you'll need:
A preliminary project scope statement
Project management processes
Enterprise environmental factors
Organizational process assets
Planning the Project Scope
In Chapter 5 we'll discuss and dissect the project scope in detail. For now, know that the project scope is the work that must be done in order to create the product, service, or result the project aims to deliver. The project manager, the project team, and the stakeholders work together to define the project scope; their goal is to create the project scope management plan. The project scope management plan defines how the project scope will be defined, verified, controlled, and how the project's work breakdown structure (WBS) will be created. The WBS, if you're not familiar with the term, is a breakdown of the project scope, and is often called the scope baseline. In order to create the project scope management plan, you'll need:
Enterprise environmental factors
Organizational process assets
A project charter
A preliminary project scope statement (created during project initiation)
A project management plan
Defining the Project Scope Statement
Now that the project has a project scope management plan, the project manager, project team, and the key stakeholders can go about defining the actual project scope. The project scope statement serves as a basis for all future project decisions. As part of defining the project scope, several inputs are needed:
Organizational process assets
Project charter
Preliminary project scope statement
The last bulleted item, approved change requests, considers the iterative nature of the planning process group and allows change requests to be considered and fleshed into the project scope as needed and approved. This process group has many outputs that are related to the project scope:
Project scope statement
Requested changes
Project scope management plan updates
Creating the Work Breakdown Structure
The WBS is created in the planning process group. This process takes the project scope and breaks it down into smaller, more manageable components. In Chapter 5, we'll discuss the WBS, its purpose, and its creation. In order to create a WBS, you'll need the following:
Organizational process assets
Project scope statement
Project scope management plan
Approved change requests
As a result of creating the WBS, the project manager will get some extras, wanted or not:
WBS
Project scope statement updates
WBS dictionary (this defines all of the components within the WBS)
Scope baseline
Project scope management plan updates
Change requests
|
Defining the Project Activities
Once the WBS has been created, the project manager and project team can examine the deliverables and then determine the actual work to create the things the WBS promises. This is activity definition. To complete this process, you'll need:
Enterprise environmental factors
Organizational process assets
Project scope statement
WBS
WBS dictionary
Project management plan
As a result of defining the project activities, the project team will receive these outputs:
Activity list
Activity attributes
Milestone list
Requested changes
Sequencing the Project Activities
It's a logical progression from defining the project deliverables and the activities needed to create them to putting those activities in a particular order. In order to sequence the project activities, the project team will need:
Project scope statement
Activity list
Activity attributes
Milestone list
Approved change requests
Like the majority of the processes in planning, the output of the processes often includes other project elements that may be needed for later purposes in project planning. Activity sequencing is no different; the outputs of this process are:
Project schedule network diagrams (you'll learn more about these in Chapter 6)
Activity list updates
Activity attributes updates
Change requests
Estimating the Resources
The project manager needs to know what resources will be required for each of the project activities. In order to complete this process, you'll need the following inputs:
Enterprise environmental factors
Organizational process assets
Activity lists
Activity attributes
Resource availability
Project management plan
Once the project manager has completed estimating the resources, she'll receive several outputs as a result of this process:
Activity resource requirements
Activity attributes updates
Resource breakdown structure (this shows the types of resources the project needs, such as professional engineers, structural engineers, or Computer Aided Design [CAD]/Computer Aided Manufacturing [CAM] operators)
Resource calendar updates (the resource calendar, which you'll see again in Chapter 9, defines when the project resources are available)
Change requests
Estimating the Activity Durations
Once the project manager knows what activities are required and in what order the activities should happen, it's time to estimate how long each activity will take to complete. In order to create the activity duration estimates, the project manager will need:
Enterprise environmental factors.
Organizational process assets.
Activity list.
Activity attributes.
Activity resource requirements.
Resource calendar.
Project management plan.
Risk register. (This is a repository of the project's risks and their attributes. Chapter 11 discusses the risk register.)
Activity cost estimates.
While this process primarily creates the duration of each of the project's activities, the project manager may also have activity attribute updates.
Developing the Project Schedule
The project schedule is more than just the sum of how long each event will take. The project schedule considers the availability of the project resources, the risks, the attributes of the project activities, and more. Chapter 6 will focus on this process, but for now, here are the inputs required to create the project schedule:
Organizational process assets
Project scope statement
Activity list
Activity attributes
Project schedule network diagrams
Activity resource requirements
Resource calendars
Activity duration estimates
Project management plan
Risk register
Based on these inputs to the schedule development, the project team will have several outputs:
Project schedule (this is the calendar that defines when the project will take place, including the working hours, access to the job site, and any other time constraints put on the project)
Schedule model data
Schedule baseline
Resource requirements updates
Activity attributes updates
Project calendar updates
Requested changes
Project management plan updates
Schedule management plan updates
Cost Estimating
Projects cost money, and every stakeholder with a checkbook wants to know how much the project will cost. This process focuses on estimating the costs for the project. The following serve as inputs to this process:
Enterprise environmental factors
Organizational process assets
Project scope statement
WBS
WBS dictionary
Project management plan
Schedule management plan
Staffing management plan
Risk register
These inputs will help the project manager create the following outputs of cost estimating:
Activity cost estimates
Activity cost estimates supporting detail
Change requests
Cost management plan updates
Budgeting the Project Work
Once the project manager has created the cost estimate, he'll aggregate the individual activities and their attributes, such as labor and materials, to create a cost baseline for the project. This process requires several inputs:
Project scope statement
WBS
WBS dictionary
Activity cost estimates supporting detail
Project schedule
Resource calendars
Contract (if applicable)
Cost management plan
The outputs of cost budgeting are:
Cost baseline
Project funding requirements
Cost management plan updates
Change requests
Planning for Quality
The project manager, the project team, and the key stakeholders will work together to determine how the project will ascertain the expected levels of quality within the project. Chapter 8 will discuss quality in detail, but for now, there are several inputs to this quality planning:
Enterprise environmental factors
Organizational process assets
Project scope statement
Project management plan
As a result of planning for the quality, the project management team will create the following outputs:
Quality management plan
Quality metrics
Quality checklists
Process improvement plan
Quality baseline
Project management plan updates
Planning for Human Resources
Of course, the project will need people to do the work—that's the project team! Chapter 9 discusses human resource planning in detail. This process specifically focuses on creating the staffing management plan, defining the project roles, defining reporting relationships, and defining responsibilities of the project team members. Here are the required inputs for human resources planning:
Enterprise environmental factors
Organizational process assets
Project management plan
Activity resource requirements
Once all the planning is completed, the project manager will have these outputs:
Roles and responsibilities
Project organization chart
Staffing management plan
|
Planning for Project Communications
It's been said that 90 percent of a project manager's time is spent communicating. With that factoid, it's no wonder that the project manager will want to plan to communicate effectively. Here are the required inputs to get this process started:
Enterprise environmental factors
Organizational process assets
Project scope statement
Project management plan
Constraints
Assumptions
The only output of this process is the communications management plan. Now there's something to discuss. (I will in Chapter 10.)
Planning for Project Risks
The project manager, the project team, and the key stakeholders will plan how to manage risk and the associated risk management activities. We'll cover this process in Chapter 11, but here are the inputs for this process for now:
Enterprise environmental factors
Organizational process assets
Project scope statement
Project management plan
This process also has but one output: the risk management plan.
Identify the Project Risks
Once the risk management plan has been created, the project management team can go about the process of identifying all the good and naughty risks within the project. In order to get this fun started, they'll need these inputs:
Enterprise environmental factors
Organizational process assets
Project scope statement
Project management plan
This process will create the central repository of project risks: the risk register. Chapter 11 explains the risk identification process and the risk register in greater detail.
Completing Qualitative Risk Analysis
Qualitative risk analysis is completed in the planning process group and "qualifies" the identified risks for additional study and analysis. Here are the inputs for this process:
Organizational process assets
Project scope statement
Risk management plan
Risk register
The only outputs of this process are updates to the risk register. In particular, the identified risks' qualitative attributes should be updated in the risk register.
Completing Quantitative Risk Analysis
This process aims to quantify the risk exposure for the risks in the project. This process is covered in more detail in Chapter 11. Here are the inputs for this process:
Organizational process assets
Project scope statement
Risk management plan
Risk register
Project management plan
Project schedule management plan
Project cost management plan
Like qualitative analysis, quantitative analysis has but one output: updates to the risk register.
Planning the Risk Responses
Okay, the project manager, the project team, and all the key stakeholders have had some serious fun identifying and performing analysis on the project risks. Now it's time to get down to the business of planning the responses to the identified risks. There are only two inputs to the risk response planning process:
Risk management plan
Risk register
This process may take some time, and will create three outputs:
Project management plan updates
Risk-related contractual agreements (think of errors-and-omissions insurance; not every project will have a risk-related contract)
Planning for Purchases and Acquisitions
When a project manager needs to purchase something for the project, there are usually rules and procedures she must follow within her organization. Buying services and products for a project requires many inputs:
Enterprise environmental factors
Organizational process assets
Project scope statement
WBS
WBS dictionary
Project management plan
Risk register
Risk-related contractual agreements
Resource requirements
Project schedule
Activity cost estimates
Cost baseline
All of these inputs allow the project manager and the project team to consider and evaluate what needs to be purchased, determine what risks may need to be considered, and then decide how the purchasing will commence. Chapter 12 centers on procurement, but here are the outputs of this process:
Project management plan
Contract statement of work (this is what the vendor will do for the buyer)
Make-or-buy decisions
Change requests
Planning for Contracting
Once the project manager and the vendors have a deal, there needs to be a contract that defines the offer and consideration of the deal. That's what this process is all about—documenting the purchase requirements between the buyer and seller. Here are the inputs for this process:
Project management plan
Contract statement of work
Make-or-buy decisions
Project management plan
Risk register
Risk-related contractual agreements
Resource requirements
Project schedule
Activity cost estimate
Cost baseline
All of these inputs help the project manager make the best purchasing decisions, and will create the following outputs:
Procurement documents (these are the purchase orders, statements of work, proposals, bids, and other purchase documents you'll see in Chapter 12)
Evaluation criteria
Contract statement of work
3.1.6. Executing Processes (PMBOK, Section 3.2.3)
The executing processes allow the project work to be performed. It is the execution of the project plan, the execution of vendor management, and the management of the project implementation. The project manager works closely with the project team in this process to ensure that the work is being completed and that the work results are of quality. The project manager also works with vendors to ensure that their procured work is complete, of quality, and meets the obligations of the agreed contracts.
Throughout the project, variances may happen. A variance is simply the difference between what was planned and what was experienced. For example, there are cost variances, schedule variances, and even scope variances. When variances happen within a project, the project manager and the project team retreat to the planning process group, analyze the variance, and determine the best method to respond. The response may, in turn, cause the project management plan to be changed, which could, in turn, affect the activities of the execution process group.
This process group is about getting the project work done. You can plan as much as you want, but it's in the doing that matters. This process group consumes the project budget more than any other group because the project team is doing the work, using the materials, and relying on the vendors to deliver upon their contracts. This process group has seven processes.
Managing and Executing the Project Plan
This is the heart of the project: getting the work done. This process guides, directs, and leads the project team to complete their assignments according to the project management plan. The project team's performance is measured, and that information will serve as input to performance reviews later in the project (team members be warned!). Here are the inputs for managing and executing the project plan:
Project management plan.
Approved corrective actions. (A corrective action brings project work back into alignment with the project plan.)
Approved preventive actions. (A preventive action is a risk-related action that avoids risk within the project; think of a workaround to a problem within your project.)
Approved change requests.
Approved defect repair. (A defect repair is an activity to repair a mistake within the project; think of a painter who painted a wall the wrong shade of green. Oops!)
Validated defect repair.
Administrative closure procedure.
The outputs of project execution are:
Deliverables.
Change requests.
Implemented change requests.
Implemented corrective actions.
Implemented preventive actions.
Implemented defect repair. Work performance information. (This is the performance measurement of the project team and the project work as a whole.)
Performing Quality Assurance
Quality assurance (QA) is a management process that all projects adhere to within an organization. QA will be discussed in more detail in Chapter 8. Here are the inputs to performing quality assurance:
Quality management plan
Quality metrics
Process improvement plan
Work performance information
Approved change requests
Quality control measurements
Implemented change requests
Implemented corrective actions
Implemented defect repairs
Implemented preventive actions
All of these QA input processes will help the project management team create the following outputs:
Change requests
Recommended corrective actions
Organizational process assets
Updates
Project management plan updates
Acquiring the Project Team
The project team doesn't join the project until the execution process group. This is a great example of how the planning process group is an iterative process. The project manager is in planning and then shifts to execution to acquire the project team. Now the project team and the project manager return to planning to create the project management plan. In order to complete the team acquisition, the following inputs are needed:
Enterprise environmental factors
Organizational process assets
Roles and responsibilities
Project organization charts
Staffing management plan
Using these inputs, the project manager creates the following outputs:
Project staff assignments
Resource availability determination
Staffing management plan updates
Developing the Project Team
Developing the project team is an execution process that seeks to determine and, if necessary, improve the skill sets of the project team members. This process, which I'll talk about in Chapter 9, also focuses on improving the interaction, communication, and trust of the project team members. You'll need the following inputs to facilitate project team development:
Project staff assignments
Staffing management plan
Resource availability
This process only creates one little, but important, output: team performance assessment. Team performance assessment will help the project manager make decisions on how to better manage and lead the project team members—and perform future team development exercises.
|
Distributing Project Information
The project manager has to disperse information to keep the project stakeholders informed of the project's health, status, and pending actions. In order to disperse information, the project manager will rely on the communications management plan. As a result of dispersing information, the project manager will keep stakeholders informed, but will also have two direct outputs:
Organizational process assets updates
Change requests
That was a tough one, yes?
Requesting Seller Responses
Remember all that fun earlier with procurement? Now the project manager is waiting for those pesky vendors to respond to the procurement documents. In order to complete this executing process, the project manager will need the following inputs:
As a result of this process, the project manager will receive three outputs:
Qualified sellers list. (This list may evolve within the performing organization or on a project-by-project basis. Either way, these are the vendors who the project manager is allowed to purchase from because they meet certain defined qualifications.)
Procurement document package. (This is all of the related procurement documents between the buyer and the seller.)
Proposals.
Choosing the Best Seller
Now that the sellers have provided their responses to the project manager's procurement documents, it's time to choose which seller is best for the project. This process, which Chapter 12 covers in detail, also deals with negotiating for the best deal with the vendors. Here are the inputs to this process:
Organizational process assets
Procurement management plan
Evaluation criteria
Procurement document package
Proposals
Qualified sellers lists
Project management plan
Risk register
Risk-related contractual agreements
This process creates the following outputs:
Selected sellers
Contract
Contract management plan
Resource availability determination
Procurement management plan updates
Requested changes
3.1.7. Examining the Monitoring and Controlling Process Groups (PMBOK, Section 3.2.4)
Wouldn't the project management life be even greater if all of the projects went off without a hitch? If only the project team, the project work, the stakeholders, and the vendors would cooperate. Oh, but we know that projects have to be constantly monitored like a three-year-old in a china shop.
This process group focuses on monitoring the project work for variances, changes, and discrepancies so that corrective action can be used to ensure that the project continues to move towards its successful completion. This means lots of measuring, inspecting, and communicating with the project team to ensure that the project plan is followed, variances to the plan are reported, and responses can be expedited.
This process group also is concerned with changes that may attack the Iron Triangle of Project Management: time, cost, and scope. As changes are allowed into the project, or changes sneak into a project through scope creep, they must be examined for their overall effect on the project's execution and, ultimately, on the project deliverable. Chapters 5, 6, and 7 will cover scope, time, and cost control, but project managers also have to be concerned with quality control. It doesn't do much good if a project is completed on time and on budget, but the deliverable is fouled, full of errors, and of poor quality. Chapter 8 will examine control in detail. Let's take a quick look at each of the 12 processes within this group.
|
Monitoring and Controlling the Project Work
What'd you expect to be doing in the monitor and control process group? This process is the heart of the process group, and includes the entire collection of project characteristics, such as time, cost, and quality statistics. Based on the collected statistics, the project manager can measure the project success, identify trends, make forecasts, create project reports, and take actions to improve the project. Here are the inputs for this process:
Project management plan
Work performance information
Rejected change requests
The outputs of monitoring and controlling the project work will give the project team five outputs:
Recommended corrective actions
Recommended preventive actions
Project forecasts
Recommended defect repairs
Change requests
Managing Integrated Change Control
Integrated change control is a process that examines how a change affects all parts of a project. Consider a change to the project scope on a project you've worked on. The change likely affected the project cost, the project schedule, and the expectations of the project quality. The change may also have affected other regions of your project: risk management, communications, human resources, and even procurement. Integrated change control manages the approved changes within a project, how and when the changes may occur, and determines if a change to the project may have already occurred. This process, as fun as it is, happens from project initiation through project closing. There are many inputs for this process:
Project management plan
Requested changes
Work performance information
Recommended preventive actions
Recommended corrective actions
Recommended defect repairs
Project deliverables
These inputs and this process will help the project manager and the project team create the following outputs:
Approved change requests
Rejected change requests
Project management plan updates
Project scope statement updates
Approved corrective actions
Approved preventive actions
Approved defect repairs
Validated defect repairs
Project deliverables
Verifying the Project Scope
If you were to hire an architectural firm to build your next mansion, you'd periodically visit the house under construction to ensure that the workers and the architects were building according to the plans you provided them. At the end of the project, you'd walk through the home and create a "punch list" of all the things that needed to be changed or repaired according to your agreement. The architectural firm would work with you to ensure that you're happy with the deliverable you asked for and the deliverable they have created for you. This is scope verification: the formal acceptance by inspection of the project deliverables. Here are the inputs the project manager needs to facilitate this process with the project customer:
Project scope statement
WBS dictionary
Project scope management plan
Deliverables
The customer would inspect and then, hopefully, formally accept the project work or provide feedback on what needs to be corrected or changed. Here are the outputs of scope verification:
Formal acceptance of the project deliverables
Change requests
Recommended corrective actions
Controlling the Project Scope
Once the project scope statement has been created, it is paramount to guard the scope from unauthorized changes and to follow a scope change control system within the project to ensure that any approved changes reflect the changes through cost, time, scope, quality, and the other knowledge areas within the project. Here are the inputs to perform this process:
Project scope statement
WBS
WBS dictionary
Project scope statement management plan
Performance reports
Approved change requests
Work performance information
The outputs of this massive and not-so-enjoyable process are:
Project scope statement updates. (Makes sense, right? If changes are approved to the project scope, then the changes have to be reflected in the scope statement, the WBS, and the WBS dictionary.)
WBS updates.
WBS dictionary updates.
Scope baseline updates.
Change requests.
Recommended corrective actions.
Organizational process asset updates.
Project management plan updates.
Controlling the Project Schedule
This process isn't a mystery: It's simply keeping the project on schedule so that it finishes on time as planned. When variances happen within the project, the project manager and the project team have to plan how to respond to these schedule variances. I'll discuss scheduling and schedule control in Chapter 6. For now, here are the inputs for this process:
Schedule management plan
Schedule baseline
Performance reports
Approved change requests
This process creates several outputs:
Schedule model data updates
Schedule baseline updates
Performance measurements
Change requests
Recommended corrective actions
Organizational process asset updates
Activity list updates
Activity attribute updates
Project management plan updates
Controlling the Project Cost
Have you ever noticed that it's usually easier to get more time than money for your projects? Management dreads hearing that a project will cost more due to errors and variances. This process aims to prevent cost overruns and control the expenses within a project. There are many inputs for this process:
Cost baseline
Project funding requirements
Performance reports
Work performance information
Approved change requests
Project management plan
Chapter 7 is all about managing project costs, including creating cost estimates and budgets. Here are the outputs of cost control:
Cost estimate updates
Cost baseline updates
Performance measurements
Forecasted completion
Change requests
Recommended corrective actions
Organizational process asset updates
Project management plan updates
Performing Quality Control
Quality control (QC), which is covered in Chapter 8, is all about keeping the mistakes out of the project—and ultimately away from the customers—before the project is declared finished. QC is considered an inspection-driven process, because that's the primary activity involved with it. Here are the inputs to perform this process:
Quality management plan
Quality metrics
Quality checklists
Organizational process assets
Work performance information
Change requests
Deliverables
QC creates many outputs that can help the project manager and the project team improve the project performance and ensure that the project work is completed correctly for the customer. Here are the outputs of QC:
Quality control measurements
Validated defect repairs
Quality baseline updates
Recommended corrective actions
Recommended preventive actions
Requested changes
Recommended defect repairs
Organizational process asset updates
Validated deliverables
Project management plan updates
Managing the Project Team
This process centers on you, the project manager. It's how you will manage, track performance, offer feedback, resolve issues, and manage your project team in the best interest of the project. There are many inputs to this process:
Organizational process assets
Project staff assignments
Roles and responsibilities
Staffing management plan
Team performance assessment
Work performance information
Performance reports
As you lead your project team through their project work—and to the project deliverable—you'll be completing this process. There are several outputs of managing the project team:
Change requests
Recommended corrective actions
Recommended preventive actions
Organizational process asset updates
Project management plan updates
Reporting Project Performance
Management, your project team, key stakeholders, and the project customer will want the project manager to keep them abreast of the project performance. That's what this process is all about. There are seven inputs to performance reporting:
Work performance information
Performance measurements
Forecasted completion
Quality control measurements (if you don't measure, you can't improve)
Project management plan
Performance measurement baseline
Approved change requests
Deliverables
As the project manager shares the project performance information, there will be five outputs:
Performance reports
Forecasts
Change requests
Recommended corrective actions
Organizational process asset updates
Managing the Project Stakeholders
Recall that a stakeholder is anyone who has a vested interest in the outcome of the project. Traditionally, the project stakeholders refer to the recipients of the project deliverable, but there's more to being a stakeholder than just that. Stakeholders include the project team, vendors, customers, management, and even the project manager. The project manager has to manage more than just the project team. The stakeholders need some management, too. Often, the stakeholders need more attention than the project team, because they're worried, fretting, and just anxious about the deliverable you're creating for them. Much of stakeholder management is simply communicating with the stakeholders. There are two inputs:
Communications management plan. (This plan tells you who needs what information, when they need it, and the expected modality of the communication.)
Organizational process assets
As you manage the project stakeholders, there will be several outputs:
Resolved issues (it's a good feeling to have issues resolved)
Approved change requests
Approved corrective actions
Organizational process asset updates
Project management plan updates
Monitoring and Controlling Project Risks
A risk is an uncertain event or condition that can affect the project's outcome. Project managers often think of risks as negative events, but that's not always the case. Many risks, such as using a new material, a new vendor, or a new approach to the project work, aren't negative, but have positive outcomes. Chapter 11 will discuss both positive and negative risks in detail. There are five inputs to the risk monitoring and controlling process:
Risk management plan
Risk register
Approved change requests
Work performance information
Performance reports
Risk monitoring and control happens throughout the project's life cycle, not just once. As this process is completed, there will be six outputs:
Risk register updates
Change requests
Recommended corrective actions
Recommended preventive actions
Organizational process asset updates
Project management plan updates
Administering the Project Contracts
If a project manager has to complete the procurement management process, she will also need to administer the project contracts. This process, which Chapter 12 explores, ensures that the relationship between the buyer and the seller remains intact, reviews how the seller is performing by the terms of the contract, and works with the seller to ensure they continue to abide by the agreed contractual terms. This process has six inputs:
Contract. (You need a contract in order to manage one.)
Contract management plan.
Selected sellers.
Performance reports.
Approved change requests. (Change requests can affect the product or service the seller is providing.)
Work performance information. (This input is primarily concerned with the performance of the work as completed by the seller.)
Contract administration creates many outputs:
Contract documentation
Change requests
Recommended corrective actions
Organizational process asset updates
Project management plan updates
Procurement management plan
Contract management plan
3.1.8. Closing the Project (PMBOK, Section 3.2.5)
In project management, there are few things more rewarding than closing a project. It's extremely satisfying, and sometimes sad, to officially close a project and move along to other challenges. This final project management process group has but two processes, but it's no less important than the other process groups within a project. The goals of closing a project are to officially confirm that all of the needed processes have been completed, that the deliverables have been transferred to the user or organization, and that the project is done.
Project closure is also concerned with the success of the project, and these processes can be used when a project may be cancelled before reaching the desired deliverables. If a project has multiple phases, the processes within this group can be used for each phase and at the end of the project.
Closing the Project
This is the goal: close the project and get back to your life. There are several inputs to project closure:
Project management plan
Contract documentation
Enterprise environmental factors
Organizational process assets
Work performance information
Deliverables
When the project manager closes a project, several outputs are created and completed:
Administrative closure procedure
Contract closure procedure
Final product, service, or result
Organizational process asset updates
Closing the Project Contracts
If a project manager has worked with vendors on a project, then there are processes that must be completed during project closure to ensure that all of the terms of the contract have been met. This allows the project manager to confirm that the seller has met its obligations and that the project manager's organization has also met the obligations of the contract before the project is closed. Here are the inputs to this process:
Procurement management plan
Contract management plan
Contract documentation
Contract closure procedure
As a result of performing these activities, there are two outputs of this process:
Closed contracts
Organizational process assets updates
3.1.9. Examining How the Processes Interact (PMBOK, Section 3.3)
The five project management process groups are not unlike the Rubik's Cube toy; what you do in one area affects all the other areas. In project management, the interactions between the processes are somewhat chronological; but often, the processes are iterative, transient, and allow the project management team to shift from process group to process group. The process groups allow for plenty of overlap throughout the whole project. For example, the extent of the monitoring and controlling processes is directly affected by the planning process group.
You've seen throughout this chapter that the output of one process is often an input to another process group. The planning process group is the best example of this axiom; project plans are created and then executed for each knowledge area. As a project moves through its life cycle, the activities of project management—that is, the 44 individual processes—interact, overlap, and share commonalities that allow the project to move forward. Figure 3-6 demonstrates the concept of how processes overlap within a project. Note that in a multiphase project, these processes can be applied to each individual phase and to the project as a whole.
All of these processes are not needed on every single project—only the processes that are relevant to the specific project are needed. For example, a low priority, simple "Move-Add-Change" (MAC) project within an organization likely won't need to complete all 44 processes in order for the project to be completed successfully. However, a four-year project to build a skyscraper will likely use all 44 processes.
Constraints within a project are often seen as process inputs. Consider any project you've worked on where management has enforced a project deadline. The deadline is a constraint that may not allow the project team to determine the best completion through normal project planning, but rather by working backwards from the deadline. Constraints that serve as inputs to process groups can cause additional risks on schedule and quality, can increase project costs, and may even require the project scope to be reduced to hit the project's target preset end date. No fun for anyone!
Figure 3-6. Process groups naturally interact throughout the project.
