The nominal 20% DBA in a weak matrix
Northbridge Retail has run IT as a functional department for nine years. You are the newly appointed project manager for a 26-week migration of the merchandising data warehouse to a cloud platform. The sponsor is the CIO. The lead DBA, Priya, is formally allocated 20% to your project but remains in the infrastructure team and reports to the infrastructure manager. In practice she attends your stand-up twice a week, then is pulled into production incidents; her project tasks are 5 weeks late. The infrastructure manager says production always wins and has not agreed to backfill. Your steering committee meets monthly. The business case promises £1.2m annual savings from faster reporting, and the finance director has already publicised the date. Two of your six deliverables depend on Priya's schema design. The team is co-located but uses three different task boards. The sponsor tells you to 'just make it work' and not to escalate yet. What do you do?
1. Diagnose the organisational structure in this situation and explain two concrete ways it is already distorting the project. What must you avoid assuming?
Read the worked answer
This is a weak matrix. You coordinate the work, but the infrastructure manager controls Priya's time, priorities and performance review. The project charter gives you accountability without matching authority.
Two concrete distortions:
- Nominal allocation is treated as real capacity. The 20% figure has no schedule, no reserved hours and no incident threshold. Production incidents consume the time first, so the schema design sits on the critical path and two of six deliverables slip. The plan is late for a reason that is visible but not owned.
- The functional chain is the real decision forum. Priya's priorities are set in infrastructure meetings you do not attend. Your task boards record activity, but they do not resolve priority conflicts. Three boards make this worse because no single artefact shows the true queue.
Do not assume that 20% means one day a week, that co-location creates authority, or that a monthly steering committee is fast enough to manage a weekly capacity conflict. Do not assume Priya is disengaged; she is responding to the incentives her line manager sets. Also do not assume escalation is a relationship failure. Escalation with options and impact is part of the PM role; 'just make it work' is not a plan.
2. Build a 30-day plan to secure Priya's capacity and put the dependency under control. State what you will measure and what you will escalate if the plan fails.
Read the worked answer
Days 1-3: quantify the demand. Break Priya's schema work into tasks with effort estimates and dependencies. Identify the two affected deliverables, their float and the cost of a one-week slip. Replace '20%' with a request for named hours over named weeks.
Days 4-7: negotiate options, not blame. Meet the infrastructure manager with three choices: a contract DBA backfill for 12 weeks, a deputy DBA who takes production incidents while Priya protects design time, or fixed protected hours with an agreed incident escalation threshold. Ask him to choose and record the decision. Give him the production risk of each option; do not present the project as more important than operations.
Days 8-14: document the agreement. Write a short service-level agreement covering reserved hours, response expectations, review cadence and what happens during a severity-1 incident. Put it in the RAID log and the project plan. Consolidate the three task boards into one source of truth for dependencies.
Days 15-30: run the dependency review. Track Priya's actual project hours weekly, the number of production pulls, milestone variance and rework caused by late design. If actual availability stays below the agreed threshold for two consecutive weeks, escalate to the sponsor with options and schedule impact, not a complaint. Ask the sponsor to decide between accepting delay, funding backfill or changing scope.