I just deployed something worldwide that took about six weeks to develop and our initial guess was about two weeks, so this is fresh in my mind. I was able to lay out a list of work items at the beginning that stayed like 80% the same from the beginning to the end, but didn't account for the possibility that each one of these could be push-button, or could lead to a blocking problem that needed a day or two of research to resolve. Based on that, I'm thinking that the way to approach the next one of these is to lay out the roadmap, but assume that something like half of the trivial steps are going to turn into complex problems that stop the train for a day or two, or lead to a change in the design.
The best framing I've heard for this problem is: minimum time for each component is bounded, maximum time is unbounded. I.e. there is effectively no answer to the question "If this component becomes a problem, what is the maximum amount of time it could take to solve it with the resources available?"
Ergo, in the worst case, any given single component's ballooning time can dominate the overall project schedule.
Which turns estimation into a game of "How certain am I that no component's time will explode?" To which the answer in any sufficiently complex system is "Not very."
I'm pushing my work to move to something more like a converging uncertainty plot, as milestones are achieved and we can definitely say "This specific component did not explode."
Our PMs aren't used to hearing an idealized minimum schedule time + an ever decreasing uncertainty percentage based on project progress, but it feels like less of a lie than lines in the sand based on guesses.
(Note: This is for legacy integration development, which probably has more uncertainties than other dev)
One interesting thing to also account for is the correlation between activities regarding cost or schedule impacts. Meaning the uncertainty analysis should also account for systemic effects where a ballooning of one item’s will also cause another item’s schedule to increase by some correlated amount
I do remember doing a risk assessment as part of a proposal for a client. They pushed back hard on a number of points and got the sales person to remove them.
The funny thing is the risks that were removed all occurred during the project. We should have stood our ground.
