4squareviews

This post will cover the outputs of the process 6.4 Estimate Activity Durations.

6.4.3 Estimate Activity Durations:  Outputs

6.4.3.1 Duration 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.

6.4.3.2  Basis of Estimates

When going to single-point estimates to the more refined three-point estimates, you make assumptions to take the most likely estimates and come up with the pessimistic and optimistic versions of those estimates.   These assumptions may come from the assumption log given as an input to this process, or they may be developed during the process itself.    In addition to the assumptions made to form the estimates (which are listed in the assumption log–see “Project Documents Updates” section below), additional supporting details for the duration estimates may include the following:

• 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

6.4.3.3 Project Documents Updates

• Activity attributes–this gives details regarding the activities in the activities list.  Based on the results of this process, the activity duration estimates are added to the list of activity attributes for each activity.
• Assumption log–any assumptions developed during the course of this estimate process are added to the assumption log
• Lessons learned register–any techniques that were shown to be efficient and effective in developing the activity duration estimates are added to the lessons learned register.

All of these outputs are added to the growing list of inputs to the next process, the final planning process for schedule management, process 6.5 Develop Schedule.   This process will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

In the last part of this two-part post, I went over the tools and techniques for this process 6.4 Estimate Activity Durations which I call generic, because they are used for any complex planning process, and not just the ones for schedule management.   These are

• Expert judgment
• Decision Making
• Meetings

In this post, I will cover the tools and techniques that are used specifically for this particular process 6.4 Estimating Activity Durations, namely:

• Analogous estimating
• Parametric estimating
• Three-point estimating
• Bottom-up estimating
• Data analysis (alternatives analysis, reserve analysis)

Let’s discuss these tools and techniques (the numbering is based on the categories in the PMBOK guide, so there will be a little skipping of  numbers–this is intentional and it means that the missing categories are the ones covered in the last post on the “generic” tools and techniques for this process).

6.4.2  Estimate Activity Durations:   Tools and Techniques

6.4.2.2  Analogous Estimating

6.4.2.3  Parametric Estimating

I am going to discuss these two techniques together because they are both examples of top-down estimating techniques, that is, estimates based on the total cost of previous, similar projects.   They both require historical information on similar projects in order to work.

Let’s illustrate these techniques with an example.   Suppose I work for a construction company, and we bid for a project to build a new home in an already existing subdivision.   How do we estimate the amount of time it will take to complete the home?  Well, one quick way is to see how long it took our company, or perhaps another company or comparable size, to complete a similar home in the subdivision.    If it took then 90 days to build it, we can use the analogous estimating technique to calculate that 90 days is a good rough estimate for our project as well.

However, say there are no homes that are comparable to the one we are doing in size.   Maybe there are small and medium-sized homes, but not one that is as large as the one we want to build.   In that case, a more nuanced estimating technique called parametric estimating can be used.    If you have data on how long it took to build homes of various sizes in the same subdivision, and you have how large these houses were in terms of square feet of floor space, then you can calculate a parameter or unit measurement which estimates how long it takes per square foot of floor space.

If the average home in our subdivision has 2,700 square feet of floor space, and we assume it takes 90 days to build it, then it takes 1 day per 2,700/90 = 30 square feet of floor space to complete an average home.    If our project is to build a house that is larger, say, 3,000 square feet, we can make a rough estimate that it will take 3,000 square feet x (1 day/30 square feet) = 100 days to complete the home.

This is a rough estimate, and it is based on assumptions such as

• the other homes being built are comparable in terms of floor plan
• the building materials being used are similar
• the experience level of the companies that did the other houses is comparable to that of our company

So the advantage of these techniques is that they are quick, but the disadvantage is that they are rough estimates are therefore not as accurate as a bottom-up estimating technique (see paragraph 6.4.2.5 below).

6.6.2.5  Bottom-Up Estimating

This is when you estimate the duration of each activity on the activity list, and then aggregate the estimates for the differing level of components in the Work Breakdown Structure or WBS.   First you sum up the durations of each activity for each work package, then you sum up the subtotals for each work package, rolling up the levels of the WBS until you get the total estimate for the entire project.

The advantage of this technique is that it is accurate, but the disadvantage is that it is time-consuming.    It is the exact inverse of the advantages and disadvantages of top-down estimating techniques (discussed above in paragraphs 6.6.2.2 Analogous Estimating and 6.6.2.3 Parametric Estimating).

6.6.2.4  Three-Point Estimating

I am putting this below the bottom-up estimating technique because that is where you start, with a single-point duration estimate for each activity that is made in the bottom-up estimating technique listed above.

You further refine this one-point estimate with the three-point estimates listed below:

• Most likely (M)–this is based on the duration of the activity, usually the one found in the bottom-up estimating technique, based on the assumptions that will most likely occur such as:
  • the resources likely to be assigned to the activity
  • the productivity of these resources when performing the activity
  • the realistic expectations for the availability of these resources for the activity
  • the dependencies of the resources on the other participants in the project team, etc.
• Optimistic (O) –this is based on the best-case scenario for the activity
• Pessimistic (P)–this is based on the worst-case scenario for the activity

The expected duration can be calculated with one of the following formulas:

1.  Triangular distribution

E = (O + M + P)/ 3

in other words, the simple average of the three-point estimates.    This is done when there is not a lot of historical data regarding the activity.

If there is historical data regarding the activity, and you have more confidence in the “most likely” estimate, you can statistically give it more weight by using what is called a “beta estimate” (I remember this by thinking of it as a “betta” estimate than the triangular one).

E = (O + 4M + P)/ 6

In this case, you divide by 6 inside of by three because in essence you have copied the “most likely” estimate of M 4 times, and so you have a total of six terms to take the average of rather than just three terms that you have with a normal average.

