6th Edition PMBOK® Guide–Process 6.1 Plan Schedule Management: Tools and Techniques


The Plan Schedule Management process has as its aim to create the Schedule Management Plan, the portion of the overall project management plan that covers processes that have to do with creating, managing and then controlling the schedule for the project.   Essentially, then, the Schedule Management plan developed in this Process 6.1 Plan Schedule Management gives guidelines on how to do all of the OTHER schedule management processes, all the way from 6.2 Define Activities through 6.6 Control Schedule.

The inputs were listed in the last post; this post will cover the tools and techniques needed to create the Scope Management Plan.   These basically cover who you will need to consult in order to create the plan (Expert Judgment), how you will analyze the data from the inputs to create the plan (Data Analysis), and then where the schedule management plan will be developed (Meetings).

6.1.2  Plan Schedule Management:  Tools and Techniques

6.1.2.1 Expert Judgment

Expertise should be considered from individuals who have expertise in the area of schedule development for your specific industry, including using scheduling software (like Microsoft Project or Primavera), or who had experience creating a schedule for a previous, similar project.

6.1.2.2  Data Analysis

The main data analysis technique used in creating a schedule management plan (not creating the schedule itself, mind you, but creating the plan) is alternatives analysis.   The alternatives that may be determined, if they are not already set out in the schedule development, management and control-related policies for your organization (these would be included as part of the Organizational Process Assets, one of the inputs to this process), would include the following:

  • does the entire schedule need to be done up front first?   If it needs to be done in detail, then this follows a predictive, aka traditional or waterfall methodology.
  • if the schedule needs to be done up front, but it can developed in stages or increments, then this follows an iterative or incremental model.
  • if the entire schedule does not need to be done in detail, so that the work to be accomplished in the near term is planned in detail, but the work to be done in the future is planned at a higher level of detail, then this is following a rolling wave methodology.    The analogy I use to describe this is that it is like laying down the train tracks for the farther portion of the railroad while the train has already started down the tracks.
  • an agile or adaptive methodology is one where the project is completed in a series of stages called releases, which release features to the customer on an incremental basis.

Also important to consider it the level of detail in the planning.   In a predictive model, especially with a project that is similar to ones done before, it may make sense to plan the schedule in a high level of detail at the beginning of the project, because this will save time in the execution phase of the project because any variances from the plan will be easier to detect.

On the other hand, if it a new project totally unlike one the organization has done before, it may make sense to follow a more iterative or incremental model, including doing something rolling wave planning.    As you get closer to the work that needs to be done, you will gain more knowledge to put the schedule in more detail.    If you put the project into too much detail at the beginning, when there are still a lot of unknown factors, you may end up having to spend time revising the schedule in the monitoring and controlling process.   So you need to adjust the schedule methodology to not only the organization doing the project, but also the type of project (it is totally new or one similar to a project done in the past).

6.1.2.3  Meetings

Meetings are where the planning is done to develop the Schedule Management Plan.  Those that may be included are:

  • the project sponsor
  • the project manager
  • selected project team members, especially those with responsibility for scheduling planning or execution,
  • selected stakeholders, especially those with information on the basic constraints on the schedule (i.e., those that can suggest milestone dates)
  • others as needed, particularly those project managers/project team members from previous projects that are similar to the project being planning

These three tools/techniques of expert judgment, data analysis, and meetings are used in other planning processes for other knowledge areas as well.

The output of any “Plan X Management” planning process, where “X” stands for the name of the particular knowledge area, is going to be the “X Management Plan.”   So, naturally, the output of Plan Schedule Management will be the Schedule Management Plan.   The details of what is in the Schedule Management Plan are to be covered in the next post.

Advertisements

6th Edition PMBOK® Guide–Process 6.1 Plan Schedule Management: Inputs


