By project
All tasks, this session and before
Demo
In an illustrative shared services rollout, a supplier slips as leadership asks for an earlier launch. The Programme Sponsor decides the response. Then test a change to one recurring step across all 4 waves.
Respond to a change in plans
An organisation is moving HR, finance and procurement requests into a shared services centre, in 4 waves. The objective: cut service turnaround from 6.0 to 3.0 working days per request while keeping service quality and control. Wave 1, 1,200 staff at head office, is planned to go live in week 12.
Illustrative example. Fictional data. Weeks count working days from today, 5 to a week. Amounts in AED, for illustration only.
Leadership wants go-live in week 9, not 12, and a supplier is 3 weeks late. Launched together, services slip to week 15; each week past plan defers AED 150,000 (AED 7.8M ÷ 52), counted once.
Programme Shared services programme 4 waves · 4,800 staff
Wave 1 · first user group
1,200 staff at head office
Target: 3.0 working days per request, from 6.0
Forecast go-live: week 15 · approved plan: week 12
Deferred savings AED 150,000 per week AED 7.8M agreed annual saving ÷ 52 programme figure, counted once
Gap to the requested week 9: 6 weeks
The finance test environment is 2 weeks late as well. It overlaps the supplier delay, so it adds no time.
What affects the launch
Deferred savings count against the approved plan.
Dependencies come from the programme plan; the simulated analysis puts the critical path through the supplier. The two delays overlap, so go-live moves 3 weeks, not 5.
Shared services programme Wave 1 · first user group
| # | Activity | Owner | Waits for | Due, plan | Due, now |
|---|---|---|---|---|---|
| 1 | Finance module from the supplier | Procurement lead | — | Week 4 | Week 7 (moved) |
| 2 | Finance test environment | IT lead | — | Week 4 | Week 6 (moved) |
| 3 | HR and procurement configuration | IT lead | — | Week 4 | Week 4 |
| 4 | Finance configuration | IT lead | 1 and 2 | Week 6 | Week 9 (moved) |
| 5 | User acceptance testing | Operations lead | 3 and 4 | Week 8 | Week 11 (moved) |
| 6 | Finance controls sign-off | Finance lead | 5 | Week 9 | Week 12 (moved) |
| 7 | Training, first user group | People and training lead | 5 | Week 11 | Week 14 (moved) |
| 8 | Readiness review and go-live | Operations lead | 6 and 7 | Week 12 | Week 15 (moved) |
Effect on go-live Simulated
Decisions needed
Launch approach for wave 1
Programme Sponsor Authorised person
Extra capacity hours
Programme Sponsor Authorised person
The Programme Manager and team leads compare two responses: all services in week 15, or HR and procurement in week 9 and finance in week 12. Phasing defers no savings but needs 280 more hours.
Wave 1: two responses compared
Dates: forecasts from completed steps in 2 earlier rollouts. Hours and service level: advisory estimates.
| Full launch | Phased launch | |
|---|---|---|
| HR and procurement go-live | Week 15 | Week 9 |
| Finance go-live | Week 15 | Week 12 |
| After the requested week 9 | 6 weeks later | On time; finance 3 weeks later |
| Deferred savings, at AED 150,000 a week | 3 weeks | None |
| Extra capacity hours | 210 h | 490 h |
| Within service level, first 4 weeks (estimate) | 80% | 74% |
| Schedule risk | Every service waits for the supplier | No float before week 9 |
Trade-off The phased launch meets week 9 for three quarters of requests and defers no savings. In return it needs 280 more capacity hours, starts at a lower service level in the first 4 weeks (74% against 80%) and leaves no float before week 9.
Comparing options is advisory work, supported by forecasts from history (built, pre-production). A comparison screen in the product is planned.
An AI agent checked the supplier's evidence and recommended, and people reviewed. The Programme Sponsor decided, with one condition on the week-9 readiness review.
Decision chain: wave 1 launch approach
Readiness check of the supplier's evidence 3 findings
Check and summary
Readiness Agent AI agent
3 findings in the supplier's evidence; recommends planning finance separately
Recommendation
Programme Manager Person
Recommends the phased launch
Review
Finance lead · Operations lead Person
Savings and controls; service level and capacity
Decision
Programme Sponsor Authorised person
Chose the phased launch and approved 490 extra hours
Condition If the week-9 readiness review is not passed, HR and procurement go live with finance in week 12.
Four kinds of action
Every team gets a named owner and an agreed date, and the decision is recorded with its evidence. Each measure keeps a baseline, a target and a forecast; actual results come only after go-live.
Wave 1, after the decision
Owners and agreed dates
Reminders go out automatically under the agreed rules; an escalation is sent only once a person confirms it.
Decision record
Wave 1 measures
| Measure | Baseline | Target | Forecast | Actual |
|---|---|---|---|---|
| Turnaround, working days per request | 6.0 | 3.0 | 3.5 | Not yet measured |
| Requests within service level (5 working days) | 64% | 90% | 85% | Not yet measured |
| Requests resolved right first time | 82% | 95% | 92% | Not yet measured |
Actual results come only from real operation, measured 8 weeks after each go-live the same way as the baseline.
Improve the operating model
A separate question: not how to respond to one delay, but which steps recur in every wave and who should do them. In the simulation, the baseline comes from comparable checks in the organisation's earlier rollouts.
Illustrative example. Fictional data; the figures are simulated projections, not results.
Before each wave, a Procurement analyst checks every supplier's readiness evidence by hand, and the check takes most of the time before approval. It is a check, not a decision: the Procurement lead approves.
Where the time goes: supplier readiness, per wave
Baseline from 10 earlier checksEvidence received to readiness approval The check takes 6 of 7 working days
Checking each supplier's readiness evidence, about 60 items
A check, not a decision: the Procurement lead still approves each wave's supplier readiness.
From wave 2, the Readiness Agent runs the check and the analyst reviews what it flags, plus a sample. The Procurement lead still approves, and nothing changes until the Programme Sponsor decides.
What-if: supplier readiness, waves 2 to 4
Baseline from 10 earlier checksChange being tested
Supplier readiness check, before each wave
Now Procurement analyst Person
Moves to Readiness Agent; the analyst reviews what it flags AI agent
Stays with a person
Supplier readiness approval
Procurement lead Authorised person
Applies from wave 2. Nothing changes in operation until the Programme Sponsor decides on the evidence.
The projection states what it rests on: where each figure comes from, what a person still reviews, and what stays the same.
What-if: supplier readiness, waves 2 to 4
Baseline from 10 earlier checksAssumptions behind the forecast
The projection shows the effect on days per wave, analyst hours and issues found before approval. The cost: items the agent flags that turn out fine, which a person must still clear.
What-if: supplier readiness, waves 2 to 4
Baseline from 10 earlier checks| Measure | Baseline | Projected |
|---|---|---|
| Evidence received to approval | 7 working days | 3 working days 4 days, about 57% shorter |
| Analyst hours | 30 h | 10 h |
| Issues found before approval | 4 of 7 | 6 of 7 |
| Hours freed, waves 2 to 4 | No baseline | 60 h |
| Trade-off: flagged items that turn out fine | No baseline | 6 per wave |
After wave 2, we measure each result the same way as the baseline and compare it with the target and the forecast. Actual results come only from real operation, so this example shows none.
The tested change, waves 2 to 4
| Measure | Baseline | Target | Forecast | Actual |
|---|---|---|---|---|
| Evidence to approval, working days per wave | 7 | 4 | 3 | After wave 2 |
| Analyst hours per wave | 30 h | 15 h | 10 h | After wave 2 |
| Issues found before approval, per wave | 4 of 7 | 6 of 7 | 6 of 7 | After wave 2 |
Supporting simulation
Every department is a nerve, and at the end of each one are the people and AI agents doing the work. Their task updates flow into ZedNerve, which spots what is late or waiting for approval and sends that back to where it is needed.
Illustrative simulation. No real people, departments or projects.
Hover over or tap a person or an agent to see their task. Tap a department to send its data, or tap the brain to run a check.
Departments in the simulation · tap to switch one off
Activity feed
Project status
Every task held by a person or an AI agent in the simulation, rolled up by project, department and owner. It changes as the simulation runs.
All tasks, this session and before
Open tasks over the last few minutes
All tasks
Who holds which work
Overdue first, then work waiting for a person to approve
In a conversation, we show the interactive demo and map your departments and approval rules onto ZedNerve. A pilot then runs on one real process for about 12 weeks, in an environment agreed with you. The interactive demo currently follows a property-development programme.