I was walking down North First Street in San Jose this evening on the way back to my hotel, when I passed a man talking to someone who wasn’t there. Now, it used to be that, if you saw a guy walking down the street holding a one-sided conversation, you’d figure he was nuts. These days, you just figure he’s on the phone. Of course, that doesn’t mean that all the nuts are now staying home. Nor does it mean that everyone talking on the phone is sane. But in the face of this modern, incremental complexity, we make simplifying assumptions.
Simplifying assumptions don’t change reality; they simply allow us to ignore low-probability events so we can proceed with making plans. And when the law of probabilities finally asserts itself, we may suddenly realize that we accepted a risk. Of course, there’s nothing wrong with making simplifying assumptions, nor is there anything wrong with accepting selected risks. The problem arises when we make these simplifying assumptions without noting the potential impact associated with the events we’re removing from consideration.
A Disciplined Approach
“First, simplifying assumptions should be chosen which simplify the design problems significantly without changing the essential character of the program which needs to be implemented. Second, the designer must keep track of all the assumptions he is making so that he can later retract them in an orderly manner.”
Charles Rich and Richard Waters, “The Disciplined Use of Simplifying Assumptions,” 1981.
The willingness to make decisions under conditions of uncertainty is a key characteristic of all leaders. That said, successful leaders defer decisions until they can either reduce the uncertainty, or mitigate the consequences of a decision they might later wish they could “do over.” Part of our responsibility as portfolio, program, and project managers is to provide our leadership team – from executives to sponsors to stakeholders – with a sense of the level of uncertainty present in the information we give them. Two of the key tools for providing this understanding are the risk register and the list of assumptions used in preparing our estimates and plans. And just as we actively manage risks, so should we work to convert our assumptions to known facts and conditions.
Getting from Assumptions to Knowns
Some of the activities we should engage in to reduce the potential variability in our project include:
- Use productivity measurements from performance of tasks performed early in the project to update our duration estimates for later tasks; in Scrum, the applicable term is “velocity”
- Conduct “early adopter” and “proof of concept” pilots to validate assumptions of ease of use, supportability, and time to value
- Apply the results of early quality inspections to your rework timelines
- Trend costs and update the project budget
- Re-visit the business case, based on what the team learns during the project, and make appropriate updates to the assumptions
At the end of the project, all of the assumptions used for planning will be known facts and conditions. But to get them to that state, you must manage them accordingly. And to maximize the benefit of that additional knowledge, you must update your plans, staffing, timelines, budgets, and sometimes even your technical approach, as you acquire it. Don’t wait for that “lessons learned” session at the end of the project to apply what you discovered from the process of confirming, qualifying, and disproving your assumptions.