TL;DR
- A real estate developer's project approval ran through 14 sequential steps, averaging 21 days. Three of those steps only happened at a monthly board meeting.
- We mapped the true dependencies. Most steps were sequential by habit, not by necessity. True dependencies reduced the chain to 4 stages.
- We built parallel Power Automate branches for Finance and Legal running simultaneously, followed by Commercial and Operations running simultaneously.
- Average approval time for standard projects after go-live: 4 hours. Monthly board bottleneck: eliminated entirely.
When we first mapped the project approval process at a real estate development company, we drew it on a whiteboard. By the time we finished, the diagram covered the entire wall. 14 approval touchpoints. Every single one sequential. Each person waited for the one before them to finish before they could start.
Nobody knew where in the process a request currently was unless they sent an email asking. The project manager who submitted it would wait. Then email. Then wait again. The average time from project request to approval: 21 days. For one signature at the end.
The Process As We Found It
The approval chain, in order: Project Manager submits, Quantity Surveyor reviews, Senior QS reviews, Finance Analyst reviews, Finance Manager reviews, Finance Director reviews, Legal reviews, Commercial Director reviews, Operations Director reviews, Group MD reviews, submission to monthly Board meeting, CEO sign-off. Twelve named steps, plus the Board meeting which could add another 30 days if the request missed it by a day.
Three of these steps only happened at fixed calendar points. The Board meeting was monthly. If a project request arrived on the second of the month and the meeting was on the first, that request waited 30 days before it could progress — not because anything needed 30 days of preparation, but because the process had been designed around a meeting that nobody had thought to question.
Projects were being delayed not by complexity, not by anything substantive about the approvals themselves, but by calendar accidents. A request that missed the board meeting by one day waited as long as one that needed a full month of investigation.
14 sequential steps with no parallelism. The monthly Board meeting created a 30-day cliff-edge — miss it by one day, wait another month. Most steps had no genuine dependency on the one before them.
The Process Re-Mapped
Before we opened Power Automate, we spent two days doing one thing: asking "does this step actually depend on the previous one?" For each of the 14 steps, we asked the process owner to explain why it had to come after the step before it.
The answers were revealing. The Finance Analyst and Legal Reviewer reviewed completely different aspects of the project — budget versus contractual risk. There was no reason they couldn't review simultaneously. The QS and Senior QS reviewed different elements too — initial cost estimate versus final verification. Parallel was fine.
The Commercial Director and Operations Director both needed to have seen the Finance and Legal reviews before forming their view. That dependency was real. But they didn't need to wait for each other — they could review the Finance and Legal outputs simultaneously.
The monthly Board meeting? After mapping the dependencies, we showed the process owner that CEO approval was the actual final authority. The Board meeting had been the approval mechanism because "that's how we always done it" — not because the Board needed to vote on every project. CEO approved the new process. Monthly cycle removed.
True dependencies reduced the chain from 14 sequential steps to 4 stages. Not because we removed any approvals — all the same people still reviewed the same information. Just not one at a time.
The rebuilt process: Finance and Legal run in parallel simultaneously. Once both complete, Commercial and Operations run in parallel. CEO receives a single summary card with all approvals captured. Standard cases: 4 hours total.
What We Built in Power Automate
An SPFx project request form on SharePoint. The form captures: project scope (structured fields, not free text), budget request, timeline, risk assessment (Low/Medium/High/Critical dropdown plus description), and whether the project involves overseas elements or exceeds the £5M threshold. These last two flags drive the routing logic.
On submission, Power Automate uses parallel branch controls to trigger the Finance review chain and the Legal review simultaneously. Both approvers receive Teams Adaptive Cards at the same moment. Their reviews are completely independent — the Finance reviewer doesn't see Legal's decision and vice versa at this stage. Each works from the original project submission.
Once both Stage 2 branches complete, the flow resumes and triggers Stage 3 — Commercial Director and Operations Director receive simultaneous Teams cards. Each card shows the Finance and Legal decisions already made, giving them the context they need.
When both Stage 3 reviews are done, the CEO receives a single summary card. It shows the project details, the Finance decision, the Legal decision, the Commercial Director decision, and the Operations Director decision. One click: Approve or Request More Information. No hunting across emails. No separate documents. Everything in one card.
The Monthly Board Meeting Problem
This deserves its own section because the conversation about removing it was the most important one in the project.
We asked the process owner: "Who has the actual authority to approve a standard project?" The answer was the CEO. "So why does it go to the Board?" The answer: "Because that's how we set it up when we started." Not because the Board needed to vote. Not because there was a governance requirement. Because nobody had questioned the original design.
The CEO confirmed that they could approve independently. The Board meeting step had added an average of 8 days to every single project approval — some months closer to 30 — without providing any governance value that the CEO's direct review didn't already provide. We removed it. The CEO now receives a Teams card directly. Average response time from the CEO in the first 3 months: 47 minutes.
Calendar-based approval steps are almost always an artefact of the process era they were designed in — when email was the mechanism and someone had to collect approvals manually. When you move to digital flows, calendar-based bottlenecks usually have no technical justification. Question them every time.
Handling the Exceptions
Not every project goes through the standard 4-stage flow. Projects over £5M route to a board subcommittee in addition to the CEO. High-risk projects add a Risk Director branch at Stage 2. Projects with overseas elements add a Compliance review branch alongside Legal.
We built all of these as conditional branches in Power Automate. The SPFx form detects the project value and risk flags from what the PM entered, and Power Automate routes accordingly. The project manager doesn't choose which approval chain to use — the system detects it from the form data and routes correctly every time. No manual triage. No "I wasn't sure which form to use." The intelligence lives in the flow.
This also means that as the business adds new approval categories in the future, they can add conditional branches without rebuilding the core flow. The architecture accommodates growth.
Results After 6 Months
Six months in, the process owner reported that project teams had stopped padding their timelines to account for approval delays. Before, teams built 3-week buffer into project plans because they knew approval could take 3 weeks. That buffer is gone. Projects start faster, which has a compounding effect on delivery timelines across the portfolio.
The Lesson That Applies to Every Approval Process
Sequential approval chains are almost never fully justified. Every step that could run in parallel should run in parallel. Every dependency assumption should be questioned. Every calendar-based bottleneck should be challenged.
The people inside the process almost never challenge these things because they're busy running the process. They've adapted to the 21-day cycle. They've built it into their expectations. An outside eye — someone who maps it from scratch and asks "why is this step here, and why does it come after that one?" — will find that 30 to 50% of sequential steps are sequential purely by habit.
That's not a criticism of the people who designed the original process. They designed it with the tools available at the time. Email-based approvals are naturally sequential because you send one email, wait for a reply, send the next. Power Automate doesn't have that constraint. Parallel is the default. Sequential is the special case that needs a justification.
Map your current process on a whiteboard first. For every sequential step, write one sentence explaining why it must come after the previous step. If you can't write that sentence confidently, the steps can probably run in parallel. Most teams find they can parallelise 3 to 5 steps they assumed had to be sequential.
Key Takeaways
Most sequential approval chains are sequential by habit, not by genuine dependency. Mapping true dependencies before building the flow typically finds 30 to 50% of steps can run in parallel.
Calendar-based bottlenecks — monthly meetings, weekly sign-off sessions — almost never survive scrutiny when you ask "who has the actual authority to approve this?" Question them every time.
Conditional routing in Power Automate means the form detects the approval chain from the data — project value, risk level, geography — and routes correctly automatically. No manual triage, no "which form do I use?"