Start where you are

When an organization decides to improve, the temptation is to sweep away what exists and build something new. New tools, new processes and new teams feel like progress. Yet the current state almost always contains services, people, knowledge and tools that already work, and discarding them wastes money and destroys value. The second guiding principle asks organizations to look carefully at what they already have, decide what can be reused, and build from there. This lesson explains how to assess the current state objectively, why direct observation beats reports, and how to decide what to keep, adapt or replace.

What the principle asks

Start where you are means: do not start from scratch without first considering what is already available to be leveraged. Services, practices, projects, people and tools in use today will usually have something to offer. The principle does not say "never replace anything". It says the decision to replace should be made after an honest look at the current state, not before.

Applying the principle involves:

• Looking at what exists as objectively as possible, using the customer or desired outcome as the starting point.
• Getting data from the source, through direct observation, rather than relying only on reports and opinions.
• Deciding what to reuse, what to adapt and what to retire, based on that evidence.
• Using risk management skills: reuse can carry risks, such as copying a flawed process, just as replacement can.

Why organizations skip the current state

There are understandable reasons why organizations jump straight to a new solution. A new leader wants to make a mark. A vendor promises that its product solves everything. A failed initiative leaves people believing that everything in the old way was bad. Sometimes the current state is simply poorly understood, so it feels easier to design something new than to find out what exists.

Each of these reasons leads to the same costs. Investment is spent recreating things that already worked. Valuable knowledge held by experienced staff is lost. People who built the current state feel their work has been dismissed, which damages engagement. And the new solution often repeats old mistakes because nobody studied why the old one struggled.

Measurement and observation

The principle has a strong link to measurement. To know where you are, you need data. Yet measurement has a trap: the act of measuring can change behaviour, and reported data can differ from reality. A team asked to report on process compliance may report what they believe management wants to hear. A dashboard may show averages that hide serious problems for some users.

For this reason, ITIL encourages going to where the work happens, an idea borrowed from Lean, where it is known as "going to the gemba" (the real place). Watching a service desk agent handle calls, sitting with a user as they try to request access, or tracing a change from request to deployment reveals things no report shows: workarounds, duplicated effort, unclear handoffs and tools used in ways their designers never intended.

Assessing what to keep, adapt or retire

Once the current state is understood, each element can be sorted. A simple approach scores each element on two questions: how much value does it contribute, and how well does it work? Elements that contribute value and work well are kept. Elements that contribute value but work poorly are adapted. Elements that contribute little value are candidates to retire, whether or not they work well.

Baselines

Starting where you are also means recording a baseline: a measured description of the current state that later improvements can be compared against. Without a baseline, an organization cannot tell whether a change made things better. Lesson 11 shows how baselines feed the continual improvement model. For now, the key point is that a baseline must be measured from real data, not estimated from memory, and should include enough context (time period, volumes, conditions) to be meaningful.

Reuse carries risks too

The principle is not an argument for keeping everything. Reusing a flawed process can lock in its flaws. Reusing an old tool can mean inheriting security weaknesses, unsupported software or poor usability. The principle asks for judgment: understand the current state well enough to make an informed decision. Sometimes the right decision, after an honest look, really is to replace something entirely.

Applying the principle in different settings

The principle applies whenever change is planned. Before introducing a new incident management approach, study how incidents are handled today. Before moving services to a cloud provider, inventory what exists and what depends on what. Before reorganizing teams, understand the informal networks that make work happen. In mergers, where two organizations each have their own ways of working, the principle helps avoid the assumption that the larger organization's way is automatically better.

Canadian public-sector organizations are expected by the Treasury Board Policy on Service and Digital to reuse common solutions, such as shared platforms, before building their own. That expectation is a form of starting where you are applied across a whole government.

Links to other principles

Start where you are works closely with progress iteratively with feedback (lesson 4): once the current state is understood, improvements can be made in small steps from it. It also supports focus on value (lesson 2), since the assessment of what to keep should be guided by value. And it relies on collaborate and promote visibility (lesson 5), because the people doing the work today are the best source of information about the current state.

A short assessment checklist

Teams applying this principle for the first time often find a simple checklist helpful. Before proposing any significant change, they answer the following questions in writing and share the answers with the people affected:

• What exists today that touches this outcome: services, tools, processes, documents, skills and relationships?
• Which of these did we observe directly, and which do we know only from reports or opinions?
• What does each element contribute to value, and how well does it perform?
• What have previous attempts to improve this area taught us, and why did they succeed or struggle?
• What is the measured baseline we will compare future results against?
• What would we lose, in knowledge, money or goodwill, if we replaced each element?

The checklist takes hours, not weeks, for most changes. Its purpose is not to delay improvement but to make sure the first step builds on solid ground. Where the answers reveal that little is known about the current state, the right first iteration is often simply to find out.

Key point to remember

The current state is rarely as bad, or as good, as people believe. Only careful, direct assessment reveals which parts deserve to be kept, and the baseline recorded at this stage is what later proves whether improvement actually happened.