Which project should come first in your IT roadmap?
The warehouse team wants to replace its software, sales needs consolidated reports, and leadership wants to try AI. Each proposal has a reason behind it, and each needs funding and someone to lead it. Approve them all at once and you may end up with too few people to confirm requirements, check results, and take over once the systems go live.
An IT roadmap lays out what a business wants to improve with technology, in what order, and what each stage should achieve. It helps teams understand why one proposal goes first, which ones need to wait, and what needs to be in place before they can start. Each project still needs its own detailed schedule.
Imagine a business about to open another branch that still reconciles stock by hand. The proposals are to replace its warehouse software, build a consolidated report, and try AI forecasting. We’ll use this example to show how business needs and available resources shape the order of work. A technology’s popularity on its own tells you little about when to start.
1. Clarify the problem before choosing a project
Start by asking each team to describe where its work gets stuck. “We need a new report” leaves two questions unanswered. What information is missing, and which decision is being delayed? “We have to call each warehouse to find out if we can fill an order” gives everyone a clearer problem to solve.
In the branch example, first find out why stock figures are unreliable. Staff might record outgoing stock late, different locations might use different codes for the same product, or their data might sit in separate systems. Each cause calls for different work. If staff record stock movements differently, the business may need to standardize that process before buying another reporting tool.
Next, describe the result in terms of everyday work. Order staff should be able to see how much stock is available to sell without calling each warehouse. The team could track how long stock checks take, how often staff reconcile figures by hand, or how many orders need adjusting because stock figures were wrong. Agree on which measures to track before making any claims about the improvement.
Start with a few real incidents, the reports people already use, and conversations with staff who do the work. If the figures are incomplete, write down what needs checking and leave savings estimates open until there is evidence. A short investigation with a clear objective may be the first thing to schedule before choosing a solution.
Decide who will own the outcome after rollout. The technical team can deliver a stock view, but warehouse and sales leads still need to agree on how staff will update, reconcile, and use the figures. Even a funded project may change little in day-to-day work if no one takes responsibility for the result.
2. Compare proposals using the same criteria
Ask teams to describe each proposal in the same way. What is the problem, who is affected, what evidence is available, what result is expected, and what happens if the work waits? Then look at scope, preparation, and who needs to be involved. A common format helps compare the needs of different departments on their merits.
Assess impact and urgency separately. A report may help many people, while an issue already disrupting orders may need attention sooner. A request marked urgent should name the reason, such as a confirmed branch opening, a workflow that is already blocked, or software nearing the end of support. Verify any support deadline for the specific product and version.
Count the work and costs that come after buying or building the software. Who will clean the data, train staff, pay recurring fees, and deal with problems? The option with the lower build cost may require more work from your own team. When information is limited, state your assumptions and what still needs investigating before settling on an estimate.
Developer availability is only one part of the picture. Two projects may both need the same warehouse manager to explain the process and check results. If that person is preparing to open a new branch, running both projects together could slow them both down. Consider the time of business users, approvers, and the people who will take over, alongside the budget.
Scoring can help if the criteria and reasons behind each score are clear. Two proposals may score equally but need different start dates because one is waiting for data or both need the same person. Use scores to guide discussion, then have the decision maker weigh the impact, risks, and practical constraints.
3. Put the work in order based on what needs to happen first
Once you’ve compared the proposals, check what each piece of work depends on. Can the next step start before the first is finished? Reporting across branches requires a common understanding of product codes and stock available to sell. Putting figures on one screen will do little for their reliability if each branch records them differently.
One possible sequence is to confirm the source of stock data and agree on product codes, improve recording at one location, then consolidate reporting across branches. Give each step a result you can check. Confirm the codes, verify that users follow the same rules when updating stock, and reconcile the report against the checked data. Adapt the sequence to how your business works.
If sales history is incomplete or product codes are inconsistent, it may be too early to expand an AI forecasting trial. Before scheduling rollout, check whether the available data is suitable for forecasting. How to prepare your business data for AI explains what to check before investing in a model.
Some preparation can happen in parallel. One team could investigate integration options while another agrees on product codes, if the scope and staffing allow. Identify which work can start alongside other tasks and which can go live only after its prerequisites are met. That distinction prevents avoidable delays and keeps teams from taking on too much at once.
If a technical unknown could change the entire approach, decide how to test it before approving a wider build. For example, the team may need to check whether it can retrieve data from the current warehouse system with the access it has been granted. PoC or MVP: What should you test first? explains how to scope a trial around the question you need answered before building more features.
Business deadlines can change the sequence. If the branch must open before the full solution is ready, agree on the minimum it can use and a temporary way to reconcile stock. Assign someone to manage that temporary process and agree when it will end, so the business can retire it on time.
4. Decide what to start now and when to revisit the plan
For work starting soon, specify the approved scope, the person responsible, the resources available, and how the result will be confirmed. For later work, it may be enough to state the intended improvement and what needs to be in place before it starts. Record project approval separately from inclusion on the roadmap.
In our example, the immediate task might be to review how one branch records stock and agree on new rules. Company-wide reporting moves forward once the data is reliable enough and someone is available to check the results. Revisit the AI trial after assessing the data and the business need. The roadmap then shows each team what is under way and why other work is waiting.
When allocating people and budget, count the work it takes to keep current systems running. If everyone on the internal team joins a new project, who handles incidents, updates, and user support? Account for that time up front so an incident doesn’t force you to pull people off the new project unexpectedly.
Revisit the roadmap when a trial produces results, new information about the data becomes available, or business plans change. Assign someone to bring the information together and someone with authority to change the order. When a proposal is deferred, explain why, record what would make it ready to reconsider, and tell the teams involved. They need to know what has changed beyond the date.
Bring the results of each completed stage into the next review. If a stock view is live but staff still call each warehouse, find out why before rolling it out further. How can you tell if your software is delivering value? shows how to check what changed in everyday work after delivery.
When you speak with Fenix, bring the proposals you’re considering, examples of where work gets stuck, and any limits on people, budget, or timing. We can work through the problems, what needs checking, and a sensible order of work before you settle on technologies or a long-term investment schedule.
