4squareviews

Once we have put all of the activities to be done on a project in a sequence, we need to find out an estimate of their durations to come up with the all-important question, “how long will this project take to complete?”   There are a lot of inputs to this process.   The inputs to the processes of schedule management are like a snowball going downhill:   the outputs of one process become the inputs to the next process and additional inputs from other knowledge areas are also added along the way.

Let’s review all of the inputs to this process 6.4 Estimate Activity Durations.

6.4.1  Estimate Activity Durations:  Inputs

6.4.1.1  Project Management Plan

The components of the project management plan that are inputs to this process include the schedule management plan, the scope baseline, and several of the project documents.

Let’s discuss the first two of these in the paragraphs below–the project documents are in the next section after this one (see below)

• Schedule management plan–remember, this is the plan that is an output of process 6.1 Plan Schedule Management that gives guidelines on how to do all of the other processes of schedule management, including this process.   In particular, the guidelines that help with estimating activity durations are:
  • Level of accuracy–the acceptance range used in determining realistic activity duration estimates (is it done in terms of a range of values, in terms of a probability of achieving a certain deadline?)
  • Units of measure–the units of measurement for measuring time (staff hours, or some other unit)
• Scope baseline–remember this is three documents in one, which includes the project scope statement, the WBS, and the WBS dictionary.   In this process, the activity durations are added to the activities list for each work package in the WBS, and the WBS dictionary may give information on any constraints or available resources which might affect these duration estimates.

6.4.1.2  Project Doocuyuuments

• Activity List–contains all schedule activities required on the project which are to be estimated in this process.   This is an output of 6.2 Define Activities.
• Activity attributes–contains information on each of the activities in the activity list, usually added as updates after the process 6.3 Sequence Activities.   Such updates include the following:
  • Defined predecessor or successor relationships between activities
  • Defined logical relationships between the activities (do they have a Finish-to-Start or series relationship, or a parallel relationship as in Start-to-Start or Finish-to-Finish)
  • Defined lead and lags between activities
  • Other constraints that can influence duration estimates
• Assumption log–assumptions may contain information on project risks that may impact the project schedule.  The assumption log is an output of the 4.1 Create Project Charter process, but can be updated after the process 6.3 Sequence Activities, and so is an output of that process as well.
• Resources breakdown structure–shows the resources potentially available for the project broken down by resource category and type.   This is an output of process 9.2 Estimate Activity Resources.
• Resource calendars–the resource breakdown structure shows the resources potentially available, but their actual availability may vary during the project because they may also be used on other projects or operational work.   The resource calendar identifies when and for how long identified project resources will be available for use on this particular project.   This is another output of process 9.2 Estimate Activity Resources.
• Resource requirements–how do the potentially available resources meet the requirements of the activities?   If someone with a higher level of skill that is normally required is not available, someone with a lower level of skill to do that same activity may require additional time, or additional resources may need to be assigned to an activity to do it in the same amount of time as it would take if the more skilled resource were doing the activity.   This is yet another output of process 9.2 Estimate Activity Resources.
• Risk register–along with the assumption log, this contains information on risks which may impact resource selection and availability.   For example, if you are assigning a key person to do an activity, one of the risks to consider is if they have scheduled a vacation or are going to be on a business trip when their work on the project is needed.   The risk register is an output of the risk management process 11.2 Identify Risks.

6.4.1.3  Enterprise Environmental Factors

• Published commercial information on duration estimates for standard work done in the industry.
• Reference databases containing duration estimates for activities done on the project.
• Productivity metrics

6.4.1.4.  Organizational Process Assets

• Duration estimates and project calendars from other similar projects (historical information)
• Lessons learned repository from other similar projects relating to how duration estimates were calculated
• Policies for creating duration estimates (usually included in the Scope Management Plan)
• Scheduling methodology (also usually included in the Scope Management Plan)

With all of those inputs, let us now turn to the process itself in the next post on tools and techniques of 6.4 Estimate Activity Durations.

Filed under: Uncategorized | Leave a comment »

The outputs to the Process 6.3 Sequence Activities are the project schedule network diagram and updates to the project documents such as the activity list and activity attributes.   Let’s discuss these outputs in this post.

6.3.3  Sequence Activities:  Outputs

6.3.3.1  Project Schedule Network Diagram

This is a diagram that looks like a flowchart; it graphically represents the logical relationships between activities by having lines and arrows connecting the activities represented by rectangular boxes called nodes.   An example of such a project schedule network diagram is given on p. 193 of the 6th Edition of the PMBOK® Guide.

