Three causes come up, and none of them is a tooling problem. They can be spotted before the first project starts, which is the only moment when correcting them costs little.
A well-made digital roadmap rarely ends up in the bin. It ends up in a shared folder, consulted three times in the first month, then never. The projects, meanwhile, start as urgencies arise, in an order that no longer has anything to do with the document.
It is almost never a question of the document’s quality. Three causes come up, and they can be corrected.
Cause 1: the roadmap describes projects, not decisions
A classic roadmap lines projects up against quarters: redesign the site, roll out the CRM, automate invoicing. It reads well and it does not get deployed, because a project is not a decision: it is the result of a decision that was never written down.
Behind “roll out the CRM” hide at least four judgement calls: which sales process is being modelled, who enters the data, what is carried over from the old database, and who administers it afterwards. Until those are settled, the project does not really start, it circles in meetings.
The correction is simple and uncomfortable: for every line of the roadmap, write down the decision that has to be taken first, who takes it, and by what date. A ten-line roadmap then becomes a list of fifteen decisions, and it often turns out that half of them belong to nobody.
Cause 2: nobody has the mandate to decide
It is the most frequent cause and the least admitted. The roadmap is approved by a committee, which gives an impression of collective commitment, but no name is attached to any judgement call.
The result is predictable: every decision goes up, comes back down, returns to a meeting. The project is not blocked by a technical difficulty, it is blocked by an approval chain nobody measured.
The test that reveals the problem is one question: for this project, who can say no on their own? If the answer takes more than five seconds, or if it contains an “it depends”, the project will slip. That is not a hypothesis, it is what we observe systematically.
The correction consists of naming, per project, a person whose decision is not reopened. That means accepting that they will sometimes be wrong. An imperfect decision taken in a week beats a correct decision taken in three months, because the second arrives after the context has changed.
Cause 3: the running cost was never costed
Roadmaps cost the build and forget the upkeep. That is what makes them attractive at the approval stage and untenable a year later.
Every project delivered adds a recurring load: somebody has to watch the automations, fix the flows when a connected tool changes, keep the data quality up, apply the security fixes. That load is invisible while it is small, then it saturates the person carrying it, and the following projects wait.
The calculation to do before approving is this, project by project: how many hours a month, and whose time do they come out of? A roadmap whose total exceeds what the team can absorb is not ambitious, it is wrong.
It is also what allows the choice between in-house and outsourced to be settled, not on principle but on a figure.
What changes when the three are corrected
The roadmap gets shorter. It is the most reliable sign that the work has been done: a list of four genuinely decided projects, each with an arbiter and with its upkeep load costed, replaces a list of twelve intentions.
The order changes too, often radically. The project you wanted to do first because it is visible moves behind the one that unblocks the others. An automation freeing five hours a week finances, in time, the projects that follow; a site redesign frees none.
Finally, the meetings change in nature. Progress is no longer presented there, the decisions written against each line are taken there. It is shorter and much less pleasant, which is a good sign.
What a properly annotated line looks like
The theory is quickly understood and badly put into practice. Here is the same roadmap line before and after, on a generic example.
Before. “Q2: roll out the CRM.” One line, one quarter, an implicit owner. It gets approved without discussion because there is nothing to discuss.
After. The same line becomes four dated decisions, each with a name.
- Which sales process is being modelled: the one the team practises, or the one you would like it to practise? Decision of the sales director, before the start of the quarter.
- Who enters the data, and what is mandatory? Three mandatory fields always filled are worth more than twelve filled half the time. Same arbiter, same date.
- What is carried over from the old database, and what is archived. Decision shared with the person who actually knows the state of the data, generally not the one running the project.
- Who administers the tool once delivered, and on whose time? A management decision, because it commits a recurring load.
The line has tripled in size and the project has gained its only chance of starting on time. Almost always, the same thing is observed along the way: one of the four decisions belonged to nobody, and it is precisely the one that would have blocked the project halfway through.
That exercise has a useful side effect. It makes visible the fact that a three-month project often calls for two weeks of prior decisions, which explains better than any speech why the previous quarter delivered nothing.
The five-minute test
Take your current roadmap and, for every line, answer three questions.
- What decision has to be taken before this project starts, and is it written down somewhere?
- Who can settle it alone, by name?
- How many hours a month will this project cost once delivered, and on whose time?
A line that leaves a single one of those three questions unanswered will not be deployed. That is not a pessimistic prediction, it is simply that it lacks what it takes to start.
It is the work we do upstream of a project, and it takes up most of our digital strategy engagements. The visible part, the projects themselves, comes afterwards and goes fast when this part has been done.
