4squareviews

In the last post, on Tools & Techniques for process 4.3 Direct and Manage Project Work, I mentioned that this process is where a lot of the budget of the project is spent.   The outputs of the process are not just the results of the process; they are about communicating those results to those stakeholders who matter the most, those who fund the project (i.e., the customer for external projects or upper management for internal ones).    Another important aspect of the results is the comparison between those results and the project plan.    Of course, this comparison is done explicitly during the Monitoring & Controlling processes, but it can be done in real time during the Executing processes as well such as this one.   These results on a project are referred to as deliverables.

If you compare a project being run to a ship traveling across the ocean, then the progress of a ship across the ocean is charted by several key variables such as the distance traveled (analogous to earned value), and the amount of fuel spent (analogous to the actual costs incurred).   These variables on a project are recorded as another important output, work performance data.

Now let’s say a naval officer is doing a quick inspection tour of the ship and comes across some safety hazards or other problems on board that could potentially cause injuries at some point in the future.    The officer can list these problems and take them to the executive officer or XO.   The equivalent of this list of problems on a project is the issue log, another important output.

If you notice the actual results are veering away from the plan, you don’t have to wait for a review meeting to start to take action.   If a sailor is watching out at the horizon and sees an iceberg heading straight for the ship, the sailor will alert the watch officer immediately and corrective action will be taken.    In a similar way, people on the project team who see a problem as it is occurring should alert the project manager, who can then order action to be taken (see paragraph below on change requests).

Now if there arises some sort of severe storm in the direction the ship is headed, the officers may decide to change the planned route of the ship in order to avoid the storm.   In a similar way, rather than changing the work to fit the plan (as with most change requests), the project manager may decide to change the plan to fit the work, especially if it is revealed during the execution of the work that the original project plan as conceived wasn’t, in fact, very realistic.   In this case the project management plan must be updated.

But in any case, even if there are no change requests made and the ship goes smoothly towards its destination, if there are any changes in conditions such as weather, these will be noted in the ship’s log, the equivalent of which on a project would be the project documents which must be updated, even they reflect a situation where everything is going perfectly according to plan.

Let’s talk more in detail about the outputs of process 4.3 Direct and Manage Project Work.

4,3,3 Direct and Manage Project Work:  Outputs

4.3.3.1 Deliverables

A deliverable is a unique and verifiable product, service or result that is completed as a stepping stone to complete the final product, service or result of the project that will be delivered to the customer.   They are the result of completion of work packages, the units of work that the project work is broken up into during the planning phase.

4.3.3.2  Work Performance Data

These are the measurements identified during activities performed to carry out the project work.   For example, today John worked 4 hours on the project and Jane worked 4 hours as well.   This is the lowest level of detail about project work and it is gathered during the Executing phase of the project.   This passes to the Controlling processes of the project where the actual work done is analyzed by comparing it to the work that was supposed to be done in the project plan.

4.3.3.3  Issue Log

Problems and conflicts that occur during the executing phase of the project are recorded and tracked in an issue log, where a project manager helps manage the issues so that they are investigated and resolved so that they do not impact the project performance.

4.3.3.4  Change requests

Change requests are formal proposals to modify any document, deliverable, or baseline.  Normally, these are thought of as being done as the result of the Monitoring & Controlling process called 4.5 Monitor and Control Project Work.   However, if a problem is uncovered during the Executing phase (as in this process 4.3 Direct and Manage Project Work), a change request may be made immediately to be considered in the way specified by the Change Management Plan, for example, by a Change Control Board.

There are several types of change requests.   The first three types are when the work is seen to differ from what it is the project plan.   These can be explained by analogy to Charles Dicken’s book A Christmas Carol.   In that book, Ebeneezer Scrooge is visited by three ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.   In a similar way, a project manager can be haunted by the specter of a defect or other negative impact in three ways:

He or she can be haunted by the Ghost of Defects Past, where a product component that has already been completed in the process 4.3 Direct and Manage Project Work is shown to be defective somehow.   The remedy?   Defect repair.

Now, what if the project manager is haunted by the Ghost of Defects Present, where the performance of the project work being done right now in the process 4.3 Direct and Manage Project Work is not in alignment with the project management plan?  The remedy:   Corrective action, an intentional activity that realigns the performance of the project work with the project management plan.

And finally, what if the project manager is haunted by the Ghost of Defects Future, where the performance of the project work is in danger of becoming unaligned with the project management plan at some point in the near future?   The remedy:  Preventive action, an intentional activity taken now that ensures that the future performance of the project work is aligned with the project management plan.

For the final category, rather than changing the work to fit the plan, what if in doing the project work in this process, it is discovered that the project management plan wasn’t very realistic after all?   Then, it is possible to do updates to the project management plan so that it is more realistic.   These change requests are covered in the next output.

