6th Edition PMBOK® Guide–Process 4.3 Direct and Manage Project Work: Inputs


Today starts the New Year of 2018, and I wanted to act on a resolution to continue my blogging project of going through the entire 6th Edition PMBOK® Guide so that I am prepared not only to take the PMP exam based on this new edition, but to help teach the material to others.

I left off before the holidays on Chapter 4 Integration Management, and that is where I will continue starting today.    The last process I covered was Process 4.2 Develop Project Management Plan.   Not surprisingly, the output of that process is, of course, the Project Management Plan, which is really like a book that contains several chapters, each of which is a management plan of one of the other knowledge areas.

The next process goes from the Planning Process group to the Executing Process Group, and the Process 4.3 Direct and Manage Project Work consists of exactly what it says:   leading and performing the work as defined in the project management plan, which is the output of Process 4.2 Develop Project Management Plan.   However, there is also another objective of this process and that is to implement approved changes.   These are the output of another process 4.6 Perform Integrated Change Control.    So already you’re seeing that processes are not like a linear set of actions done like passing the baton in a relay race.    It’s more complicated in that the batons are coming from different directions, and they all have to passed forward simultaneously.

Let’s review the inputs to this process so we know all the elements that are going into the process.

1. Project management plan

This should be obvious because now that you’ve planned the work, it is time to work the plan.

2.  Project documents

The PMBOK Guide lists some project documents that are of particular relevance to this process.   What I’m going to do is organize them according to the knowledge area they are pertinent to.

Integration

  • change log–this contains the status of all change requests–those that have been approved will be implemented by the project team
  • lessons learned register–this contains the output of Process 4.4 Manage Project Knowledge, which is the result of a periodic review of the project.   These are used to avoid repeating mistakes and therefore to improve the performance of the project.

Scope

  • Requirements traceability matrix–if there are deliverables that are being worked on during the process 4.3, then if there are any issues involved with their completion, the requirements traceability matrix will help in tracing the underlying requirements connected to those deliverables and who is responsible for owing those requirements.

Schedule

  • Project schedule–this will show the list of work activities, their durations, the resources that are supposed to work on them, and their planned start and finish dates, which will be communicated to the project team
  • Milestone list–this shows the scheduled dates for specific milestones, which will be communicated to management

Communications

  • Project communications–specifically performance reports for the previous work cycle or iteration, the status of deliverables, and any other information that describes the status of the project

Risk

  • Risk report–provides information on overall project risk along with summary information on identified individual project risks–this is the high-level or “big picture” description of the risk environment of the project.   It is the output of process 11.2 Identify Risks.
  • Risk register–provides information on specific threats and opportunities that may impact project execution.

3.  Approved change requests

These are located in the change log document listed above, and are the output of process 4.6 Perform Integrated Change Control.   The approved change request may be

  • defect repair, correcting a defect that has been detected after the work has been done
  • a corrective action, correcting a defect that has been detected while the work is being done
  • preventive action, correcting a defect that may occur in the future if the work continues on its present course

In a parallel to the Christmas Carol by Charles Dickens, I refer to these as the Ghost of Defects Past, the Ghost of Defects Present, and the Ghost of Defects Future, respectively.

These can take the form of either changing the work to fit the plan, if the work has deviated from the plan.   Or, if upon reflection it turns out the plan wasn’t realistic, then you may have to adjust the plan to fit the work, in which case the project management plan will have to be amended, along with any pertinent project documents (like the project schedule, for example).

4.   Enterprise Environmental Factors (EEFs)

The EEFs are conditions not under the control of the project team that can influence a project; these can be either internal or external to the organization.   The EEFs that can be inputs to Process 4.3 Direct and Control Project Work are:

  • The organizational structure, culture and management practices
  • Infrastructure (what facilities and/or equipment are available to do the project work)
  • Stakeholder risk thresholds (in particular, what are the allowable cost and schedule overrun percentages that are allowed before reporting is required to management)

5.  Organizational Process Assets (OPAs)

The OPAs are the processes, policies, procedures, and knowledge bases used by the organization performing the project.    These will be contained within the Project Management Organization or PMO of an organization, if one exists.  The OPAs that can be inputs to Process 4.3 Direct and Control Project Work are:

  • Organizational standard policies, processes, and procedures
  • Issues and defect management databases and procedures for  defining issue and defect controls, issue and defect resolution, and action item tracking
  • Performance measurement databases
  • Change control and risk control procedures
  • Project information from previous related projects

