It’s an old project management adage that appears in many similar forms and the general gist is: in many projects, though we strive to deliver the full scope, to a high quality, and in good time, we often have to choose two and sacrifice one.
For example, if I asked you to cook a chicken breast in one minute, your options are:
- Sacrifice quality: I’m sure you could cook it for one minute but the quality would be suspect and I would not recommend eating it.
- Sacrifice scope: If I insisted that I needed something in one minute, perhaps you could reduce the scope by cutting off a tiny morsel of chicken and cooking only that.
- Sacrifice time: Use as many minutes as you need to cook the full chicken breast to a delicious high quality.
In the above example, I presented the three options in the best case whereby we are taking control up front and choosing which element to sacrifice. Problems are exacerbated when we kid ourselves into thinking we can get everything done and when this happens we often end up in one of the following undesirable scenarios:
- Delivering sloppy low quality work on time.
- Dropping entire components of the work last minute because we did not have time to deliver everything.
- Realizing too late that we are not going to meet a deadline and having to make that awkward call to whoever is awaiting delivery of our work.
There is no silver bullet solution to this conundrum but, in my experience, the best approach is to get ahead of it early and if you sense a project is facing this problem flag it and figure out which of the three elements can be adjusted. Usually we will not want to sacrifice quality so the discussion centers around either reducing the scope to meet a deadline or pushing out the deadline to a more reasonable future date. Don’t rule out sacrificing some quality, there may be options to pare back to a minimally sufficient solution – sometimes the customer just wants a simple tire swing!
A final note: I think the Agile methodology really addresses the nub of this issue because quality is assured by including testing as an inherent part of a sprint. Time is fixed – typically 2 week sprints – and this leave scope to be adjusted and agreed upon at the beginning of each sprint.