Lesson 1 of 5
Why underestimation happens
9 min
Ask any experienced SAP program lead which workstreams blew their estimates, and two names come up again and again: testing and data migration. Neither is underestimated because people are careless. They are underestimated because their effort depends on things nobody knows when the plan is written: how many defects the build will contain, how dirty the legacy data really is, and how much time the business can actually give. This lesson names the patterns, so you can spot them in your own plan before they spot you.
Where the effort hides
A first-draft estimate usually counts the visible work: test cases to execute, objects to load. The bulk of the effort sits below that line. It is the preparation, the retesting, the reconciliation and the coordination that make the visible work possible and prove that it worked.
Seven patterns to look for
- The single pass. The plan assumes every test case runs once and passes. In reality a share of cases fail, are fixed, are retested, and trigger regression of neighbouring processes.
- Counting cases, not cycles. SIT is planned as one block of weeks rather than as two or three cycles, each with its own entry criteria and its own retest window.
- Borrowed business time. The plan assumes key users are available whenever testing needs them, while they are also closing the books, serving customers and attending training.
- Migration as a technical task. Data migration is estimated as extract, transform and load work for IT, leaving out cleansing, business validation and sign-off, which are business effort.
- The bid estimate. The number in the plan came from a proposal written to win a deal, before anyone had seen the data or the custom code.
- Backward planning. The go-live date is fixed first, and testing gets whatever weeks are left after build. That is a schedule, not an estimate.
- Forgotten test types. Authorizations, output forms, interfaces, batch jobs, period-end close and performance are missing from the scope count, then discovered in UAT.
These patterns rarely appear alone. A plan that counts cases rather than cycles usually also assumes business time it has not asked for, because both come from the same habit: estimating the happy path.
- Build finishes three weeks lateGo-live date stays fixed; nobody re-estimates
- SIT is compressedCycle 2 is merged into cycle 1; regression is dropped
- UAT overlaps SITBusiness testers find integration defects SIT should have found
- Defects pile upFix capacity is shared between SIT and UAT; retest waits
- Go-live with open defectsSign-off becomes a negotiation, not a decision on evidence
What this looked like at Contoso
When Grace, Contoso's PMO lead, reviewed the plan she inherited at the start of Realize, she found a single SIT block of four weeks for about 180 end-to-end test cases, with no time for retest, and UAT of two weeks starting the Monday after SIT ended. The data workstream had a line called "data migration" with technical build effort and two mock loads, and no hours at all for business validation. Maria, the order-to-cash key user, and Dan, the finance process owner, were shown as available for UAT during the week of the quarter-end close.
None of these numbers was wrong in isolation. Each was simply the happy-path figure. Grace's job was not to pad them, but to make every assumption visible, replace guesses with drivers, and show the steering committee what the real range looked like.
| Source of optimism | What it looks like | Counter-measure |
|---|---|---|
| Happy path | One pass, no failures | Model retest and regression explicitly as a percentage of execution |
| Anchoring | Estimate starts from the bid or the date | Re-estimate bottom-up from scope; compare, then explain the gap |
| Invisible business effort | Key users not in the resource plan | Name each person, week by week, and get line-manager agreement |
| Unknown data quality | Cleansing assumed small | Profile the legacy data early and size cleansing from error rates |
| Single-point numbers | Exactly 6 weeks | Give ranges (optimistic, most likely, pessimistic) and say which one the plan uses |
Common sources of optimism and how to counter them.
What would you do?
The executive sponsor asks Grace to confirm that Contoso's testing will fit in the six weeks shown in the original plan. Grace's first bottom-up look suggests eight to eleven weeks. What should she do?
- Testing and migration effort depends on defects, data quality and business time, which are unknown at plan time.
- Most of the effort sits below execution: preparation, rework loops, proof and coordination.
- Watch for the single pass, cases-not-cycles, borrowed business time, migration-as-IT, bid estimates, backward planning and forgotten test types.
- A fixed date with the remaining weeks given to testing is a risk to report, not an estimate.
Check your understanding · not graded
Lesson check
1. Why are testing and data migration so often underestimated in SAP programs?
2. Which item is most often missing from a first-draft test estimate?
3. A plan gives testing the weeks left between end of build and a fixed go-live date. What is that?
4. Why is "migration as a technical task" a trap?