What a roadmap that survives contact contains
Most roadmaps on this subject fail for an arithmetic reason rather than a strategic one: they count build time and nothing else. Build time is rarely half the real calendar of a first project. Getting read access to a production database, passing a security review, catching a monthly release window and spending the weeks after launch alongside the people whose work changed together consume more than writing the system does. A plan that omits them is not optimistic, it is wrong, and it will be visibly wrong by week three, which damages the credibility of everything that follows it. An honest roadmap fits on one page. It commits to a quarter, states an intent for twelve months, details nothing beyond that, and gives explicit calendar space to three things that are not projects: who approves data access, where evaluation sets live, and which named person arbitrates. Settling those three during the first project saves more time on the second than any amount of skills development, and no organisation we have worked with has regretted doing it early.
The real calendar of a first project
Assessment, one to two weeks. Watch the work being done, open the data rather than its documentation, establish the realistic ceiling. The highest-return phase and the one most often skipped.
Data access, two days to six weeks. The widest-spread variable, and the one that best explains the difference between two otherwise comparable projects. Start it on day one, before deciding what to build, because the clock runs either way.
Build, three to six weeks. The part everyone talks about and the part that slips least, provided a real user sees something in the first few weeks rather than at the end.
Integration and release, two to five weeks. Mostly waiting rather than difficulty: security review, permissions, imposed release windows. There is no point negotiating these and every point in counting them.
Adoption, three to six weeks. The line plans delete first and the one that decides whether the system gets used. A plan that allocates zero days to it has decided, without saying so, that usage is out of scope.
Choosing the first project
The first project has a purpose beyond its own result: it teaches the organisation how to deliver. It should therefore be chosen for its probability of landing rather than for its ambition.
Three traits, and reject candidates that have only two. Enough volume for the gain to be visible. A clear, shared definition of what a good output is. A named person accountable who wants the change.
The third decides the outcome more often than the other two combined, and it appears on no project scoring sheet. The opposite temptation is to begin with whatever is most visible at board level, which is usually the riskiest thing available. An early failure costs durably more than an early success returns, because it fixes the organisation's opinion of the technology for about two years.
The three workstreams that are not projects
The data access path. Who approves, how long it takes, through what procedure. Establishing this once turns a six-week wait into a few days for every subsequent project, and it is the single largest productivity gain available to most organisations on this subject.
Where evaluation sets live. Who maintains them and how they are re-run. Without this, every project builds its own and the organisation accumulates nothing, even though these sets are the most durable asset the work produces.
Arbitration. A named person with real authority, to whom a question about an intended use goes. A committee with no name attached produces documents and no decisions, and teams eventually route around it.
How to write the quarter down
The committed quarter is the only part of the roadmap that needs precision, and it needs less of it than most plans carry. Four lines are enough: the problem, the named owner, the date by which a real user will see something imperfect, and the measure that will decide whether it worked.
That fourth line is the one worth arguing about before anything is built. One measure survives contact: how many people use the system without being required to, a month after the project team has left. Login counts, stated satisfaction and enthusiasm in review meetings all decay the moment attention moves elsewhere, and all three can be produced without anybody's work having changed.
Everything else in the quarter, the architecture, the choice of model, the integration order, belongs to whoever is doing the work. A roadmap that specifies those decisions is making them months before the information needed to make them well exists, and it will be defended past the point where it should have been revised.
What does not belong in the plan
Parallel projects, until the first has reached production and use. The blockers are shared, the same security reviewers and release windows apply to all of them, and three at once inside an organisation that has delivered none mainly multiplies the chance that nothing lands.
Quantified efficiency targets before the assessment. Committing to a percentage before looking at the data is committing to an average of other companies, and the variance between organisations on the same process is larger than the effect being claimed.
And detail beyond twelve months. Capability moves fast enough that a detailed three-year plan forces the organisation to defend choices made in a world that has changed, which is the most reliable way to lose the confidence of the people expected to execute it.
One problem, thirty minutes
Describe something that takes too long today, including the exceptions. We will tell you whether it is worth building, and we will say so plainly when it is not.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
