Planning Safety
The "Margin of Safety" by Micha? Poczwardowski explores a mental model for making estimates more reliable by considering potential risks and incorporating a buffer.
Poczwardowski attributes his interest in this model to Farnam Street's discussions on the topic, which highlight the margin's importance in various fields, from engineering to investing. Incidentally, the three most important words in investing according to Warren Buffet are: 'Margin of Safety.'
Real-world object engineers typically estimate capacity to more than double expected maximum loads to account for unpredictable stresses. This model, adapted by Shane Parrish, suggests a safety margin sufficient to handle "double the worst-case scenario." And we are all really happy with that when we are stuck in bumper-to-bumper gridlock traffic with abnormal load trucks on a bridge. With software engineering, the margin for safety in controlling radiation dosage for an x-ray machine needs to be as much, if not more rigorous.
In software engineering business function systems, underestimating a project due to outdated documentation can be avoided if the margin of safety is based on a solid understanding of all potential variables, including unfamiliar or outdated systems.
Planning needs to be performed with, but not limited to, the following checklist:
Open communication about knowns and unknowns in project requirements helps teams realistically assess risks. Recognizing team limitations yields a more accurate safety margin.
Despite all this, while a safety margin reduces risk, "black swan" events - rare, unforeseen occurrences - could still arise. The margin of safety is a proactive tool, but readiness to adapt to surprises is still crucial. And here, no amount of preparation for the forseen helps. What does help is if the team is adaptable to changing circumstances. Or, in fewer words (and I hesitate to use the word): is agile.
"But we are agile! We have implemented Agile trademark&patent pending to the letter of the law and now we are agile!" I hear some readers explain. Well, they are not readers of this, but perhaps they may be readers' stakeholders?
Agility is not the ability to "sprint fast". Agility is not about sprinting at all. Agility is not about traveling at great speeds linearly; agility is about changing direction quickly. Don't take my word for it. Here's?Kevlin Henney?making the same point better than I ever could. He (eventually) compares agility not to a sprinter getting to the finish line, as fast as possible, but rather, to a floor gymnastics gymnast's contortions as they make their way across the floor, bobbing and weaving out of the way of imaginary obstacles along the way, as fast as possible (and twirling a baton or juggling as they do).
To be agile, a team must be optimised to receive fresh redirection frequently. Daily if possible. That is a very agile team. A less agile team may only be able to handle weekly redirection. A less agile team less frequently than that and so on and so forth till a 100% rigid team which cannot handle any directional changes ever.
And no matter how agile a team or, rather, no matter how frequently a team can accept new direction and no matter how much redirection team can or cannot handle - every team must, at the very least, identify which things can be changed and which things are non-negotiable, regardless of changing circumstances. As such, black swan events which put pressure to make those sorts of changes create project terminating circumstances that are best discussed separately.
But, apart from the non-negotiable stakes in the ground, everything else should be changeable and estimable for change, as we discover more and more newer requirements (which may or may not be in conflict with old ones) as time passes and delivery advances.
And so, to Poczwardowski's checklist Requirements Analysis, Risk Assessment and Pre-mortem Sessions I would add the following point - Team Agility Limitations: estimating how much upfront instructive task breakdown is required for a team to complete one full cycle of delivery which can be assessed in terms of software quality and business value. Daily? Weekly? More? Those questions can be answered upfront so that there are no surprises when we get to incurring time cost penalties associated with any redirection.
Teams that can take daily redirection with minimal cost (say 2-5% or less) are extremely cost efficient on high-rate changing requirements projects and so, could be priced higher in a per-hour currency terms, precisely because they are cheeper over the full duration of delivery.
Such teams are very rare, as are projects with this level of organic need for discovery work. What is more common are people who do a horrible job at one or more checklist items (or skip some altogether) then push straight for implementation as a means of doing discovery work. Implementing as a means of doing discovery work is an excellent approach that I advocate but only with an understanding that that way of performing analysis has a high rate of redirection for a team assigned to the problem; and, a team with abilities to handle redirects at that rate and of that volume is required.
More often than not, the high rate cost is a) not accounted for while b) the business decision-making process is to make decisions based off of feedback from the delivery team, which c) may or may not be suited to working with frequent redirects. And, then, post fact, blame slow delivery on poor performance when executing The Plan (rather than blaming a process that includes poor planning for delivering an unrealistic plan, casting it in stone and assigning blame elsewhere).