4.3.3.5 Project Management Plan Updates

Any component of the Project Management Plan may be updated as a result of a change request.

4.3.3.6 Project Documents Updates

Now, besides changes to the work or to the project management plan, there may be other changes to project documents that are necessitated by things that happen during the executing of project work.   For example:

• Activity list–additional activities may be added or activities may be modified.
• Assumption log–if the original assumptions or constraints (specified in the project charter) have changed, the assumption log may be modified.
• Lessons learned register–although this is normally updated during the next process 4.4 Manage Project Knowledge during the Monitoring & Controlling phase, if a lesson is learned during the course of the project work, it may be added to the lessons learned register right away, without even waiting for the following process.  As a reminder, a change request is a change to the product or to the project plan; lessons learned are changes to the process of doing the project itself.
• Requirements documentation–during the course of work on the project, new requirements may be identified and added to this documentation.   In addition, the progress made in meeting the current requirements may be updated.
• Risk register–new risks identified during the course of work on the project are added to the risk register.   Also, if a work package that entailed some risk is completed without incident, the risk associated with that work package is no longer in play and the risk register can be updated to reflect that.
• Stakeholder register–if there are new stakeholders, or if the status of a stakeholder changes that might affect the analysis of that stakeholder, then these additions or changes are made.

4.3.3.7  Organizational Process Assets Updates

Organizational process assets or OPAs are the plans, processes, policies, procedures, and knowledge bases used by the organization performing the project.   If during the course of the project work, there are lessons learned (see the paragraph “Lessons learned register” in the last paragraph 4.3.3.6 Project Documents Updates) that may be useful outside of the current project, i.e., that suggest changes to the policies and procedures of the organization in general, then these OPAs may be updated as a result.   In this way, knowledge is transferred from the project team to the organization.

This transference of knowledge gained on the project to the organization in general is the subject of the next process 4.4 Manage Project Knowledge.   This is a new project management process for the 6th Edition of the PMBOK® Guide, and it is has its origins in Agile project management methodology.   For that story, please see the next post…

Filed under: Uncategorized | Leave a comment »

The project management process 4.3 Direct and Manage Project Work is where most of the action is during a project.    If you look at a graph of where the money on a project is spent, a lot of it will be spent here getting the work done that was planned for in the previous process 4.2 Develop Project Management Plan.

There are only three tools & techniques listed under this process, Expert Judgment, Project Management Information System (PMIS) (for example, Microsoft Project or Primavera), and Meetings.    Let’s discuss each of these in turn.

4.3.2 Direct and Manage Project Work:  Tools & Techniques

4.3.2.1 Expert Judgment

As a project manager, you should have as human resources not just the members of your project team, but also experts who may be outside of your project team who can assist the project work because of their specialized knowledge or training.   Sometimes these are referred as SMEs or subject matter experts because their expertise extends to a specific subject matter which affects your project.    Here are some examples from the PMBOK® Guide:

–Technical knowledge related to your industry and specifically to your project

–Cost and budget management

–Legal and/or regulatory matters

–Organizational governance

If you look at the Integral Model of business and leadership from the website

The Integral Model

you can see that any project done in an organization can be seen through one of the dimensions listed above, the interior vs. the exterior and the individual vs. the collective.   The expertise needed to run a project will often be related to the exterior/collective dimensions or SYSTEMS which are the contexts in which a project is done, either the technical context (physical systems) or a social context (financial or legal systems), but sometimes related to the interior/collective dimensions or CULTURAL context of the organization itself (organizational governance).

4.3.2.2  Project Management Information System (PMIS)

Before I talk about the PMIS, a quick quiz:

Is the PMIS such as Microsoft Project or Primavera an example of an OPA (Organizational Process Asset) or an EEF (Enterprise Environmental Factor)?

Answer:  It is an EEF.

Now, the reason why I’m throwing this quiz question in here is that, as a Director of Certification helping train people at our local Project Management Institute chapter in the Chicagoland area to pass the Project Management Professional (PMP) exam, this was one of the questions most often missed by those studying for it.   Think about it for a moment:   does a computer program like Microsoft Project sound like an asset or an environmental factor?   It sounds like an asset; however, there is a distinction to be made.   The data you put into the program is an example of an organizational process asset, because it is proprietary to your organization and should be protected as such.   However, the program itself is usually NOT created by your organization, but is a tool used by your organization to process OPAs such as project schedules, etc.

Okay, that being said, the aspects of a PMIS that you will be using as a project manager while you direct and manage project work are:

–Scheduling software

Microsoft Project is an example.

–Work authorization systems

Work authorization systems ensure that all prerequisites are completed before authorization for a specific work package is given, such as that all preceding work packages are completed, and that all the resources required for that work package are available, etc.

–Configuration management systems