6.3.3.2  Project Document Updates

6.3.3.1  Activity List

The activity list is the result of the technique of decomposition applied to the work packages of the WBS.   The work packages are things, tangible or otherwise, and so are nouns, whereas activities are the work required to completed those work packages, and so are verbs.   The activities list was created as an output to process 6.2 Define Activities.   The associated list of activity attributes may be updated as an output of this process.

6.3.3.2  Activity Attributes

Activity attributes are associated with each activity in the activity list; the activity attributes that may be added after this process include:

• any activities that describe a necessary sequence (mandatory dependencies)
• defined predecessor/successor relationships among activities (usually FS or “Finish-to-Start if otherwise unspecified; any unusual activity sequences such as SS “Start-to-Start” or FF “Finish-to-Finish” should be specified)
• defined leads or lags between activities

6.3.3.3  Assumption Log

The assumptions and constraints that affect the project schedule (some of which may have been stated way back in the project charter) may be impacted by changes in the relationships between activities specified during this process.   (For example, mandatory dependencies cannot be altered as opposed to discretionary dependencies, and internal dependencies can be altered more easily as opposed to external dependencies.)

6.3.3.4  Milestone Log

Some of the specified dates for specific milestones on the project may be impacted by changes in the relationships between activities specified during this process.

Now that we know the SEQUENCE in which the activities will take, the next thing we have to determine in order to create the schedule is an estimate of the DURATION of these activities.   That is the next process 6.4 Estimate Activity Durations and is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

This process is where the activities given in the activities list, the output of the previous process 6.2 Define Activities, are analyzed to see which of them should logically come before others.   There are three basic techniques, the precedence diagramming method (PDM), dependency determination and integration, and the adding of leads and lags between activities as needed.    The basic tool of this process is the Project Management Information System or PMIS (such as Microsoft Project).

6.3.2  Sequence Activities:  Tools and Techniques

6.3.2.1  Precedence Diagramming Method (PDM)

The precedence diagramming method represents activities by boxes called nodes.   If a certain activity logically comes before another activity that it is dependent upon, then that is called a predecessor activity.    And conversely, if a certain activity logically comes after another activity in a schedule, then that is called a successor activity.    It is the next technique, Dependency Determination and Integration, which can help determine which activities are connected logically in this manner.

This is the “precedence” part of the method.   The diagramming part comes next, where the activities are represented by rectangular boxes called nodes.   These nodes are then linked depending on the type of dependency or logical relationship between them.

There are four types of logical relationships between a predecessor and a successor activity.    Two are series relationships, where the activities are done one after the other.  Two are parallel relationships, where the activities partially overlap in time.

With the following four designations that consist of the two letters “F” (for “finish”) and “S” (for “start”), the first letter refers to the predecessor activity and the second letter refers to the successor activity.

• Finish-to-start (FS)–this is the most common type of logical relationship, where a successor activity cannot start until the predecessor activity has finished.
• Finish-to-finish (FF)–this is the next most common type of logical relationship, where a successor activity cannot finish until the predecessor activity has finished.  However, the activities can overlap in time.   The example used in the PMBOK® Guide is where you must finish writing a document (the predecessor activity) before you can finish editing it (the successor activity).   However, once you get a few pages of the document written, you can start editing those pages before you continue writing the rest of the document, so the writing and the editing of a document can occur overlap in time.
• Start-to-start (SS)–this is the next most common type of logical relationship, where a successor activity cannot start until the predecessor activity has started.   The example used in the PMBOK® Guide, the activity of leveling the concrete (the successor activity) cannot begin until pour foundation (successor activity) begins.  Although you can start leveling the concrete that has already been poured in one section of the foundation while another section of the foundation is being poured, you cannot level concrete before it has been poured.
• Start-to-finish (SF)–this is the least common type of logical relationship, where a successor activity cannot start until the predecessor activity has started.   This is very rarely used, although the example used in the PMBOK® Guide  is that a new accounts payable system (successor activity) has to successfully start up before the old accounts payable system is shut down (predecessor activity).

6.3.2.2  Dependency Determination and Integration

The dependencies between activities can be characterized by certain attributes, some of which are mutually exclusive.   Dependencies can be either a) mandatory or discretionary, and b) external or internal.

• Mandatory dependencies–dependencies that are legally or contractually required or inherent in the nature of the work.
• Discretionary dependencies–dependencies that are established through general best practices within a particular application area.

