• Home
• ABOUT TENSTEP
• OUR PRODUCTS
• Consulting
• TRAINING
• Community
• PM Tool
• TenStep Store

Build the Schedule - Overview (2.0 P1)

The project schedule and budget is created along with the appropriate Project Charter deliverable from Step 1.0. The schedule is a vital tool to ensure that the project team knows what they need to do. Many people are uncomfortable creating a schedule. Usually this is because the project has not been well defined. It is very difficult to create a valid schedule if the project manager is not really sure of what the project will deliver. 

The budget represents the amount of money available to spend on the project. Depending on your organization and how you do your accounting, the budget could contain only the external costs of the project (contractors, hardware, software, material, etc.). Some organizations also include the costs of internal labor in the budget. These organizations typically have some type of chargeback process to allocate the internal costs back to the client or client department.

(The TenStep process does not include the financial work that would be required to justify the project to begin with. This financial work could include determining a simple cost/benefit or more sophisticated Return on Investment (ROI), Internal Rate of Return (IRR), etc. This process for determining the financial justification for a project is covered in the PortfolioStep Portfolio Management Framework (www.PortfolioStep.com).  In the TenStep process, it is assumed that the high-level financial analysis and project justification are already completed and that the project has been initially approved.)   

The Define the Work step ensures you have an agreement with the project sponsor on the work that should be completed. In this step the project manager determines how the work will be completed. Depending on the size of the project, it is possible to use a project management package like MS Project, a spreadsheet or you could even just keep track of the activities in your head.

There are a number of techniques for building a schedule. Perhaps the best option is to utilize a prior schedule from a previous, similar project as your starting point. However, because of the unique nature of projects, that may prove difficult.

A good second choice is to look for a pre-existing schedule template from a project with similar characteristics. For instance, you may be installing a package. Although this is the first time that this particular package has been implemented in your company, you may be able to find a generic template for a package implementation project.

If you do not have a prior historical schedule or a schedule template to use as your starting point, the Work Breakdown Structure (WBS) technique can be used as a starting point. The WBS is a technique for looking at the project at a high level and subsequently breaking the work into smaller and smaller pieces until you can get the full picture of the work that needs to be performed. The entire team can collaborate on this exercise. For the most part, the Work Breakdown Structure technique can always be used as the starting point for creating a schedule from scratch. If you (and others) do not know enough to create a WBS for the project (or at least for the first three months of the project), you probably are not in a position to start the project. In that case, you may want to only define a project for the analysis portion of the project. When the analysis portion is complete, you should have enough information to define the rest of the project. 

Estimating Threshold - Overview (2.1.2.P1)

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time through. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

An appropriate question to ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more), any work that is greater than 80 hours of effort should be broken down into smaller pieces. Medium-sized projects (say 1000 effort hours) should have activities no larger than 40 hours. If the project is small (say 200 hours), you should break down the activities into work no greater than 20 hours. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller then your threshold allows the work to be more manageable. For instance, if your project is 250 hours and you have activities that are 80 hours each, you don’t have enough time to recover if one of the activities is late. However, if the largest activity is 20 hours, you are able to find out much more quickly if work is not being done on time. 

Of course, it is possible that activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. In this case, one approach would be to actually break the work into a couple smaller projects. The second project can be defined more accurately based on the results of the first project.

If you do not have the option of multiple projects, the future work can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work.  

In addition to allowing you to manage the work more effectively, another reason to break down activities into smaller pieces is to make sure that you understand what the work means. When you assign a team member an activity from the schedule, they may not understand what the work is and they may ask you for an explanation. If you don’t know what the work means either, you will be in trouble. So, you should make sure that the work is broken down into a level small enough so that the activities are understandable.  For instance, if an activity that is estimated at 80 hours has never been done before, it may still need to be broken down into smaller activities to ensure that the team member that is assigned the work knows exactly what is expected.

These two factors – the ability to manage the work effectively and to understand the work required - should drive your decision on how small to make your activities. 

Create Detail and Summary Activities (2.1.5.P2)

If you look at a WBS activity and determine that it needs to be broken down to another level, the original activity becomes known as a "summary" level. A summary activity does not have any work or hours specifically associated with it. It represents a logical roll-up of the activities that are under it.

On the other hand “detailed” activities are those that have not been broken down further

Summary activities are broken down into detailed activities. Therefore once the detailed activities under the summary activity are completed, the summary activity is also considered to be completed. If there is more work required, then additional detailed activities must be added under the summary.