Welcome to the next chapter of the 6th Edition PMBOK® Guide, that of Schedule Management.   The first process with any knowledge area related to the major constraints of the project (scope, schedule, and cost) is going to be a planning process which basically is a guideline on how to do all of the other processes in that knowledge area.   Schedule management is no exception:   the first process is Plan Schedule Management.   Figuring out the output is easy; it’s the Schedule Management Plan, one of the components of the overall Project Management Plan.  But what are the inputs to this process?   That is the subject of today’s post.

6.1.1  Plan Schedule Management:  Inputs

6.1.1.1  Project Charter

The project charter contains many elements, including any high-level constraints on the major constraints of scope, schedule, and cost.   In the case of the schedule, the sponsor of the project, who is responsible for the creation of the project charter, can specify any important milestone dates for the project in the “summary milestone schedule.”   This outlines the major constraints on the schedule, including the most important one, the projected deadline date for the completion of the project.

6.1.1.2  Project Management Plan

Remember, the project management plan consists of the following categories of elements:

  • Management plans from each of the knowledge areas
  • Three subsidiary management plans (requirements related to the scope knowledge area, and change and configuration related to the integration management process 4.6 Integrated Change Control)
  • Project baselines–for scope, schedule, cost, and performance measurement (which uses earned value analysis that measures each of these constraints)
  • Project life cycle (will the project be done in phases?) and product developmental approach
  • Project documents (requirements documentation, issue log, change log, risk register, etc.)

Here are the elements that are used in creating the Schedule Management Plan.

  • Scope Management Plan–the scope management plan shows how to go from the detailed Work Breakdown Structure created in the process 5.3 Define Scope to the first process used in creating the schedule, process 6.2 Define Activities.   The WBS by itself just shows a list of work to be done; the planning processes of schedule management give a plan on exactly how to get that work done.    It’s analogous to a recipe; you need both the list of ingredients (analogous to the WBS) and the instructions on how to turn those ingredients into the finished dish (analogous to the schedule).
  • Product developmental approach (predictive, also known as traditional or waterfall, iterative/incremental, adaptive, also known as agile, and/or a hybrid approach)–this will have an effect on how the schedule is estimated, developed, and then controlled.

6.1.1.3  Enterprise Environmental Factors

  • Guidelines for tailoring the organization’s standard set of processes and procedures to a specific project
  • Standardized estimating data for the application area and/or industry
  • Scheduling software (crucial point:   the software itself, such as Microsoft Project or Primavera, is an Enterprise Environmental Factor, but the data files themselves from previous projects are considered Organizational Process Assets)
  • Organizational culture and structure–will determine how resources are allocated and decisions are made with respect to the schedule
    • is it functional/centralized, devoted mainly towards operations, in which case decision making is done by a functional manager
    • is it projectized, devoted mainly towards projects, in which case decision making is done by the project manager
    • or a matrix organization, somewhere in between the two structures mentioned above, in which case decision making may be shared between the functional and project manager
  • Availability of team member resources and physical resources within the organization

6.1.1.4  Organizational Process Assets

  • Policies, procedures and guidelines (whether formal or informal) related to the development, management, and control of the schedule
  • Templates, forms, and monitoring and reporting tools
  • Historical information and lessons learned repositories from previous similar projects

With those inputs, the process of creating the Schedule Management Plan has tools and techniques that are common throughout the planning process in the various knowledge areas dealing with the major constraints:   expert judgment (to help with who is doing the plan), data analysis (to help with how the plan is done), and meetings (to help with where the plan is done).

Those tools and techniques are the subject of the next post.

 

6th Edition PMBOK® Guide–Process 5.6 Control Scope: Outputs


As we stated in a previous post on the inputs to this Control Scope process, the process consists of asking three questions:

  1. “what’s the plan?”
  2. “is the project going according to the plan?” and if the answer to question 2 is no,
  3. “how can we get the project back to the plan?”

The outputs are based on the answers to question 2 (Work Performance Information, and updates to the Project Management Plan and Project Documents) and question 3 (Change Requests).

Here are the specific outputs to this process:

5.6.3 Control Scope:  Outputs

5.6.3.1 Work Performance Information

