The Scope Triangle is brilliant. I have never been the best negotiator, but when I learned how constraints in one area highlight opportunities in another it became essential to have frank conversations about realistic expectations.
Here is my takeaway #18 from one of the most useful practical books in my field, “Project Management for the Unofficial Project Manager”:
18) “Constraints are like threads in a spider’s web. If you pull on one, the rest of them are affected, too. It is your responsibility as a project manager to recognize the constraints on a project and then ask your key stakeholders to determine which have the highest priority.”
The book gives a great example of negotiating the triple constraints (Scope Triangle) with a CEO who requested the impossible–about 1,000 copies of a high-quality brochure, by next Thursday, for a trade show and new demographic (made solely by her for under $500), “…by clarifying expectations and prioritizing the list of constraints, she was able to negotiate (against what could not be compromised) a larger budget and more resources.”
Note: This comes from Chapter 3 “Initiating the Project: Move Ahead or Go Around in Circles?” (pages 56-57)
The book lists 6 areas of possible constraints: Scope, Quality, Resource, Budget, Risk, and Time. I tend to think it is redundant to list Scope separate from the triad of Quality, Resources, and Time. Even when Scope is attempting to solely refer to “the sum of the products, services, and results to be provided” as this book defines it, I feel it is a given that the Scope Triangle encompasses the big three as well as the desired deliverable itself. And Budget can be covered as part of Resources, and Risk can be considered within one of the applicable triple constraints too. But it is good to know all of the talking points…
———————–
STORY TIME:
When doing independent contracts (or really when clarifying expectations on any project charter), I always negotiate the work (or clarify the work) using the Scope Triangle before setting out to fulfill the contract (or navigate the course charted). I would ask about the scope of the work to be done relative to the quality, resources, and time expectations. It really helped frame (and reframe, if needed) the conversation to make sure we were on the same page. I often experienced the same as the book recounts when working with Executives, where they just want it all.
If you want higher quality, it will take more time and/or more resources (and money). If you want it faster, it will be less quality and/or more resources (and money). If you want to commit less resources (and money), it will be less quality and/or more time.
I explained that to one Executive and he still thought it could all be done, if I balanced it properly. In other words, the advice was to just work harder and faster and better. Since, neither me, nor he, nor anyone else in the company had proven to be able to accomplish such a feat before,
I knew that these were simply unrealistic expectations. I knew that something had to give. I knew nothing I could do under these circumstances would ultimately impress.
That’s when I adjusted our requirements. I could deliver high quality, on time, with no more resources, but only if we identified what requirements were absolutely critical and which ones were just cosmetic, which would effectively narrow the triangle equilaterally (essentially reducing the quantity of work expected). I knew enough about the project to know that this would still offer more for the product and service than we were currently offering and that we could still upgrade the information at a later date, before that non-essential information became essential (If it ever did).
———————–
Before learning better project management practices, I mistakenly assumed that when someone made an assignment that they had thought it all out. I somehow thought that no one would give me a project with impossible parameters. That has not been the case. Come to think of it, I don’t know if I have ever received a project that I didn’t have to adjust the expectations a little bit. For some reason, most of us are overly optimistic about estimating project work. Like the author of the story that I summarized above, I had to learn to stop going back to my desk and trying to make the impossible happen.
I still have to remind myself that the person asking for something to be done rarely knows what exactly it will take to get something they are asking done. The higher up the chain of command they are, the farther removed they are from having performed similar work and the more out of touch they are with the actual work. Even after you settle on what the expectations are for a given project and what is most important, be wary of deadlines given based on when it is needed by some event outside the project, not based on anything else about the actual project.
You are going to need some time to estimate the real work against other known knowns of similar work and consider project variables (such as Collaboration, Coordination, Communications), such as availability and capability of the resources at hand (such as People, Processes, Tools).