In last week’s schedule assessment tip, I talked about identifying and being wary of any activities that were longer than a week in duration. This week I’m going to address how I assess engineering work in a schedule. Again, my context is primarily drilling equipment.
TIP #2, Engineering work needs to be scheduled in detail, and to do that, you must first build a WBS.
This sounds like a no-brainer, but I’m amazed at how seldom this actually happens. Many project schedules that have engineering (and design) look something like this:
Figure 1: What is supposed to happen during these 6 weeks of engineering?
Yes, the whole schedule is crap, but our focus is engineering. Note that the engineering activity is a nebulous effort longer than a week and over half of the project’s duration. This should immediately put you on high alert. What’s going to happen during these 6 weeks? Who is doing the work and when? What was the 6-week duration based on? The 2-week procurement suggests off-the-shelf parts, but is this true? You have no way of knowing the answers to these questions unless you first break down the work—a process that will help reveal the assumptions that went into the 6-week estimate.
Let’s assume we fully understand the project’s scope of work. There are different ways to break down engineering work, but I typically prefer to break out the system elements from the equipment elements, like this:
Figure 2: Break down engineering work
In this example, we’re turn-keying a test unit for a test cell and are not responsible for the system engineering work (the integrator who is buying our test unit is responsible). But notice I have a system engineering element anyway. I always include a system engineering element on any WBS I’m working on that requires engineering work. Why? Because it’s a great memory jogger and it invariably leads to the engineers identifying something that somebody (it can be engineering, client, third party, vendor, end user, operations, etc.) overlooked. I didn’t make this stuff up: I’ve been paying attention to what Frank has spent much of his time on over the years—troubleshooting interface problems at the systems level. Which leads me to the next schedule assessment tip:
TIP #3, Whatever you’re engineering, it interfaces to something, so account for those interfaces in the WBS.
Breaking down the engineering scope of work can be quite a challenge. I’ve never been able to capture 100% of it up front. Probably because most engineering work I’ve dealt with contains some element of new product development. You don’t always know what you don’t know at the beginning of a new product’s lifecycle. But you can get close by starting with a detailed WBS before messing around with any scheduling software. Notice that with the WBS, all we’ve done is break down the engineering work to a manageable level. Next, you’d identify the detailed activities necessary to complete the work, which you’d likely do in your scheduling software (MS Project, Primavera, etc.).
Regarding WBS software, I highly recommend using WBS Schedule Pro. I’ve also had success with XMind. I’ve exported both into MS Project. A pile of Sharpies and Post Its and a large white board works well too.
Next week I’ll talk about assessing a schedule’s resources.