Just as a review, there are three levels of knowledge on a project.

  1. Work performance data–generated in the Process 4.3 Direct and Manage Work by the project team
  2. Work performance information–this level of knowledge is useful to the project team;  the work performance data is analyzed in the separate monitoring and controlling processes connected with each knowledge area, like this one Process 5.6 Control Scope; they are then in turn inputs into the overall monitoring and controlling process 4.5 Monitor and Control Project Work
  3. Work performance reports–this level of knowledge is useful to the stakeholders; the work performance information is organized and presented in the overall monitoring and controlling process 4.6 Monitor and Control Project Work so that it is useful to those stakeholders who are engaged with the project.

This output is work performance information that is based on the analysis done in the Process 5.6 Control Scope.  The main tool/techniques of this process (described in the last post) are variance analysis and trend analysis.   These not only answer the question 2 above, i.e., is the project going according to the plan, but if the answer is “no”, then they dig deeper into the reason for the variance existing now or the trend that a variance may exist sometime in the near future.   Other parts of the analysis are determining the impact the variance in scope has on the other two major constraints, that of schedule and cost.

The Work performance information is then input into the overall monitoring and controlling process 4.6 Monitor and Control Project Work.

5.5.3.2  Change Requests

The answer to question 3 above, “how can we get the project back to the plan?”, will determine the change request which will either

  • fix the project scope back to fit the plan OR
  • in the case that the plan has been discovered to be unrealistic, it may be necessary to change the plan to fit the project scope

If the scope needs to be changed, then there will be a change request outlining what needs to be changed.   If the plan needs to be changed, then the scope management plan, the various project baselines, and the project documents may need to be changed (see next paragraph).

There are three types of change requests:   defect repair, corrective action, and preventive action.   Here’s how to keep them straight in your head.   In Charles Dickens’ novel A Christmas Story, the main character Ebeneezer Scrooge is visited by ghosts, the Ghost of Christmas Past, the Ghost of Christmas Present, and the Ghost of Christmas Future.   As a project manager, you too may be visited by three ghosts, but in this case these are:

  • The Ghost of Nonconformities Past (i.e., variances from the plan that have already occurred):   in this case you need to make a defect repair to make sure that the variance is repaired and the project scope can continue as planned
  • The Ghost of Nonconformities Present (i.e., variances from the plan discovered in the Variance Analysis tool and technique mentioned in the last post):   in this case you need to take corrective action to make sure that the variance is corrected and the project scope can continue as planned
  • The Ghost of Nonconformities Future (i.e., trends towards a future variance from the plan discovered in the Trend Analysis tool and technique mentioned in the last post):   in this case you need to take preventive action to make sure that the a potential variance in the future is prevented by reversing the downward trend in the performance baseline.

The change requests are then inputs to the process 4.6 Perform Integrated Change Control, which analyzes and decides upon what changes to perform on the project based on change requests from ALL monitoring and controlling processes, not just this one.

And remember, there is the fourth possibility that the analysis done in this process uncovers that the plan was unrealistic because it did not realistically account for all the project scope that had to be done.   That is covered by the next two sections listed below.

5.6.3.3 Project Management Plan Updates

  • Scope management plan–it may be uncovered in the Lessons learned register (see section below on Project Document Updates) that during this process, more efficient and effective ways of controlling the scope are discovered, including getting at the cause of the variances and choosing the best type of action to take with a change request.   In this case the portion of the scope management plan that gives the guidelines for this particular process may be updated.   The change in scope may be severe enough to change not just the deliverables and the work packages, but the requirements themselves, in which case the requirements documentation will also need to be updated (see section below on Project Document Updates).
  • Baselines–the scope baseline may be changed if the change requests outlined in the above paragraph are approved, which may in turn cause changes in the baselines for the other two major constraints, the schedule baseline and the cost baseline.   If the scope baseline is determined to have been unrealistic, then the scope baseline, and the other baselines of the schedule baseline and cost baseline may need to be changed as well.   This will in turn change the performance measurement baseline (used in earned value analysis), because this combines measures of all three constraints.

