4squareviews

The tools and techniques used for monitoring and controlling the project work are pretty general:   expert judgment, decision making, and meetings.   These are just generically described below.  But there is one set of tools that is very specific and those are data analysis techniques.   These will be described in more detail.

4.5.2 Monitor and Control Project Work:  Tools & Techniques

4.5.2.1 Expert Judgment

This is judgment provided by individuals who have expertise in the data analysis techniques that are described in the next paragraph.

4.5.2.2 Data Analysis Techniques

These techniques that can be used include the following:

1.Detection

First of all, there are the techniques that are used to detect whether there is a variation or not.

Earned value analysis–provides an integrated perspective on scope, schedule, and cost performance.

Variance analysis–reviews the differences between planned and actual performance.

Trend analysis–used to forecast future performance based on past results.

2. Diagnosis

Once a variation is detected, then you diagnosis the source of the variation.

Root cause analysis–identifies the main reasons for a problem that is causing a variation.

3.Corrective and/or Preventive Actions

Once the root cause of a problem that is causing a variation is identified, the various possibilities for a solution are investigated and the best solution is chosen to correct the problem.

Alternatives analysis–used to select the combination of corrective actions and/or preventive actions to implement

Cost-benefit analysis–helps determine the best corrective action in terms of cost in case of project deviations.

These techniques are designed to generate a change request which, when implemented, will solve the problems identified.

4.5.2.3  Decision Making

If there are several alternatives suggested to solving a particular problem, then the data analysis techniques listed above of alternatives analysis and cost-benefit analysis are used to help the project team decide on the best solution.   Decision-making techniques can include voting and the outcome can be based on unanimity, majority, or plurality (the greatest number of votes gathered even if not a majority).

4.5.2.4  Meetings

Meetings are tools where project team members gather to use the data analysis techniques and expert judgment to make a decision regarding the best course of action to take in order to solve problems discovered during the monitoring of the project.

The outputs of this process are discussed in the next post…

Filed under: Uncategorized | Leave a comment »

With this process, we are moving in to the Monitoring & Controlling Process group.   The work that is being done in the process 4.3 Direct and Manage Project Work is tracked and reviewed to see if it is meeting with the performance objectives defined in the project management plan.   The results of this analysis are then reported to various stakeholders.   If the analysis shows that there is a variance from the project plan,  then corrective action in the form of change requests may be recommended.

Let’s take a look at the inputs to this process.

4.5.1..1 Project Management Plan

We need to have the project management plan and all its components to compare it to the actual results that have been accomplished.

4.5.1.2  Project Documents

Besides the project management plan, several project documents may be inputs to this process.   Rather than simply list the bullet points listed in the PMBOK® Guide, let me divide the documents by knowledge area:

Integration Management

Assumption log–contains information about assumptions and constraints affecting the project.

Issue log–used to document and monitor who is responsible for specific issues by a target date.

Lessons learned register–may have information on effective responses for variances, and corrective and preventive actions.

Scope Management

Schedule Management

Basis of estimates–indicates how estimates were derived and can be used to make a decision on how to respond to variances.

Milestone list–shows the scheduled dates for specific milestones and is used to check if the planned milestones have been met.

Schedule forecasts–used to determine if the project is within defined tolerance ranges for schedule and to identify necessary change requests.

Cost Management

Cost forecasts–used to determine if the project is within defined tolerance ranges for budget and to identify any necessary change requests.

Quality Management

Quality reports–includes

• quality management issues
• recommendations for process, project, and product improements
• corrective actions recommendations (rework, defect/bugs repair, 100% inspection, and more)
• summary of findings of the Control Quality process

Risk Management

Risk register–provides information on threats and opportunities that have occurred during project execution.

Risk report–provides information on the overall project risks as well as information that have occurred during project execution

Procurements Management

Agreements (see paragraph 4.5.1.4 below)

4.5.1.3  Work Performance Information

