Digital Project Business Case: baseline, cost and decision scenarios

The decision in two paragraphs

An economic case should be based on the baseline, change scope, total cost, risks and outcome scenarios. The calculation remains an assumptions-based model until the outcome is measured against comparable data. For this task, the initial evidence is “requirements disconnected from a decision”, and the decision boundary concerns the baseline process and its exceptions.

The practical focus is organisational readiness, accountability for process change and verifiable acceptance. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is the release or pilot scope.

Applied analysis: Digital Project Business Case: baseline, cost and decision scenarios

The practical framing of “Digital Project Business Case: baseline, cost and decision scenarios” connects process, data and authority. The baseline process and its exceptions defines the boundary, while “unprepared data and roles” identifies the moment when a decision is required.

The team then links decisions and role authority to a role, rule and the action “baseline the current scenario”. This framing allows options to be compared through one scenario without confusing mandatory requirements with interface convenience.

Acceptance uses evidence for the release or pilot scope. Method, period and source of actuals remain comparable with the baseline; exceptions are recorded separately.

• Working object: The baseline process and its exceptions.
• Diagnostic signal: Requirements disconnected from a decision.
• Response action: Baseline the current scenario.
• Controlled risk: A pilot using unrepresentative data.

Starting situation and evidence

Diagnosis examines a concrete episode involving the baseline process and its exceptions. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “unprepared data and roles” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Indicator: Different business and IT expectations. Analysis needs an actual example and the resulting change in user-readiness criteria.
• Diagnostic signal 2: Requirements disconnected from a decision. Its record contains an example and impact on the outcome of the end-to-end scenario.
• Management signal 3: Acceptance based only on an interface demonstration. Use condition: a link to an actual example and to the baseline process and its exceptions.

The decision point to resolve

State the decision before compiling requirements. It identifies the release or pilot scope, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “requirements disconnected from a decision” and the risk “a pilot using unrepresentative data” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “baseline the current scenario” connects them in a testable scenario.

• Decision 1: object — the baseline process and its exceptions; signal — different business and IT expectations; action — baseline the current scenario.
• Decision 2: object — decisions and role authority; signal — requirements disconnected from a decision; action — assemble the full cost of change.
• Decision 3: object — the release or pilot scope; signal — acceptance based only on an interface demonstration; action — describe financial and non-financial outcomes.

Baseline and decision scenarios

For decisions and role authority, the sequence begins with “baseline the current scenario”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for decisions and role authority. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Baseline the current scenario is the action at stage 1. The output documents user-readiness criteria.
• At position 2, the action is “assemble the full cost of change”; its result is the outcome of the end-to-end scenario.
• Stage 3: describe financial and non-financial outcomes. The working artefact describes the baseline process and its exceptions.
• Stage gate 4 connects the action “run sensitivity analysis” with the result “decisions and role authority”.

What belongs in scope

The subject model starts with two reference objects: the baseline process and its exceptions and decisions and role authority. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “describe financial and non-financial outcomes”.

The primary boundary is the baseline process and its exceptions. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Subject area 1: The baseline process and its exceptions. Verification basis: system of record, owner authority and the signal “unprepared data and roles”.
• Record 2. Object: Decisions and role authority. Required details: identifier, lineage, quality rule and update event. Signal: Change without a durable owner.
• Control record 3. Object: The release or pilot scope. Observable signal: Different business and IT expectations. Accountability: semantic owner and quality owner.

Process and data owners

For the release or pilot scope, the role model determines more than screen access. In the action “baseline the current scenario”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For the release or pilot scope, this separation is especially important because of the risk “scaling before stabilisation”.

• Business owner is accountable for user-readiness criteria and confirms the action “assign the measurement owner”.
• Role: Architect. Decision object: the outcome of the end-to-end scenario; verified step: baseline the current scenario.
• Data owner decides within the baseline process and its exceptions; the basis is prepared through “assemble the full cost of change”.
• For decisions and role authority, the assigned role is Project manager; its control duty is to describe financial and non-financial outcomes.

Record lineage

Describe data exchange as a contract between owners. For decisions and role authority, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “requirements disconnected from a decision” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Object 5: The outcome of the end-to-end scenario. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Acceptance based only on an interface demonstration.
• Boundary 4. Object: User-readiness criteria. Define the source, frequency, permitted transformations and response to “requirements disconnected from a decision”.
• Control record 3. Object: The release or pilot scope. Observable signal: Different business and IT expectations. Accountability: semantic owner and quality owner.

Baseline and actual outcome

Verification of the release or pilot scope starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “requirements disconnected from a decision” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for the baseline process and its exceptions.

• Criterion 1 uses the baseline process and its exceptions; the result is compared with the baseline using one method. Signal: Different business and IT expectations.
• Criterion 2: Decisions and role authority; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Requirements disconnected from a decision.
• Criterion 3. Object: The release or pilot scope. Test fields: baseline, target change, source and owner. Signal: Acceptance based only on an interface demonstration.
• 4. Acceptance object: user-readiness criteria; compare the baseline sample, expected change and confirmed actuals. Test signal: Unprepared data and roles.

Assumptions, stop signals and rollback

The risk map starts with two conditions: “a pilot using unrepresentative data” and “scaling before stabilisation”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “scaling before stabilisation” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• The risk scenario “scope growth without schedule review” is addressed through “run sensitivity analysis” and confirmed using the baseline process and its exceptions.
• Controlled constraint: formal training without a process change. The owner performs “assign the measurement owner” and provides decisions and role authority.
• For the risk “a pilot using unrepresentative data”, assign the action “baseline the current scenario” and evidence “the release or pilot scope” in advance.
• Risk review starts with the condition “accepting a feature instead of an outcome”. The decision uses the action “assemble the full cost of change” and data about user-readiness criteria.

Initial working cycle

The first session examines one real case involving the baseline process and its exceptions. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “requirements disconnected from a decision”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “baseline the current scenario”; assign an additional test or stop condition to the risk “scaling before stabilisation”.

• Baseline the current scenario is the action at stage 1. The output documents user-readiness criteria.
• At position 2, the action is “assemble the full cost of change”; its result is the outcome of the end-to-end scenario.
• 4. Acceptance object: user-readiness criteria; compare the baseline sample, expected change and confirmed actuals. Test signal: Unprepared data and roles.
• Evidence item 5 describes the outcome of the end-to-end scenario, comparable test conditions and the person accountable for interpretation. Signal: Change without a durable owner.