Have you ever sent a drawing around for review, copied in everyone who might need to see it, and then heard nothing?
You follow up a week later. One person thought they were only copied for information. Another was waiting for the first person to finish. Someone else reviewed it, saved their comments, and assumed you would find them.
Meanwhile, the construction team is asking when they can start.
This can happen in any project. In an alliance, where people from several organisations are working together, there are even more opportunities for a simple request to get stuck between people, departments and company systems.
Everybody may be busy. The document is still going nowhere.
Problem: The Alliance Works Together but Its Processes Do Not
Different organisations bring different ways of working
An alliance can bring together the client, designers, constructors and other participants to deliver a project collaboratively. The Australian Government’s National Guidelines for Infrastructure Project Delivery describe alliance participants working as an integrated team and making decisions in the interests of the project.
That can offer considerable benefits. However, putting people in the same office or giving them the same project email address does not automatically make their internal processes compatible.
One company may use an online approval system. Another may require a signed form. The alliance may have its own authorisation process, while a parent company still needs to approve particular commitments.
People often know how things work in their own organisation. They may have no idea how the other organisations work, or which process takes precedence within the alliance.
Alliance communication efficiency suffers when people have to discover these arrangements each time they need something done.
A distribution list does not assign responsibility
Sending information to a group does not tell anyone what they are responsible for doing.
A request to “please review” might mean check the technical calculations, comment on constructability, confirm the cost allowance, or authorise the document for issue. Those are different tasks, potentially requiring different people.
Some recipients may assume someone else is coordinating the response. Others may provide comments outside their area of responsibility while the person whose approval is actually required does nothing.
The sender then has to chase everyone individually. Much of that chasing could have been avoided by making the original request clear. I have been in that situation multiple times on the receiving end, and also on the sending end before I learned my lesson.
Design verification can become a long queue
Design documents may need checks within the originating discipline, coordination with other disciplines, independent verification where required, and approval before release. In an alliance, these activities may cross several organisational boundaries.
The difficulty is often the waiting between activities. A drawing can sit in an inbox for several days before someone discovers that it was sent to the wrong person or is missing supporting calculations.
If the process is unclear, a reviewer may also forward it to another department “just in case”. That department may repeat work already completed, or start a different approval route.
Eventually, the project manager sees a design marked nearly complete while the site still has no authorised drawing to use. The schedule allowed time to prepare the design, but too little time to get it through the required reviews.
Administration can cost more than people realise
In one alliance project, I needed to arrange external design work for an agreed price. It took ten weeks to get the purchase order in place, including about ten hours of my time going backwards and forwards through the process.
We had to establish which parent company was paying, obtain the correct forms, arrange agreement reviews and collect signatures. Different people directed us towards different forms. By the time the paperwork progressed, some of the designs had been completed internally because they were needed, so the external scope had to change and further signatures were required.
The design work was worth about $8,000. The direct management effort was about $2,000, excluding purchasing and accounts staff time.
That is a considerable administrative cost before the external designer even starts. It also shows why improving communication needs to include the approval process itself. A clearer email cannot fix a system in which nobody knows which form or authorisation is required.
Solution: Make Every Action and Handover Clear
Agree how the alliance will process work
At the start of the project, bring together the people who actually process documents, purchases and approvals. Include representatives from the parent companies where their involvement is required.
Agree which system and procedure will be used for each common task. Identify any parent company requirements that remain, and establish how those requirements fit into the alliance process.
For purchases, for example, the team should know which organisation places the order, which agreement and forms apply, who checks the request, and who can authorise it. A designated purchasing contact should help the project team navigate this process without making each engineer rediscover it.
Link these arrangements from your project management plan. Resolve conflicting requirements with the people who own them, then publish the agreed process where the team can find it.
Separate the person doing the work from the person approving it
For each common document or decision, identify who prepares it, who checks it, who provides specialist input, and who has authority to approve it.
A responsibility matrix can help. APM’s guidance on taking responsibility for stakeholder engagement recommends clarifying roles and using a RACI matrix: Responsible, Accountable, Consulted and Informed.
The practical value is that people know whether they must act, decide, provide advice or simply stay informed. The matrix should reflect the alliance’s actual governance arrangements, including any decisions reserved for a leadership team or the client.
Name a person to coordinate each request through to completion. That person does not need authority to make every decision. They do need to know who has the next action and whether it has been completed.
Keep a current contact list, including authorised substitutes for absences. A job title alone is not much help when nobody knows who currently holds it.
Put the action in the request
Make it easy for the recipient to understand what you need without reading a long email chain.
A request should identify:
- The document number, title and revision being considered.
- The person responsible for each action.
- The specific check, decision or response required.
- The due date and time, including the time zone where relevant.
- Where the response must be recorded or returned.
- What happens after that response is received.
For example, an illustrative review request might say:
“Priya, please complete the mechanical review of drawing M-042, Revision C, and record your comments in review package DR-018 by 2 pm Brisbane time on 12 November. Confirm when your review is complete, including if you have no comments. Alex will consolidate the responses and return them to the designer. Jordan and Sam are copied for information only; no response is required.”
This identifies the action and the next handover. It also prevents the sender having to guess whether silence means the review is complete.
The subject line should be useful too: “DR-018 — Mechanical review of M-042 Rev C — Response due 12 November”.
Make information copies different from action requests
Be explicit about who is copied for information. Do not rely entirely on whether their name appears in the To or CC field.
If several people need to act, list their individual tasks. If a manager only needs visibility, say that no response is required from them.
Being informed should not quietly become another approval gate. Equally, someone whose approval is required should not have to infer that responsibility from being included in a large distribution list.
Keep distribution relevant. People are more likely to notice important requests if they are not receiving every minor exchange across the alliance.
Plan the design review sequence
Map the required review and verification stages before documents start moving. Agree the purpose of each stage, the required inputs, the reviewer and the evidence that shows completion.
Some reviews can run in parallel. Others depend on earlier checks or corrected information. Have the design and assurance leads agree which activities can overlap while preserving the required sequence and independence.
Allow time in the schedule for comments, corrections and any necessary rechecking. Confirm reviewer availability, including leave and commitments to other projects. Simply assigning a due date does not create capacity.
Where several disciplines review the same package, nominate someone to consolidate comments and coordinate conflicting requirements. Reviewers should identify the revision they checked, and changes after review should receive the further checks required by the design process.
As I discuss in How to Make Design Management More Efficient, a clear sequence helps prevent important steps being missed. Reduce unnecessary waiting while keeping the required technical checks and release controls intact.
Provide a one-page procedure people can follow
A detailed management plan may explain the full governance arrangements, but people also need quick instructions for everyday work.
I suggest a one-page procedure for each frequently used document process. For example, a design review procedure could cover:
- The sender checks that the review package contains the required drawings and supporting information.
- The coordinator identifies the reviewers, their tasks and agreed response dates.
- Reviewers record their comments and completion against the specified revision.
- The coordinator consolidates comments and assigns their resolution.
- The designer makes corrections and obtains any required rechecks.
- The authorised approver records the release decision when the required checks are complete.
- Document control issues the approved revision and notifies the intended users.
Adapt this to the project’s actual requirements. Include links to the forms, systems and detailed procedures (so people don’t have to go searching), plus the contact for questions or overdue actions.
Test it with someone who has not used the process. If they still have to ask where to send the document or what happens next, the instructions need work.
Make the documents accessible across company boundaries
Check that people from every participating organisation can open the files, submit comments and record approvals using the agreed system. Test this with their actual accounts.
A link that works for the sender may not work for someone employed by another alliance participant. That person then requests an attachment, creates a separate copy, and the project has another version to reconcile.
Use one controlled location for the current document and its review record, with access appropriate to each person’s role. Clearly identify revisions and status so a draft cannot easily be mistaken for a document authorised for use.
My posts on a Simple Document System and clarifying who uses documents and why cover the practical details. In an alliance, those arrangements need to work across the participating organisations.
Use clear deadlines and reserve urgent for genuine urgency
“Urgent” does not tell the recipient whether you need a response this afternoon or next week. State the date and explain the consequence of missing it.
For example: “We need the review completed by Wednesday so there is time to resolve comments before the planned release on Friday.”
Check that the requested date is realistic. If the recipient cannot meet it, ask them to tell you promptly so priorities, resources or the delivery plan can be addressed.
As I explain in Is Urgent Really Urgent?, overusing urgent labels makes them less useful. Where an issue genuinely needs immediate attention, contact the responsible person directly and record the resulting action. Do not assume an email flag will get noticed.
Track the outstanding work and close the handover
Use a shared workflow or register to show who currently has each important action, when it is due and what is preventing completion. Link to the document and the original decision or approval record.
A project communication, decision and action register can provide this visibility. If your document system already tracks the information properly, use it rather than maintaining another manual list.
Sending a request is not completion. Neither is saving a reviewed document somewhere and assuming the next person will notice. Confirm that the response has reached the coordinator and that the next action has an owner.
Agree how overdue items will be escalated. Raise a likely delay before it affects the next activity, with the specific decision or assistance required. If the team is co-located, a short conversation may resolve the blockage much faster than another round of emails. Record any resulting decisions afterwards.
Finally, look for recurring problems. If requests repeatedly stall at the same stage, investigate the workload, access, instructions or approval arrangements. Automated reminders may help with forgotten tasks, but they will not correct an unclear process.
Lesson: Make Responsibility Clear at Every Handover
An alliance can provide considerable project benefits, but the participating organisations still need a practical way to move information, decisions and approvals between them.
Do not assume that working together means everyone understands the process. Establish who must act, what they must do, when they must finish and where the result goes next. Make it equally clear who is receiving information without being asked to respond.
Keep the procedures easy to follow, make the documents accessible, and track the work through to completion. Preserve the required checks and authorisations while removing avoidable confusion and waiting.
The test is simple: can someone receive a document and know exactly what to do with it? If they cannot, improve the request or the process before sending more reminders.
