There’s a weird mishmash of technical planning and proposals - roadmaps, planning documents.
These properties are a wishlist for an “ideal” technical plan. It may not be possible to make one that obeys all of these properties but it is important to understand what a plan should be shooting for.
Two important quotes:
- “No plan survives first contact with the enemy” -Helmuth von Moltke the Elder - Wikiquote
- “Plans are worthless, but planning is everything” - Dwight D. Eisenhower
Keeping these quotes in mind, what is the purpose of a good technical plan? In a nutshell a good technical plan is a decision-making tool. It allows everybody involved in a project to make optimal decisions based on new information and predict what decisions other people will make. It is not a checklist of actions nor is it an idealized wishlist (like this piece of writing.)
Because different people in the project need to make different decisions based on their role, you might argue that you should have different artifacts for each role. However, there hasn’t been a technical plan in the history of the world that hasn’t changed. A changing plan means that role-based plans would get out of sync. Additionally, nobody will be doing the exact same thing, especially in research-heavy technical plans. As a consequence, no decision about where to draw lines between role-based plans will be perfect. Creating different artifacts for different groups may be a necessary concession to reality, but since we’re describing the ideal plan, it’s important to call it out as a concession.
Based on these properties, any good technical plan is going to vaguely resemble a roadmap. Roadmaps have two pieces - the map and the path. The map corresponds to #2, #7, #8.2, #8.6, #9, #11, #14 and the road corresponds to #8.1, #8.5, #8.7, #8.8, #10, #12,