This title may be a paraphrase of a really old Air Supply song, but it is not too far from reality. In the last article about Uncertainty, the lack of firm requirements and the expectation of setting an estimate can lead to extraordinary measures by the team. High level estimates become deadlines and force the team to try to keep commitments through extra hours.
What are the ways that I should have helped in the case as a savvy IT leader who knows how the poor high-level estimate can sink the project? Leaders win through communication and demonstrating the principles for the team. Here is the key principle that I apply to the uncertainty of estimation: write a series of assumptions that become temporary requirements to base the estimate in some concrete form.
I like to provide a list of assumptions. If we were speaking in mathematical terms, I would say that my Assumptions List grows proportionately to the lack of good requirements. I keep a list of questions – no more than 20 – that I ask of the business experts that would help me make a reasonable estimate. Instead of leaving any question unanswered and not possible to consider for the estimate, I transition into recording an assumption.
Sample Questions:
How many screens will your app have?
How many data fields will be in the app?
How much of the data will be editable?
How many steps are there in the workflows?
How many people will use the system?
How many roles (manger, customer service rep, customer, etc.) will use the system?
The interview is simple. If the business expert is confident in an answer, we record that and agree to use it to frame a good estimate. That would be the happy path of the conversation.
In the case of the dreaded “We don’t know” answer from the sponsor, I use a tactic that is (admittedly) not very fair. I just pull a guess out of mid-air and state that as the answer to the questions and the Assumption. Let’s call this guess a Chucksumption.
Here’s an example from my past. I was working on the estimate of a complex digital form, and the experts were still mulling the content but wanted a firm estimate. I switch to question mode.
“How many pages on this form?” I asked.
“We aren’t sure yet.”
“Ok, let’s say 3 pages,” I set a Chucksumption. “How many data elements are on the form?”
“It could be detailed or we may only want a summery, so we aren’t sure.”
“Ok, let’s say 10 fields,” I set another Chucksumption.
“Wait,” the business expert stopped me. “You are going to assume 3 pages but only have 10 total fields?”
“You are right,” I smiled. “I am completely off. What number of fields would you think?”
The grumbling from across the table would begin. It is easy for me to float a really stupid assumption, and then agree with the business that I am nuts. But, that puts the ball right back in their court to give anything better than a Chucksumption. It is a dirty trick.
“Let’s say 100 data fields,” the business expert would offer.
“Perfect.”
An interesting scientific observation follows: the lack of quality in my assumption is enough to have the business expert give me a stronger assumption. That is great! I take that business-side educated guess as a much better assumption.
In using this technique, the engineering team can see that the organization shares the concern about uncertainty. Do we still know that software engineers will have plenty of hard work and perhaps some extra hours? Sure. Does the organization know there is a risk to project costs going up? Yes. Will engineering teams still need to come up with a commitment to delivery? A conditional Yes. Has the dreaded List of Assumptions been replaced by facts? If so, it is time to commit to a reasonable delivery.
If the entire team, from business sponsor to each contributor, share in understanding this uncertainty, the stress does not collect only on the engineering job family.