Use the Post-It Note Approach for Collaboratively Creating the WBS (2.1.5.P3)

It might surprise you to know the number of people that use Post-it pads and a blank wall to create the first draft of the Work Breakdown Structure. This technique is very easy. You first get the appropriate people into the same room. These are the project team members and clients who have the expertise to build the WBS. Typically you start off by writing the names of the major deliverables on Post-it notes - one deliverable per note. Make sure the attendees agree on the major deliverables to begin with. If any of the deliverables are very large, you can create new Post-it notes that describe the deliverables at a lower level, or individual work products. These are arranged under the higher-level deliverable. The deliverable needs to be identified at a level low enough that you understand what it takes to build it. In general two levels should be enough. One level is typical.

Next, for each deliverable, describe the activities that must take place to complete it. Each activity goes on a separate Post-it note. These activities are arranged under the specific deliverable they refer to. If you have a sense for the order that the activities need to be completed, you can arrange the Post-it notes sequentially. However, this is not important at this point. The important thing is to identify all the work.

Look at the activities that are required to build each deliverable (or work product) and estimate the work associated with each activity. If the effort associated with an activity is larger than your estimating threshold, identify the more detailed activities that make up the higher-level one. Each of these activities is represented by new Post-it notes under the higher-level activity (which now becomes a summary activity). Continue with this process until the work required to complete all of the deliverables is defined, as best you know today. The levels of activities will not be the same for each deliverable. Some simple deliverables may meet the threshold criteria in one or two levels. Others may take three or four, or more levels.

The advantage of this approach is that your team can visually see the work and they can help ensure all the work is identified to complete the project. The Post-it sheets also give you the ability to easily move things around. If you add an activity and then decide to remove it, you just pick up the Post-it sheet. Likewise, if a deliverable or group of activities is in the wrong place, you just move the Post-it notes to where they need to be.

When you are all done, you can enter the summary and detailed work activities into your scheduling tool.

A Common Approach is to Identify Deliverables in the First or Second Level, and Then Identify Activities (2.1.5.P4)

Sometimes people have a hard time getting a WBS started because they are not sure what to put at the very top and they are uncertain about how to break the work down from there. Although there are many ways that the WBS can be started, ultimately you want to focus on deliverables. If you assume that the top level is the overall project (level 0), then the next level can start to describe the main deliverables. After the deliverables are described, the activities can be defined that are required to build the deliverables. The project schedule is ultimately made up of activities, but the activities need to be listed in the context of completing deliverables.

There are a number of options for defining the WBS at level 1 (under the top level 0).

• It might make sense to place the major project deliverables directly at level 1, and break the deliverables into smaller components on the next level, if necessary.

• Another option for level 1 is to describe the organizations that will be involved, such as Sales, Marketing, IT, etc. The next level should describe the deliverables that each organization will produce. 

• A third option is to look at level 1 in terms of the project life cycle; for instance analysis, design, construction, testing. Again, if that is the best logical way to look at level 1, then level 2 should describe the deliverables produced in each life cycle stage.

You see that level 1 can start with deliverables or level 1 can describe another way to logically group major portions of the project. However, if you choose another way to initially organize your thinking of the project, you need to transition immediately from there to deliverables and then move to the activities necessary to build the deliverables.

See 2.1.5.1 WBS Examples for more information.

Use these Additional Techniques to Break Down Summary Activities (2.1.5.P5)

When the team is creating the WBS, there are usually questions about how detailed the detailed work activities should be. The answer determines when to stop breaking the work down into smaller activities. Part of the answer is to utilize an overall estimating threshold, as described in 2.1.2 Build the Schedule and Budget / Estimating Threshold. Other things to take into account include:

• The activity should contain sub-activities that are related and continuous. For instance, if you had an activity called 'Create Testing and Training Strategy', it probably should be broken down further, since the Testing Strategy and Training Strategy are not necessarily related and they are not necessarily continuous. 

• The activity should be able to be completed by one person, or one group of related people. If you have an activity that requires different people for different sub-activities, then it should be further broken down into the sub-activities so that a person or the same group of people can complete the entire activity. Remember that the detailed activities ultimately are carried over to the schedule. You don’t want to have one schedule activity that is assigned to two different groups, or two unrelated people. 