Let’s see how this works with an example.

Okay, let’s say you move to a new house, and your boss asks you how long it will take you to get to work from your new place.   On a typical work day, you see the estimate of the time you leave your house to the time you get to your work place to be 30 minutes.   Not bad!    However, that is the “most likely” estimate, if traffic is normal and you only have to deal with “rush-hour” traffic.

What would be the “optimistic” and “pessimistic” estimates for getting to work.   In the optimistic or “best-case scenario”, there would be very little traffic.   This can happen if you are coming to work on a holiday or maybe even on a Saturday, when there is no “rush-hour” traffic to deal with.   Let’s say it only takes 20 minutes to get to work in that case.

How about the pessimistic or “worst-case scenario”?   That might be if there is a traffic accident which causes traffic congestion that is worse than the normal “rush-hour” traffic.   In that case, say it takes 60 minutes to get to work.

What is the three-point estimate of how long it will take to work?    If you are new to your new route to work, and don’t have a lot of historical data to compare it with, then you might want to go with a regular triangular estimate:

E = (O + M + P)/3 = (20 + 30 + 60)/3 = 40 minutes.

If you tell your boss it an estimate of 40 minutes, then since it most likely will take you 30 minutes, you will always make it to work on time if you leave 40 minutes before you are scheduled to work UNLESS you face the pessimistic scenario of an accident on the freeway or highway you are taking to work.

Let’s say you get some more confidence in your route to work, and you have never seen an accident yet on the road to work, so you can now use the beta or weighted average to calculate your time to work.   Now

E = (O + 4M + P)/3 = (20 + 4 X 30 + 60)/6 = 33.3 minutes.

If you give your boss an estimate of 33.3 minutes, then you now can tell yourself to leave 3.3 extra minutes rather than 10 and still be reasonably confident that you can make it to work on time.

That’s how three-point estimating works.   It takes the single-point estimates found in bottom-up estimating and creates an estimate that is robust, that is, will work under most scenarios but perhaps the most pessimistic.

6.4.3.6  Data Analysis

The techniques used to analyze the duration estimates of activities are:

• Alternatives analysis–this is an analysis of the assumptions behind the various options you have for doing an activity.   These assumptions come into play a lot when doing the three-point estimates described above.
• Reserve analysis–this has to do with determining contingency and management reserves needed for the project.   Contingency reserves are those that can be used by a project manager, and management reserves are those that need approval of management (such as a project sponsor).

Let’s take the example we talked about before.   It takes 30 minutes according to your GPS for you to get to work.   The three-point estimate shows that, in order to account for the possibility of some unforeseen circumstance that might cause you to take more time, a better estimate is 33.3 minutes.   This extra 3.3 minutes could be considered a contingency reserve which would allow you enough extra time if there was some sort of slowdown on the highway that caused you to take more time than you normally would (i.e., 30 minutes).   This is a reserve that you control yourself and it helps you get to work on time in most cases.

However, if there was some sort of traffic emergency on the road, you might have to call in to your boss and tell him or her that you might not make it by the time work starts.   The boss will usually say “okay” given the nature of the emergency, and this is like a management reserve which allows you to take the extra time you would need provided that is is an emergency.    “Hey, boss, sorry I forgot to set the alarm clock” would not be considered sufficient circumstances to allow you a “management reserve” of extra time in this case.

There will be more on these estimating techniques when we turn to the next knowledge area of schedule management.

With this discussion of tools and techniques for schedule management being concluded, let’s now turn in our next post to the outputs of this process.

Filed under: Uncategorized | Leave a comment »

As we go through the planning processes for scheduling, we see that each one gets more complex than the previous one, mainly because they are building on the results or the outputs from the previous process, but also because the process itself is more complex.   Sequencing the activities is more complicated than just creating a list of those activities, and estimating the duration of the activities is even more complex.   The final planning process, process 6.5 Develop Schedule, where you put the result of all the previous planning processes together to create the schedule, is the most complex.

For that reason, I am going to take a discussion of the tools and techniques for this process and split it into two parts:   the first part (this post today) covering what I call the generic planning tools and techniques, that is, tools and techniques that would be used for any planning process of this complexity, namely:    expert judgment, decision making, and meetings.

Then, in the next post, I will cover the tools and techniques that are used specifically for this particular process 6.4 Estimating Activity Durations, namely:

• Analogous estimating
• Parametric estimating
• Three-point estimating
• Bottom-up estimating
• Data analysis (alternatives analysis, reserve analysis)

Let’s quickly go through the “generic” tools and techniques for this process (the numbering is based on the categories in the PMBOK guide, so there will be a little skipping of  numbers–this is intentional and it means that the missing categories are to be covered in the next post).

6.4.2  Estimate Activity Durations

6.4.2.1  Expert judgement

There are three types of experts you may want to consider inviting to your meetings (see category below) to help estimate the activity durations on your project.   You should try to get experts with expertise in

• general schedule development, management, and control
• specific expertise in estimating
• experience with other previous, similar projects

6.4.2.7 Decision Making

Voting of course is one way of making a decision if there are alternatives available for any given activity duration estimate.   Remember, there are different types of voting, such as voting with a majority, a plurality, and other techniques used in agile approaches.   I will cover the agile approaches to schedule planning in a separate post (to be done after I cover all the schedule planning processes.

6.4.2.8 Meetings

Any time you have a group decision, it is important to have face-to-face meetings or virtual meetings as the next best alternative.    There are special rules for meetings in an agile approach, to schedule planning and again, this will be covered in a separate post after I cover all the five tools and techniques listed above.

The next post will cover all of the special tools and techniques for this process that are listed above.

Filed under: Uncategorized | Leave a comment »

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.

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 »