Managing the Project Time – The Official Approach (How It Looks on Paper) (#2 in the series Managing the Project Time)
By Joseph Phillips
In the perfect project-management world, which doesn’t exist, there is a logical, practical approach to calculating how long a project should take to complete. Let’s pretend that we’re living in this perfect project management world and see how things should go.
First we work with the customer to define the product scope—describing the thing that they want us to create. Then we create the project scope—all of the required work and only the required work to create the product scope. And then, boy oh boy, we create the work breakdown structure (WBS).
The WBS is not a list of the activities to complete the project. That’s right. The WBS is a deliverables-oriented decomposition of the project deliverables—not the project work. Once we’ve created the WBS, we can generate a list of the activities that the project team will need to perform to create the identified deliverables.
The activity list should conform to a fun heuristic called the 8/80 rule, which states that the smallest element of the WBS, called the work package, should take no more than 80 hours to create and no less than 8 hours to create. We don’t want the WBS to be so granular that we’re dictating each step to create the deliverable; nor do we want the work package to be so large, as in more than 80 hours large, to leave much of the work open to interpretation. (As with most rules, of course, there are exceptions.)
The activity list should then be arranged in the order in which the activities must or should take place. Many of the activities will rely on hard logic; they must occur in a particular order for the project to be successful. We have to install the operating system before installing the application. Soft logic relies on management discretion. For example, we could create a fancy script to install the operating system and then call a remote server to pull the application and install it on the target machine once the OS has been installed. But we may choose not to do that. It’s preferential logic based on experience, the nature of the work, or your mood on that particular day.
Now the real fun starts. As the expert time-starved project manager, you examine the work sequence and realize that you can actually take several paths to project completion in tandem. So you map out the work visually in a project network diagram (PND), as shown in Figure 2. A PND visualizes the work and allows you to find the critical path. The critical path is not the path with the most important activities; it’s the longest path to reach the project’s conclusion. The critical path reveals the activities that, if late, will cause your project to miss its target completion date. You can find the critical path by simply counting the duration of activities from Day 1 to project completion.
Figure 2: A project network diagram illustrates the project’s path to completion.
But what of the activities that are not on the critical path? These activities have float—the amount of time by which an activity can be delayed or late without affecting the project end date. There are some fancy formulas called the forward and backward pass to calculate the float for each activity.
You don’t have to be a genius to do the math, but it’s easier to just let your project manager information system (such as Microsoft Project) do the calculations for you.
Your critical path can change. Some of your non-critical path activities may be late, additional activities may be added to your project, or the duration of non-critical activities may be revised. Your project may take longer if any of this happens, and you’ll have a new critical path.
Between each set of activities in your PND are relationships that describe how and when successor and paired activities may begin. There are four different relationship types, though chances are that you’ll use only one or two of them:
- Finish-to-start. This most common of relationship types means that the upstream activity must finish before the downstream activity can begin. For example, you must create the disk image before you can push it out to 1,200 machines.
- Start-to-start. This relationship allows two activities to start at the same time, but not necessarily end at the same time. For example, imagine that your organization has a new piece of software that all users will have installed on their desktops. In your project plan, all users must complete a four-hour training session before the application is installed. You create a system that installs software on users’ desktops while they’re in class for the new application. Both activities start at once, but they sure won’t finish at the same time.
- Finish-to-finish. This relationship requires both activities to end at the same time. For example, you’re managing a project to redesign your new web site. To promote the new chic look, your organization will mail a million postcards to current and potential customers. Your project plan requires that the final modifications to your web site and the postcards arriving at your prospects’ offices finish at the same time. Fascinating.
- Start-to-finish. This is the most unusual and least-used relationship of all. It’s special. You’ll find this relationship when you’re using just-in-time scheduling. Basically, the upstream activity must start so the downstream activity can finish. Imagine that you’re a manufacturer of plastic bottles. You don’t have room on your shop floor for an infinite amount of plastics, so you only order plastics when your supply is running low. The depletion of plastics by current activities triggers an order for more plastics so you can create more bottles in the future.
Coupled with each of these relationships you can use lags and leads. A lag is simply waiting time, while a lead is hurry-up time. For example, you’re installing a brand new network in a building. You’d like the cable installation and the installation of the punch panel to happen in tandem. Realistically, however, the punch panel needs a head start on your cable runs, so you add lag time to the cable installers. This plan allows both activities to happen at once, but requires the cable installers to wait a bit until they begin their activity. (Cable installers usually have no problem waiting.)
Sometimes project managers have to hurry things along in a project. This is where lead time comes into play. It allows you to move activities closer to the project start date by subtracting time from each activity’s scheduled start time, as shown in Figure 3. Lag is positive time; lead is negative time.
Figure 3: Move activities closer to the project start date by subtracting time from each activity’s scheduled start time.
Joseph Phillips is the author of five books on project management and is a, PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about Project Management Training, please visit Project Seminars.