In the next section, I will go through the tools and techniques of Process 4.3 Direct and Manage Project Work.    As processes go, this is where a lot of the time of the project is spent, namely, on doing the project work to create the project deliverables, because that is what the project is all about!

 

 

 

 

 

 

 

Advertisements

6th Edition PMBOK® Guide–Project Management Knowledge Areas


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In previous posts, I discussed the project life cycle and project phases.   In the last post, I discussed how the 49 processes of project management are divided into five process groups.    In this post, I will discuss how the 49 processes are also divided among ten knowledge areas.

The ten knowledge areas are:

  1. Integration–processes that combine, unify and coordinate the various project management activities within the five process groups.
  2. Scope–processes that ensure the project includes all the work required, and only the work required, to complete the project successfully
  3. Schedule–processes that manage the timely completion of the project
  4. Cost–processes that plan, estimate, fund, manage, and control costs so the project can be completed within the approved budget
  5. Quality–processes for incorporating the organization’s quality policy regarding planning, managing and controlling project and product quality requirements in order to meet stakeholders’ expectations.
  6. Resource–processes that identify, acquire, and manage the resources needed for the successfully completion of the project.
  7. Communications–processes required to ensure the planning, creation, distribution, control and monitoring of project informations
  8. Risk–processes for planning risk management, the identification, analysis, and monitoring of risks on a project, and the implementation of risk responses.
  9. Procurement–processes necessary to purchase or acquire products, services, or results needed from outside the project team.
  10. Stakeholder–processes required to identify stakeholders, to analyze their expectations and impact on the project, and to develop management strategies for effectively engaging stakeholders in decisions that affect the project.

Okay, those are the ten knowledge areas as defined in the PMBOK® Guide.   If I were ordering the knowledge areas, I would have put the tenth knowledge area, Project Stakeholder Management, right between Communications and Risk.   Why?   Let’s put the knowledge areas into groups

Group 1–Integration

The first knowledge area Integration ties together the processes from all the other nine knowledge areas.    It has some of the most important processes on a project, from its inception (4.1 Create Project Charter) to its conclusion (4.7 Close Project or Phase).

Group 2–Constraints

The main constraints you will be dealing with on a project are Scope, Schedule, Cost, and Quality, which represent knowledge areas #2 through #5.   Schedule and Cost are pretty self-explanatory, but what is the difference between Scope and Quality Management.  Scope management has as its goal the completeness of the work; Quality management has as its goal the correctness of the work.

Group 3–People

Knowledge areas #6 (Resources), #7 (Communications), and #10 (Stakeholders) deal with the people either on the project or related to the project.   Resources used to be called Human Resources in the previous edition of the Guide; Human Resources and material resources have been combined to create a knowledge area that covers them both.    But despite the trend of de-humanizing our vocabulary over the years from “staff” to “personnel” to “human resources” to “resources”, this knowledge area still deals in large part with people.   (This will be true even in the future when PMI starts referring to  “carbon-based production units”–in the end we’re still talking about people.)    #7 Communications deals with the communications of people within a project and the communications between people on the project and the group of people effected by the project, the stakeholders.  That is why #10 Stakeholders should be considered part of this group, because you are not just trying to communicate with stakeholders, you are trying to influence them to get them more positively engaged in the project.

Group 4–Resources

These are resources used on a project, so they can include #6 Resources and #9 Procurement, which obtains products, services or results from outside the organization.

NOTE:   #9 Procurement is the only knowledge area that is potentially optional on a project, in the sense that a project may be done solely based on the resources available within the organization itself, in which case procurement from outside the organization would not be needed.

Group 5–Risk

If I were ordering the knowledge areas, Stakeholder Management would be put in between #7 Communications and #8 Risk Management, rather than having it be stuck at the end as #10.   Why?

Stakeholder Management is related to Communications Management–in fact, it is an outgrowth of the latter knowledge area, because you have to communicate with stakeholders in order to influence them.

But it is also related in a less obvious way to Risk Management.   Why?

