Fixed Price, Fixed Date, Moving Requirements
A software house has signed a fixed-price contract to deliver a claims-processing system for an insurer in 20 weeks. The contract lists 60 requirements and states that acceptance occurs only when all are delivered. The insurer's operations manager, who acts as product owner, is available one hour per week. In week 7, the team discovers that the claims rules engine cannot meet the stated performance requirement without a redesign that adds four weeks. At the same time, the insurer requests a new fraud-check feature that is not in the contract. The delivery manager wants to stop all demos until the redesign is complete, work overtime, and add the fraud check 'to keep the client happy'. The team has already missed one timebox and morale is dropping.
1. Which DPMM principles are under pressure in this situation, and what does each require here?
Read the worked answer
Several principles are under pressure. Focus on the business need: the fraud check may add value, but it is outside the contract and has not been prioritised against the 60 agreed requirements. Deliver on time: the four-week redesign threatens the 20-week date. Never compromise quality: overtime and cancelled demos would hide quality problems rather than solve them. Collaborate: one hour a week from the product owner is not meaningful collaboration for a project of this complexity. Demonstrate control: stopping demos removes the evidence the insurer needs to see progress and make decisions.
The performance shortfall is a real technical constraint, not a failure of effort. Each principle requires a visible trade-off, not a silent workaround. The first step is to quantify the gap: is performance 10% short or 300% short? That determines whether redesign, scope reduction, or acceptance with a defined tolerance is viable.
The delivery manager's proposals address symptoms - visibility, morale, client satisfaction - with actions that increase risk. The principles should drive a structured decision, not a heroic sprint.
2. Evaluate the delivery manager's three proposals.
Read the worked answer
Stopping all demos until the redesign is complete should be rejected. It hides progress, breaks collaboration, and increases the chance of late discovery. Demos can continue by showing the constraint and the options being evaluated. Working overtime should also be rejected as a default plan. It masks the estimation problem, risks quality, and is unsustainable. A short, explicit recovery period with a cap and monitoring may be acceptable, but it is not a strategy. Adding the fraud check to keep the client happy should be rejected as uncontracted scope. It adds cost and risk and undermines prioritisation. It should be logged as a change request, estimated, and traded against something else.
The common flaw is that all three proposals absorb a problem without changing the plan or the contract. That may look responsive, but it transfers risk to the team and to the delivery date. The project manager should not let any of them become the plan by default.
A better response is to present data and options, then ask the insurer to decide what to trade: date, scope, performance tolerance, or cost.
3. Propose a way forward that respects both the contract and collaboration.
Read the worked answer
Hold a facilitated workshop with the insurer product owner, delivery lead, and architect. Present the performance test data and three options. Option 1: redesign, moving the date four weeks or removing scope of equivalent effort. Option 2: reduce the performance requirement to an agreed tolerance, with the insurer's written acceptance. Option 3: phase delivery - launch with the current engine for standard claims and redesign for complex claims after launch.
For the fraud check, require a change request with an estimate and a MoSCoW position. If it is a Must, something else must go. Increase product owner engagement to a fixed weekly decision slot plus written decisions between sessions. Agree quality gates and a demo schedule that continues through the redesign.
Record the outcome as a contract change note or schedule amendment, including acceptance criteria and responsibilities. This respects the contract while applying DPMM principles: business case, collaboration, quality, and control. It also gives the team a clear, bounded problem instead of an open-ended demand to work harder.