Work performance data is gathered from the process 4.3 Direct and Manage Project Work and is passed to the controlling processes for the various knowledge areas (Control Scope, Control Schedule, Control Costs, etc.).   In these control processes, the work performance data is compared with the corresponding component of the Project Management Plan (input 4.5.1.1) and Project Documents (input 4.5.1.2).   The results of this comparison are turned into work performance information which is useful to the project team when doing the process 4.5 Monitor and Control Project Work.   This information may include metrics that measure performance with regards to cost and schedule and can tell a project manager whether the project is on schedule, on budget, or whether there is a variance.

4.5.1.4  Agreements

If there is a procurement agreement with a contractor, then the project manager may need to monitor the contractor’s work to compare it with the agreements (i.e. contracts) made with that contractor.

4.5.1.5  Enterprise Environmental Factors

The EEFs that can influence the process 4.5 Monitor and Control Project Work are:

• Project management information system (PMIS) such as Microsoft Project
• Infrastructure (facilities, equipment, telecommunications channels)
• Stakeholders’ expectations and risk thresholds
• Government or industry standards

4.5.1.6  Organization Process Assets

The OPAs that can influence the process 4.5 Monitor and Control Project Work are:

• Organizational standard policies, processes, and procedures
• Financial controls procedures (required expenditure and disbursement reviews, accounting codes, standard contract provisions)
• Monitoring and reporting methods
• Issue management procedures (issue controls, issue identification, resolution and item tracking)
• Defect management procedures (defect controls, defect identification, resolution and action item tracking)
• Organizational knowledge base (process measurement, lessons learned repository)

The next post will cover the actual tools and techniques used in this process.

Filed under: Uncategorized | Leave a comment »

Today I am concluding my series of posts are this process by talking about the outputs of the process.    When looking at the outputs, don’t just look at what the output is, but look at where it is going–outputs of one process become the inputs to another process, and it is helpful to know what process that output is going to feed into.

4.4.3  Manage Project Knowledge:  Outputs

4.4.3.1 Lessons Learned Register

