4squareviews

This is it:   the final planning process for the schedule management knowledge area.   The first planning process, 6.1 Plan Schedule Management, has as its goal the creation of the overall Schedule Management Plan, which includes all of the guidelines on how to do all the other schedule management processes, including this one.

The other planning processes before this, namely

• 6.2 Define Activities
• 6.3 Sequence Activities
• 6.4 Estimate Activity Durations

take the inputs of one process, use the tools and techniques of that process, and create outputs, which in turn are used as inputs into the next process, etc.   That is why the list of inputs for this final planning process is so long.

One word before we start:   you will hear the phrase “schedule model” used by PMI in connection with this process.   Although the title of the process is “develop schedule”, PMI likes to use the word “schedule model” to remind project managers and the people who interact with them that a schedule is not written in stone.   When you think of the word model, think of the model-building kits you used to play with when you were younger.  They consisted of building blocks and connectors that you could use to make structures out of those building blocks.   For a schedule model,  it is based on the building blocks of activities, but these are connected together with assumptions, facts that are assumed to be true provisionally in order to determine how these building blocks called activities are put together.  If the assumptions end up changing later on, or new ones get discovered during the planning process, then the connections between the activities may end up changing.    Even the size of the activities in terms of duration estimates may change based on a change in assumptions.   So at any given point, the schedule is a model that may change and so that is why you will see the phrase “schedule model” in the PMBOK® Guide.

Okay with that preliminary set of remarks out of the way, let’s list the inputs to this process.

6.5.1 Develop Schedule:  Inputs

6.5.1.1  Project Management Plan

This is the overall project management plan that is put together in the process appropriate namely 4.2 Develop Project Management Plan.   It has several types of components, including a) knowledge area management plans (like the schedule management plan listed below), b) subsidiary management plans like ones for requirements, change, and configuration, c) project baselines for the major constraints of scope, schedule, and cost (see scope baseline listed below), d) project documents (which are outputs of many processes from different knowledge areas–see long list of project documents below), and e) information on the specific life cycle approach (will the project be broken up into phases?) and the development approach (traditional/waterfall, incremental/iterative, agile/adaptive, or a hybrid of these).

The specific components of the Project Management Plan that are inputs to this process are:

• Schedule Management Plan–created as an output of the appropriately namely process 6.1 Plan Schedule Management, it contains guidelines on how to do all of the other processes of schedule management, including this process 6.5 Develop Schedule.   Some specific information that may be helpful for this process is:
  • the scheduling method used (schedule network analysis, critical path method, resource optimization–all covered in next posts on “tools and techniques” )
  • tool used to create the schedule (e.g., Microsoft Project)
  • how the schedule is to be calculated (specifically what data analysis techniques are to be used–covered in next posts on “tools and techniques”)
  • 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.
• Scope baseline–remember this is actually three documents in one, consisting of
  • the project scope statement (the scope is broken down from the original requirements given in the initiation phase to the level of project deliverables, the tangible or intangible items that will fulfill these requirements)
  • the Work Breakdown Structure or WBS (the scope is further broken down from the level of project deliverables to the more manageable work packages needed to complete them
  • the WBS dictionary (contains information on other constraints that are related to each work package, such as who is assigned to do it, and what the duration estimate and cost estimate are to complete it)

6.5.1.2  Project Documents

The PMBOK® Guide, in true laundry-list fashion, lists the documents in alphabetical order, but I will organize them for you based on what knowledge area and process these documents come from.

Integration Knowledge Area

Output of 4.1 Create Project Charter

• Assumption log–although this is created as an output of develop project charter for any basic assumptions behind the project that are known by the project sponsor, this log is then updated during the schedule planning processes to include any new assumptions that are uncovered during those processes that may affect the schedule (either by affecting the sequence of activities or their duration estimates)

Output of 4.4 Manage Project Knowledge

• Lessons learned–this will be updated in this process to include any lessons learned with regard to developing the schedule model early on in the project to improve its validity in later phases of the project.

Schedule Knowledge Area

Outputs of Process 6.2 Define Activities

• Activity list and activity attributes–the activity list is an output of process 6.2 Define Activities, and the associated list of activity attributes for these activities are updated by
  • adding information on the sequence of activities as an output of 6.3 Sequence Activities, and by
  • adding information on the duration estimates as an output of 6.4 Estimate Activity Durations.
• Milestone List–this takes the general milestones that may be listed during the initiation phase in the project charter, and adds to them during the Define Activities process to include more specific milestones.

Outputs of Process 6..3 Sequence Activities

• Project Schedule Network Diagrams–this contains the logical relationships of predecessor and successor activities in the form of a diagram that looks like a flowchart, with the the logical relationships between activities represented by lines and arrows which connect the activities represented by rectangular boxes called nodes.

Outputs of Process 6.4 Estimate Activity Durations

• Basis of estimates–this document includes
  • Documentation of any known constraints that may influence the estimates
  • Indications of the range of possible estimates, stated in terms such as plus or minus a certain percentage, or in terms of a confidence level of the estimates (i.e., the percentage probability that the actual duration will not exceed the estimate)
  • List of individual project risks influencing the estimates
• Duration of estimates–these are the assessments of the likely number of time periods needed to complete the activities in the activities list.   I say “likely number”, because the estimates may be refined so that they are not single-point estimates, but ranges of possible results.  These ranges may be expressed in terms such as 1 week plus or minus 2 days, for example, or in terms of a confidence interval, that is, an 85% probability of taking only one week.

Resources Knowledge Area

Output of 9.2 Estimate Activity Resources

• Resource requirements–identifies the types and quantities of resources required for each activity used in creating the schedule model.
• Resource calendars–contains information the availability of the resources during the project

Output of 9.3 Acquire Resources

• Project team assignments–specifies which resource is assigned to each activity used in creating the schedule model.

Risk Knowledge Area

Output of 11.2 Identify Risks

• Risk Register–although this is created as an output of 11.2 Identify Risks, it is updated in later risk management planning processes to include details about those identified risks.   It is used to see if there are any identified risks which may affect schedule model, and is important for creating schedule reserves (buffers used to account for both anticipated and unanticipated delays in the project).

6.5.1.3  Agreements

If you have vendors on your project who are doing some of the project work or creating components that will go into the product of the project, agreements need to be specified so that they supply those components or work in a timely manner so that it can be used on the project and not cause any delays in the overall project work.

6.5.1.4 Enterprise Environmental Factors

The factors that can influence this process are:

• Government or industry standards for schedule modeling
• Communication channels within the organization

6.5.1.5 Organizational Process Assets

The factors that can influence this process are:

• Scheduling methodology, including policies governing schedule model development (usually included in the Scope Management Plan)
• Project calendar(s)–these are calendars from other projects, which may affect resources who are working on more than one project

With this long list of inputs from many processes, let’s discuss the overall tool and technique of schedule network analysis in the next post.

 

 

 

Filed under: Uncategorized |