“All magic comes with a price, dearie.” Rumplestiltskin

In ABC’s Once Upon a Time, Robert Carlyle’s character regularly reminds other characters that “magic has a price”, one action coming at the cost of another. I was thinking of this as someone asked for a work-back schedule, and had nearly titled this article with a Star Wars quote instead: “It’s a trap!”

A work-back schedule, before a project is even planned, is meant as a requirement or constraint. “After this date, the project has diminished or no utility, therefore this is a constraint.” Constraints are planned for. If you must have a thing by a certain date, other things like scope and cost will change. All magic has a price.

Work-backs, however, are often used as project traps. Consider the scenario: You have a fixed number of resources, not flexible in the short term (say three months). In brainstorming, the team has dreamed up some scope, which is to say aspirational deliverables that provide utility. Now comes the trap. Leadership looks at the scope and says, “Hey, looks great – I have to have this in three months, give me a work-back schedule to deliver all that scope.”

See what happened there? A project constraint was introduced, but hasn’t yet been accounted for. Instead, an expectation was created. The job of the project manager is to manage that expectation. “Oh, good to know that requirement – let me talk with the team and work out what can be delivered with quality in that time frame, and let’s review after.” While a wise leader will understand, some will reply with, “Oh, just give me a back-of-the-envelope estimate, I won’t hold you to it.” Don’t give into the temptation of telling someone what they want to hear because it’s easiest. The price of doing this is project failure, because it is nearly inevitable that stakeholder expectations will not be met. “I won’t hold you to it” is just the bait for the trap. Once the jaws close, you’ll be held to that estimate. The only way to successfully navigate this is to use the situation as an opportunity to gather stakeholder requirements.

It seldom works to say, “No, but…”, since people stop listening when they hear “No.” Instead, “Yes, and…” tends to work better. People have problems, projects exist to resolve them. Project managers exist to orchestrate solving problems. To solve a problem, it’s important to fully understand it. Rather than complying to an early schedule demand, a bit of magician’s misdirection will help get things on the right path, “But of course! Of the deliverables you see here, can you help me understand which are the most important to you?” Answering questions with questions also works. “When can I have this?” can be answered with “which of these is highest priority?” There’s also the truth, “Any schedule I propose at this point would not be based on data, and therefore not realistic – help me better understand so we can get you the results you want.” Understanding requirements and constraints is essential to designing the right solution. Knowing how the stakeholder processes information will let you use the correct approach to gather requirements and understand constraints.

Once upon a time, you may have faced this situation – but if you didn’t before, now you understand the price of magic.