ERP Change Control Under Sponsor Pressure
Northwind Distributors is seven months into a 14-month ERP rollout covering finance, order-to-cash, and warehouse operations. The change log holds 46 requests. The steering committee has approved 22 of them during 30-minute calls, each without an impact analysis; the project manager later discovers that three high-visibility additions-a custom pricing engine, mobile approvals, and a rewrite of 14 legacy reports-were accepted verbally by the sponsor and never entered the WBS. The approved baseline has five weeks of schedule float, but systems integration testing is already nine days late. The vendor estimates the pricing engine alone at 600 hours. Two team members resigned last month after sustained 55-hour weeks, and the remaining analysts are triaging defects informally. A change control board exists in the charter but has not met in 11 weeks. The sponsor says the three additions are 'small' and must stay; the go-live date is tied to a customer contract.
1. Identify the root causes of the control failure and describe the first five actions you would take in the next two weeks. Explain why each action addresses the cause rather than the symptom.
Read the worked answer
Root causes, not symptoms. The late integration test and overtime are symptoms. The causes are: (1) no working integrated change control-22 approvals without impact analysis means the CCB is a rubber stamp; (2) verbal sponsor approvals bypass the change log and WBS, so scope is not baselined; (3) no capacity check against 600 hours and two resignations, so commitments are made without resources; (4) configuration management is informal, which is why testing is late. Next two weeks: 1. Freeze new change intake except safety or regulatory items. 2. Reconstruct the change log from email, meeting notes, and the WBS; classify each request as approved, rejected, or pending, with cost, schedule, and risk impact. 3. Convene the CCB with a written decision charter and the sponsor present; decide the three verbal changes first. 4. Publish a one-page change process: no work starts before a logged request and impact assessment. 5. Re-plan the integration test sequence against the true scope and remaining capacity, including the two resignations. These actions address decision rights, baseline integrity, and capacity-not just the visible testing delay.
2. The sponsor insists that all three additions stay because they are 'small.' How should the project manager respond, and what would a defensible decision look like?
Read the worked answer
Treat the sponsor's demand as a decision to be informed, not a request to be refused. Prepare a one-page options analysis for the three additions: custom pricing (600 hours is about 3.4 person-months at 176 hours per month), mobile approvals, and the 14-report rewrite. Show each option's effect on the critical path, cost, risk, and the customer contract. Then offer 'yes, if' choices: (a) approve all three with a formal change request, added funding, a re-baselined go-live date, and named resources; (b) defer mobile approvals and the report rewrite to phase 2, keeping pricing if it protects the customer contract; (c) approve pricing only and buy contract testing capacity. Do not accept 'small' as an impact assessment. If the sponsor still insists, document the decision, update the scope, schedule, and cost baselines, and record who accepted the resulting risk. The project manager's job is to make the trade-off explicit, not to absorb it silently through overtime.
3. Some of the unapproved change work has already been built. What should the project manager do with that work, and what principles govern retroactive approval?
Read the worked answer
Work already performed on unapproved changes cannot be treated as approved just because it exists. First, identify what was built, by whom, at what cost, and whether it is in the integration test environment. Second, stop further work on those items until the CCB decides. Third, assess each item on value, risk, and reversibility: if the custom pricing engine is strategically necessary, submit a retroactive change request with full cost and schedule impact and get formal approval; if the report rewrite is low value, remove it and archive the work. Fourth, update configuration management records and the WBS so the baseline matches reality. Fifth, communicate the decision to the team without blaming them-they were responding to sponsor requests-and capture the lesson in the change-control process. Retroactive approval is acceptable only with full disclosure and a baselined decision; otherwise it becomes another uncontrolled change.