IT Portfolio Management

Snapshot

• Role: IT Portfolio Manager
• Organisation: One of Germany's four largest telecommunications providers
• Portfolio: Digital Help Center
• Starting point: ~25 barely defined Jira tickets, unclear priorities, almost no budget transparency
• Outcome: 14 initiatives with defined scope, cost, timeline and delivery expectations

Starting point

When I took over the role, the portfolio was in no good state: around 25 Jira tickets, some of them untouched for over ten months — and that despite continuous activity over the nine months prior, just without much actually being delivered.

Most tickets consisted of one or two lines of text, with no acceptance criteria or effort estimate, but almost all of them marked as "highest priority" — what that term was still supposed to mean in this context was no longer really clear.

On top of that, there were many stakeholders with partially conflicting objectives. Budget and resource questions were handled reactively rather than proactively, and risks were not addressed early, because nobody felt clearly accountable for the overall portfolio. Only after problems became visible in a larger C-level round did the portfolio management finally start moving.

The core problem was therefore less the number of tickets than the missing basis for sound decisions: scope, effort, cost, dependencies and expected value were not transparent enough.

What I did

1. Making the backlog visible and comparable

The first step was basic, but necessary: go through the backlog in full and understand which tasks actually existed and what state they were in.

Within the first week, I turned the roughly 25 tickets into a concrete list with initial effort estimates and a traceable prioritisation. It wasn't perfect, but it was enough to go into stakeholder conversations with a defensible starting point rather than a personal opinion.

From those conversations emerged a roadmap that the participating stakeholders stood behind. With that, the basis for further elaboration was in place.

2. Turning tickets into concrete initiatives

Next came the stepwise elaboration of the prioritised topics, starting with the Priority 1 initiatives.

From vague ticket descriptions, concrete Jira tickets emerged, including:

• Acceptance criteria
• Use cases
• Business value
• Measurable success criteria
• A clearer scope

Tickets that met the checklist for that were tagged "ready for refinement" — a signal that the respective Product Owner could bring them into the next team refinement. Once the development team accepted a ticket as estimable, the status changed to "ready for estimation". After estimation, the resulting effort values fed back into the roadmap timeline and the ticket received the status "ready for development". In parallel, feasibility and dependencies were discussed with the relevant stakeholders.

This gradually created a connection between product requirement, technical implementation, effort and planned delivery.

3. Establishing governance and decision-making

I introduced regular steering meetings and built a KPI-based reporting framework, including:

• Time
• Budget
• Effort estimates
• Development progress
• Cost per sprint
• Release dates

In addition, ownership and escalation structures were more clearly defined.

It was important to me not to build governance as an additional reporting layer. The information should serve to enable decisions: What gets implemented? What gets postponed? Where do resources need to be adjusted? And for which initiatives is further investment no longer reasonable?

4. Dealing with competing interests

Part of the work was also dealing with competing interests and priorities within the organisation.

Such conflicts cannot simply be resolved through another escalation layer. I therefore tried to make the underlying assumptions, costs and dependencies visible and steer the discussion toward these facts, rather than postponing decisions or letting them rest on unproven assumptions.

This did not work equally well for every topic. In one or two initiatives it still ended up being a compromise rather than a clean prioritisation, because the interests of the involved stakeholders were too far apart.

That was an important realisation for me: transparency makes conflicts visible, but it does not automatically resolve them.

5. Connecting roadmap, resources and budget

On the financial side, I linked the roadmap with resources, delivery dates and budget. In addition, KPI tracking was introduced to make cost per deliverable measurable at all.

This created a basis for consciously continuing, adjusting or stopping initiatives, instead of simply letting them continue.

For the further allocation of budget, business cases were used. They compared expected value and cost and made it possible to evaluate additional financial resources on a traceable decision basis.

6. Translating team estimates for portfolio planning

One challenge arose from the fact that portfolio and budget planning needed a time-based view in project days, while the development team was estimating in story points.

I did not want to replace the team's estimation with an artificial conversion. For portfolio and budget planning, however, I needed a common planning unit.

