67 lines
6.8 KiB
Plaintext
67 lines
6.8 KiB
Plaintext
---
|
||
id: baseline
|
||
title: Baseline
|
||
sidebar_label: Baseline
|
||
description: Understand a workflow, select relevant candidate metrics and establish feasible starting evidence for later comparison.
|
||
pagination_prev: measurement/index
|
||
pagination_next: skills-governance
|
||
hide_table_of_contents: true
|
||
---
|
||
|
||
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||
|
||
<div className="strategy-content">
|
||
|
||
Establish a starting position for one workflow before choosing an intervention in months 1–2 of the [6 Months Roadmap](./six-months-roadmap.mdx). Baseline current uneven AI-assisted practice, not an assumed no-AI organization. This is not a mandatory company-wide baseline of every metric in the [Measurement registry](./measurement/index.mdx). The [EXP-01 packet](./six-months-roadmap.mdx#exp-01-a-small-decision-ready-example) assembles a practical comparison and budget. Departmental role names below are proposed functions to map with the partner team, not verified company appointments.
|
||
|
||
<ArchifyDiagram name="strategy-baseline" title="From current workflow through relevant selection and feasible evidence to a starting position and later comparison" story />
|
||
|
||
**Target operating model — no actual baseline values or approved thresholds are established here.** Missing evidence remains an explicit gap, not an invented starting value.
|
||
|
||
## Delivery example: know what must improve
|
||
|
||
In the [illustrative Delivery workflow](./stage-01-skills-adoption.mdx), Product Engineering maps a bounded code change through regression tests, independent review and existing release controls. Suppose the concern is repeated rework because regression evidence is incomplete: first verify the cause from actual changes, rather than assuming a skill will fix it.
|
||
|
||
Consider accepted-task outcomes, escaped-quality follow-up and review/rework inputs to cost if their contracts fit. Select only evidence that can inform that concern; deployment frequency need not help. The output is a workflow map and comparison record, not a pass/fail score. The owning team's designated workflow owner confirms scope with the independent Quality Engineering reviewer; unresolved source or acceptance gaps limit later conclusions, not authorize a pilot.
|
||
|
||
## Understand the current workflow
|
||
|
||
Describe the task, team or service, intended outcome, current tools, handoffs, controls and known friction. Bound what is in and out of scope. For Delivery, start with codebase structure and existing principles, system-logic sources, tests, builds and packaging, then deployments. Record current practice, including any existing AI use; do not label it “no-skill” unless that is true.
|
||
|
||
## Select relevant metrics, with reasons
|
||
|
||
Start with **Workflow effectiveness**: select relevant current-workflow outcomes before standardized skills adoption—accepted work, delivery time, failures/rework, cost, human effort/experience or business acceptance where the contracts apply. Choose the registry entries that answer this workflow's questions. Record why each selected metric applies, what decision it can inform, and why other candidates are irrelevant or deferred. There is no required universal subset. A service-level DORA metric, a qualification test and a people survey have different populations; they are not interchangeable.
|
||
|
||
Keep **Skills effectiveness & health** separate. If no applicable skills exist, selection, bundle, adoption and review measures may be N/A, not zero; they are not prerequisites for baselining current work. If skills already exist, record that starting context and qualify named revisions separately. Do not mix sandbox skill evaluations into validated workflow task success or live policy-effect rates.
|
||
|
||
Agree what counts as a started task, independent acceptance and completed follow-up before counting outcomes. Freeze eligibility and acceptance rules and verify event joins. Select a complete comparable workflow cycle and a predeclared precision/sample requirement appropriate to the decision. Do not select a convenient end date after seeing results. Where those requirements cannot be met, record the resulting evidence limitation.
|
||
|
||
## Agree feasible evidence
|
||
|
||
Confirm collection feasibility, period, sources, owner, independent reviewer, access, lawful basis, privacy and retention before collecting. Use the [shared safeguards](./measurement/collection-and-safeguards.mdx) and each selected contract's input requirements. Proposed owner/cadence entries are not already assigned responsibilities.
|
||
|
||
Start with a controlled worksheet or export if automation is unavailable. Join task IDs to acceptance records, PR/commit IDs, CI results and later defects where relevant; test source coverage and permissions. Repository and CI evidence support verification, but a green build alone is not task acceptance. Record exact skill revisions and client/model configurations when present; keep missing versions unknown.
|
||
|
||
## Record the starting position
|
||
|
||
Collect prospective current-practice evidence over the agreed period. Record actual starting values only when supported by traceable evidence. Include units, population, observation period, counts, exclusions, source coverage, calculation version, uncertainty and limitations. Zero denominators mean “not available,” not zero performance.
|
||
|
||
For each selected metric, keep one of these explicit records:
|
||
|
||
- **Available:** evidenced starting value, source links, calculation, owner and limits.
|
||
- **Unavailable:** missing input or permission, affected comparison, responsible owner and proposed next action or review point. Never fill the gap with the synthetic example or an assumed industry value.
|
||
|
||
Record deferred and non-applicable candidates separately from selected-but-unavailable metrics. This page is the recording method, not an Eldorado baseline report or a set of approved targets.
|
||
|
||
## Keep later evaluation comparable
|
||
|
||
Retain task class, service, skill, client/model configuration and concurrent changes. In [Adoption](./skills-adoption.mdx), use the same agreed eligibility, acceptance and observation rules; in [Maintenance](./skills-maintenance.mdx), record any changes and breaks in comparability rather than silently replacing the starting position.
|
||
|
||
A matched or randomized comparison may be used when practical and ethical. Label observational trends as descriptive, not causal ROI; report confounding, selection and uncertainty. Missing or small samples limit conclusions. Baseline values describe current practice; they do not establish acceptable risk or authorize expansion.
|
||
|
||
**Next:** [Govern skill ownership and authority →](./skills-governance.mdx)
|
||
|
||
Carry the map, selected definitions and evidence limits into candidate design. Return here from [Adoption](./skills-adoption.mdx) when scope changes, or from [Maintenance](./skills-maintenance.mdx) when the current workflow no longer matches the comparison. See the [whole Stage 01 journey](./stage-01-skills-adoption.mdx).
|
||
|
||
</div>
|