Risk are defined as events which can positively or negatively impact a project.   Stakeholders are people who are either impacted by a project, or who can positively or negatively impact a project.   You see the connection with risk?    In both cases, you are dealing with uncertainties that may impact your project.    They are different in that, with risks, since they are events, you can’t engage them or negotiate with them.   You can’t stick your head out the window and demand that it stop raining so you can make it to your car without getting wet.   However, you can mitigate the impact of that rain by the simple expedient of–taking an umbrella with to shield you from the rain.   That is an example of a risk response.

With people, there are ways of engaging them and hopefully being able to influence them in a way to make them more favorable to your project.

But those five groups are my take on how these ten knowledge areas are put together.
Here’s how they stack up in terms of the number of processes in each:

  1. Integration (7 processes)
  2. Scope (6 processes)
  3. Schedule (6 processes)
  4. Cost (4 processes)
  5. Quality (3 processes)
  6. Resource (6 processes)
  7. Communications (3 processes)
  8. Risk (7 processes)
  9. Procurement (3 processes)
  10. Stakeholder (4 processes)

For how each process fits in each category of process group and knowledge areas, check out the chart on page 25 of the Guide.

In the next post, I will discuss the processes themselves–their component parts (inputs, tools and techniques, outputs), and how they fit together on a project.

The Last Toastmasters District Conference


Toastmasters International has decided that many of the newer struggling districts around the world have trouble putting on two conferences a year, so they have said that starting in 2018, districts will put on only one conference a year in the Spring.   So that meant that the Fall Conference I went to today for District 103 is going to be the last one I ever go to!

The reason why this conference was special was not just because it was the last one.  Some notable events happened:

  • Mike Rafferty, Past International Director and former Regional Advisor, announced that the new Toastmasters educational program called Pathways will be rolled out in our District in February of next year.   That’s only about three and a half months away!    He was recruiting Ambassadors and Guides for the new program and I volunteered to be both.
  • Don Williams, our Club Growth Director, said in terms of adding new clubs, we are on track for becoming a President’s Distinguished District.   As the Club Retention Chair, a position that is essentially that of being an assistant to the Club Growth Director responsible for getting club coaches for struggling clubs, I hope to help out District become a President’s Distinguished District by making sure that clubs that are struggling stay above water in the 2017-2018.   In this way, there are least no more additional clubs required to make up for ones that close.
  • The announcement was made that the International Conference will be held from August 22-25, 2018–right here in Chicago!   That’s another reason for working hard to become a President’s Distinguished District–because our district will then receive an award on the world stage!
  • Jeff Stein, a Toastmasters acquaintance from the Windy City Professional Speakers Club (now in District 30) introduced me to Stephanie Kowalyk, the Club Retention Chair from District 30.   District 103, representing downtown Chicago and the South Suburbs, was split off from District 30, which now represents only the North Suburbs.   She and I realized we were in parallel positions in the District leadership in our respective districts, so we had a long talk about challenges we both faced.  We realized it would be a good idea to collaborate for that very reason.

I’m so glad I went to the conference, which was a lot more intimate that last year’s Fall Conference mainly because it was half the size.   After all, District 30 and District 103 were split last year, District 30 getting five out of the previous nine divisions and District 103 getting the remaining nine.   Being smaller has its advantages, not just because those who competing in contests have a greater chance, but because organizing on a district-wide basis is also a lot easier with four divisions rather than nine to worry about.   Although many grumbled about the split, it certainly was in retrospect a good idea!   Now with only a Spring Conference to worry about in the future, life will get even simpler in the District.

However, I will miss Fall Conferences because they were a part of the Toastmasters seasons of the year.   They were the finale of the first six months of the Toastmasters year, to be followed by the Winter Toastmasters Leadership Institute in December getting ready for the final six months.   I will miss the fun and fellowship–as I remarked to a fellow conference goer, the Fall Conference felt like a trip to the Toastmasters version of Disneyland!

6th Edition PMBOK® Guide–Process 4.2 Develop Project Management Plan Outputs


The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.    In the 4.1 Develop Project Charter, the project manager is in contact with the project sponsor and the key stakeholders in order to develop the information in the project charter, the output of that process.

In the process 4.2 Develop Project Management Plan, the project manager is in contact with the project team and subject matter experts in order to develop the subsidiary management plans that end up being the main inputs to the process.   They are also the same people involved in the process of integrating them into the overall Project Management Plan.   Some of the subject matter experts the project manager can consult with may be key stakeholders.

The output of the process 4.2 Develop Project Management Plan is, not surprisingly, the Project Management Plan.   There are a total of 18 management plan components and 33 project documents.   Let’s organize these elements.

