In the project management land, surprises are very costly. In the best case, they are introducing work you have not budgeted for, extending your timeline.
In the worst case, you discover a dependency on external vendors, or internal teams. And that is blocking you right now! Your team cannot proceed and can only sit idle and observe the roadblock removed.
Since sitting empty-handed is corrosive, drains morale and kills momentum, you undertake some filler work or some other project in the meantime. By the time your dependencies get resolved, you are deep in something else, which you have to switch back from.
Your total cost of the surprise is:
Cost_Of_a_Surprise = Time_Spent_Waiting_on_Others + Time_Spent_Integrating_Their_Solution + Time_Switching_Back_From_Filler_Work
Simple solution: Frontload the surprises
There are many project management frameworks and philosophies, but my simple heuristic is to discover surprises, so work can be put in parallel as soon as possible.
When kicking off the project, the natural instinct of engineers is double down on what they know, share that brilliant idea on how to deal with the X requirement, or use the technology Y they have been playing with in spare time. This compounds the problem, because it postpones dealing with uncertainty. The least known area holds the most surprises, and is usually the most underestimated.
I fight these urges, starting any project with the least known area first.
- We will make slower progress at the beginning,
- We cannot jump at those exciting ideas from the kickoff,
- We will discover undetected dependencies which we can start delegate right away
- We can adjust timeline much sooner
In plain SQL, `SELECT tasks FROM project ORDER BY surprising DESC;`