Len DiMaggio's (mostly) Software Testing Weblog: 2012

We create schedules for many different things but generally for the same reasons - to enable us to determine when in the future a task will be completed, to enable us to allocate time and money and resources to perform that task, and to enable other organizations to coordinate their future actions.

In other words, we create schedules in an attempt to predict the future.

But, why do we get it wrong so often?

Why is it that, in spite of how precisely we plan our tasks and try to take into account what might go wrong, so many project schedules miss their original target completion date?

Why did Boston's famous "Big Dig" road and tunnel construction project (http://en.m.wikipedia.org/wiki/Big_Dig_(Boston,_Massachusetts)) slip from being a $3 billion project to a $15 billion project?

Part of the reason may be simply that it is a difficult task to create a schedule that can accurately predict the future. Another part of the reason may be that people, as Frederick Brooks observed in "The Mythical Man-Month," (http://en.wikipedia.org/wiki/The_Mythical_Man-Month) are eternal optimists. We always think that "this time" things will go well, and we won't have any schedule-related problems. As a result, we fail to plan for everything that may possibly "go wrong."

But, there may be another reason. Maybe we cause our own imprecision by trying to be too precise. In other words, maybe we set ourselves up for failure and make schedule "slips" a self-fulfilling prophecy.

Which leads me to a golf story. An historical golf story, that is.

When he was asked to explain his surprising lack of success when he tried to play competitive golf a few years after his retirement at the early age 28, golf great Bobby Jones attributed it to his misguided attempt to achieve a level of precision and consistency greater than he had ever had during his best playing years. Who was Bobby Jones? The Tiger Woods of his era - back when gofers wore ties.

Maybe it's a bit like that with scheduling. Do we doom ourselves to always creating schedules that are missed by trying to achieve a target that is so precise that it can never actually be hit?

I've been thinking lately that a better approach for scheduling a large, long running, and complex project schedule is to not attempt to target a single "hard" and unchanging target completion date (for example, "our project will be completed on May 23rd at 09:00, Eastern Daylight Time"), but rather but rather to target a window of time in which the project will be completed, "slide" that window closer or further away and have it expand and contract based upon your level of confidence according to the current conditions of the project, all in the context of the the current project conditions.

This window can be thought of as the "sliding window of doubt."

OK, this idea of a "sliding window of doubt" raises a couple of questions:

What are the potential advantages of a sliding window approach?

One of the best aspects the sliding window approach is that it of scheduling a project schedule with a sliding window is that it converts the reassessment of the schedule from a reactive to a proactive task. Reassessing the schedule, and possibly sliding the project completion window is not an aberration or exception, that is only done as a reaction to a problem. Instead, it is a ongoing part of the management of the project. These re-assessments will become increasingly more accurate estimate as the project proceeds as the more you learn about the problems that a project faces during its development the better you can predict its future. As a result, you will have more accurate estimates (the window only shrinks when your confidence in the project's ability to meet its schedule increases) based on the re-assessments, and the project team will have constant access to up-to-date schedule information.

Another advantage of the sliding window approach is the flexibility that it provides the project team. The "consumers" of the schedule include the project team members themselves as well as the consumers (other project teams or end user customers) of the project deliverables, as these consumers must create their own schedules, for their own deliverables, all of which depend on your project and its schedule. With a rigid, single-date based schedule, even small changes can effect that date, and cause disruption (or maybe even panic) to dependent project and customer schedules.

Also, by building into the project plan the ability to slide the release window,people who might otherwise delay in providing bad news that would affect the schedule, out of fear of a "shoot the messenger" situation, may be more inclined to make that news available to the team sooner.

How is a "sliding" window any different from defining a more convention schedule, and then "slipping" the target dates?

The difference really comes down to what controls the schedule changes.

As we discussed just a moment ago, the constant reassessment of the schedule, where the level of doubt is re-evaluated based on the current project conditions, is a proactive task. Your project team is in more control of its fate with the sliding window approach. Also, remember that these re-assessments are not only performed when there are problems to be resolved, they are also performed when things are going well. Accordingly, while the window can slide out in response to unexpected problems, it can also move in if the project is progressing better than the original plan.

So, to sum up, when you are faced with the challenge of devising a schedule for a large, complex, long-running project, it's worthwhile to consider the "sliding window of doubt" as an approach to scheduling key milestones and release dates. At its core, this approach provides you with the flexibility to refine the schedule over time, and perform proactive schedule reassessments, that will result in the window sliding closer or further away, and expanding or contracting, all based the most up-to-date information available.

We started this discussion by asking - "Why does every project miss its target milestones and completion dates?"

Maybe the the real question that we should ask ourselves is: Why does every project schedule seem to miss its target completion date?

If the dates were rigidly defined, and the project team never re-assessed those dates as the project proceeded and unanticipated problems were encountered, then the dates were probably never achievable in the first place. What the project needed was a sliding window of doubt!

Postscript - the presence of doubt or the absence of confidence?

It's interesting how your occupation can color your view of the world. If you work in engineering (and especially if you work in software testing) you tend to look for the negative side of things. In other words, you look for what might go wrong. People engaged in sales or marketing tend to have a rosier view of things. For example, when I described the sliding window of doubt to a marketing person, she replied:

"Oh, you mean the sliding window of confidence!"

I guess she was correct, as confidence is the inverse of doubt!

(Special thanks to John Graham (http://osmusings.blogspot.com/) for his inspiration for this post.)

Len DiMaggio's (mostly) Software Testing Weblog

Tuesday, July 31, 2012

Brno!

Friday, June 22, 2012

JBoss' SwitchYard - for the impatient newbie user

Sunday, April 22, 2012

Sharing Photographs - with an Open Source Flavor

Wednesday, January 25, 2012

On Kindle too!

The JBossESB Book is officially published!

Thursday, January 19, 2012

Embracing the Sliding Window of Doubt