Well, this is the whole focal point of the process, to create this project document.   In the past (i.e., in the 5th Edition of the PMBOK® Guide, this document was created at the end of a project, and the insights gained were meant to help project managers who are in charge of similar projects in the future.   But in agile project management methodologies such as Scrum, the discussion of lessons learned is not done at the end of the project, but at the end of each sprint or iteration (it is part of what is called a Sprint Retrospective).   The benefits of this lessons learned discussion now benefited not just some future project, but the current project itself.    PMI thought that this benefit should be realized in the more traditional or waterfall project management methodologies as well, so the process 4.4 Manage Project Knowledge was added in the 6th Edition of the PMBOK® Guide.

Okay, what kind of things are in a lessons learned register?

• Challenges or problems faced by the project team
• Realized risks and opportunities, that is, risks that actually occurred and became issues, and what the risk response was that dealt with them

Who creates the lessons learned register?   The members of the project team, because it is their experience on the project that creates the raw material for the lessons learned.

This document is created early in the project and is updated periodically.   The lessons can be captured in the written document called the lessons learned register, but there are additional ways of capturing knowledge gained, such as audios (podcasts), videos (e.g. YouTube), etc.

At the end of the project, the lessons learned on a project are transferred to the organizational process asset called the lessons learned register (see paragraph 4.4.3.3 below)

4.4.3.2  Project Management Plan Updates

The lessons learned on a project usually have to do not with the product of the project, but the process of doing the project.   However, one of the lessons that can be learned on a project is that the original project management plan is unrealistic given new information or new conditions that occur on a project.   In that case, one of the project management plan components may need to be updated (after the change request is approved through the process 4.6 Perform Integrated Change Request).

4.4.3.3 Organizational Process Assets Updates

The new knowledge created on a project and codified in the lessons learned register can be transferred to the organization as a whole through the organizational process asset known as the lessons learned repository.    It is possible that an idea for a new procedure is created as a result of one of these lessons learned, and the project then serve as a “pilot” for that procedure.

This is important, because it is important to have projects serve as incubators for change within the organization.  At the discussion had at the Project Management Institute’s Executive Council, where I was the director in 2016-2017, centered around this theme, and one of the members of the council said that sometimes there would be a great breakthrough created on a project due to the creative collaboration that existed on the project team.   The members of the team would leave the project in an evangelical mood trying to convince others to use this breakthrough on their project.   However, if the organization at large did not have a way to incubate these new ideas, then as he put it “the corporate antibodies” would attack the new idea and make sure it never got implemented outside of that project.    The antibodies he referred to were people who liked the status quo and who were therefore resistant to change.   But if management can create an atmosphere conducive to change, and create structures in place to encourage change (such as the creation of a lessons learned repository), then the organization will permanently benefit by the results created on temporary projects.

Now, the next process takes us from the Executing process group to the Monitoring and Controlling process group with the process 4.5 Monitor and Control Project Work.

Filed under: Uncategorized | 2 Comments »

I was going to do a post on the outputs of the Process 4.4 Manage Project Knowledge which I have blogging about over the past few days. However, my laptop computer has decided to start a seemingly interminable series of software updates, so I thought I would take advantage of my smartphone and write a relatively shorter post.

I discussed in a previous post about the distinction between explicit knowledge, the kind you can get from reading a book or watching a video, and tacit knowledge, the kind you can get only from experience. How do you share this kind of knowledge? Through conversations and interactions with people. As a Toastmaster, I can tell you the best way I have found to convey this kind of information is through a story or anecdote.

The first level of certification for project management is called Certified Associate in Project Management. This requires explicit knowledge about project management processes as laid out in the PMBOK Guide. However, you can pass the exam without having any actual experience on a project, just explicit or “book” knowledge.

However, the higher level of certification, the Project Management Professional or PMP, does require tacit knowledge or actual experience as a project manager. This requirement is in he form of a certain number of hours of experience required.

But the written exam also tries to test for tacit knowledge, which is harder than testing for explicit knowledge. How do you write a question that tests whether you have internalized the lessons of being a good manager through hard-won experience?

This is where the scenario question comes into play. This is a question that describes a situation through explicit details about a hypothetical project you are on as a project manager. Then it will ask you what to do next, or what is the best course of action? Of course this is not a free-form answer like an essay question–it is a multiple-choice question so you are given four possibilities to choose from.

What you are expected to know is tacit knowledge about project knowledge in the form of assumptions informally called “PMI-isms”. For example, in the area of change management:

• Avoid unnecessary changes to the project scope
• When you receive a change request from upper management, your next task is analyze the impacts of that change on the project’s constraints (usually time and cost).

These are assumptions, and if you know them then you can answer such a scenario question even if you have not had the particular experience described in that scenario.

However, assumptions such as the first one may not be true in certain situations–avoiding unnecessary changes is a mindset that is definitely NOT present in agile project management. An additional assumption in agile project management is that you need to prioritize the various constraints in terms of there importance to the customer at the beginning of the project to help guide the decision process after the analysis listed on the second bullet point above is complete.

That is why I liked studying with the Rita Mulcahy PMP Exam Prep study guide when I was helping our study group prepare for the exam back in 2012. It had an entire section devoted to these PMI-isms because understanding them will help you pass the exam. Whatever textbook you use, make sure it spends some time on these assumptions, because they contain the tacit knowledge PMI wants you to have as a project manager!

Well, assuming my computer updates itself in the next 24 hours, I will return to my regularly scheduled post, outputs of the process 4.4 Manage Project Management, tomorrow.

Filed under: Uncategorized | Leave a comment »

The Process I am describing today has its origins in the “lessons learned” exercise traditionally done in project management at the end of a project.   However, due to the influence of agile project management methodologies, the project management community gradually created the new “best practice” of creating a lessons learned register during the course of a project.   That is what this process is about, although it is not limited to the production of a lessons learned register.   Let’s see what tools and techniques can be used to take the knowledge, both

• explicit knowledge in the form of things learned on a project that can be written down in places like the lessons learned register
• tacit knowledge in the form of experience and insights gained

This latter form of knowledge is internal to the person holding it and it can only be shared through conversations and interactions with people.    The way these two types of knowledge are managed are different, as can be seen in the paragraphs below.

4.4.2 Manage Project Knowledge:  Tools & Techniques

4.4.2.1 Expert Judgment

You should consider gaining knowledge from individuals or groups with specialized training or expertise, such as those with training in knowledge management, information management, organization  learning, or other topics.

4.4.2.2 Knowledge Management

You need to connect people so that they can share tacit knowledge and then integrate the knowledge of diverse team members.   Here are some examples of ways to share tacit knowledge gained on a project.

• Networking–in particular social networking on an intranet system like Sharepoint
• Communities of practice–like monthly meetings of the local chapter of the Project Management Institute
• Discussion forms such as focus groups–like “lunch and learn” forums held by many companies

There are many other examples given on p. 103 of the PMBOK Guide.

4.4.2.3  Information Management

Information management tools (such as a Project Management Information System or PMIS like Microsoft Project) can be used to create documents that can share more explicit forms of knowledge gained on a project.

These documents can codify explicit knowledge so that a person trying to solve a particular problem can type in a search word or phrase to find relevant entries in the documents.

4.4.2.4  Interpersonal and team skills

The sharing of knowledge first requires setting up a relationship of trust between the people sharing that knowledge.   That is why interpersonal and team-building skills are useful because they can help create and nurture those relationships based on trust.   Some of these skills are:

• Active listening–acknowledging, clarifying and confirming, understanding, and removing barriers that adversely affect comprehension
• Facilitation–effectively guiding a group event to a successful decision, solution, or conclusion.    A facilitator ensures
  • effective participation
  • mutual understanding between participants
  • consideration of all contributions
  • the achievement of full buy-in or consensus regarding any conclusions or results achieved by the group, and
  • the taking of appropriate actions to follow-up on those conclusions or results
• Leadership–because a project is done by people, a leader demonstrates skills that guide, motivate and direct the people on a project team.  Such skills include:
  • Negotiation
  • Resilience
  • Communication
  • Problem solving
  • Critical thinking
  • Interpersonal skills
• Networking–interacting with others to exchange information and develop contacts in order to solve problems, influence actions of stakeholders, and to increase stakeholder support for the project
• Political awareness–engaging stakeholders appropriate in order to maintain their support throughout the project

So you can see that, where the origin of this process is the lessons learned register (and indeed that is one of the main outputs of the process), it is much larger and includes the larger set of relationships the people on a team have to their organization , their industry, their profession, and to society itself.

The next post will cover the outputs of this process.

Filed under: Uncategorized | 1 Comment »

Before I list the tools and techniques involved in this process in the next post, let me first make some distinctions that PMI makes in its discussion of Manage Project Knowledge.

• Work performance data, work performance information, and work performance reports–work data is generated during the process 4.3 Direct and Manage Project Work.   For example, John worked 20 hours last week on the project and so did Mary.   Work information would take that data, and then make it meaningful to the project team by comparing it to the plan.  If they both were supposed to work that many hours, then fine, the Schedule Performance Index for that work period will be 1.00.   However, if John was supposed to work 40 hours, then only 40 (20 for John plus 20 for Mary) out of 60 scheduled hours were actually done, and the Schedule Performance Index is now, 40/60 or 0.67.   This is work performance information, because it is useful to the team:   it tells them they’re behind schedule!  If they go back to John and find out this is just a temporary problem, and that he will able to make up the time either on the weekend or the following week, then fine.   However, if John says that going forward he is going to only be able to work 20 hours on the project because of other work his functional manager has him doing, then that may be a problem.   The problem uncovered by the work performance information and its solution might be contained in a work performance report, that goes to selected stakeholders.
• Information vs. knowledge–this is not explicitly as stated in the PMBOK® Guide as I would like.   However, it seems that work performance information is related to a specific project, but knowledge has a more general context, and is therefore transferable from project to project.   That is why knowledge from previous projects is incorporated in Organizational Process Assets such as company guidelines, processes, and procedures, so it can be used on future projects.   However, this body of knowledge is not static; there are lessons learned on a project which could help future projects and that is why the lessons learned register is created by this process, to help transfer new knowledge back to the organization at large.
• Explicit knowledge vs. implicit knowledge–Explicit knowledge is something that can be written down and codified, whereas implicit knowledge is the skills, experience and expertise that people gain during a project.    Explicit knowledge can be shared using information management systems (see next paragraph), but implicit knowledge is not external but internal, and is only transferable by sharing that experience through conversations and interactions with people.
• Information management vs. knowledge management–systems for information management include a Project Management Information System such as Microsoft Project, and of course the lessons learned register itself that is compiled during the course of a project.   However, knowledge management techniques are many, because you can share with someone in your company, in discussion forums or meetings, or with someone in your industry, at meetings of communities of practice like the dinner meetings that are held chapters of the Project Management Institute.

The fact that knowledge is shared by conversations and interactions with people means that people who are introverted, like myself, who find these activities more difficult than people who are extroverted, will find themselves potentially at a disadvantage.   This is why I recommend Toastmasters International for anybody who is a project manager; many Project Management Institute chapters have their own Toastmasters club (like the Chicagoland club I belong to), and here you can practice on interactions with people in a supportive atmosphere which will allow you to develop the confidence you need to be able interact with others and transfer knowledge back and forth about project management.

With these distinctions in mind, then, let’s turn to the tools and techniques of this process Manage Project Knowledge in the next post…

Filed under: Uncategorized | Leave a comment »

In the 6th Edition of the PMBOK® Guide, there are 49 project management processes, divided into five process groups and ten knowledge areas.   In the 5th Edition, there were 47 processes.   So it turns out that the Project Management Institute added a few processes, and this is one of them.   Manage Project Knowledge is a new process in the Executing process group that is covered by the Integration knowledge area.

Manage Project Knowledge is about using existing knowledge within the organization to achieve the project’s objectives and then using new knowledge gained on the project to contribute to the organization”s body of knowledge.   This new knowledge is referred to as lessons learned, and in the past 5th Edition of the PMBOK® Guide, this was collected during the final process called Close Project or Phase.

The “lessons learned” document was then given to the organization’s Project Management Organization so it could be used on future projects to guide project managers by helping them avoid the same mistakes and to assist them in dealing with similar issues on their projects.

However, since the publication of the 5th Edition, the “best practice” of companies with regards to lessons learned has evolved, due to the influence of agile project management methodologies.    In agile, at the end of each iteration or sprint, there is a review called a “retrospective” which, among other things, documents the issues encountered that have been resolved and the lessons learned from them.    This does two things:  it helps the current project by helping the project team take corrective action in real time to improve the performance of the project, and secondly, it helps future projects by adding to creating a lessons learned register which can capture and share the knowledge gained to the organization at large.

Those companies doing traditional or waterfall project management methodology took note of this and started doing the same on their projects, by incorporating the process of creating lessons learned during the project and not just at the end of it as had been done before.   By the time of the 6th Edition PMBOK® Guide, PMI had recognized this sea change with regards to the lessons learned process, and enshrined in its own new process, 4.4 Manage Project Knowledge.

This process is a prime example of the way that agile project management methodologies are profoundly shaping the way that ALL projects are done, including those still done with the traditional or waterfall methodology.

This post will discuss the inputs to this process,

• the project management plan and project documents (outputs of process 4.2 Develop Project Management Plan)
• deliverables (outputs of process 4.3 Direct and Manage Project Work)
• the “generic” inputs of Enterprise Environmental Factors (EEFs) and Organization Process Assets (OPAs)

4.4.1 Manage Project Knowledge:  Inputs

4.4.1.1 Project Management Plan

All components of the project management plan are inputs to this process.   Remember, the project management plan is the main output of process 4.2 Develop Management Plan, along with project documents (see next paragraph).  In the course of doing the project work in process 4.3 Direct and Manage Project Work, there may be some issues related to the project management plan that need to be resolved.  For example, if the estimates for time and/or cost for a particular activity turn out to be inaccurate, then rather than trying to change the work to fit the unrealistic plan, it may be necessary to change the plan.   The new knowledge gained which caused people to realize that the plan was inaccurate may be just the sort of thing that you would want to include in the lessons learned register, so that other people doing similar projects won’t make the same mistake.

4.4.1.2  Project Documents

The other main output of process 4.2 Develop Project Management Plan which is in turn used as an input for this process are certain project documents, such as the following:

• Lessons learned register (also an output of this process)–this is the document to which new lessons learned will be added.   Notice that it is called a “register” which implies a system of categorization that will make it easier for people to find information stored in it.   Also, a register is something to which you add entries on a regular basis, implying that it is a “living document” that will continue growing throughout the project.   The existing register is an input to the process, the process itself updates it, the resulting updated document is then an output of the process.
• Project team assignments (output of process 9.3 Acquire Resources)–this may provide information on the type of competencies and experience available in the project, so that any gaps in the knowledge and/or experience required on the project can be identified and then filled (by training existing resources or acquiring new resources with that knowledge and/or experience).
• Resource breakdown structure (output of process 9.2 Estimate Activity Resources)–this provides information on the composition of the team and the various roles of its members, so that any gaps in the knowledge required by the project can be identified and then filled (by rewriting descriptions of roles or adding new roles).
• Stakeholder register (output of process 13.1 Identify Stakeholders)–this contains details about identified stakeholders to help understand the knowledge they have.   If they have knowledge that is pertinent to one of the lessons learned on the project, then may need to be consulted.

4.4.1.3  Deliverables

A deliverable is the product of a work package, a “bite-size” portion of the scope, like a piece of the puzzle that is put together to form the final work product.   These are tangible components completed to meet work requirements.   The deliverables created in the time since the last lessons learned review may be reviewed in order to come up with new lessons learned.

4.4.1.4   Enterprise Environmental Factors

These are factors which are contained in the environment the project is done in:   the organizational environment, the social, culture and political environment, as well as the legal and regulatory environment.

The various types of environment are outlined in the diagram below, taken from the website.

http://www.businessintegral.com/approach/the-integral-model/

There are interior/collective CULTURAL aspects of the organization (its values, mission statement, etc.) , and its exterior/collective SYSTEMS (processes, procedures, etc.).   These are within the organization, but there are the same categories within the larger circle of the society itself, the CULTURAL aspects of society as well as the SYSTEMS (for example, the legal and regulatory environment).

Here are the EEFs that can influence this process 4.3 Manage Project Management

• Organizational, stakeholder, and customer culture (lower left quadrant in the diagram above)– in order to manage knowledge, it needs to be shared, and sharing implies a relationship of trust in the working relationships between members of an organization, and with stakeholders including customers.
• Geographic distribution of facilities and resources (lower right quadrant in the diagram above)–location of team members determine methods for gaining and sharing knowledge (how will knowledge gained be added to the organization, and how will such information be accessed by its members).
• Organizational knowledge experts (lower right quadrant in the diagram above)–these are individuals or a team of people in the organization who specialize in knowledge management.
• Legal and regulatory requirements and/or constraints (lower right quadrant in the diagram above in a larger circle including society)–this relates specifically to the confidentiality of project information.

4.4.1.5 Organizational Process Assets

Organizational process assets or OPAs such as project management processes and procedures have embedded in them knowledge gained about projects done in the past.   The new knowledge generated in a project that is the subject of this process will therefore directly affect these very OPAs, such as the following:

• Organizational standard policies, processes, and procedures regarding knowledge management, such as
  • Confidentiality and access to information
  • Security and data protection (passwords, encryption, etc.)
  • Use of copyrighted information
  • Destruction of classified/proprietary information
  • Maximum size and format of files
  • Lessons learned data and metadata
  • Authorized social media
• Personnel administration
  • Employee development and training records
  • Competency frameworks
• Organizational communication requirements
  • Formal, rigid communication requirements–good for sharing information
  • Informal communication requirements–good for creating new knowledge and integrating knowledge across diverse stakeholder groups
• Formal knowledge-sharing and information-sharing procedures
  • Scheduling learning reviews during project phases and at the end of project phases
  • Methods of identifying, capturing, and storing lessons learned in the lessons learned register

Okay, so that gives us all the ingredients to create a lessons learned register.   But how are those lessons created?    To understand this, it is necessary to some of the theory of knowledge management, which I will do during the next post on the tools and techniques of process 4.4 Manage Project Knowledge.

Filed under: Uncategorized | 2 Comments »

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

http://www.businessintegral.com/approach/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 »