Managing The Project Time

By Joseph Phillips | minute read

Though we all have the same amount of time, it just seems to slip by me faster than it does other people. It's not that I'm lounging around smoking cigars, playing poker all night, and ignoring my work (okay, not usually). It's that I take on much more than I should and everyone suffers. And the projects that I take on magically grow from cute, innocent endeavours into eight-armed monsters that crush my schedule over and over.

Project managers know, or should know, the iron triangle of project management sometimes called the triple constraints of project management because all projects are constrained by these three elements: time, cost, and scope. My nemesis is the angle on the left, time.

Any project, from developing a new piece of software to building a new house, takes some amount of time. The relationships between the scope of the project, time, and cost should balance. If there's not enough time or budget, the project is doomed. (No kidding).

The real problem? Planning. Delegation. And learning to say no. First, we must define the product scope: the verifiable, tangible deliverables that make the customer happy (or happier, depending on the customer). Once all agree on the product scope, then it's on to the project scope, all of the work and only the work to create the project deliverable. The product scope and the project scope are dependent on one another; if you change a detail in the product scope gosh, the project scope will change, too. And these changes take time.

Now, sometimes I'm late and it just ain't my fault. (Come on, I did say "sometimes"). For example, I was working on a project for a company that couldn't decide exactly what they wanted. It was like one of my usual dates: I don't know what I want, but this isn't it. We'd go round and round through feasibility studies, new versions of the training manual, class development, and more frustration, then they wanted to know whether I could still hit the target deadline for project completion. My mental response? Yes, just as soon as I get back from my bike ride to Hawaii.

On any given day the phone rings, email chimes, or the fax spits out some new request, and without thinking we say yes. That failure to think is killing us. A little change here, an addition there, and four or five new projects coming in; time disappears faster than a plate of donuts at a Weight Watcher's meeting.

But this isn't an article on how to whine. We're all crushed for time; some of us just manage it better than others. When it comes to project management, I know that the time management discipline is my Achilles' heel. In the past, I would gladly take on the work without thinking, planning, and delegating. But I'm getting better about it, I told someone no last week. It was sad and disappointing, but I can't let things pile up anymore and current commitments slip by.

The Official Approach (How It Looks on Paper)

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 realise 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). A PND visualises 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.

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 maths, 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:

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. Lag is positive time; lead is negative time.

Estimating Project Duration

The estimated project duration is based on the sum of the activities. With some maths magic, we can predict the best, worst, and most likely scenario for how long each activity will take, and ultimately how long before we put this beast to bed and move on to the next.

To create an estimate that's accurate or close to accurate, it's really more than just adding up the activity durations. We also have to consider several factors that could wreck the schedule, drive managers nuts, and cause our hair to fall out:

Time Management and the Crystal Ball

How do we ever know how long any given activity will take? For some activities, you can rely on experience. Other activities have to rely on expert judgment, historical information, and approximation. Approximation?! Yep. Consider any IT project you've ever managed, worked on, or heard about. Each IT project is subject to the first-time, first-use penalty. Just about every IT project is unique. Even if it's an integrator installing the same old piece of software over and over in different environments, there are unique aspects to each environment. No two IT environments are identical. Even if it comes down to the humidity in the air, the ghosts in the machines, or the users who will crunch and crank on the software, there are always differences.

These subtle and sometimes not-so-subtle differences can drive us crazy, or inspire us to take up professional roller hockey. These unique configurations also confound best efforts to predict how long an activity will take to complete. Sometimes you think you know and other times you know that you don't know.

And now a word from reality: That's why estimates are called estimates. Management and customers don't seem to get this part, do they? Have you ever given an ad-hoc estimate where you pulled a duration estimate out of the sky? This is a Rough Order of Magnitude (ROM) estimate; a simple, ballpark guess that management and customers are certain to hold you to. No fun for you, just them. I encourage you to not give any ballpark estimates. If you must, add an asterisk to your verbal quote, indicating that this is an ROM estimate and that it can be way, way off from 75% up to 125%. Otherwise, you're stuck with the number you throw out there. Should your actuals be different from the ROM, you've heck to pay. Right?

Time To Wrap This Up

If time management were easy, everyone would do it. The biggest input to effective time management is effective planning. As project managers, we must have control over our project schedules, which requires a constant eye on activity duration estimates; actual time committed to activities; and expert judgment, guts, and experience to make refinements to our schedule when appropriate. Of course, it's never fun when a project manager replaces a bad date with another bad date.

We all have the same amount of time. The only thing we really control is what we do with it.

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 Instructing.com