Those who’ve rolled around in the construction of software for a long time are comfortable viewing a project as a process to drive uncertainty from 100% to 0% over a period of time by building something. In contrast, those who have been victimized by custom software creation - stakeholders and patrons - tend to demand certainty too early as a risk mitigation strategy.
These stakeholders who don’t like uncertainty want us to do something about it. In reality the only thing to do is to begin the real work of the project. But, all too often, the unfamiliar stakeholders insist on more planning, which exacerbates the problem.
Only too willing to please, many teams capitulate by creating a facade of certainty, e.g., detailed project plans, complex resource loading charts, myriad milestones, status meetings. It’s easy to understand why: most people want to please, and the rest want to stop being harangued.
The problem is, at some point the facade is exposed. But, we have only ourselves to blame. This behavior seems to fit the modern explanation of an addiction: a behavior that in the short term mitigates pain, but in the long term only makes the situation worse.
It would behoove us to educate our stakeholders that the nature of a software project is to reduce uncertainty by delivering something often. Oh, and when the bad things happen - as they usually do - to live by the words of that apocryphal general “the only thing worse than bad news is bad news late.”