Prioritising IT projects
By Redaktion techport.ai, IT-Beratung · Last updated on
Almost every mid-sized company has more IT initiatives than capacity. That is normal. It becomes a problem when all of them are started because nobody wants to set an order. Then twelve projects run at fifteen percent each, every single one is explainably delayed, and at the end of the year none is finished.
A portfolio is not a list. It is a decision about what is not being done right now, and the willingness to say that out loud.
How you notice it
- The project list grows but nothing gets completed.
- The same people are planned into six projects, at twenty percent of their time each.
- Initiatives start because a department head pushes, not because they are next in line.
- At the end of the year the budget is spent but nobody can say what came of it.
Why this happens
Prioritisation means saying no to someone, and that is uncomfortable. As long as there is no shared basis for assessment, every refusal is a personal decision against a colleague. So initiatives are all started and then quietly delayed. On top of that comes a systematic misjudgement of capacity: planning uses theoretical working time while operations, incidents and holidays absorb half of it in practice.
How we go about it
- Collect the initiatives completely. We gather all initiatives, including those planned in departments without IT involvement, and describe each in a few sentences with goal, benefit and rough effort.
- Assess against common criteria. We assess each initiative by business benefit, effort, risk of doing nothing and dependencies on other initiatives. Mandatory work driven by law and work driven by expiring support is shown separately, because it is not genuinely up for selection.
- Set capacity against it realistically. We determine the project capacity actually available in house, separated by role and by bottleneck resource, and place initiatives in order until capacity is exhausted. Everything below that is the waiting list, visible and named.
- Decide regularly. We set up a short cycle in which progress, postponements and new initiatives are handled, using the same criteria as the first assessment. Prioritisation becomes routine rather than an annual trial of strength.
What you gain
- Fewer simultaneous initiatives and therefore more completed ones.
- Refusals that are justified and therefore accepted.
- A visible waiting list that stops initiatives starting through the back door.
From our projects
In a first complete collection we regularly find between thirty and fifty initiatives in mid-sized companies, of which IT knows about half. The rest sit in departments and only become visible when an interface or an account is needed. The second reliable observation concerns capacity: when we set the planned person days for IT against those actually available, the plan is on average twice what is possible. That comparison is uncomfortable and ends discussions faster than any scoring matrix.
Häufige Fragen
How many projects can a small IT team carry at once?
As a guide: one larger initiative and two smaller ones per person who genuinely has project time, not per head in the department. What matters is the bottleneck, usually a single person with system knowledge. Planning that person into more than two projects at once is planning for delay.
How do we handle initiatives that are imposed from outside?
Legal obligations and expiring support are not candidates for prioritisation but fixed dates. They are planned first and absorb capacity before the rest is discussed. That separation prevents the most common disappointment, which is a sensible initiative being selected and then displaced by an obligation.
Let us talk about Prioritising IT projects
In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.
Further reading
Back to the field IT Strategy and Steering