5.6.3.4  Project Document Updates

  • Lessons learned register–rather than the results of the process, i.e., possible changes in the scope, if the process 5.6 Control Scope itself needs to be changed, then this is where you would put updates to the process that are more effective and efficient in controlling the scope, which would in turn be used to change the portion of the Scope management plan that gives guidelines on how to do the process.
  • Requirements documentation (including requirements traceability matrix)–if there is a change request that makes a recommended change in the scope, the scope baseline (which contains the deliverables in the Project Scope Statement, and the work packages in the WBS and WBS dictionary) will normally be what is altered if the change is approved.   However, the variance in the scope may be so great that even the requirements, from which the deliverables and eventually the work packages are derived, may need to be changed, in which case the requirements documentation will need to be updated.

And that, my friends, is the end of the fifth chapter of the 6th Edition PMBOK® Guide; the next chapter will cover the knowledge area of Schedule Management.

 

6th Edition PMBOK® Guide–Process 5.6 Control Scope: Tools and Techniques


As we discussed in the last post on the inputs to this process 5.6 Control Scope, there are three questions to be asked in the monitoring and controlling of the scope:

  1. “what’s the plan?”
  2. “is the project going according to the plan?” and
  3. “how can we get the project back to the plan?”

The first two questions are the monitoring part of this process, and the third question pertain to the controlling part.

This post will discuss the two main tools and techniques used in this Control Scope process, which are also used in the monitoring and controlling processes for the other major constraints (schedule and cost).

5.6.2 Control Scope:  Tools and Techniques

5.6.2.1 Variance Analysis

Variance analysis is where you take the work that was supposed to be done on the scope of the project in the last reporting period (obtained from the Scope Baseline input) and compare it to the actual work done during the last reporting period (obtained from the Work Performance Data input).   Let’s say there is a variance detected between the two.   Then what do you do?

  • See if the variance exceeds any threshold amount set at the beginning of the project.   If it exceeds that threshold, the sponsor may need to be informed, for example.
  • Analyze how the variances in the scope affect the other constraints of schedule and cost.
  • Find out if defect repair or corrective action is required to bring the scope back to the baseline (using the Requirements Documentation and/or Scope Baseline inputs).

5.6.2.2  Trend Analysis

A comparison of current performance with the performance measurement baseline (usually using Earned Value Analysis) will show if there is a trend towards improving or deteriorating performance.   If it is deteriorating, then find out if preventive action is required to reverse that trend.

The output of these two analyses will be recommendations for change requests, which are the main output of this 5.6 Control Scope process.   (Change requests in fact are the main output of any monitoring and controlling process for other knowledge areas as well, not just for scope.)

We will discuss the types of change requests when we cover the outputs of this process, which are covered in the next post.

 

 

6th Edition PMBOK® Guide–Process 5.6 Control Scope: Inputs


If a project scope keeps expanding without any adjustments to the other constraints such as the time, cost, and resources, you have a situation referred to as scope creep.   That is why you have this process called Control Scope.   Now, a change in the scope is probably inevitable, but the key here is to make sure that it is done in a controlled way that takes the other constraints into account.

The inputs you will need for this process are covered in this post.

5.6.1  Control Scope:  Inputs

5.6.1.1 Project Management Plan

Here are the components that may be needed as inputs to this process.

Remember that the project management plan consists of

a) 9 knowledge area management plans, (one plan for each of the knowledge areas besides Integration, which integrates all of them into the overall project management plan)

b) 3 subsidiary management plans

  • for requirements, related to the Scope management knowledge area,
  • for change, related to the Integration management knowledge area (this covers the contents of the changes)
  • for configuration, also related to the Integration management knowledge area (this covers the structure of the changes, so that everybody is working off the same version of the project and/or product)

c) 4 baselines, covering the 3 major constraints of scope, schedule and cost, plus the performance measurement baseline, which uses earned value analysis to combine measures of all three of these constraints

