Last week, I talked about the importance of being diligent in breaking down engineering work with a WBS. I get kind of fixated on engineering because it’s at the start of any engineered-to-order system or new product development that I typically deal with. I’ve learned (the hard way) that the quality of planning reveals itself in the quality of the work at the beginning of a project, which will typically determine how the project will end. The better the detailed planning up front, the less risk and greater chance your project will succeed.

By the way, if you’ve completed about 20% of your project, you have enough reliable data to predict how your project will finish. So, if you’re late and over budget 20% of the way in, you’re pretty much screwed. Chances are, your project will finish late and over budget. This is the reason I tend to focus a lot on planning the up-front work in great detail (not just engineering work, all work, but for this post I’m talking about engineering work).

Tip #4: To reduce the risk of your schedule, assign resources to activities.

Just like with the WBS tip last week, this sounds like a no-brainer. But I’ve rarely seen it done (again, my frame of reference being projects related to drilling equipment). In general, there are three ways to prepare a schedule. Note that as the accuracy increases, the level of effort required to create your schedule also increases:

  • Way 1: the schedule is created with activities, dependencies and durations only. This is the least accurate way to model your project, but the most common (probably because it requires the least amount of work).
  • Way 2: in addition to Way 1, resources are “loaded” (assigned) and deconflicted, increasing schedule accuracy.
  • Way 3: in addition to Way 2, costs are assigned and you end up with a time-phased project budget.

Depending on what you’re trying to achieve, you could have valid reasons for going with Way 1 versus Way 2 or 3. I typically strive for Way 3 most of the time.

Continuing with the example from last week, Figure 1 shows we’re trying to use Way 2 and “Engineering” has been assigned as the resource for all engineering activities, which is only marginally better than if you showed no resource at all:

Figure 1: “Engineering” is assigned as the resource … not very helpful

So, it probably isn’t helpful except if you were going to assign an hourly rate to “Engineering” in order to get the overall cost of the engineering effort for budgeting purposes. But this doesn’t really help from an execution or accuracy standpoint because you don’t know who is doing the actual work, whether or not your assumptions about the activity dependencies are any good, or whether or not they need to be deconflicted. Here is the schedule again, but with names assigned in Figure 2:

Figure 2: Resources assigned by name, notice Dale and Joe are over-booked on the 14th and 17th, respectively

Notice that Dale has to do two days of work on the 14th and Joe has the same problem on the 17th. Uh oh. See how you start to understand more about your project as you put more detail into your model? If you didn’t assign resources by name, you likely wouldn’t know that you were predestined to be at least 2 days late on your project. At this point, you might chose one of two options: assign additional resources to still finish engineering on the 23rd as planned, or change the dependencies such that Dale and Joe aren’t double-booked, which would move engineering’s finish date out by two more days.

Yes, this is elementary project management stuff. But it’s the fundamentals (like creating a WBS or adding resource names to activities) that I find are frequently trivialized and foresaken.

Next week I’ll talk about assessing a schedule for costs.