Discretionary dependencies are not “set in stone” as the mandatory dependencies are.   This is important because they can be modified if necessary, whereas mandatory dependencies cannot be so modified.

Here’s the other set of mutually exclusive attributes.

• External dependencies–dependencies that are usually outside of a project team’s control
• Internal dependencies–dependencies that are generally inside of a project team’s control

Those internal dependencies that are inside of a project team’s control are therefore more easily modified if necessary as compared to external dependencies.

6.3.2.3  Leads and Lags

A lead is the amount of time a successor activity can be advanced with respect to a predecessor activity.    A two-week lead for a successor activity would mean that it could be started two weeks prior to the completion of the predecessor activity.

A lag is the amount of time a successor activity can be delayed with respect to a predecessor activity.   A two-week delay lag for a successor activity would mean that it could only be started two weeks after the completion of the predecessor activity.

If you would like to see an example exam question involving the precedence diagramming method, including leads and lags, you can go to the following post I did in reviewing the 5th Edition of the PMBOK® Guide.

https://4squareviews.com/2013/03/31/5th-edition-pmbok-guide-chapter-6-precedence-diagramming-method-leads-and-lags/

6.3.2.4  Project Management Information System (PMIS)

This is the scheduling software that you use to help sequence the activities (such as Microsoft Project or Primavera).

The next post will show the outputs of this process.

Filed under: Uncategorized | Leave a comment »

In the last process 6.2 Define Activities, the activities that go into creating each work package of the scope are defined and listed in an activity list.   This process 6.3 Sequence Activities, is where the relationship among the project activities is identified and documented in order to determine the logical sequence of work in order to do the project.

Here are the inputs to the process:

6.3.1  Sequence Activities;  Inputs

6.3.1.1  Project Management Plan

The two components of the project management plan used in this process are:

• Scope management plan–this is the knowledge area management plan that covers scope management, in particular
  • the scheduling methodology (for example, Critical Path Method) and
  • the scheduling tool (for example, Microsoft Project) to be used in developing the project schedule model are specified.

When PMI talks about the project schedule model, just think of the project schedule.   The word “model” is added by PMI to make sure you know that it is not written in stone:   it may change if the assumptions that created it change based on newly discovered or recently changed information about the project.

• Scope baseline–remember, this actually consists of three separate documents, the
  1. Project scope statement, which has the scope broken down from the level of requirements to the deliverables that will fulfill those requirements
  2. WBS–the work breakdown structure, with the scope of the deliverables further broken down into manageable parts called work packages.
  3. WBS dictionary–this contains information about the work packages, for example, who will do the work, what resources are needed, etc.

6.3.1.2  Project Documents

Project documents used as inputs are mostly those that are outputs of the previous process, but may also include documents that were created way back when the project charter was created (assumption log).

• Activities list–all activities needed for the project, based on the decomposition process done on the work packages during the 6.2 Define Activities project.  These are to be sequenced in the upcoming process.
• Activity attributes–information about the activities (most of this will be developed during the upcoming process, but to be included if any of this information is already known)
  • any clearly defined predecessor or successor relationships among activities
  • any specified leads or lags between activities
  • any specified logical relationships between activities (does the successor activity need to start before or after the predecessor activity ends, for example)
• Milestone list–milestones can be specified as early as the project charter, but can also be made specific as a result of the last process
• Assumption log–can be created as early as the project charter; these assumptions may influence the way the activities are sequenced.

6.3.1.3  Enterprise Environmental Factors

• Project management information system (PMIS) and/or scheduling tools–note that PMI considers that the software is an enterprise environmental factor, but documents created by the organization using the software are in fact part of the organizational process assets (see next section)
• Organization work authorization systems (for each activity, does there need to be authorization at a certain level for work to go forward?)
• Government or industry standards, particularly if the current project is similar to ones done before in the industry

6.3.1.4  Organizational Process Assets

• Templates to be used for creating a network of the project activities during the upcoming process (should be included as part of Scope Management Plan)
• Policies, procedures and/or guidelines for developing logical relationships between activities (should be included as part of Scope Management Plan)
• Lessons learned repository–if there have been similar previous projects done by the organization, this can help with the process of sequencing the activities in the current project

With the inputs described above, we can now go ahead and do the main techniques of the

• Precedence Diagramming Method
• Dependency Determination and Integration
• Leads and Lags

using the tool of the Project Management Information System (like Microsoft Project, for example).

