Your new workforce won't be all human. Join the
conference to learn the new workforce OS.
request invite
TL;DR: Start where you are is the second ITIL 4 guiding principle. It says: do not scrap what you have and build from scratch, do not plan from what you assume is true, and do not try to boil the ocean. Take one small step from where you actually stand: observe a piece of the current state directly, measure it with accurate data from the source, and build on what you learn. Teams break this principle in two ways. They plan from a fiction (a stale CMDB, a leadership assumption, a vendor's rip-and-replace deck), or they swing to the opposite failure and try to assess everything at once, which is so heavy it never happens. The safer move is small and concrete: pick one team and one narrow question, and go measure just that.
Part of the ITIL 4 series: The seven ITIL 4 guiding principles, The ITIL 4 service value chain, rebuilt with AI Coworkers, Focus on value, the first guiding principle, Progress iteratively with feedback, the third guiding principle.
This is the second post in a series walking each of the seven ITIL 4 guiding principles one at a time. Part 1 was Focus on Value. Focus on value tells you what to aim at. Start where you are tells you where to aim from, and most teams get the starting point wrong before they take a single step.
In ITIL 4, start where you are is a caution against two instincts. The first is the urge to rip out what exists and rebuild from scratch, when there is usually a great deal in the current services, processes, tools, and people that can be reused to reach the outcome you want. The second, and the one that bites harder, is planning from assumption instead of observation. The principle is explicit: investigate the current state directly, observe it, and base decisions on accurate information.
There is a subtle warning built into the principle too: the act of measuring can change the thing you measure. So you want data sourced close to the source, and you want to know how it was gathered, before you trust it enough to plan on it.
And there is a quieter part that gets missed. Start where you are does not mean assess everything before you move. A full, all-domains audit is its own way of never starting, because it is too big to finish and too risky to trust in one go. The principle rewards a small, safe step from your actual position: look at one thing, in one place, with accurate data, learn from it, then decide whether to look wider.
Most improvement programs do not start where the organization actually is. They start where someone believes it is. The CMDB says there are 400 servers, so the plan assumes 400 servers; the reality is 520, and 90 of the recorded ones were decommissioned last year. Leadership assumes access is tightly controlled because that was the policy written three years ago. A vendor arrives with a transformation deck that assumes your current stack is the problem and their platform is the answer, which is a rip-and-replace story dressed as an assessment.
None of these are lies exactly. They are just not the current state. They are a picture of the current state, filtered through whoever last touched it. And a plan built on that picture optimizes a place you are not standing.
The test is not whether you can produce a full baseline of everything. It is whether you can take one small, safe step from where you stand and learn something real. Pick one team and one narrow question, something you have an assumption about, and go get the actual number from the source system, an identity provider, a SaaS app, or your cloud bill.
That single step is the whole point. You cannot prove an improvement you never measured a starting line for. "We tightened access" means nothing without the before number. And a small step gives you that before number without a program, a committee, or any risk, because reading is not changing.
When you take even one such step, the number rarely matches the assumption. In one read-only pass of a source we happened to have connected, an identity provider, only about 55% of licensed users had signed in at all, 14 of 20 accounts held an admin role, and 116 app access grants were more than a year old and still live.
You do not need a vendor, a project, or a login to take the first measurement. To show how accessible this is, we built a small open-source tool that does exactly what start where you are asks. It is called the ServiceDesk Intelligence Analyzer, and it answers three questions this principle sits under: where are we today, where do we want to be, and how do we get there. You export your tickets from whatever service desk you already run, ServiceNow, Jira Service Management, Freshservice, Zendesk, ManageEngine, as a CSV or Excel file, drop it in, and it reads that export and tells you where you actually stand.
It is deliberately not a dashboard. It produces an assessment: a data-quality check first, then a theme breakdown, a Pareto view of the vital few categories driving most of the load, MTTR by theme and priority, an automation opportunity backlog, and a 30-60-90 starting plan, exportable to HTML, Markdown, or a PowerPoint deck.
It runs entirely on your machine, uses no model and no training (deterministic, rule-based analytics), and keeps no data: the file is processed in memory, never written to disk, and auto-purges after thirty minutes or the moment you hit "Forget now." The code is open at github.com/shankvijaybackup/servicedesk-analyzer.
The tell is the size and safety of the first move. If it is a full transformation plan built on an assumed starting point, you are planning from a picture. If it is one small, source-traced number you measured this week for one team, changing nothing, you have started where you are.
Identity is the sharpest example, not the only one. Before a CMDB cleanup, measure the real drift between the records and the discovered estate rather than assuming the CMDB is roughly right. Before an endpoint compliance push, read the actual device posture from the source rather than last quarter's report. Before you automate a workflow, baseline how it truly runs today, including the messy exceptions.
Pick one team and one question you have a strong assumption about, unused SaaS seats, who holds admin, stale access, idle cloud resources, and go get the real number from the source system, not from the report about it. Write down what you assumed first, then what you found, and keep both; the gap between them is the most useful thing you will learn this quarter.
What does "start where you are" mean in ITIL 4? It is the second of the seven guiding principles. It means you should not build from scratch without first considering what can be reused, and you should assess the current state directly, using accurate data, before deciding how to proceed.
Why is start where you are important? Because plans built on an assumed current state optimize a place the organization is not actually standing. Assessing the real state protects existing investments and gives you a measured baseline so later improvements can be proven rather than asserted.
How do you measure the current state accurately? Observe directly and source data as close to the source as possible to reduce distortion from intermediate reports.
How is this different from just doing an audit? An audit is usually a big, periodic, all-at-once exercise. Start where you are is smaller and standing: take one safe, source-traced step before you plan, then decide whether to take another.
Is this an official ITIL resource? No. ITIL 4 is owned by AXELOS and PeopleCert. This post explains the guiding principle in our own words; it is not affiliated with or endorsed by AXELOS or PeopleCert.
Start where you are is the discipline of checking the ground before you trust the map, one small, safe step at a time. Do not scrap what already works, do not plan from what you assume is true, and do not wait for a full audit you will never finish; go read one real thing at the source and build from there.
Next in this series: Progress Iteratively with Feedback. For the overview of all seven, see the guiding principles.
Sources and further reading: PeopleCert ITIL 4 Foundation; AXELOS ITIL service management.