PLUS

d) A description of the project life cycle (will it be split up into phases) and development approach (traditional or predictive, also known as waterfall, incremental/iterative, agile, or hybrid)

and a lot of project documents.

In the inputs for this process, we have examples from all of the first three categories of elements from the project management plan.    They can be divided into three groups, based on what question they answer:

  • “what’s the plan?”
  • “is the project going according to the plan?” and
  • “how can we get the project back to the plan?”

A.  What’s the plan?

Here are the elements of the project management plan related to the scope, which should give a measure of what the scope is according to plan.

  • Scope management plan–remember that the scope management plan, developed in process 5.1 Plan Scope Management, contains guidelines on how to do all of the other processes of scope management, including this one 5.6 Control Scope.
  • Requirements management plan–this shows specifically how the project requirements will be managed.
  • Scope baseline–contains the project scope statement, the WBS and WBS dictionary.
  • Requirements documentation (including the requirements traceability index)

Remember that the scope comes in three levels of detail:

  • the requirements, which are set forth by the customer or sponsor of the project (located in the Project Charter at a higher level and then in the Requirements Documentation at a more detailed level)
  • the deliverables, which are the products of the project which fulfill the requirements (located in the Project Scope Statement, a part of the Scope baseline) and
  • the Work Breakdown Structure (or WBS) which breaks down the deliverables into manageable, “bite-size” chunks called “work packages”, accompanied by the WBS dictionary, which gives additional information on each work package (who it is to be done by, cost and time estimates, etc.).

B.   Is the project going according to the plan?

Okay, what if the monitoring process shows that the work is somehow NOT being done according to plan?   For that you need the following:

  • Performance measurement baseline:   the three major constraints on a project are scope, schedule and cost.   Earned value analysis combines measures of each of these constraints to get a measurement of the overall performance of the project.  (Details about earned value analysis are contained in chapter 7 on Cost Management.)    The important point here is that earned value analysis tells you whether you are ahead of schedule or behind schedule, and whether you are within your budget or exceeding your budget.

Based on the answer to question B, you may find that the project is NOT going to plan, and so you now have to go to question C:

C.   How can we get the project back to the plan?

This is where change requests come in.   For the guidelines on how to handle these, you need the following:

  • Change management plan (one of the three subsidiary management plans)–shows how to handle the change control process.   Will it be done by the project team as a whole?   Will it be done by a special Change Control Board?   If so, who will be on the Board, and how will decisions be reached?
  • Configuration management plan (if there is a change request that is accepted, how will the documents related to the project be designated so that everybody is working on the current version of the project and not an earlier version)
  • Lessons learned register (lessons learned earlier on in the project with regard to change requests may help the process go more smoothly as the project progresses)

5.6.1.3 Work Performance Data

The actual work done on the scope of the project in the last reporting period goes into the work performance data.   This is important because the tools and techniques in this process will compare the work planned to be done to the actual work done.   Data on the number of change requests received, and the number of requests accepted can be obtained from the change log.

5.6.1.4 Organizational Process Assets

The OPAs that can influence this process include:

  • Templates and reporting methods to be used for monitoring the scope
  • Existing  policies, procedures, and guidelines to control the scope

All of these should be included in the Scope Management Plan.

The next post will deal with the tools/techniques used in this process–the main one is change requests, to bring a project back to the plan (or if necessary, to change the plan to be more realistic).

 

6th Edition PMBOK® Guide–Process 5.5 Validate Scope: Outputs


After the inspection process which is the main tool/technique of the Validate Scope process, there are one of two possible outcomes.   Either the customer or sponsor

  1. formally accepts the final deliverables of the project, in which case the project can be considered complete, and the next process is then process 4.7 Close Project or Phase
  2. rejects certain of the deliverables as nonconforming to the acceptance criteria decided upon at the beginning of the project, in which case a change request is made so that those nonconforming deliverables can be brought in line with the acceptance criteria.