These will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

In the same way that the scope management process 5.4 Create WBS creates the WBS (which contains the scope broken down into work packages) and the WBS dictionary (information related to the work packages), the schedule management process 6.2 Define Activities creates the activities list (the work packages broken down into the activities needed to produce them) and the list of activity attributes (information related to the activities).

Another document produced in this process is the list of milestones, which are significant points in the project (including the deadline for concluding the project).

Because of the tool and technique of progressive elaboration, each iteration of the planning may uncover new details of activities, in which case there will be change requests to the activities list and changes in the schedule baseline.

Here’s a more detailed look at the outputs of this process.

6.2.3.   Define Activities:  Outputs

6.2.3.1  Activity List

The activity list is the result of the technique of decomposition applied to the work packages of the WBS.   The work packages are things, tangible or otherwise, and so are nouns, whereas activities are the work required to completed those work packages, and so are verbs.

If the rolling wave planning technique is used, then the activities list may be updated periodically during the course of the progress.   The activity list typically includes

• activity label or name
• a unique activity identifier
• WBS ID (the identifier of the work package associated with each activity)
• the scope of work description for each activity

Other details regarding the activities, such as an estimate of their cost of the resources required to do them, are included in the list of activity attributes.

When the next process 6.3 Sequence Activities is done, more details may added to the activity list such as the predecessor activities, successor activities, logical relationships (how are the activity and the successor activity connected), and/or any leads or lags between the end of the activity and the start of the next one.

6.2.3.2  Activity Attributes

Activity attributes are details related to the activities in the activity list, such as:

• where the work is to be performed,
• the resources assigned to do the work

6.2.3.3  Milestone List

A milestone is a significant point or event in a project.   A milestone list identifies all project milestones, but remember that in terms of the schedule, a milestone is considered to have zero duration because they represent a point or event on the project.

6.2.3.4  Change Requests

If progressive elaboration is used as a planning technique, then after the initial iteration of the plan, additional levels of activities may be uncovered in further iterations.   In this case, activities are added to the activity list through a change request.   Since these activities will add time and cost to the project, the project baselines will also be changed (see the following paragraph.)

6.2.3.5  Project Management Plan Updates

The baselines of the project, which are part of the project management plan, may be changed whenever additional activities are added to the activity list.

• Schedule baseline–as work packages are progressively elaborated into activities, work may be revealed which was not part of the initial schedule baseline, in which case the schedule baseline may also need to be changed
• Cost baseline–if additional activities are added to the activity list, then the cost associates with these activities may also require changes to the cost baseline

Now that all of the activities are listed, they need to be put in order.   That is the subject of the next process, 6.3 Sequence Activities.

Filed under: Uncategorized | Leave a comment »

The Define Activities process is one that takes the work packages developed in the scope management process 5.4 Create WBS and breaks them down using the same decomposition technique into the activities needed to produce each work package.

Here are the tools and techniques used in carrying out this process.

6.2.2  Define Activities:  Tools and Techniques

6.2.2.1  Expert Judgment

Individuals or groups who have worked on similar past projects would be helpful in carrying out the process of working out what activities are needed to produce each work package.

6.2.2.2  Decomposition

This is the same technique used in the 5.4 Create WBS process that took the scope in the form of deliverables and divided it into smaller, more manageable parts called work packages.   Work packages are things, tangible or intangible, and are therefore nouns.  Activities, the effort needed to complete each work package, are verbs.    When creating the activity list for each work package, any additional information about the activity (information about the other constraints associated with it such as the cost, or the resources required, etc.) are included in the activity attributes, similar to the information about the work packages included in the WBS dictionary.

Decomposition is an activity that is best done by teams rather than individuals, because one person may catch something that another person might miss if working alone.   This is why decomposition is often done in meetings (see paragraph 6.2.2.4 ) below.

6.2.2.3  Rolling Wave Planning

Although planning can be done in a predictive approach, where you plan all the details of the work ahead of time, there is another, iterative approach called rolling wave planning, where the work in the near term at the beginning of the project is done in detail, but the work further down the line is planned at a higher level.   It is a form of progressive elaboration of the schedule plan, but with the added feature that the work on the near term may be started before the detailed plan is completed of the work further down the line.   It is like laying down the tracks for a railroad, and then having the train leave the station at one end while the tracks are still being laid down towards the other end.

6.2.2.4 Meetings

Any planning activity is best done as a team, and this is where meetings come into play as a tool for planning, especially when dealing with a technique such as decomposition.