• In general, the work should be broken down to a level that makes sense for the project manager to control. Theoretically, the schedule could be broken down to a point where each activity was one or two hours. Obviously, it does not make sense to break the work down to this level. The assigned team member will not need the work described at that level of detail and the project manager does not need to manage the work at that level.  

Do Not Make the WBS Too Tall (2.1.5.P6)

If you envision the WBS being built with Post-it notes on the wall, it is important that you not let the WBS get too tall (or too deep). Depending on your WBS approach, it may take you one to three levels to get the deliverables defined. The general rule of thumb is that the number of levels for each deliverable should not exceed five and even five might be too many. Smaller projects may not need more than two or three levels of activities for each deliverable. If you have a very large project, the levels might be deeper. However, there is a point where the detail will be too complex to manage. If you find that you are defining down to five or more levels of activities for a deliverable, stop and evaluate what you are doing. First, you may be defining the work at too low a level. Second, you may have defined your deliverable too broadly. In that case, see if a large deliverable can be broken up into smaller, integrated pieces. The work associated with the smaller deliverables should not require so many levels. 

Create a Work Breakdown Structure Dictionary for Large Projects (2.1.5.P8)

Normally a dictionary would not be needed, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. If the WBS is very large, it might make sense to place all of the important information in a data dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. Once the WBS information is entered into a tool, the tool can also help to keep track of changes to the work so that you can trace how the change impacts the WBS and the schedule. Having the WBS in a tool also makes the information easier to reuse for future projects.  

Use Your Summary Activities for Schedule Milestones (2.1.5.P9)

Your WBS contains both detail and summary activities. When you create the network diagram in your schedule, however, you should only include the detailed activities, not the summary ones. For the sake of clarity and readability, it often makes sense to include these higher-level summary activities in the schedule as well to represent a logical roll-up of the detailed activities. A summary activity that represents the completion of a major deliverable could also be included in the schedule as a milestone.

Break Summary Activities into Two or More Detailed Activities (2.1.5.P10)

Since you chose to break a summary activity into smaller activities, it does not make sense to only have one detailed activity under a summary one. If you do, the detailed activity represents the exact same work as the summary activity. This does not buy you anything. If this occurs in your WBS, you either need to:

• Break the summary activity into multiple smaller tasks

• Get rid of the detailed activity and associate the work with the summary - which now becomes a detailed activity

The Detailed Activities Should be Written as Action Oriented Activities (2.1.5.P11)

The detailed activities on your WBS are carried down to be the activities in your schedule. For that reason, it is easier if the detailed activities in your WBS are action oriented – just as activities in your schedule would be. For example instead of stating a detailed WBS activity as “meeting”, you should state it as “schedule a weekly meeting”. Instead of having a WBS detailed activity for “Testing Plan”, you should state it instead as “Create Testing Plan”. In this way, the detailed activities can be moved to the schedule with a minimum of wording changes.  

Do not Place Requirements on the WBS (2.1.5.P12)

The WBS is used to break down larger pieces of work into smaller pieces of work. If you place a deliverable on your WBS, you can break this deliverable down into the activities that are required to create it. You do not break a deliverable down into the requirements that describe it. Requirements do not belong on a WBS.

The detailed activities from your WBS are activities that will be moved to your schedule. This is about what your schedule would look like if it contained things like “needs to have simple interface” or “must be able to work 25 feet below water.” These are requirement statements. Requirements belong in the Requirements Management Plan. They do not work on the schedule or in the WBS. 

You Can Leave Your WBS at the Work Package Level for Large Projects (2.1.5.P13)

Very large projects generally have very large deliverables. One way to build your WBS on these projects is to define your deliverables and then break your deliverables into work components. Work components are simply smaller portions of a large deliverable. When all of the smaller work components are completed and integrated, the larger deliverable is also created.

Sometimes on very large projects it is not practical to determine the summary and detail activities because there are just too many of them. On these very large projects, the WBS may only be broken down to the work component or “work package” level. This work package level may be very large – perhaps big enough to be a sub-project and probably big enough to have a cost account associated with it. 

If you have a large project, you may stop the WBS at the work package level. However, the work should still not be assigned to team members at that level. The work package should be assigned to a team. The team leader should take the work package and break the work down to the activities required to actually build the work component (or to complete the entire scope of work in the work package).

In this scenario, the full WBS is still created down to the detailed level of activities. However, it is done in two parts – the first iteration stops at the high-level work package, and then the detailed activities are defined when the work package is actually assigned to a work team.