Classifying Onboarding Information Types

Hello again. Last lesson gave you a testable finish line: an approved production service, a repeatable and trustworthy data feed, and appropriate user access. But before those conditions are met, an onboarding generates a steady stream of statements such as “the customer can export historical records,” “privacy approval may take longer than expected,” and “the first file failed validation.” Those statements call for different responses.

This lesson gives you a way to classify them as a risk, issue, action, decision, assumption, or dependency. The aim is not to memorize six labels. It is to recognize what each statement means for the work: what needs checking, doing, deciding, protecting against, or resolving. That distinction is especially useful when you own both technical delivery and the customer-facing account of progress.

Six labels, six different questions

“RAID log” does not have one universally fixed expansion. The image below puts Actions and Assumptions under A, and Decisions and Dependencies under D. For this lesson, keep all six categories distinct.

A quick first pass is to ask what kind of statement you are looking at:

The categories describe different relationships to the work, not six levels of urgency. A routine action can be urgent; a high-impact risk may never occur. Nor must one situation fit in exactly one box. An unverified assumption can create a risk, while an action can be assigned to test that assumption. The important discipline is to write different, precise statements rather than copy the same vague concern into several categories.

For a short introduction to the underlying distinctions, watch the opening of How to Use RAID Log in REAL-LIFE Project (+ Template) from Tactical Project Manager. Its final segment is also worth watching for the idea of using the log as a conversation aid, rather than as paperwork kept apart from the customer.

One caution when adapting any example: an agreed, confirmed responsibility is not an assumption merely because it affects your plan. If the customer has formally confirmed who will extract the data, record that responsibility and its dependent activity. If you are only presuming they will do it, you have an assumption to verify.

The time boundary: risk versus issue

The most useful distinction is often whether the adverse condition has occurred.

Suppose an integration will ingest a daily file. Before you receive a representative sample, you might write: “There is a risk that the export will not contain the event identifier needed to match repeat reports; if so, mapping and validation will need rework.” The missing identifier is possible, not yet observed. You can investigate it early and plan a response.

Once a sample arrives without the identifier, the situation changes. “The supplied sample lacks the event identifier, so the current mapping cannot pass validation” is an issue. It warrants diagnosis, an owner, and a resolution path. You do not need to wait until the launch date slips to call it an issue: the defect already exists, even if the team has time to fix it.

This is a practical boundary, not a demand for dramatic language. A risk is not “small”; it is uncertain. An issue is not necessarily “severe”; it is present. If a risk materializes, manage the resulting problem as an issue and retain a link to the original risk where that history is useful. Do not leave it reported only as a future possibility.

University of Waterloo’s Project Management Office describes this distinction alongside actions and recorded decisions. Read its concise purpose statement and the note on what to do when a risk occurs.

In an onboarding, a useful risk statement names the uncertain event and its consequence: “If the customer’s identity team cannot provide a suitable test account by the agreed validation window, representative SSO testing may be delayed.” A useful issue statement names what is observed and what it currently prevents: “The supplied test account is disabled, so the designated reviewer cannot complete the sign-in test.” Neither requires a speculative numerical probability to be useful.

Assumptions are premises; dependencies are prerequisites

These two are easily confused because both can appear in a schedule.

An assumption is a proposition you are currently planning as though it were true, without enough evidence to treat it as confirmed. For example: “The historical extract is assumed to cover all records within the agreed period.” That premise may determine your migration estimate and reconciliation approach. The management question is: Who can verify it, by what evidence, and what changes if it is false? An assumption is not a substitute for asking the question; it marks the question as consequential.

A dependency is a relationship between work and something it requires. “Historical reconciliation cannot be completed until the customer provides a source count for the agreed period” names both the prerequisite and the downstream activity. The prerequisite may be a customer deliverable, an internal configuration, an approval, or the result of another task. The management question is: What is waiting on what, who owns the prerequisite, and when is it needed?

Consider two statements about privacy review:

“We assume the existing data-handling approval covers the proposed historical extract.”

That is an assumption if the team is proceeding on that unverified premise. It deserves prompt validation, particularly because sensitive data is involved. Until coverage is confirmed, the team should not treat the premise as authorization to transfer data.

“The production historical transfer requires the applicable data-handling approval.”

That is a dependency: approval is a prerequisite to that transfer. It remains a dependency whether approval is expected quickly or slowly.

If you also have reason to think approval might not arrive before the planned transfer window, record a risk about the possible delay. If approval is already required for work due now and has not been granted, you may have an issue as well. These are not duplicate descriptions: they state a premise, a prerequisite, a possible consequence, and a present blockage respectively.