The outputs of this process are the activity list and the list of activity attributes.   These outputs are described in the next post.

Filed under: Uncategorized | Leave a comment »

The previous process, Plan Schedule Management, was the process which created guidelines that help the project team do all of the other schedule-related processes.   This is the first planning process which takes the result from the scope management process 5.4 Create WBS and uses it as input to the first step in creating the schedule for the project.   In particular,  it takes the work packages, the lowest level of the work breakdown structure, and identifies the activities needed to produce them.

So one way of thinking of the distinction between work packages and activities is to recognize that work packages are nouns, because they represent what is to be accomplished, and the activities are verbs, because they represent how those work packages are to be produced.

This post will cover the inputs to this process.

6.2.1  Define Activities:  Verbs

6.2.1.1 Project Management Plan

The components of the project management plan that will be inputs to this process are:

• Schedule management plan–this is the knowledge area management plan related to the schedule, and it will contain guidelines for taking the WBS, part of the scope baseline that is an output of the 5.4 Create WBS process, and using it to create the output of this process 6.2 Define Activities, namely, the activity list.
• Scope baseline–one of the baselines for the major constraints of the project (scope, time, and cost).    It is not one document, but three altogether:   the project scope document (which contains the scope broken down from the customer requirements to the deliverables that will fulfill them), and the WBS (the work breakdown structure which further breaks down the scope down to the level of work packages) and WBS dictionary (which contains information about the constraints or other important details associated which each work package).

6.2.1.2  Enterprise Environmental Factors

• Organizational cultures and structure (this will affect which scheduling methodology will be used on the project, for example, and how decisions are made regarding the schedule)
• Published commercial information from commercial databases (this helps create activity lists from work packages which are standard for the industry and type of project you are working on)
• Project management information system (PMIS)–remember, PMI considers the software such as Microsoft Project and to be an enterprise environmental factor because it is something which is created by another company, but the actual data, that is, project documents from previous projects, are part of the organizational process assets (see below)

6.2.1.3 Organizational Process Assets

• Templates, standardized processes, and schedule planning-related policies, procedures, and guidelines (which should be incorporated into the overall Scope Management Plan)
• Lessons learned repository (especially those entries related to lessons learned about how  to create the schedule)
• Historical information (i.e., activity lists from previous similar projects)

With these inputs, it is now time to do the process itself, which is covered in the next post on Tools and Techniques of 6.2 Define Activities.

Filed under: Uncategorized | Leave a comment »

For the Plan Schedule Management, there is only one output, the Schedule Management Plan.    It essentially gives guidelines on how to do the other processes related to schedule management.    I list each possible component as given by the 6th Edition PMBOK® Guide, together with the schedule management process it relates to most closely.

Schedule Management Plan

6.2 Define Activities

• Organizational procedures links–how will the work breakdown structure (WBS) be used to further decompose the project work into the activities needed to produce the work packages specified in the WBS?

6.3 Sequence Activities

• Project schedule model development–the scheduling methodology (for example, Critical Path Method) and the scheduling tool (for example, Microsoft Project) to be used in developing the project schedule model are specified.    When PMI talks about the project schedule model, just think of the project schedule.   The word “model” is added by PMI to make sure you know that it is not written in stone:   it may change if the assumptions that created it change based on newly discovered or recently changed information about the project.

6.4 Estimate Activity Durations

• Level of accuracy–what is the acceptance range used in determining realistic activity duration estimates
• Units of measure–what will be the units of measurement for measuring time (staff hours, or some other unit)

6.5 Develop Schedule

• Release and iteration length–if you are using an adaptive of agile life cycle, you need to specify the time-boxed periods for releases (phases of the project), and iterations of a release:  usually this is a 2 or 4-week cycle, but it needs to be specified and it needs to be consistent.

6.6  Control Schedule

• Project schedule model maintenance–the process used to update the status and record process of the project in the schedule model
• Rules of performance measurement–how will earned value measurement be used to monitor the schedule
• Control thresholds–variance thresholds for monitoring schedule performance, so that some action will be needed to be taken if the performance (based on the rules of performance measurement specified in the previous paragraph) varies beyond a certain threshold
• Reporting formats–in what format, with what frequency, and to whom will reports about the progress on the schedule be made?

With those frameworks and guidelines specified in the Schedule Management Plan, it’s time to start putting together the schedule for the particular project you are working on.  We start with the next process 6.2 Define Activities, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | 2 Comments »