A.  Subsidiary management plans

These are the management plans that are the output of the planning processes for all of the other 9 knowledge areas:

  • Scope management plan
  • Schedule management plan
  • Cost management plan
  • Quality management plan
  • Resource management plan
  • Communications management plan
  • Risk management plan
  • Procurement management plan
  • Stakeholder engagement plan

B.  Supplemental management plans

I list the knowledge area that these supplemental management plans are most closely connected with.

  • Requirements management plan–establishes how the requirements will be analyzed, documented, and managed (Scope Management)
  • Change management plan–describes how the change requests will be formally approved and incorporated into the project work (Integration Management)
  • Configuration management plan–describes the version of the product, service or result that the project will create so that it will be produced consistently

C.  Baselines

  • Scope baseline–consists of the scope statement, work breakdown structure (WBS), and its associated WBS dictionary
  • Schedule baseline–approve version of the schedule model that is used as a basis for comparison to the actual results.
  • Cost baseline–approved version of the time-phased project budget that is used as a basis for comparison to the actual results.
  • Performance management baseline–an optional baseline that is an integrated scope-schedule-cost plan for the project work against which project execution is compared to in order to measure and manage performance (essentially a combination of the three baselines listed above)

D.  Additional components

  • Product life cycle description–describes the series of phases that a project passes through from its initiation to its closure
  • Development approach–describes the development approach, such as predictive, iterative/incremental, agile, or hybrid

E.   Project documents

They are usually the outputs of the planning process for each of the knowledge areas, and so they are listed below with the knowledge area they are related to.

  • Integration–assumption log, change log, issue log, lessons learned register, milestone list
  • Scope–project scope statement, requirements documentation, requirements traceability matrix
  • Schedule–activity attributes, activity list, basis of estimates, duration estimates, project calendars, project schedule, project schedule network diagram, schedule data, schedule forecasts
  • Cost–cost estimates, cost forecasts
  • Quality–quality control measurements, quality metrics, quality report, test and evaluation documents
  • Resources–physical resource assignments, project team assignments, resource breakdown structure, resource calendars, resource requirements, team charter
  • Communications–project communications
  • Risk–risk register, risk report
  • Procurements
  • Stakeholder–stakeholder register

As you can see, the only knowledge area that doesn’t have a project document associated with it is the procurements knowledge area, and that is because this is the only knowledge area that is optional:   if the project is done using only internal resources, then procurement of services and/or materials is not needed.

Most of these project management plan components, whether they are planning documents or are the repository of information such as the project documents listed above, will end up being inputs to the next process, which is 4.3 Direct and Manage Project Work.   This process will be the subject of the next post.

 

 

 

 

6th Edition PMBOK® Guide–Process 4.2 Develop Project Management Plan Tools & Techniques


The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.    In the 4.1 Develop Project Charter, the project manager is in contact with the project sponsor and the key stakeholders in order to develop the information in the project charter, the output of that process.

In the process 4.2 Develop Project Management Plan, the project manager is in contact with the project team and subject matter experts in order to develop the subsidiary management plans that end up being the main inputs to the process.   They are also the same people involved in the process of integrating them into the overall Project Management Plan.   Some of the subject matter experts the project manager can consult with may be key stakeholders.

Here are the inputs to process 4.2 Develop Project Management Plan:

  1. Project Charter
  2. Outputs from other processes
  3. Enterprise Environmental factors
  4. Operational Process Assets

How do you approach the project team members and subject matter experts in order to  to create the subsidiary plans and then the overall project management plan?   That is where the tools & techniques come into play.   Here they are:

Expert judgment

Talk to stakeholders and/or subject matter experts who know about

  • tailoring the project management process to meet the project needs
  • developing additional components of the project management plan if needed
  • determining which project documents will be used to apply to the project

Data gathering

  • Brainstorming–two-part process consisting of a) idea generation and b) analysis, used to gather ideas and solutions about the project approach.
  • Focus groups–discussion of project management approach and the integration of the different components of the project management plan.
  • Interviews–used to obtain specific information from stakeholders to develop the project management plan.
  • Checklists–the project manager can use these to verify that all the required information is included in the project management plan.

