Project Roadmap: Which Projects Will You Add to Yours in 2026?

The leadership team of a Quebec City SME arrives at its annual planning session with 14 projects on the list: an end-of-life ERP, a new accounting standard, a warehouse to automate, two requests from marketing. Three business analysts are available. Nobody has quantified what each project will demand of them. The roadmap that comes out of that meeting will be approved, then bypassed by March.

The figures cited come from public international studies and serve as indicative benchmarks: your project success rate depends on your governance, your data and the real availability of your teams.

According to PMI's Pulse of the Profession 2018, 9.9% of every dollar invested in projects is wasted through poor performance, down from 13.5% in 2013.

How do you build a project roadmap from business needs?

A project roadmap is built by starting from a specific business need, such as a database to secure or facilities to upgrade, then listing every potential project before selecting a single one.

Running a business means keeping operations flowing and employees well, but also seizing the opportunities that come along. Digital transformation is one of them. That does not justify every project attached to the label.

Ten questions help identify the most important and most urgent projects:

• Will any current projects have a follow-on phase?
• Are some of your systems reaching end of life?
• Do new regulatory obligations apply to your organization?
• Does an organizational restructuring require new systems?
• Is an acquisition or the sale of a business unit planned?
• Does a new accounting or industry standard force changes to your processes?
• Did completed projects fail to deliver all the expected functionality?
• Do some business processes have performance problems or significant issues to fix?
• Does the business strategy require new systems for you to deliver your share of the plan?
• Which projects in other divisions will affect you, and who delivers prerequisites to whom?

The last question is the one most often skipped. It deserves its own exercise, described in The interdependence of projects, a reality not to be overlooked.

What should a solid business case contain for each project?

A solid business case contains a cost range rather than a single number, the full list of financial, strategic, quantitative and qualitative benefits, the candidate solutions with their maturity level, and it is updated throughout the project.

The estimate you hold at business-case time is preliminary and high level. Presenting it as a firm number is the surest way to create a bad surprise. We detail that discipline in Project cost estimation: simple but unforgiving.

Then explain how and why the project will benefit the company, including cost reductions and cost avoidance. Find out how mature and robust the candidate solutions are: meet experts in your field, review your industry's best practices and meet the software vendors. An independent opinion, from someone who sells no software, is worth a great deal at this stage.

A few benchmarks to calibrate your business cases:

• 9.9% of every dollar invested in projects wasted through poor performance (PMI, 2018).
• 92% of projects successful at champion organizations, versus 32% at underperformers (PMI, 2018).
• 45% average budget overrun and 56% less value delivered than predicted for large IT projects, according to McKinsey and the University of Oxford (2012).
• 15% additional cost overrun for every extra year of project duration (McKinsey, 2012).
• 1 cost range, never a single number, in every business case submitted for funding (PlanAxion).

Finally, understand your company's prioritization and funding allocation process. The more profitable and strategy-aligned a project, the better its odds of being selected by senior management. The business case then serves as a compass for the major decisions made during delivery.

Why do your own people set the pace of the roadmap?

Your internal resources set the pace because some expertise specific to your company cannot be bought on the market: it has to come from your staff, and that is often the ultimate constraint on how fast the portfolio can be delivered.

Prepare a human resources plan for each project under consideration. It reveals whether your organization can supply all the required expertise and which skills will have to come from outside. Above all, it reveals that the same controller, the same warehouse manager and the same analyst appear in four projects at once.

A roadmap that ignores the real availability of your people is not a plan: it is a wish list approved in committee.

Arbitration between projects competing for the same scarce people is not systematic in most organizations. It gets settled by influence, and that approach rarely leads to the best decisions.

Harvard Business Review named the phenomenon in 2018: initiative overload. Its causes range from impact blindness to unfunded mandates and plain inertia. The proposed remedy starts with an exact count of the initiatives under way and a sunset clause for each one.

Before launching a project, build the team that will carry it. Our article Recruiting: 14 questions to ask yourself before recruiting project team members offers a grid for doing so without improvising.

So, which projects will you add to your roadmap?

Add the projects that answer a named business need, whose business case presents a cost range and explicit benefits, and for which you have verified that the scarce internal people are genuinely available. The others wait for the next cycle, without shame. A short roadmap that gets delivered beats a long one that gets bypassed.

Frequently asked questions

What is a project roadmap?

A project roadmap is the ordered list of projects an organization commits to deliver over a given period, with their sequence, their dependencies and the resources they mobilize. It flows from business needs, regulatory obligations and strategy. Every project on it should be backed by a business case and a human resources plan that names the people involved.

Why present a cost range rather than a single number?

Because the estimate available at business-case time is preliminary and high level. A single number becomes a promise the project cannot keep. A range reflects the real uncertainty, protects the team's credibility and avoids bad surprises. McKinsey notes that large IT projects run 45% over budget on average, which is exactly the kind of gap a range anticipates.

How do you prioritize projects when internal resources are scarce?

Prepare a human resources plan per project, then spot the people who appear in several projects at once. They set the speed of the portfolio. Arbitrate systematically, with known criteria, rather than by influence. Harvard Business Review also recommends counting every initiative under way and giving each one a sunset clause so that stopping is not seen as failure.

What does a project business case contain?

A business case contains the target business need, a cost range, the full set of expected benefits (financial, strategic, quantitative, qualitative, cost reductions and cost avoidance), the candidate solutions with their maturity, the risks and the required resources. It is updated throughout the project and guides the major decisions made during delivery.