Some Perils of Reverse Scheduling

Reverse scheduling is a common pattern that typically occurs in the course of negotiations between a project manager and the project's sponsor. The sponsor has a definite delivery date in mind, and naturally, prefers a low construction cost with minimum usage of precious resources. The pattern can emerge in a form such as this:

Sponsor: I need it by October 30.

Project manager: Then there isn't much time. I'll see what we can do.

Sponsor: Just bring me a schedule that gets it done by October 30. Work backwards from October 30 so we can see what we need to have and by when we need to have it.

At this point, the project manager convenes the leaders of the project team to explain the charge from the sponsor. They work out how they'll examine the problem, and that usually involves some project management software. There are some well-known traps associated with using conventional project management scheduling software to perform reverse scheduling. But this post is not about those traps.

Rather, in this post I explore the psychological traps associated with the whole idea of reverse scheduling. These traps cause the greater part of the trouble that results when the organization commits itself to unattainable objectives. And it is these traps that cause the people involved to believe that they are undertaking a project that they can actually complete successfully, when in fact, often, they cannot.

In what follows, I'll use the name Marguerite (M) to refer to the Project Manager (M), and the name Sean (S) to refer to the Project Sponsor (S).

Trying to design a project approach to deliver a result by a given date, working backwards from that date, exposes the project manager and the team to many risks, two of which lead planners to falsely assume that a workable schedule is even possible.

The false presumption of possibility

Believing There are psychological traps associated with
reverse scheduling that cause organizations
to commit to unattainable objectivesin the existence of a solution to the project-planning problem can be helpful in devising a workable plan. But believing doesn't make it so. The so-called "iron triangle of project management" is a metaphor that expresses the idea that we are not free to choose independently the attributes of a project and the product it creates. The attributes in question here are usually cited — rather tersely — as "scope, cost, schedule, and quality."

But the price of terseness is ambiguity, and in this instance ambiguity makes for some difficulty in understanding the applicability of the iron triangle metaphor. So let me take a moment to reduce the ambiguity. Scope refers to the capabilities of the project deliverables. In this context, a highly capable deliverable is good. Cost refers to the budget of the project. A low budget is good. Schedule refers to the delivery date of the project. An early date is good. And Quality refers to attributes of the deliverable, including ease of use, reliability, maintainability, and more. (Some include the quality of life of the project team in the definition of quality) In the iron triangle metaphor, the three sides of the triangle are scope, cost, and schedule. The angles between the sides (and/or in some formulations, the area of the triangle) represent the various quality attributes.

If we were designing a triangle, we would be free to choose, for example, the lengths of two of the sides and the angle between them. Having chosen them, the length of the third side is determined. There are other combinations that also work. You might recall from plane geometry that for triangles, we are free to choose side-side-side, side-angle-side, angle-side-angle, or angle-angle-side (see MathIsFun.com).

So, for example, in designing a project, how we constrain scope, schedule, and quality, can affect cost. Or we can choose all three of scope, cost, and schedule, but then quality is determined. And so on. This metaphor, like all metaphors, isn't precise. It communicates the idea that the four attributes of scope, cost, schedule, and quality are interrelated. We are not free to set them arbitrarily.

In the reverse scheduling scenario, Sean has specified scope and schedule explicitly. He hasn't said anything aloud about cost or quality, but for typical projects, every project manager knows that there are constraints on both cost and quality. And so there is a strong possibility that, in specifying scope and completion date, Sean has already implicitly over-determined the project-planning problem. It is therefore possible that a reverse scheduling problem violates the iron triangle of project management.

To avoid iron triangle violations, Sean must begin by acknowledging that there are constraints on cost and quality that he imposes implicitly. The other two elements of the iron triangle are schedule and scope. That leaves him with a choice of only two questions he can legitimately pose to Marguerite:

• What part of X can you deliver by October 30?
• How long would it take you to deliver X?

The first question leaves scope flexible; the second leaves schedule flexible. The reverse scheduling problem presumes that a solution exists after specifying bounds on scope, cost, schedule, and quality. Perhaps such a solution does exist, but in my experience with reverse scheduling, legitimate solutions are rare. Even if the planning team devises a plan that appears to meet the four targets for scope, cost, schedule, and quality, overruns of cost and schedule are likely; meeting scope and quality targets are unlikely.

How we get it wrong

Because project sponsors want what they want, the less experienced can (perhaps) be forgiven for posing over-determined problems to their project managers. But the more experienced should have learned about the iron triangle of project management. Many do learn; some seem not to.

More intriguing, though, is the question why project planners repeatedly accept the challenge of reverse scheduling a project. Many fail to anticipate the elevated risk of iron triangle violations in the reverse scheduling problem.