Not every unknown deserves an assumption entry. “Which identity protocol does the customer use?” is simply an open discovery question until your plan relies on an answer. If you set an SSO schedule on the belief that a particular protocol is available, then that belief is an assumption worth exposing. This keeps the log focused on unknowns that affect commitments or implementation choices.

Actions change the situation; decisions settle a choice

An action is work that can be assigned and completed. “Clarify the export format” sounds useful, but it leaves too much room for interpretation. “The customer’s data owner will provide a representative export and its field definitions by the agreed review date” identifies a result that can be checked. Actions often follow from the other categories: obtain a sample to test an assumption, arrange a workshop to reduce a risk, or correct a mapping to resolve an issue.

A decision is an actual choice with consequences, made by someone with the relevant authority. “Use the scheduled file feed for the initial release; defer the API option for later evaluation” can be recorded as a decision if the appropriate customer and internal owners have approved it. Preserve the choice, who made or accepted it, when, and the reason or scope boundary needed to interpret it later.

An unanswered choice is not yet a decision. “Should the initial load include free-text notes?” is a decision needed. You may track an action to obtain the ruling and a dependency if mapping cannot be finalized without it. Once the authorized owner chooses, record the decision itself. This distinction prevents a question discussed in a meeting from silently acquiring the status of an approval.

Authority matters here because your end-to-end ownership does not grant every kind of approval. You can recommend a technically workable redaction pattern and coordinate its validation. That does not make you the customer’s data-handling approver. A decision record should show who was empowered to accept the relevant trade-off, especially when it affects access, privacy, scope, or launch readiness.

Follow one concern through all six categories

Imagine preparing a historical load alongside a continuing daily feed. The customer has mentioned that an older source may use different codes for the same type of operational event. Here is how the information might develop without forcing it into one oversized “data concern” entry.

At first, you assume that the older codes can be mapped using documentation the customer already holds. You make that premise visible because the historical-load estimate relies on it. You also identify a risk: if the codes cannot be interpreted consistently, historical records may need additional review before they are fit for initial use.

To test the premise, you agree an action: the customer’s data specialist will supply the code list and representative records. The load has a dependency on an accepted mapping for those codes; that relationship tells everyone which downstream work is exposed. When the records arrive, several codes have conflicting meanings. This is now an issue requiring resolution, not merely the earlier risk repeated in the future tense.

Resolving it may require a decision: should the ambiguous records be excluded from the agreed initial historical scope, or can a validated rule distinguish them? That choice needs the appropriate data and delivery owners, with the implications for completeness made explicit. Further actions can then implement and check the agreed treatment.

The value of classification is visible in the change over time. “We are worried about old codes” cannot tell a customer whether they need to supply evidence, choose between options, or simply know that the team is monitoring a possibility. The six labels can.

A small decision routine for everyday updates

When a new fact comes out of a discovery call, test result, or status discussion, you can classify it without building a large process around it:

1. Is there an observed problem now? Record an issue and its present effect. If not, ask whether you are describing an uncertain future event with a consequence: a risk.
2. Are you relying on an unverified claim? Record the assumption, how it will be checked, and what your plan depends on.
3. Does one activity require a particular input, completion, or approval? Record the dependency with both sides of the relationship.
4. Does someone need to perform concrete work? Record an action with an owner and a checkable result.
5. Has an authorized choice actually been made? Record the decision. If the choice is still pending, identify who must make it and what work it holds up.

This is a questioning routine, not a rule that a statement may occupy only one category. The same concern can generate linked entries as long as each has a distinct purpose. Keep the level of detail proportional to the effect on scope, schedule, data quality, permitted handling, access, or acceptance. A log containing every minor conversation is harder to use than one that reliably surfaces consequential items.

For your own review, a compact entry needs enough context to be intelligible later: the statement, its effect or downstream relationship, an owner, its current state, and the next relevant date or evidence. The exact layout is less important than being able to answer, during a customer discussion, “What is known, what remains uncertain, and what happens next?”

Key takeaways

Classify onboarding information by what it calls for. A risk is a consequential possibility; an issue is a present problem. An assumption is an unverified premise your plan relies on; a dependency names what another activity requires. An action assigns checkable work, while a decision preserves an authorized choice—not merely a question awaiting an answer. Related entries can coexist, and their classifications should change when new evidence arrives.

Next, you will look at progressive elaboration: how to plan responsibly when many onboarding details cannot be known at the start, without treating early assumptions as settled facts.