What does good technical planning look like?

What does good technical planning look like

There’s a weird mishmash of technical planning and proposals - roadmaps, planning documents.

What are the ideal properties of a good technical plan

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.

  1. Good technical plans are coordination tools, not a bibles.
  2. Good technical plans enable people to make decisions
  3. Good technical plans are made for people
  4. Good technical plans are a joy to read
  5. Good technical plans are useful to people at any level of a hierarchy
  6. Good technical plans are living documents
  7. Good technical plans make uncertainty explicit
  8. Good technical plans provide answers to the The Heilmeier Catechism
    1. What are you trying to do? Explain it in as few words as possible with zero jargon.
    2. How is it done today? What are the limitations of the current system?
    3. What is new in your approach and why do you think it will be successful?
    4. Who cares? If you are successful what difference will it make?
    5. What are the risks?
    6. How much will it cost?
    7. How Long will it take?
    8. What are the mid-term and final reports to know we’re on track?
  9. Good technical plans lay out alternative possibilities
    1. They illustrate the different known junctions in the The Idea Maze
  10. Good technical plan talks about who is best suited to actually do the work
  11. Good technical plans give you a way to prioritize different options given finite resources
    1. Prioritization requires “decision making algorithms” - if we find out X, it will affect Y
    2. Prioritization requires a certain level of precision or admitting that you don’t have that level of precision
  12. Good technical plans talk about what kind of work will need to be done to address different pieces. Is this just a matter of trying a lot of combinations? Do you need to invent new physics or math to succeed?
  13. Good technical plans address exogenous changes in the world that could happen and their effects on the plan. For example - does the plan assume that Moore’s law will continue to decrease the cost of compute?
  14. Good technical plans allow people to take away something valuable at different levels of engagement: someone non-technical should be able to get a sense of the plan just by glancing at it, but someone deeply technical should be able to unambiguously execute on it after engaging with it deeply.
  15. Good technical plans realize that ideally they are only the start of something bigger. Planning to Start vs Planning to Finish

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,

Web URL for this note

Comment on this note