Key Design Decision Documents help record important thought processes for communicating with current and future team members. It details the key decisions that the organisation is going to take over a period of next four months. Generally, the audience for the decision log includes the project team, project sponsor, business owner, steering committee and key project stakeholders. The primary information documented includes “What is the decision”, “When was it made”, “Why it was made”, and “Who made it”.
A decision document is a tool for capturing the status of a current program, project, initiative or other investment which has come to a fork in the road. Now, an important decision must be made and the team of decision makers needs to be aligned on what options exist, make a selection, document why the option was chosen and by whom, for future reference. It is a tool for providing clarity, expediting alignment and removing barriers to success. A decision document aligns key stake holders on current status, a particular issue or challenge and options to consider. It explains each option, the relevant benefits and risks, documents which decision is made, by whom and when, provides a record of accountability and drives support by decision makers.
When Should a Decision Document Be Used?
There are many scenarios in which a decision document may be useful. Some examples include when the decision to be made is not clear to those who must make the decision. For example, if the project is very detailed or technical in nature but the investment decision goes to a very senior level of leadership not familiar with those details. Another scenario may be in a fast-paced project where the leadership have little time to dig into the details. Furthermore, highly regulated or sensitive environments such as food and drug industries or security matters may benefit from regular use of this tool. Of course, these documents can be useful in highly political or confrontational environments to ensure support and alignment is maintained throughout as well.
What are the Primary Components of a Decision Document?
Each decision document may have its own terminology. However, in essence, each document should include the following primary sections:
1. Decision to be Made
In this section, describe the decision that must be made. This should be very clearly stated, but succinct. This is an executive brief of what recipients of the document are being asked to decide.
2. Current Status
This section must include the who, what, when and where of the situation requiring a decision. You should also provide the history of how you came to the issue at hand. While your decision-makers need to understand the background, this requires a careful balance of providing enough history without going into exhaustive and unnecessary details. A good litmus test for content to be included here is to simply ask yourself, “is this information relevant to the decision?” In other words, would knowing the piece of history or current status detail influence the decision maker one way or another? If the answer is yes, then it is relevant enough to be included.
3. Options
Be sure to capture all relevant decisions, with an emphasis on the relevant part. This section is not to list every possible variation anyone could ever dream up. Instead, list genuine options that the decision makers could consider selecting. Depending upon the nature of your particular environment, you may want to include a section of “excluded options”. In this case, you would briefly list options that were quickly ruled out and a short statement of explanation.
For each option, explain the option in detail first. Then, in bullet or similar quick-reference fashion, highlight the positives and negatives (I prefer the position of “Benefits” and “Risks”) of each option.
4. Recommendation
This is the recommendation of the team or individual submitting the decision document for consideration. It should include a reference back to the specific option being recommended (Option #1, 2 or 3…). In addition, the reasoning for this recommendation should be captured. For example, you should explain why the recommended option is better than others. Logic such as lowest overall risk or cost are obvious reasons. Others may include a balance of risk and costs or time sensitivity.
5. Decision
Here, you document the decision the team agreed to. If you’ve done your legwork prior to submission, you may anticipate the chosen option. In this case, you may want to document the chosen option (anticipated) when presenting the document for signatures / approvals.
6. Next Steps
Based on the decision being made, what actions must happen next? This may not be required in all cases, but it is often helpful in ensuring the right actions happen in a timely manner. In addition, key decisions that require documentation like this often stem from a problem and include lessons learned or opportunities to avoid a recurrence. This section may also be useful for capturing this information.
7. Sign Off
If deemed necessary, here the decision-makers physically sign the document. Most of the time though, a simple email confirming approval and alignment is sufficient form the individuals.
Fusion Practices believes in a design authority to be setup by the customer and agree to the end-to-end design of the programme spanning operating model, people, process, data and technology to achieve the agreed outcomes. The customer oversees taking key design decisions or making agreed proposals to the relevant stakeholders, typically where there is a material impact on Finance or HR people. The customer oversees defining the qualitative and quantitative measures of success for each business outcome, the supporting design principles and the strategic design decisions of this transformation programme. For the avoidance of doubt and complication, the customer does not govern programme delivery as this is the responsibility of the System Integrator and Delivery Leadership Team.
In early stages of the project, Fusion Practices clearly sees the need for certain design decisions to be made some of which are listed below. These key design decisions have a detailed paper drafted for each decision and follows the below structure for governance and is scored appropriately.
Key Design Decision Structure:
Document Sign-off: Who signs off and audits of their sign off.
The Ask: Explain what the Design Authority is being asked to do i.e., Endorse a design decision to take to the Program Board for approval or to make a decision on a design recommendation.
The Design Decision / Recommendation: Providing an overview of decision/recommendation highlighting the key expected or known implications for the operating model, data, technology, process & people, and how it supports the approved business outcomes and design principles. If the decision/recommendation goes against an approved business outcome or design principle, justification is provided as to why this is the case. Providing details if the decision/recommendation has an impact on the Program scope. Providing details if the decision/recommendation is expected to have an impact on the Program budget. Highlighting the key dependencies with other workstreams and areas outside of the Program.
The Rationale: Explaining the rationale for the decision/recommendation including the qualitative and quantitative pros and cons. These cover minimum business outcomes and design principles; alignment to the business case; known future developments that will impact Finance, including regulatory, statutory or management requirements; complexity and sustainability of the design; the impact on the customer’s staff; and any identified risks, issues and opportunities.
The Governance and Engagement Process Followed: Providing a summary of how the decision/ recommendation has been arrived at, including a summary of any alternatives considered and the reasons for dismissing these options. Identifying the stakeholders and SMEs engaged in the process.
The Business Impact: Considering the impact on the business, with particular emphasis on any people or operating model implications and simplification across options.
Further ratification required: Highlighting if any further approvals are required, and providing details for example, people and operating model decisions to be approved by the Program Board, technology decisions to be ratified by the Architecture & Board etc.
Other matters: Provide details of any other matters that the Design Authority should consider or be aware of relating to the decision/recommendation. For example, the complexity and sustainability of the design; considerations of known future developments that will impact Finance or HR, including regulatory, statutory or management requirements; and whether the design contradicts previous decisions made by the Design Authority, or calls into question the validity of the current design.
Supporting Documents: Append supporting documents required.