If a project plan is changed, then everybody needs to be working off of the new and improved plan, and not on the old one that has been superseded.   The configuration management system applies a number system (e.g. “version 2.3” where the 2 designates a major configuration change and the number 3 after the decimal point represents a minor configuration change).

–Information collection and distribution systems

The project management team will receive a lot of the work performance data generated by those doing the project work.    It will be turned into work performance information that collects this data on the project work from the PMIS and compares it with what is in the project plan (see paragraph on Key performance indicators or KPI below).  This work performance information is shared with members of the project team.   Work performance information that is considered significant enough to be shared with stakeholders is gathered into a work performance report.

–Key performance indicators (KPI)

Automated systems can take the raw work performance data generated by those doing the project work and turn it into work performance information that is used by the project management team to see how the project work is doing as compared to the project plan.   Often this is done by a key performance indicator (KPI) such as the cost or schedule performance index (CPI or SPI, respectively).

4.3.2.3  Meetings

Meetings are used by the project manager and the project management team to discuss and address issues pertaining to the project with a) members of the project team and b) appropriate stakeholders.   There are different types of meetings, such as

–Kick-off (either done at the beginning of the Planning group of processes or at the end of planning right before the Executing process group starts)

–Technical

–Agile process meetings (sprint or iteration planning, Scrum daily standups, sprint or iteration retrospective meetings)

–Steering group (accountable for the project’s expenditure and the overall work of the project)

–Problem solving or brainstorming

–Progress update

PMI recommends the following to make a meeting successful (taken from section 10.2.2.6 Interpersonal and Team Skills):

1. Prepare and distribute the agenda stating the objectives of the meeting.
2. Ensure that the meetings start and finish at the published time (NOTE:  you will gain much positive karma from people who go to your meetings if you can end a meeting EARLY, thus allowing them time to prepare for their next task or meeting).
3. Ensure that the appropriate participants are invited and attend.   (NOTE:  If a key participant cannot attend, it is better to postpone the meeting.)
4. Stay on topic.   (NOTE:  This is the responsibility of the facilitator of the meeting, who should not be the same person taking notes of the meeting so that he or she can concentrate on precisely this task.)
5. Manage expectations, issues, and conflicts during the meeting.  (NOTE:  again, this is the facilitator’s role.)   Don’t hesitate to have recorded in an issue log (or “parking lot” or whatever you call it)” any issues or conflicts that arise that cannot be resolved during the course of the meeting itself.   This will ensure that rule 2 is maintained…
6. Record all actions and those who have been allocated the responsibility for completing the action.   (NOTE:  following up on an “action item list” generated at a meeting is as important or even more important than the meeting itself.)

The next post will deal with the outputs of the process 4.3 Direct and Manage Project Work.

Filed under: Uncategorized | Leave a comment »

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!

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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!

Filed under: Uncategorized | 2 Comments »

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.

Filed under: Uncategorized | 1 Comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | 1 Comment »

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.  How would you go about doing it?

In the last posts, I discussed the inputs you need to develop the project charter, namely:

• Business documents
• Agreements
• Enterprise environmental factors
• Organizational process assets

The key document here is the business case document, one of the two business document inputs listed above.   It may contain the following key pieces of information that will help you put together the project charter.

• Project purpose (business need)
• Measurable project objectives and related success criteria
• Identification of scope
• Identification of known risks
• Recommended milestones
• Identification of key stakeholders

With the information on this business case document, you already are getting some of the information you need for the project charter, PLUS you are getting a list of key stakeholders whom will contact to get the rest of the information you need.

How do you approach the stakeholders to get that information?   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

• organizational strategy so the project is aligned with it
• technical knowledge of the industry
• benefits management (departments that will receive the results of the project)
• duration and budget estimation
• risk identification

Data gathering

• Brainstorming–two-part process consisting of a) idea generation and b) analysis.
• Focus groups–bring in groups of stakeholders and subject matter experts to learn about project risk and success criteria
• Interviews–rather than talking to groups of stakeholders, talking to them individually to find out about assumptions and/or constraints, high-level requirements, and approval criteria.

Interpersonal and team skills

• Conflict management–bringing stakeholders into alignment regarding objectives, success criteria, high-level requirements, project description, summary milestones.
• Facilitation–Effectively guiding a group event (such as a focus group) to a successful decision or conclusion.
• Meeting management–ensuring key stakeholders are invited to meetings, preparing an agenda, and then sending follow-up meeting minutes and action items.

Meetings

Held with key stakeholders to identify the project objectives, success criteria, key deliverables, high-level requirements, summary milestones.

These are used in conjunction with each other, so at the early stage, you would use data gathering tools & techniques and expert judgment, then follow up with meetings using interpersonal and team skills.

The result will be the project charter, the elements of which will be discussed in the next post on outputs.

Filed under: Uncategorized | 1 Comment »