The outputs related to either of these outcomes are listed below.   If the final deliverables are accepted as in paragraph 1 above, the output will be any accompanying formal documentation of that acceptance (see 5.5.3.1 below).  If they are NOT accepted as in paragraph 2 above, the output will be the change requests (see 5.5.3.3 below), along with any documentation outlining the reasons why they have not been accepted (see 5.5.3.2 below).

There are project documents updates done in either case, whether the final deliverables are accepted or not (see 5.5.3.4 below).

5.5.3 Validate Scope: Outputs

5.5.3.1 Accepted Deliverables

If the customer or sponsor has accepted the deliverables, then the formal documentation acknowledging that acceptance is forwarded on to process 4.7 Close Project or Phase

5.5.3.2  Work performance information

Information on which deliverables have been accepted, which have not been accepted and the reasons why, is described and communicated to shareholders.

5.5.3.3  Change requests

If there have been some of the completed deliverables that have not been formally accepted, documentation on the reason for the non-acceptance of those deliverables is used to create a change request for defect repair.   The change request goes through the usual process for such requests, 4.6 Perform Integrated Change Control.   Once the deliverables have been corrected to be in line with the acceptance criteria, they are submitted again to the process 5.5 Validate Scope.

5.5.3.4  Project Documents Updates

  • Lessons learned register–what challenges were encountered in the Validate Scope process.   What approaches worked well for validating deliverables?
  • Requirements documentation (including the requirements traceability matrix)–the result of the Validate Scope process for the requirements should be documented.  What methods were used to validate the requirements and what was the outcome of the validation process? Did the actual results fulfill the requirements?   Did any of them exceed the requirements?    Were any requirements waived by the customer or sponsor?

Now let’s turn to the monitor and controlling process that usually comes BEFORE the Validate Scope process related to the final deliverables, that of 5.6 Control Scope, which is the process of monitoring the status of the project and product scope and managing any changes to the scope baseline (which consists of the Project Scope Statement, the WBS, and the WBS dictionary).

 

 

6th Edition PMBOK® Guide–Process 5.5 Validate Scope: Tools and Techniques


How is the process of validating the scope done?   That is the subject of this post.

5.5.2  Validate Scope–Tools and Techniques

5.5.2.1 Inspection

The main tool/technique is that of inspection, which in this case means measuring, examining, and comparing the characteristics of the deliverables to see that they fulfill the requirements and product acceptance criteria developed at the beginning of the project.   I think you can see why it is important that these product acceptance criteria have to be measurable and objective, rather than subjective, because then there is less room for potential disagreement on whether a deliverable does or does not meet those criteria.   For example, “I want the final product to look nice” would not be an objective criteria, because what “looks nice” to one person may not look nice to another person.

As the PMBOK® Guide mentions, in some application areas the inspection may be referred to as a “product review” or “walkthrough.”   The name doesn’t matter as much as the process.

5.5.2.2  Decision Making

As important as the process of inspection is, and in particular the necessity of deciding on the acceptance criteria, it is also important to agree ahead of time on how the decision will be made as to whether the product meets those acceptance criteria.   Who exactly will make the decision?   Will it be solely the customer or sponsor?   Or will the decision be done by a group of people, including some of the project team and;or other stakeholders.   And if so, what will be the method of voting?   Will it have to be a unanimous vote, by majority vote, or vote by a plurality vote?   This also needs to be spelled out ahead of time so if there is any disagreement, there is a clear path towards resolving it.

At the end of the day, there will be one of two possible decisions:   either

a) the final product meets the acceptance criteria, in which case the customer or sponsor sends formal acceptance in the form of a written letter to the project manager.   The project has now officially gone from the monitoring and controlling phase to the closing phase.

or

b) the final product does not meet all of the acceptance criteria, in which case a change request must be made which states the reason for the non-acceptance of certain deliverables.   The project then goes to the Perform Integrated Control process (4.6) and once the changes are made, another attempt is made to do the Validate Scope process (and hopefully get it right this time).

For the outputs to this process, let’s go to the next post.