Interpersonal and team skills

  • Conflict management–bringing stakeholders into alignment with the project management plan.
  • Facilitation–Effective participation by all members of the project team ensures that the project management plan has full buy-in according to the decision making process established for the project.
  • Meeting management–ensures that meetings are efficient and well-run in addition to being effective in developing the project management plan.

Meetings

Held with project team to discuss the project approach, how the work will be executed, and the way the project will be monitored and controlled.

The kick-off meeting is associated for larger projects with the end of planning and the start of executing; however, for smaller projects, the kick-off may occur after initiation at the start of planning.

The output of the process is (as the title Develop Project Management Plan suggests) the project management plan, and it contains many components.   I will go over these in the next post on the outputs of process 4.2 Develop Project Management Plan.

6th Edition PMBOK® Guide–Process 4.2 Develop Project Management Plan Inputs


The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.

Here are the inputs to process 4.2 Develop Project Management Plan:

  1. Project Charter
  2. Outputs from other processes
  3. Enterprise Environmental factors
  4. Operational Process Assets

The first input, Project Charter, is the output of process 4.1 Develop Project Charter.   The second input, the vaguely named “Outputs from other processes”, are essentially all of the outputs of the management plan processes from the other nine knowledge areas, what PMI calls subsidiary management plans.    These will be listed in detail in the post on the outputs of this process.   So this process is not one of the first planning processes to be done, but rather one of the last because it ties together the results of all of the other planning processes.

The other two inputs are what I call the generic inputs, because they are inputs to a great many processes.

The next post will cover what tools and techniques are used to put together the project management plan.   They are close to the tools and techniques used in putting together the project charter, but instead of mainly involving the stakeholders, for this process they will mainly involve the project team.

6th Edition PMBOK® Guide–Process 4.1 Develop Project Charter Outputs


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.   This post starts a series of posts on the first project management process, process 4.1 Develop Project Charter.    Let’s assume that, as a project manager, you have been tasked by the sponsor to create the project charter.  What should you put in it?

Of course, the main purpose of the project charter is for the project sponsor to give the project manager authority to use the organization’s resources to do the project.   But the secondary purpose is for the project manager to go into the project with as much high-level information about the project as possible when he or she goes into the planning phase.   So what I’ve done is I’ve gone through the list of items that PMI recommends putting in the project charter, and I’ve divided them into the 10 knowledge areas covered by the PMBOK® Guide.

  1. Integration–project purpose, project approval requirements, name and authority of the project sponsor, assigned project manager,
  2. Scope–measurable project objectives
  3. Schedule–summary milestone schedule
  4. Cost–pre-approved financial resources
  5. Quality–high-level requirements, project success/exit criteria
  6. Resources–project manager responsibility and authority level
  7. Communications (see Stakeholders)
  8. Risk–overall project risk
  9. Procurement (optional only if project is external)
  10. Stakeholders–key stakeholder list

As you can see, most of the knowledge areas will have some element of high-level information included in the project charter.   As mentioned in a previous post, much of the information to be included in the project charter can be found in one particular input, that of the business case document.

And since much of the information required in the project charter will come from key stakeholders, this is why the one other process that is included in the Initiating Process Group is 13.1 Identify Stakeholders.

Note that the other output for the Develop Project Charter process is the assumptions log, which lists high-level strategic and operational assumptions and constraints.   The reason why these are put in a separate log is that these assumptions need to be revisited periodically during the project (in the Monitoring and Controlling Process Group) to make sure they are still true.    If the conditions listed in the assumption log change for whatever reason, they might directly impact the project and need to be paid immediately attention to.

Two items which PMI did not explicitly put in the PMBOK® Guide on p. 81 but which are important nonetheless are

Pre-assigned human resources–these are people whom the project sponsor wants to have working on the project.   These will then be highlighted in the Resource Management Plan so that these people can be included on the project if at all possible

Exclusions–besides giving a general description of the project objectives, a good tool for preventing unnecessary changes is to have exclusions, that is, listing those objectives which the project sponsor explicitly is wanting to have excluded from the product, service or result which the project will create.    If a key stakeholder suggests one of these excluded objectives, then the project manager will have additional authority to say no by virtue of the fact that the project sponsor has said “no” right in the project charter.

This concludes my discussion of the project charter.   The process of creating it is the first integration management process.   Once you as the project manager have the project charter in hand, it’s off to the races, right?   No, you have to do Process 4.2 Develop Project Management Plan, and that is the subject of the next series of posts.