Client approvals: creating a clear design decision record
Admin · 22 October 2026
Illustrative image. Photo by Andreea Avramescu on Unsplash. Unsplash License.
A client approval can mean different things to the people receiving it. The sponsor may believe it confirms a preferred appearance, while the project team assumes it authorises procurement and the operator expects another opportunity to review functionality. A clear decision record prevents those interpretations from drifting apart. It states what was considered, what was agreed and which commitments the decision actually permits.
For client project managers, the task is to connect consultation with authority. Many people may contribute requirements or advice, but not everyone can approve scope or expenditure. The project needs an understandable route from options to decision, with enough evidence for the authorised person to assess the choice and enough context for the delivery team to implement it correctly.
Define the decision before requesting approval
State the question the client must answer. Selecting an option, confirming a requirement and authorising an order are different decisions. Avoid a covering email that simply asks the recipient to approve the attached design. The request should explain what approval means and what work follows, using the project’s actual governance and agreement arrangements.
Identify the date required and the reason. A procurement or design dependency gives the client a basis for prioritising the request. Allow time for the information to be prepared, reviewed and discussed. If the organisation uses scheduled committees or delegated approvals, include those steps in the programme rather than place a single decision milestone on the date another party needs to act.
Identify the authorised decision maker
Agree who can approve the matter and any limits on that authority. A user representative may confirm operational needs without being authorised to commit the organisation financially. The project should preserve that distinction. Where a decision crosses several internal responsibilities, identify who brings the recommendation together and who gives the final authorisation.
Check the route when personnel or responsibilities change. An established habit of sending information to one person may no longer reflect the client’s current arrangements. Keep the decision schedule and contact information controlled. The delivery team should not have to infer authority from a job title or from the fact that someone attended earlier meetings.
Present the options on a common basis
Explain the practical alternatives and the consequences relevant to the client’s objectives. Use consistent scope boundaries and identify any differences that cannot be normalised. A visually attractive option should not be compared with an incomplete alternative without acknowledging what is included. The decision maker needs to understand the actual choice rather than a presentation that favours one solution through uneven information.
Keep the recommendation concise but supported. Identify the reason the team prefers an option and the evidence behind consequential claims. If a specialist assessment is required, provide or reference it appropriately. Do not substitute a project manager’s assurance for technical advice outside that person’s responsibility. The client should see where the recommendation depends on further information.
Explain the operational consequence
Include the people who will use and maintain the asset in the appropriate consultation. They may identify requirements that are not apparent in an executive review. Record their input and distinguish accepted requirements from unresolved preferences. Consultation should produce an actionable account of needs, rather than an open invitation for conflicting instructions after approval.
Consider a hypothetical client choosing between two reception layouts. One option may offer more visitor seating while another preserves space for a particular operational activity. The decision paper should explain that trade-off and identify which user requirements each arrangement meets. A simple image with an approval box would leave the client to discover the consequence later.
Make assumptions visible
State consequential assumptions and their owners. The preferred option may depend on an equipment choice, access arrangement or information still to be confirmed. Identify what would change if the assumption proves wrong. This allows the client to decide whether the evidence supports a conditional commitment or whether further work is needed first.
Separate known effects from estimates and untested expectations. The decision record should not imply certainty merely because a figure appears in a table. Ask the responsible advisers to explain the basis and limitations of cost, time or performance information. The client can then weigh the recommendation in light of the evidence actually available.
Record the approval precisely
Identify the selected option, relevant document references and revisions, date and approving authority. State the scope of the decision and any conditions. If the client approves only part of a proposal, make the boundary explicit. The receiving team should understand what it may do without relying on a verbal explanation from someone who attended the meeting.
Distinguish approval from a request for further development. A comment that a concept is promising may not authorise procurement or establish that all requirements are satisfied. Use the project’s agreed terminology and appropriate professional advice. The record should reflect the decision made rather than expand its meaning to keep the programme moving.
Manage conditions through to closure
Give each condition an owner, output and required date. Explain which activity depends on it and whether work can proceed meanwhile. A vague note that details remain to be agreed gives the team little basis for planning. Conditions should be specific enough for the responsible person to act and for the reviewer to confirm completion.
Keep the status visible after approval. Some conditions are lost when the main decision is marked complete. Link them to the project’s action and information processes and communicate closure to affected parties. The decision record remains useful when it shows both the authorisation and the work needed to implement it coherently.
Control changes to an approved position
The APM overview of change control provides general context for assessing requests to alter an approved basis. On the project, use the actual governance and contractual procedures. A later client comment should be assessed against the agreed record rather than automatically treated as either a harmless clarification or an authorised instruction.
Record why the position is being revisited, which requirements are affected and what advice supports the change. Keep earlier decisions accessible with a clear link to the superseding record. This prevents different teams from continuing to rely on different approvals and gives the client an understandable account of how the project’s commitments evolved.
Hand the decision to the people implementing it
Identify the documents, packages and operational plans that need updating. Assign the work and confirm it reaches the relevant recipients. An approval is not fully implemented because the minutes have been circulated. The revised requirement must appear in the information people use for design, purchasing and delivery.
At mobilisation or personnel changes, review consequential client decisions with incoming team members. Explain unusual requirements, accepted trade-offs and unresolved conditions. A clear record reduces reliance on individual memory and helps the project preserve the client’s intent as responsibility moves between preconstruction, site delivery and operation.
The practical test is whether someone outside the original discussion can understand the choice, its basis and the authority to act. A dependable approval process makes that possible through a precise request, proportionate evidence and a traceable decision, giving the client a meaningful opportunity to direct the project before commitments become difficult to change.
Keep a short log of decisions awaiting the client, with the information status and consequence of delay. Review it with the authorised representatives rather than send repeated isolated reminders. The log helps the organisation see competing demands and identify where its own preparation is incomplete. It should support prioritisation without implying that a requested date alone establishes an agreed commitment or changes the project’s contractual responsibilities.
