Glossary.

People who actively support and promote the change created by a project. They are usually peers, colleagues, or users who are trusted by others and have influence within affected groups. A Change Champion acts as a bridge between the delivery team and those impacted, helping explain the change in plain language, surface concerns early, and encourage others to engage. In practice, a small number of committed champions (often around 5 to 7) is more effective than a large, passive group.

A way of defining how work will be reviewed, tested, or validated as part of proving it works. Check types are used to reduce uncertainty before committing to bigger decisions and typically include business review, user or customer review (where possible), and specialist review.

A way of describing the scale and nature of the work based on how complex or uncertain it is. Different complexity zones require different approaches to planning, decision making, and control.

Cost of change is how much time, money, and disruption it takes to change the solution once work has started. If the cost of change is high, mistakes are expensive, so you should do more design before you build.

The smallest phase of work that can be delivered, used, and reviewed on its own to test whether the solution works. Delivery phases are designed to prove value and generate learning before scaling bigger and scaling out further. The first Delivery Phase is always the Pilot.

The group of people who support you as Project Manager to plan, build, test, and deliver the work. The delivery team is made up of specialists who provide the skills and expertise needed at each stage. Team members may be full-time or part-time, and can include colleagues, partners, friends, or extended network members.

A simple way to describe how a design matures over time as uncertainty is reduced. Design stages help teams understand what level of detail is needed now, and what can wait until later.

• Sketch – A quick description of the idea and what "good" looks like. Enough to explain it and start a sensible conversation.
• Outline – A simple picture of the solution and how it will work at a high level. Enough to agree the shape of the approach and spot obvious gaps.
• Developed – A clearer design that joins the main parts together. Enough detail to test the key assumptions and reduce uncertainty.
• Build-ready – A detailed design that is ready to build from. Clear requirements, decisions, and acceptance criteria for the parts that matter most.
• Assured – A design with evidence behind it. Reviewed, tested, or simulated so you can be confident it will work and meet the key constraints.

A way of describing how much design is needed before moving forward, based on the cost of change.

• Level 1 – Minimum – Use when cost of change is very low. You mainly need a Sketch.
• Level 2 – Light – Use when cost of change is low. You need a Sketch and an Outline.
• Level 3 – Working – Use when cost of change is medium. You need Sketch, Outline, and Developed.
• Level 4 – Detailed – Use when cost of change is high. You need everything up to Build-ready.
• Level 5 – Maximum – Use when cost of change is very high. You need the full set, including Assured.

The industry or field that a project sits within. The domain provides context for the work and shapes the language, standards, regulations, risks, and specialist skills involved. Examples include construction, defence, healthcare, IT, or education.

A job describes the outcome someone is trying to achieve. A job is not a task, tool, or method.

Jobs define the goal of the work. Rules guide how to think, plays show what to do, and tasks break the work into steps.

Jobs are written in the Jobs to Be Done style. They start with a verb and focus on the outcome.

Examples

• Deliver a project
• Deliver a strategy
• Solve the real problem
• Build an organisation that delivers projects well

An area of uncertainty that you are currently taking as true, but have not yet proven. In the Simplified Projects Model, Key Assumptions should be made visible and, where possible, tested.

The specific areas of uncertainty or assumptions you want to test. Learning Goals are usually written as SMART statements and focus on what you need to learn, not just what you need to build.

A learning loop is a planned pause in the work to review what was done, what was learned, and what should change next, before continuing.

Learning loops turn action into insight. They are closely aligned with the Plan / Do / Check / Act cycle and help teams reduce uncertainty before making bigger commitments.

A loop is one complete cycle of planning, doing the work, reviewing the results, and deciding what to change before starting again. Loops can apply to a whole solution, a version, or a single work package, depending on cost of change and complexity.

A quantitatively expressed reduction of uncertainty based on observation.

A possible way of addressing a problem and achieving the desired outcomes. Options represent different solutions you could choose from, each with its own trade-offs. For example, to get from A to B you might build a bridge or improve a bus network. The purpose of exploring options is to compare them and select the one that works best for your situation.

A real-world change that shows success, such as people using, adopting, or buying what you have produced. Outcomes focus on behaviour and value, not just delivery.

The tangible things you produce to enable outcomes, such as products, services, tools, or documents. Outputs, also known as 'Products' or 'Deliverables'. They only matter if they lead to outcomes.

The smallest version of a product or service that delivers value to a user or customer and can be used for testing and learning. A Pilot is always the first Delivery Phase.

Plays help you deliver a job without reinventing the wheel every time.

A play is a collection of tasks used to deliver part of a job. It shows how experienced people approach common situations and helps you apply proven ways of working.

Playbooks bring these plays together. They help you avoid reinventing how you deliver a job by using approaches that already work.

You may choose different plays depending on the situation. There is rarely only one way to deliver a job well.

Play titles describe repeatable delivery activities. They are written as clear actions that people already do.

