Springboard (Level 2) key terms

Any person or group who affects, is affected by, or has an interest in the outcome of a piece of work. Stakeholders include sponsors, users, regulators, and delivery staff, each with different needs and influence.

A tangible or intangible output produced as a result of work and handed over to a recipient. Deliverables are usually contractual or formally accepted items, distinct from internal work products that never leave the team.

The boundary defining what work is included in an effort and, by implication, what is excluded. Clear scope statements prevent uncontrolled expansion and give a baseline against which changes can be assessed.

The conditions a deliverable must satisfy to be accepted by the recipient. They are written before work starts, are testable, and are used to decide whether an item is complete rather than merely finished.

Something accepted as true for planning purposes without proof. Assumptions carry risk, so they should be recorded, owned, and validated as work progresses; an invalidated assumption often becomes an issue.

A limit that restricts available options, such as fixed budget, deadline, regulation, or available skills. Constraints are not problems to solve but boundaries within which solutions must be designed.

The interdependent trade-off between scope, time, and cost, with quality affected by how the three are balanced. Changing one dimension normally forces adjustment in at least one other, which is why trade-offs must be explicit.

An approach that delivers work in repeated cycles, refining the product based on feedback after each cycle. It accepts that requirements emerge over time and favours early partial delivery over one large final release.

A usable, potentially shippable addition to the product produced within an iteration. Each increment builds on previous ones, so value accumulates and the product is never wholly unfinished at any checkpoint.

The smallest version of a product that lets a team test core assumptions with real users while spending the least effort. Its purpose is validated learning, not a cheap final product.

A principle set focused on maximising value and removing waste from a process. Common wastes include waiting, rework, overproduction, and handoffs; lean practice maps value streams and limits work in progress.

Analysing a problem as a set of interacting parts rather than isolated components, so that feedback loops and side effects are visible. It guards against local optimisations that damage overall performance.

The structured activity of drawing out needs from stakeholders through interviews, workshops, observation, or document analysis. Good elicitation uncovers underlying problems, not just stated feature requests.

A short statement of a need written from a user's perspective, typically naming the role, the goal, and the reason. It is a placeholder for conversation rather than a full specification.

A shared checklist describing the quality conditions every item must meet before the team counts it complete. It prevents items being declared finished while testing, documentation, or review remain outstanding.

A formal process for logging, assessing, approving, or rejecting proposed changes to an agreed baseline. It records impact on scope, cost, and schedule so decisions are made deliberately rather than absorbed silently.

An approved, frozen version of a plan or specification against which actual progress is compared. Baselines allow meaningful variance analysis; they change only through formal change control.

The gradual, unapproved expansion of work beyond what was agreed. It typically appears as small helpful additions that are never assessed, and it erodes schedule and budget without any single visible decision.

A structured technique for finding the underlying reason a problem occurred rather than treating its symptoms. Common methods include the five whys, fishbone diagrams, and fault tree analysis.

A simple root cause technique that repeatedly asks why a problem happened, typically about five times, until the underlying cause is reached. It works best when answers are checked against evidence rather than guessed.

Comparing the current state with a desired future state to identify what is missing and what must change. The output is usually a prioritised list of actions that close the difference.

A progress measure combining planned value, actual cost, and value of work completed to show cost and schedule performance. It answers whether work done is worth the money spent so far.

Comparing planned figures with actual figures to explain differences in cost, schedule, or quality. The aim is to understand causes and decide on corrective action, not merely to report the number.

A visual display of work items moving through defined stages, used to expose bottlenecks and limit simultaneous work. Columns represent process steps and cards represent items, making flow visible to the whole team.

A cap on how many items may be in a given stage at once. Limiting concurrent work reduces context switching, shortens cycle time, and forces the team to finish work before starting more.

The full sequence of steps required to take a need from request to delivered value, including waiting time and handoffs. Mapping it reveals where delay and waste accumulate, which is often not where work happens.

A rough early model of a product or process built to test understanding with users before full investment. Low-fidelity prototypes are cheap and invite criticism; high-fidelity ones test detailed interaction.

A maintained log of identified risks, each with an owner, likelihood, impact, and planned response. It is a living document reviewed regularly, not a one-off list produced at kickoff.

The amount of risk an organisation is willing to accept in pursuit of its objectives. It guides whether a given risk is tolerated, treated, transferred, or avoided, and should be set at leadership level.

An action taken to reduce the likelihood or impact of a risk before it occurs. Mitigation differs from a contingency plan, which is triggered only if the risk actually materialises.

A problem that has already occurred and is currently affecting the work, unlike a risk which is still uncertain. Issues need an owner and a resolution date, and are tracked separately from risks.

A requirement imposed by law, regulation, contract, or internal policy that the work must satisfy. Obligations are non-negotiable constraints and should be identified early, since late discovery is costly.

A recorded history of decisions, changes, and approvals that allows an independent party to reconstruct what happened and why. It supports accountability and is often required by regulation.

A chart assigning each activity to people who are Responsible, Accountable, Consulted, or Informed. It clarifies decision rights; exactly one person should be accountable for each row to avoid ambiguity.

Plotting stakeholders by influence and interest to decide how closely each must be engaged. High-influence, high-interest parties need active management; low-interest parties need only summary communication.

Concentrating fully on a speaker to grasp both content and intent, then confirming understanding by summarising. It reduces misunderstanding and is especially valuable when requirements are being elicited from busy stakeholders.

A situation where a person's private interest could improperly influence a professional judgement. It must be disclosed promptly, and the person may need to withdraw from the affected decision.

Acting honestly and consistently with stated values, including when no one is checking and when honesty is inconvenient. It includes reporting bad news early rather than concealing problems until they become unavoidable.

Protecting information entrusted to you from unauthorised disclosure, including after a working relationship ends. It applies to client data, personal information, and commercially sensitive material alike.