Progressive Elaboration for Effective Onboarding

Hello again. Last lesson distinguished an unverified assumption from a dependency, a risk, and an issue. That vocabulary helps you describe what is unknown. The next challenge is planning work around those unknowns without either waiting for perfect information or pretending you already have it.

An enterprise onboarding may have a clear destination—approved production data flow and appropriate users able to sign in—while the route remains uncertain. You may not yet know the source data’s shape, the identity team’s available configuration, or which historical records can be transferred. This lesson introduces progressive elaboration: keep the destination and essential constraints visible, plan the work you can responsibly specify now, and add detail to later work as evidence arrives.

A plan can be honest without being vague

A plan built on unknowns often fails in one of two ways. It may specify every future task and date as if early guesses were facts. Or it may say little more than “discover, build, launch,” leaving nobody sure what to do next. Progressive elaboration avoids both extremes by giving different parts of the plan different levels of detail.

Rolling wave planning is a practical way to apply that principle. Near-term work is planned in enough detail to execute and assess. Work farther away retains its outcomes, major dependencies, and decision points, but not task-level detail that discovery is likely to invalidate.

Watch What is Rolling Wave Planning? - How to Create a Rolling Wave Plan from Online PM Courses – Mike Clayton for a short visual explanation. Treat the time horizons he gives as illustrations, not as a prescribed schedule for an onboarding.

The useful boundary is a planning horizon: how far ahead you can specify work with reasonable confidence. It is not necessarily a fixed number of weeks. If an approved sample and field definitions are available, you may be able to plan a mapping review in detail. If the customer has not yet identified an owner for its historical archive, a detailed historical-load schedule would be largely invented. The horizon can therefore differ across workstreams within the same onboarding.

Read the linked portions of Plane’s Rolling wave planning in project management: When and how to use it. They distinguish the broad principle from its repeatable planning method, then show the checks that make the method controlled rather than improvised.

The key distinction is that progressive elaboration describes what happens to your understanding; a rolling wave provides a deliberate occasion to update the plan. New evidence does not merely make an old plan more detailed. It may disprove a premise and require a different implementation choice.

Keep guardrails firm and implementation choices open

Before adding detail, separate three kinds of information:

A planned date needs the same honesty. An externally committed date, an internal target, and a tentative estimate are not interchangeable. A firm date may constrain your options, but it does not turn an unknown export format into a known one. If evidence shows that the agreed outcome cannot be reached within a constraint, make that conflict visible for a decision; do not quietly redefine success.

This is also why progressive elaboration is not permission for uncontrolled scope change. Discovering which fields belong in an already agreed feed is elaboration. Adding a newly requested source system may change the agreed scope. The former can often be resolved within the onboarding plan; the latter needs evaluation and the appropriate approval. Both may emerge during discovery, but they should not acquire the same status merely because they appeared at the same time.

The image below summarizes a useful rhythm. Read it as a recurring discipline, not as six steps performed once at kickoff.

The baseline in step five deserves care. It is a reference for the current wave—what was agreed to be done, by whom, and what would cause a rethink. It need not imply that every later implementation task or date has been settled.

Plan the learning work before the uncertain implementation work

When you cannot yet specify an implementation task reliably, you can often specify the work that will make it specifiable. That is the central move in applying progressive elaboration.

Suppose a customer has agreed to provide historical records as well as a continuing feed. You know the intended outcome and the broad need for migration. You do not yet know the archive’s volume, whether its older fields have the same meanings as current fields, or whether the proposed transfer is approved for the data it contains.

A weak plan assigns a date to “complete historical migration” and fills the preceding weeks with guessed extraction and mapping tasks. A more useful first wave can be quite precise without pretending to know the later design:

• Identify the people who can explain the archive and authorize its handling.
• Agree how representative records and counts can be obtained through approved means.
• Review samples and field definitions to test the assumptions affecting mapping and effort.
• Record which questions remain open, the consequence of each, and the evidence required before choosing a load approach.

“Review representative records” should itself have a checkable result: for instance, documented findings about the fields needed for the agreed use, plus an explicit list of ambiguities for the customer’s data owner. The task is detailed because its purpose, owner, input, and output can be described now. The eventual load procedure remains high-level because the evidence needed to design it is not yet available.

The same approach applies beyond data. If SSO configuration is uncertain, plan to establish the customer’s identity owner, determine the supported federation method, and agree a test route before committing to configuration steps that assume particular claims or provisioning behavior. If privacy approval is unresolved, plan the review and its required evidence; do not treat a provisional approval date as authorization to transfer sensitive records.

Not every unknown merits equal attention. Test first the assumptions whose failure would have a serious consequence, especially when you currently have little evidence for them. The Services in government article below offers a structured way to make that prioritization explicit. Its scoring is optional for a small onboarding; the underlying questions are what matter.

In the historical-data example, an unconfirmed archive volume may affect an estimate. An unconfirmed right to transfer particular records affects whether that work may proceed at all. Both should be investigated, but the second cannot be handled merely by adding schedule contingency. The consequence of being wrong determines how you plan around an unknown.

Roll the plan forward when evidence changes what you can say

At the end of a wave, do more than mark tasks complete. Ask what you now know that you did not know when the wave was planned. Continuing the historical-data example, a sample might confirm that current and older records share the necessary meanings. You can then detail the next wave’s mapping and validation work with better-grounded estimates.

Alternatively, the sample might reveal that older codes have conflicting meanings. The plan should not simply acquire extra tasks under its original dates. First establish what the finding prevents, who can interpret the codes, and whether the agreed initial scope or approach needs a decision. Then detail the next executable work. The original assumption has been tested; a present mapping problem is an issue; the choice about handling ambiguous records is a decision needed until an authorized owner makes it. The classifications from the previous lesson make the replan intelligible.

A useful wave review has four questions:

1. What was completed, and what evidence did it produce? Completion of a meeting alone is less informative than the finding or decision it enabled.
2. Which assumptions were confirmed or disproved? Update the plan that relied on them, not just the log entry.
3. What can now be planned in detail? Give upcoming work owners, prerequisites, and checkable results; leave genuinely distant work at outcome level.
4. Has the evidence changed an agreed constraint or commitment? If so, expose the trade-off and seek the relevant decision rather than making an implicit adjustment.

A scheduled review creates a dependable cadence, but significant findings should not wait for the next one. A failed sample, a denied approval, or an unavailable customer owner may immediately change which work is safe or productive. Replan when the new information matters, then make the revised understanding visible to the people relying on the plan.

How you describe the plan externally is part of this discipline. “We will use the approved sample to finalize the mapping approach; the historical-load estimate remains provisional until volume and field meanings are confirmed” communicates both action and uncertainty. It is stronger than offering a precise migration date unsupported by those inputs—and stronger than saying only that the migration is “to be determined.”

Key takeaways

Progressive elaboration means increasing planning detail as evidence makes it reliable, not postponing planning. Keep agreed outcomes and constraints explicit; detail the next executable work; leave later implementation choices at an honest level of resolution. Where the next technical step cannot yet be specified, plan the evidence-gathering step that will allow you to specify it. Review what each wave taught you, update assumptions and dependencies, and seek decisions when findings affect scope or commitments.

The next lesson considers a related boundary: when a customer request is part of onboarding, when it belongs in product development, and when it should be handled through ongoing support.