So I used a pragmatic conversion factor based on the team's historical performance. The team delivered an average of 53 story points per 10-day sprint:

53 story points ÷ 10 sprint days = 5.3 story points per sprint day

For portfolio planning, I worked with the assumption:

1 team day ≈ 5.3 story points

A team day consists of all members of the Scrum team — not just the developers, but also the Scrum Master and the Product Owner. From this, an approximate person-day value could be derived:

53 story points ÷ team size ÷ 10 = approximate story points per person day

This was explicitly a planning and communication workaround and not a claim that story points should fundamentally be converted into person-days. The team's original estimation remained the basis for technical planning.

The approach allowed me, however, to connect the existing team estimates with costs and planned delivery dates at portfolio level.

7. Using AI as a solution to a concrete problem

Alongside the portfolio work, I initiated an AI-supported chatbot PoC to explore whether efficiency potential could be unlocked in the Help Center's service.

Beforehand, I had already published a LinkedIn post on the topic and built a small application with Voiceflow: linking their chatbot to the publicly available Help Center content. I had the provided links crawled, vectorised and transferred into a database, so that the Voiceflow bot (with LLM integration) could use them as a RAG data source. That quickly led to conversations inside the company and, later, to its concrete implementation.

The approach emerged because there was a concrete problem: the existing classic Help Center search did not always deliver the answers customers needed for their specific question. The PoC's goal was therefore to generate more relevant and targeted answers with the help of a large language model (LLM) and the vectorised content.

In that way, AI was not treated as an end in itself, but as a possible technical solution to a concrete service problem.

Outcome

From the initial roughly 25 tickets, 14 initiatives emerged with clear scope, timeline, cost and delivery date, as well as a new budget approval.

For the first two Priority 1 topics, acceptance criteria and business value were defined within the first week. This meant these topics could be further refined, estimated and planned for the upcoming sprints.

Efforts were expressed in project days and linked to a cost rate. This made it possible to present stakeholders with a concrete, estimated timeline rather than vague delivery expectations.

With each sprint, the timeline and financial planning became a little more robust. As a result, resource allocation and prioritisation became more traceable.

A business case was established for every initiative, weighing expected value against cost.

The most important change was ultimately transparency: decisions could be based more strongly on effort, cost, expected value and delivery constraints — and less on who had most recently argued loudest for an initiative.

What I took away from it

A backlog is not a roadmap

A backlog is initially just a collection of tickets. Before it can become a solid roadmap, the entries need to be sufficiently detailed to be comparable in terms of effort, value and delivery constraints.

Priority labels without effort, expected value and delivery constraints basically say very little. I experienced that here very directly, when practically every ticket was marked as "highest priority" and the actual content sometimes consisted of only one or two lines.

Budget

Once costs and the delivery envelope become visible, a pure preference debate transforms into a concrete trade-off.

The question is then no longer just:

"Do we want this initiative?"

but:

"What expected value do we get for the necessary effort, and which other initiative might we have to postpone for it?"

That doesn't automatically make prioritisation easy, but it creates a much better basis for decision-making.

Governance

Governance only helps if it actually leads to decisions and ownership — not if it merely creates another reporting layer.

I already knew that beforehand. In practice, though, it became very clear how large the difference is between reporting that merely documents and reporting that prepares a concrete decision.

Transparency

Situations like this require maximum transparency so that everyone involved is aware of where the portfolio actually stands.

At the same time, that inevitably also exposes mistakes from the past. That can create further unease and make additional change necessary on different levels.

A shared retrospective with the stakeholders was something I could not establish during my time as IT Portfolio Manager. Interest in it was low. A typical response was along the lines of:

"What's the point of going back over the past? We need to look ahead."

That we need to look ahead is true. Yet I took away from this situation that without shared reflection, everyone involved develops their own explanation for the past.

That way, not only possible learnings are lost. It also becomes harder to develop a shared understanding of why certain problems arose and what would need to change organisationally to prevent them from repeating.

For me, therefore, portfolio work involves not only the question:

"What do we do next?"

but also:

"What have we learned from how this played out?"