One possible explanation for this failure to anticipate might be provided by what are called priming effects. For a period of time after we're exposed to some form of stimulus, our responses to related stimuli are affected, often outside our awareness. The nature of the effect and period of time during which the effect is measurable depend on the kind of stimulus and the way it's presented. For example, before dining in a restaurant, visiting a bookstore and casually perusing a book about desserts can both elevate the probability that we might order dessert, and determine the actual dessert we select. These effects can occur completely outside our awareness.

When Sean (the project sponsor) tells Marguerite (the project manager) his desired delivery date for the project, that information can affect how Marguerite thinks about the project. Even if she believes she is remaining objective as she goes about calculating a schedule for the project, she has been primed to make judgments and interpretations that assume that the delivery date will be what Sean suggested. Outside her awareness, Marguerite begins to regard Sean's proposed date as a given, and she makes trade-offs and assumptions accordingly.

For example, project planners must make estimates of the time required to complete project tasks. As I've noted in a previous post, estimates are inherently syntheses of judgments and experience data. By compelling planners to achieve a specific target date, project sponsors create conditions in which priming effects can bias judgments. The bias isn't random. It consistently favors achieving the target date, which renders the estimates unrealistic.

Another source of bias, also a priming effect, cannot be traced to project sponsors. It is the knowledge that we cannot reschedule the past. That is, when project planners conduct their reverse scheduling exercise, they know the current calendar date. They know they cannot schedule a task to begin yesterday, last week, or last month. All tasks must begin in the future. And so, when after working backwards, they come to a point where they must estimate how long Task 31 will take, given that it must be complete, say, ten days from now, planners tend to estimate Task 31's duration to be ten days or fewer. If that estimate seems plainly ridiculous, then they try to push Task 31's completion date into the future, crowding any tasks that depend on Task 31. And so the waves of bias set off by knowing the current calendar date propagate forward into the future portions of the plan that have been so far defined.

But the biases triggered by knowing today's date are actually a little worse, because planners also know — or at least, have a guess — how long the reverse scheduling process might take. It might be days, or weeks for a complex project. Whatever is their guess, they know they cannot deliver to the sponsor a reverse schedule that shows tasks with start dates that are earlier than the date on which the deliver the new plan to the sponsor.

Last words

Thus, squeezed between Sean's target date and the date on which Marguerite delivers the reverse schedule to Sean, is a schedule for the project based on estimates biased just enough to appear to be feasible. The planners have focused so much of their effort on schedule that, typically, all considerations of effects on cost, scope, and quality have been set aside. The project might be completed on time, if the definition of complete has been expanded to include whatever the team can build, for whatever budget they have left, at whatever level of quality they can produce by October 30.  Top    Next Issue

Is every other day a tense, anxious, angry misery as you watch people around you, who couldn't even think their way through a game of Jacks, win at workplace politics and steal the credit and glory for just about everyone's best work including yours? Read 303 Secrets of Workplace Politics, filled with tips and techniques for succeeding in workplace politics. More info

Your comments are welcome

About Point Lookout

Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.

This article in its entirety was written by a human being. No machine intelligence was involved in any way.

Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.

Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.

Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.

Related articles

More articles on Project Management:

Films Not About Project Teams: II

Here's Part II of a list of films and videos about project teams that weren't necessarily meant to be about project teams. Most are available to borrow from the public library, and all are great fun.

Beyond Our Control

When bad things happen, despite our plans and our best efforts, we sometimes feel responsible. We failed. We could have done more. But is that really true? Aren't some things beyond our control?

Down in the Weeds: I

When someone says, "I think we're down in the weeds," a common meaning is that we're focusing on inappropriate — and possibly irrelevant — details. How does this happen and what can we do about it?

Wishful Interpretation: I

Wishful thinking comes from more than mere imagination. It can enter when we interpret our own observations or what others tell us. Here's Part I of a little catalog of ways our wishes affect how we interpret the world.

Higher-Velocity Problem Definition

Typical approaches to shortening time-to-market for new products often involve accelerating problem solving. Accelerating problem definition can also help, but a curious paradox stands in the way.

See also Project Management and Project Management for more related articles.

Forthcoming issues of Point Lookout

Coming December 11: White Water Rafting as a Metaphor for Group Development

Tuckman's model of small group development, best known as "Forming-Storming-Norming-Performing," applies better to development of some groups than to others. We can use a metaphor to explore how the model applies to Storming in task-oriented work groups. Available here and by RSS on December 11.

And on December 18: Subgrouping and Conway's Law

When task-oriented work groups address complex tasks, they might form subgroups to address subtasks. The structure of the subgroups and the order in which they form depend on the structure of the group's task and the sequencing of the subtasks. Available here and by RSS on December 18.

Coaching services

I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.

Get the ebook!

Past issues of Point Lookout are available in six ebooks:

• Get 2001-2 in Geese Don't Land on Twigs (PDF, )
• Get 2003-4 in Why Dogs Wag (PDF, )
• Get 2005-6 in Loopy Things We Do (PDF, )
• Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
• Get 2009-10 in The Questions Not Asked (PDF, )
• Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info