EXIN Dynamic Project Management Method Foundation study materials
EXIN Dynamic Project Management Method Foundation study resources

Shared Architect, Split Sites, and an Audit Clock

EXIN Dynamic Project Management Method Foundation · Put your knowledge to work in context.

All case studies

Shared Architect, Split Sites, and an Audit Clock

A regional water utility is replacing its billing engine while a regulatory audit is scheduled in five weeks. The project runs in a matrix organisation. The lead architect is shared with operations and is available two days a week. The product owner is the billing manager, who is also running the audit and can give the project about one hour a week. The team is split across two sites with no overlapping working hours. Tariff configuration changes need sign-off from the finance director, who has a two-week approval queue. Two timeboxes have ended with incomplete increments, mostly because requirements and acceptance decisions waited for the product owner. The sponsor asks the project manager to 'speed up delivery' without moving the date or budget. The audit will inspect evidence of controlled change, so dropping documentation is not acceptable. The team suggests cancelling the daily cross-site coordination call to save time.

1. Analyse the contextual constraints that are actually slowing delivery.

Read the worked answer

The delay is not mainly a team-speed problem; it is a decision-capacity and context problem. The product owner has one hour a week and is also running the audit, so requirements and acceptance decisions queue. The shared architect is available two days a week, creating a design bottleneck for tariff changes. The two sites have no overlapping hours, so questions wait overnight. The finance director's two-week approval queue adds serial delay to every tariff configuration change. The audit requires evidence of controlled change, so removing documentation would increase risk, not speed.

Cancelling the daily coordination call would reduce visibility across sites and increase rework. The real symptom is work waiting for decisions, not developers typing slowly. I would measure decision lead time and blocked time per increment to confirm this. That evidence changes the conversation from 'work faster' to 'remove the waiting'.

The context also includes a hard audit date and a regulated environment. Any change must preserve traceability. A solution that speeds up delivery by bypassing sign-off would create a bigger issue later.

2. Propose changes to decision rights and governance that fit this context without violating audit needs.

Read the worked answer

Redesign decision rights around the actual constraints. First, the billing manager should name a deputy product owner with authority to accept increments and prioritise within an agreed budget; both attend one weekly decision forum. Second, replace ad hoc architect access with a scheduled twice-weekly design clinic and written decision records. Pre-agree design patterns for tariff configuration so routine changes do not need architect approval.

Third, create a tariff change panel with a named finance representative and a 48-hour service level. Use a standard change template so audit evidence is created as a by-product of the change, not as separate documentation. Fourth, keep coordination but shorten it to a 15-minute cross-site call with a shared board, and add a written handover at the end of each site's day.

Fifth, agree an escalation path for missed service levels, with the sponsor as final arbiter. These changes preserve controlled-change evidence while removing waiting. They also make the product owner's limited time focus on decisions only they can make, rather than routine acceptance.

3. The sponsor says: 'I don't care about governance, just make the team faster.' How do you respond?

Read the worked answer

I would acknowledge the pressure and then reframe the request with evidence. 'Faster' is not an action the team can take while work is blocked waiting for decisions and approvals. I would show the decision lead-time data and the blocked time per increment, then propose the specific governance changes that reduce waiting. That makes the response concrete rather than defensive.

I would also explain the audit risk in business terms. If we bypass controlled change to save two weeks now, the audit may force rework or findings that cost more later. The audit is not optional context; it is a project constraint. The sponsor can choose to accept audit risk, but that choice must be explicit and recorded, not hidden inside a delivery instruction.

Finally, I would offer a trade-off: if the date cannot move, reduce scope in the next timebox to work that does not need tariff changes, while the decision-rights changes are implemented. That gives the sponsor visible progress without pretending the governance constraint does not exist.