|
Build the Work Plan- Process |
Overview
The section describes the process for building a work plan. The work plan for small projects can be built without a lot of formality. If you have a medium to large project, there are a couple techniques that can be used to build a work plan. The best approach is to utilise a similar project work plan from a prior project as your starting point. If you do not have a prior work plan, the Work Breakdown Structure (WBS) technique can be used. This WBS process is utilized in the following process.
Small Projects
| Usually there is not a formal process used to build a work plan for a small project. The projects are of the size where it is easy to mentally |
lay out the steps that need to be performed and the order the steps need to be performed. There are probably only one or two people involved, so it is not hard to figure out who does what. Regardless of the simplicity of the project, the final work plan should be documented. For a small project, you can use a project management package like MS Project, or you can use a spreadsheet, or a piece of paper. The point is to sit down, with other team members if appropriate, and lay out the work to be performed. This exercise will give you the estimates on effort, cost and cycle time that is needed to complete the Service Request.
Medium and Large Projects
At the smaller end of these projects, there may be an ability to use the same techniques as for the small projects. However, the larger the project, the harder this process becomes. In the techniques section of this step, there is information on how to build work plans from previous projects. For the purpose of this section, the assumption is that you have to build the work plan from scratch. The best way to do this is through the Work Breakdown Structure (WBS). The general process is as follows.
Gather Pre-existing Baseline Documents
Review the Project Definition to ensure an understanding of what is to be produced, the overall timeframe, risks and assumptions, etc. The Project Definition may not be complete, but it needs to be in decent first draft form so that the draft work plan can be built. For a larger project, the Project Definition should also contain the project approach, which provides a high-level description of how the project will be completed. For more information on how to put together the high-level project approach. All of this information should be on hand when you start to put together the Work Breakdown Structure.
Create a Work Breakdown Structure
First determine the large chucks of work that must be completed for the entire project to be completed. At this point, it does not matter how you define the large chucks of work. It is only important that all the work is identified at the end of the process. For instance, a traditional breakdown might be 'planning / analysis / design / construct / test / implement', which lays out the project in a high-level timeline. The breakdown could also be by deliverable - for instance 'online application / data warehouse / data marts / user query tools'. It could also be by some functional breakout such as 'extract data / load data / report on information'. Break down the work into whatever structure makes sense for your project. The initial high-level breakdown of work is called level 1. The point of the Work Breakdown Structure is to capture all the elements of work. Sequencing is not important at this time. It is important to calculate an estimating threshold so that you know how small to break the work down. See Build the Workplan / Estimating Threshold for more information. Also see the section on "How Big Should You Make an Activity?" on Build the Workplan / Work Breakdown Structure.
After you finish your initial breakdown of the work, do a quick estimate to determine whether any of the pieces require a work effort that is larger then the estimating threshold. (Some help on estimating is found at Estimating Process and Estimating Techniques.) If you have a medium to large project, most of the first level of work are still larger that the estimating threshold. Look at these large pieces of work and determine what activities are required to complete them. (This next level breakdown can also apply to work that is already less than the threshold). This gets you to level 2 of the Work Breakdown Structure. When the process is complete, again estimate whether any of the second level activities are greater than the estimating threshold. If so, then they need to be broken down further.
Continue to break down each step as above, until all of the work is represented as granularly as necessary, with no activities having an estimated effort larger than the estimating threshold. This takes you to level 3, 4, 5 etc. It should be a rare case where you would need to break the work down greater then five levels.
You have already done a high-level estimate of effort to determine if the work for each activity is greater than the estimating threshold. When the Work Breakdown Structure is complete, you need to review all the detailed activities and assign initial estimates of effort hours to all of them. (The detailed activities are the ones at the lowest level that are not broken down further.) Again, you can use estimating techniques found in Estimating Process and Estimating Techniques. For instance, you may determine, by expert opinion, that a certain activity is 70 effort hours. Then you can use an analogy technique to determine that other activities that are about the same size will also take 70 hours to complete.
For additional tips and techniques for building a Work Breakdown Structure, see Build the Workplan / Work Breakdown Structure.
Create a Network Diagram
Activities that are further broken down into smaller activities are called summary activities. The first step in converting the Work Breakdown Structure into a network diagram is to look at all the detail activities (not the summary activities) and sequence them in a chronological order. Remember to include all the activities that are not broken down further, regardless of what level they are at in the WBS. In the sequencing process, you determine what work gets done first, second, third, etc. This step is the reason why it does not matter how you structure the initial WBS. As long as you discover all of the work in the WBS, the sequencing of the activities is done now.
When you have a rough sequence established, go through the work again. At this time look for the relationships and dependencies between the activities. Note whether one activity cannot start until another activity is finished. In many cases, two or more activities may need to be completed before another one can start. You identify the work that must be done sequentially, and the work that can be done in parallel with other work. This step is very important and is the key to having a solid workplan to start the project.
If you have not been entering the activities into a project management software tool, you should do so now. (The larger the project, the more critical it is that you use an automated tool to help build the work plan.) Although the activities can be added in any order when entering them into the tool, it is easier to understand if you enter the activities in chronological order. As you enter the activities, you can also enter the dependencies, since these prior dependant activities should have already been entered into the tool. If you do not enter the activities in chronological order, then you will need to put activities in first, and then specify the dependencies after all of the activities are entered. For each activity entered, you should also include the estimated work effort.
Enter any date constraints. Constraints are events that are outside of the control of the project team and must be managed around. For instance, a deliverable may need to be completed before the Board of Directors meeting on a certain date. Or, you may need to place an order with a vendor by a certain date.
Assign Resources
So far you have built the plan without specifying any resources. If you have exactly the resources you need at the right time, the final work plan would look pretty much like it does at this time. Obviously, that is never the case. In this step, you assign resources to the work activities. If you have specific resources allocated to your project, you can assign them directly to the appropriate activities. If you do not have all your resources assigned, this allocation will need to be by a generic type of resource. For instance, if you have three 'programmers' assigned, you may need to assign them to the work plan as 'programmer1', 'programmer2' and 'programmer3'.
If you are using a tool to do the initial scheduling of the project, do so now. Based on the effort hours, resources and constraints, the tool will calculate the overall timeline.
Now check for resource constraints, to see if resources are over-allocated or under-allocated. (If you have a large project and are not using a tool, this will just about be impossible.) What you may find is that a resource may be allocated for 100 hours one week and 20 hours the next week. Smoothing out this workload is called resource levelling. Techniques for levelling resources include:
Scheduling activities sequentially, even though they could be done in parallel if not for resources constraints, For instance, you may have two activities, each estimated at 40 hours, that can be worked on at the same time. However, the same resource is needed to work on both. In this case, one activity needs to be schedule for one week, and then the other activity needs to be done afterward. This will work if both activities are not on the critical path.
Move work from one person who is over-allocated, to another person with similar skills that is under-allocated in the same timeframe.
Look for slack elsewhere in the schedule and push some work there. For instance, an activity may have 5 days duration, but can be completed within a 30 day window. A resource may need to work on many other activities first, but have some available time toward the end of the 30 days. In this case, the more flexible activity can be scheduled later, after other less flexible activities have completed first.
Change the resource mix. If two (or more) people are assigned to an activity, see if one person can be freed up to work on another activity that is resource constrained, even if the first activity now takes longer to complete. Likewise, see if additional resources that are under-allocated can be added to an activity to accelerate its completion and then allow another activity to be started earlier?
Adjust Plan and Add Milestones
After you have estimated the effort for each activity and assigned resources, you can schedule the project and see how long it will take (duration). At this point, you have your first real draft of a work plan. If you have assigned a cost per hour to the resources, you can also see the project costs - at least in terms of labour.
Review the work plan and timeline to see if it makes sense. If it doesn't reflect what you need, make changes and reschedule. For instance, your work plan may show duration of ten months, but you may only have eight months to get it done. At this point, you can look at alternatives such as adding resources, working some overtime, removing some of the work activities, etc.
Determine when key deliverables will be completed and assign milestones to those events. A milestone is an activity with zero duration, and is used to help manage the work at a high-level. If you (or your manager) run a report showing the project milestones, you should be able to quickly tell whether you are on schedule or ahead / behind schedule.
Once the work plan has been completed and the project is approved, save a current copy of the work plan as a baseline version. Later on, when the work plan is being managed, the updated work plan can be compared against this original baseline version to determine variances.
A very early decision needs to be made as to whether you will capture actual effort hours and cost on the work plan. For instance, let’s say you estimated an activity to have 40 hours of effort and ten days duration. It is easy to know when the activity is complete so you can compare estimated duration against actual duration. However, are you going to keep track of whether the effort was actually 40 hours? Capturing actual effort hours requires much more diligence on behalf of the project team to keep track of their time per activity, and report it back accurately. There is a lot of value associated with capturing actual effort hours, including helping make future estimates more accurate, and being able to gather more detailed reports from the project management tool. However, many projects use effort hours to estimate costs and build up the work plan up front, but then they only track activity completion dates once the project begins