The Reporting Project That Keeps Slipping
A university's IT faculty is building a new enterprise reporting dashboard for 300 staff. The project is 5 weeks into a 12-week schedule. The business analyst left in week 3 and was not replaced. The project manager has been reporting "on track" because the Gantt chart still shows tasks finishing on their original dates, but two developers say they are blocked waiting for data definitions that the analyst was meant to produce. The steering committee meets monthly and has approved no change requests. The vendor supplying the data warehouse has delivered its interface two weeks late, and the project manager quietly moved the integration task later on the chart to absorb the delay without telling the committee.
1. Identify the project control failures and recommend what the project manager should do before the next steering committee meeting.
Read the worked answer
Several control failures are visible. First, status reporting is based on the plan's original dates rather than on evidence of progress, so "on track" is false: two developers are blocked on data definitions that no longer have an owner. Second, the loss of the business analyst is a resourcing risk that was never escalated or mitigated; the role's outputs are on the critical path and nobody has picked them up. Third, the project manager absorbed the vendor's two-week delay by silently moving the integration task, which hides a schedule variance from the body that governs the project. Fourth, the monthly steering cadence is too slow for a project with weekly dependencies, and no change requests have been raised despite a scope-relevant delay.
Before the meeting the project manager should re-baseline honestly: establish actual progress against deliverables, quantify the blocked work, and calculate the real schedule impact of the missing analyst and the late interface. A change request should be prepared covering the revised dates and the options to recover, such as backfilling the analyst role, reallocating data-definition work to an existing team member, or reducing scope for the first release. The committee should be told about the silent date change, because concealing it undermines the governance the committee exists to provide. The manager should also propose a shorter reporting cycle, such as weekly status with a monthly committee, so blockers surface before they compound.
2. The steering committee must decide between delaying the dashboard and cutting scope for the first release. Recommend a decision process and the criteria to apply.
Read the worked answer
The committee should not choose on preference; it should choose on criteria tied to the project's purpose. First, establish who the 300 staff are and which reports they actually need on day one, because a dashboard that delivers the highest-value reports late may be worse than one that delivers fewer reports on time. Second, assess the cost of delay: if the dashboard supports a fixed event such as a semester start or an accreditation deadline, delay may be unacceptable and scope reduction is the only viable route. Third, assess the cost of cutting: which reports can be deferred without leaving users worse off than they are today, and can the deferred items be delivered in a defined second release?
The process should be: the project manager presents the honest re-baseline and at least two options with their impacts; the committee applies the criteria (deadline criticality, user value, risk of deferral, effort to recover); the decision is recorded as an approved change with a revised baseline; and the committee sets a checkpoint to confirm recovery is working. The recommendation should also address the underlying cause, the unfilled analyst role, because without it any option chosen will continue to slip.