You can start with your own playbooks, or use the playbooks developed by experts. Each play includes tools, templates, techniques, and insights to help you deliver.

Examples

• Build a contingency
• Align stakeholders
• Compare options
• Define success criteria

An undesirable situation, pain point, or issue that needs to be fixed or moved away from. A problem describes what is not working today, for example a team not delivering to expectations, or an IT system that no longer meets needs. Clear problems help shape meaningful outcomes.

A small exercise or activity used to test whether an idea or approach is viable, usually when there is uncertainty about what the project should achieve.

A document created during Job 2 (Prove It Works) that sets out the delivery phases, building blocks, assumptions to test, and how learning will happen.

A temporary initiative designed to deliver change, new products, new systems, new ways of working.

A sub-category of work focused on delivering change through a structured approach. Depending on scale and complexity, work may be organised and managed as a project, a programme, or a portfolio.

An individual handling the day-to-day delivery of a project, which may include both delivering outputs and realising outcomes.

A way of describing the kind of project you are dealing with, based on how clear you are about:

• the goal (the what), and
• the approach (the how).

There are four project types:

• Type A. Routine Delivery – the goal and the approach are both clear.
• Type B. Figure out the Plan – the goal is clear, but the approach is not.
• Type C. Figure out the Goal – the approach is clear, but the goal is not.
• Type D. Figure out the Goal and Plan – neither the goal nor the approach is clear.

Project type is identified using the what-how matrix and helps you decide how carefully and adaptively the work should be managed.

The standard components or patterns reused in each Delivery Phase. Repeatable blocks allow work to be delivered consistently, faster, and with less risk by learning once and applying many times.

An uncertain event or condition that, if it occurs, will affect the work. A risk can be a threat, where the impact is negative, or an opportunity, where the impact is positive.

Risk appetite is how much uncertainty and downside you are willing to accept for this work. It reflects the balance you want between caution and speed, and influences how tightly the work is controlled, how much design is done upfront, and how comfortable you are with change, rework, or overruns.

Simple rules are a tool for dealing with complex situations.

The scientific term for them is heuristics. These rules are learned wisdom, drawn from experience. When we learn these rules from others, we can walk a mile in their shoes and save ourselves the scars by standing on the shoulders of giants and doing what successful people who have done the job before do.

Science tells us that we have between two and a few dozen of these simple rules for any job we do.

Rules must resonate. We must feel them to be true. They are not textbook definitions. They are short, sharp zingers learned through experience.

Heuristics is the scientific term. Some people call them rules of thumb or success factors. In Confluity we call them simple rules, or just rules.

Examples

• Projects do not go wrong, they start wrong
• Keep it simple
• Start with the end
• Do not beat around the bush, get to the point

To simplify means choosing to focus on what really matters and removing what does not, so it becomes easier to decide and act.

Simplicity is when work feels clear and manageable because you are doing fewer things, but the right ones.

Simplistic means making something look easy by ignoring important details, risks, or reality, which often causes problems later.

A common way to describe good goals. In this model, SMART stands for:

• Specific
• Measurable
• Accurate
• Realistic
• Time-based

An individual who provides specific skills or expertise needed to deliver the work. Specialists are part of the delivery team and are brought in to contribute their knowledge, experience, or capability at the point it is needed.

A stakeholder is any person, group, or organisation that can affect, be affected by, or see itself as affected by the project, its decisions, or its outcomes. Stakeholders can include customers, users, sponsors, delivery teams, suppliers, regulators, and other groups with an interest in the work.

Owns the why behind the project. Unlocks money, time, people and decisions. Has authority to approve progress and remove barriers. Champions the project when others have doubts.

The design or approach you put into place to deliver a chosen option. A solution describes how the option will be realised in practice, including the overall design, specification, and way of working that will be used.

The measures you will use to decide whether a project has been successful. Success criteria should be agreed early and linked to outcomes, not just outputs.

A test method describes how you will test a key assumption in order to reduce uncertainty before committing to bigger decisions.

Common test methods include:

• Proof of Concept – used to test whether an idea is viable.
• Detailed Design – used to test feasibility when the cost of change is high.
• Pilot – used to test the solution in real-world conditions at small scale.

The choice of test method depends on where uncertainty sits and how costly it would be to change direction later.

A piece of work that needs doing to move something forward. A task is usually made up of one or more smaller activities.

A specific iteration of a product, service, or solution. Versions reflect learning over time, for example version 1, test and learn, then version 2. Version, also known as an 'Iteration'.

The activities carried out to do something and move towards an outcome. How work should be planned and managed depends on the situation, including the level of uncertainty, risk, and complexity involved.

A way of grouping work based on how it should be managed. Different categories of work benefit from different tools, levels of control, and learning cycles.

Examples may include:

• Predictable work
• Exploratory work
• Experimental work

A manageable chunk of work in a plan. A work package groups related tasks and activities to produce a clear output, or part of an output.

This glossary will evolve as the model develops.