Add Work to Shorten Your Schedule

  1. Posted on April 30, 2010 8:46:AM by Earl Beede to Practicing Earl
  2. Technique, humor, estimation, risk, schedule, Management

I love this one; blows the mind of many a project manager: if you add select items to your work plan, you can shorten the project schedule. Absurd you say? You may be right, let’s take a deeper look.

Any good development planning should start out with the high level details of only the work needed to get the release out. Let’s call this the Work I Gotta Do (WIGD) plan. I will represent the WIGD plan below.


Ok, so now if I add items, say, the things I think I should do because somebody said they were an important part of development (we will call this the Important Stuff or IS), what does my plan look like now? It probably looks something like this.


You take this plan to the leadership. What are they going to say? If they are reasonably intelligent, they will say something like, “Gosh, the Important Stuff is important, but we don’t have time for that so take it off.” This puts us back to our starting point.


Adding work in this scenario does NOT decrease your schedule but increases it. Not a lot of help, thank you very much.

But what is really happening on the project? Well, bad things actually. Not bad like somebody just shot the product owner in the alleyway behind the office while muttering something about “Gigi.” But bad things like missing requirements, not having enough common understanding of the design approach, or the ongoing disagreement about the proper role and use of the configuration management tools.

Risk management has a process to quantify all those little bad things that add up on a project. I don’t want to go into all the details about how risk management works but to sum it up, risk management can put a number to all those little bad things that happen on every project and is happening on your project right now. They call this quantification the Risk Exposure or RE.

So, how much RE (remember, that is Risk Exposure for those who suffer from really bad short term memory loss) can we expect on a project who has planned the Work I Gotta Do without the Important Stuff? Just a little? Maybe a 10% or 20% hit, just the amount we put into our buffer?

Researchers have researched this and the number is bigger. At Construx, we have also investigated this with our clients and our findings echo what the researchers’ research revealed. It is a really big number. A number in the 150%+ range. A big scary number.

So our project has two components. A plan Work I Gotta Do which is sitting pretty in a project planning tool and Risk Exposure which is NOT planned and NOT accounted for in all the schedules and promises you made to other people. Add the two together and you get the likely duration of the project.


In a technical project management term: that sucks.

In fact, the reality is that the WIGD plan by itself was pure fantasy as a timeline. The real timeline is always WIGD + RE. It is just that we don’t put RE in our plans. RE is unplanned work.

So what is going to happen to this project that has such a large RE? You promised it in the time defined just by the WIGD plan and the project is taking a heck of a lot longer. Since you are probably living this project right now, what do you do?

We do what we almost always do in this situation. We slide the schedule and cut quality. (BTW, by cut quality I really mean sacrificing non-functional requirements that people are not paying attention to which I talk about in another blog post.) We may even cut out some of the features we already started building.

And we act really, really surprised that our wonderful WIGD plan didn’t work out.

At the project debrief we again list the Important Stuff we should have done and will cut out of the next project plan because we don’t have time.

Here is the rub, what if the Important Stuff that we cut out directly attacks the RE? Important Stuff, by definition, is only important because it directly mitigates the risk on the project. If it didn’t mitigate risks, it wouldn’t be important.

Here is what our project looks like if we do the important stuff.


Now here is the weird part. By adding planed items (the IS) to the base work necessary (WIGD) the realistic timeline of the project is dramatically cut down by mitigating a lot of the risk (RE). By adding items to the plan, we make the timeline shorter.


I love watching the brains start to smoke as they figure this one out. To make a project timeline shorter, I need to add select items to the project plan whose sole purpose is to mitigate risks.

Sure, I can come up with any fantasy timeline I like. “The entire platform replacement and 32 system consolidation project will take 18 seconds because that sounds good to me.” But if I want to be realistic, I have to remember RE. And if I want the shortest realistic timeline, I need to do something to keep the RE small.

And no, we DON’T wait for that bridge until we cross it. By that time our ability to reduce the RE is very limited and likely not to derive much time savings. We will be back to our fantasy plans.

So here is the realistic choice. Do you want to go with just the WIGD plan which will take WIGD plus all that unplanned rework or do you want to go with the WIDG+IS plan which will take far less time?

You have got to add work to get shorter schedules.

Twitter Trackbacks for Add Work to said:

May 2, 2010 1:42:AM

Pingback from  Twitter Trackbacks for                 Add Work to Shorten Your Schedule - Practicing Earl         []        on

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl