Digital Roadmap & Feasibility Consulting
The engagement to run before committing a development budget. It establishes what is actually needed, what is realistic, what it depends on, and in which order the work should happen — in writing, with the reasoning visible.
The situation this service is built for
A decision is pending and the organisation is not equipped to make it confidently. Perhaps a system is showing its age and nobody agrees on whether to fix it or replace it. Perhaps a good idea exists but the scale is unknown. Perhaps three departments each want something different and the budget will support one.
Meanwhile the cost of getting it wrong is not just money. A poorly chosen route consumes a year, exhausts internal goodwill and leaves the organisation more reluctant to try again.
This engagement is deliberately short and deliberately cheap relative to a build. Its purpose is to convert opinion into evidence, and a wish-list into a sequence, before a much larger commitment is made.
It is also the right engagement when a budget needs justifying to a board, a lender or a funding body: the output is written to be read by people who were not in the room.
Problems this service may address
- Nobody agrees on scopeEach department describes a different project, and the version being priced depends on who was asked last.
- Build, buy or improve is unresolvedExisting products have been demonstrated but nobody has assessed them against the actual requirement.
- The project is too large to startThe requirement is genuine but the whole thing cannot be funded at once, and no sensible first phase has been defined.
- Quotations vary wildlySuppliers have quoted very different figures, which usually means they were quoting for different things.
- Feasibility is unknownThe plan depends on assumptions — data availability, integration, volume — that nobody has tested.
- Budget approval needs a caseMoney will not be released without a written rationale, phased costs and identified risks.
- Previous attempts stalledSomething was started before and abandoned, and nobody has established why in a way that prevents a repeat.
Possible deliverables
Content is agreed at the outset. A short engagement concentrates on the two or three elements that will actually change the decision.
Deliverable components
- Current-state review
- Requirement clarification
- Priority mapping
- Opportunity assessment
- Feasibility observations
- Phased roadmap
- Risk and dependency overview
- Next-step recommendations
Typically included in scope
- Stakeholder interviewsConversations with the people who hold the requirement and the people who would use the result.
- Review of existing materialDocuments, previous proposals, current systems and any earlier attempt at the same problem.
- Option developmentRealistic routes, including doing nothing and doing something smaller.
- Indicative effort rangesRough scale for each phase, stated as a range with its assumptions rather than a false precision.
- Written reportFindings, reasoning and recommendations, readable by a non-technical decision-maker.
- Walkthrough sessionA discussion of the findings so the reasoning is understood, not only the conclusion.
What is not automatically included
- A binding fixed-price quotation for the buildIndicative ranges are given. A firm price requires the detailed scoping that follows a decision.
- Detailed technical architectureComponent maps and data-flow models belong to Solution Architecture & Technology Selection.
- Code-level review of existing softwareDetailed inspection of an existing application is covered by Application Review & Modernisation Strategy.
- Supplier procurement managementAdvice on what to ask suppliers is included; running a tender process is not.
- Financial, legal or regulatory adviceCommercial and compliance implications must be assessed by the client's own advisers.
- Any guarantee of outcomeThe report improves the quality of a decision. It is not a legally binding guarantee and cannot promise a commercial result.
Engagement process
Framing the decision
A short conversation establishing precisely what must be decided, by when, and by whom. Engagements that begin without this tend to produce interesting documents that change nothing.
Proposal and access arrangement
A written proposal setting out the deliverable components, the people to be interviewed, the material required, the timescale and the price.
Information gathering
Interviews and document review. Where accounts differ between departments, the difference itself is recorded — it is usually the most useful finding in the engagement.
Analysis and option development
Options are constructed and tested against the agreed criteria, including the options that involve no development work at all.
Draft findings and factual review
A draft is shared so factual errors can be corrected. Conclusions are not negotiated; facts are.
Final report and walkthrough
The final document, delivered with a session covering the reasoning, the risks and the recommended first step.
Expected deliverables
- Written roadmap or feasibility reportThe agreed components in one document, structured for a decision-making audience.
- Phase planWork sequenced so each phase delivers something usable, with dependencies between phases identified.
- Option comparisonRealistic routes assessed against the agreed criteria, with trade-offs stated plainly.
- Risk and dependency registerWhat could derail the plan, how likely it is, and what would reduce the exposure.
- Assumptions and open questionsWhat the analysis assumed and what remains genuinely unknown.
- Recommended next stepOne specific action to take next, so the report ends in movement rather than reflection.
Client responsibilities
- A clear statement of the decision to be made and the constraints around it
- Access to the relevant people, including those who disagree with the prevailing view
- Existing documentation: previous proposals, current system information, earlier attempts
- Honest information about budget range and timing, even if approximate
- Prompt factual review of the draft, within the agreed window
- A named recipient with authority to act on the recommendations
Factors that affect scope and price
Increase scope
- Many stakeholders across several departments or sites
- Substantial existing documentation requiring proper review
- Several distinct options needing detailed comparison
- Formal presentation material for a board or external funder
- A roadmap spanning multiple systems rather than one
Keep scope lean
- One specific decision rather than a general technology review
- Three or four interviews rather than fifteen
- A concise report over a formal document pack
- A single nominated contact arranging all access
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
Follow-up options
Nothing at all
A legitimate outcome. The report is yours, and can be used with any supplier or kept until circumstances change. There is no obligation to proceed.
Architecture engagement
Where the roadmap confirms a build, the next step is usually a component map and technology comparison before development is priced.
Phase one build
Where the first phase is clear, a development proposal can be prepared directly from the roadmap without repeating discovery.
Questions about this service
For a specific decision, yes. The constraint on this engagement is rarely analysis time; it is the availability of the people who need to be interviewed.
Longer engagements are usually a sign that the question was too broad. Where an organisation genuinely needs a wide technology review, that is scoped as a larger piece of work and priced accordingly.
It gives indicative effort ranges per phase, with the assumptions behind them stated. That is usually enough to establish whether a plan is affordable and where the expensive parts sit.
It is not a fixed quotation. A firm price requires detailed scoping, which follows the decision rather than preceding it. Presenting a precise figure at this stage would be false precision.
Yes. It is written to be usable by anyone: an internal team, another development supplier, or the organisation itself.
Several engagements are commissioned specifically so that suppliers can quote against a consistent requirement, which usually produces far more comparable quotations than a verbal brief.
By including options that produce no development work — configuring an existing product, extending a current system, or changing a process instead of building software — and by assessing every option against the same criteria.
The reasoning is written down, so a recommendation can be challenged on its merits. A conclusion that always favours a build would be visible immediately in the argument, which is a reasonable protection for the client.
Then that is what the report says, with the reasoning and, where one exists, a smaller version that would work.
Delivering that conclusion is the most valuable thing this engagement can do. It costs a fraction of the build it prevents, and the report explains the position clearly enough to be presented internally.
Continue
Services that often follow this one
Service enquiry
What decision is currently stuck?
State the decision, who needs to agree and what has already been considered. That is enough to establish whether this engagement is the right size.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom