Skip to content
Leandro Vieira

IT project portfolio: the practical guide to structuring it (Part 1)

Learn how to structure a Project Portfolio service in an IT PMO from scratch. I share my practical experience, challenges and initial solutions

Share WhatsApp

Imagem 1 do artigo: IT project portfolio: the practical guide to structuring it (Part 1)

Do you juggle too many demands at once and feel lost? In 2023, I was in exactly that situation, and I'll show you what we did to turn things around in technology project portfolio management.

Keep in mind that every company has its own context and culture, so the structure I present here will guide you, but it isn't necessarily a silver bullet that solves every problem.

Even so, I'm confident this content will help you a lot throughout the process.

Structuring the Project Portfolio Management Area

Portfolio and project management maturity at the company

At the time, the company had no project and portfolio management culture to speak of, meaning maturity and governance were close to zero, and that directly affects how a new structure gets implemented.

In practice, that meant there were no defined processes for managing the department's projects, let alone managing a portfolio of those projects.

Organizational structure

The company was structured functionally, with 5 clearly defined departments at the time: Administration & Finance, Commercial, Legal, Operations and Technology.

The Portfolio area would be created inside the Technology department, while the others operated as the business side.

The Technology department had the following teams: Infrastructure & Telecom, Systems and Support, Governance, Information Security, Business Intelligence, and the new structure that would be created: Portfolio & Projects.

Context

Within the Technology department, although there was a Governance area, it was also at an early maturity level, fairly low (I couldn't say exactly how low). As a result, control over incoming requests to the IT area still had gaps in the process.

Why does this matter? Picture these questions:

  • What projects and fixes is our team working on?
  • What's the scope of work for the projects?
  • What's the delivery deadline for the projects?
  • Who requested the projects we're working on?
  • What impact do these projects have on our company?
  • Which projects tie into the company's strategic plan?

Imagine you're the director and you have no answer to any of the questions above. That was the situation at the time.

Also consider that the business areas were frustrated with the technology area for not meeting agreements, deadlines, and often not even getting a response.

Sources of frustration?

😡 An IT team that felt "burned" and reactive; 😡 IT team missing promised deadlines; 😡 IT team slow to deliver things; 😡 Everything here is a priority;

The initial solution

Before thinking about a new structure, area, methods or tools, the first thing we did was list EVERYTHING we were doing in a spreadsheet.

We wanted a quick, simple sense of the amount and size of the work we were putting effort into, and where it was going.

There was no defined scope. Every leader in the technology department listed the projects and requests that came in by email, hallway conversations, chat, WhatsApp, things from anywhere at all.

We just listed everything with as much detail as possible in a shared spreadsheet.

The goal was simple: visibility!

Things were completely scattered across channels, and to be fair, the only centralizing place we had was the ticketing platform, which stored requests of every kind of work.

The spreadsheet

Every manager and director loves a spreadsheet with a pivot table next to it. 🙂

Our spreadsheet was structured with the following columns:

  1. Requesting department/head
  2. Initiative name
  3. Description / summary
  4. Detailed need
  5. Status (exactly at that moment)
  6. Requester's contact
  7. Estimated effort, by order of magnitude: low, medium, large, very large
  8. Impact on our business: low, medium, large, very large
  9. Where it came from: ticketing system, chat, phone...

As we filled it in, we added:

  • Cross-departmental: yes/no, which department;
  • Grouping: main theme to group related things together;
  • Priority: estimated delivery in Q1, Q2, Q3, Q4;
  • Strategic plan: structural or strategic;
  • Pillar: specific system;
  • Type of impact: operational optimization, revenue increase, cost reduction;

In the video below I walk through the spreadsheet and the process of filling it in, check it out!

The survey and listing took about two weeks, and around 250 initiatives, projects or requests emerged. That became our starting point for seeing the full picture.

Once listed, the next step was to classify, refine, update statuses, understand the scopes and go into as much detail as possible.

The second step of the initial solution

Knowing the size of the problem you're facing is the first step to solving it.

With the work made visible to all managers, we had to face the reality that demand was far greater than our execution capacity.

The second step was to bring that reality to the other departments in the company and start the prioritization process for requests.

With estimated effort (small, medium, large) and impact data in hand, the initial criteria were:

  1. Start with the "quick wins," where the smallest effort could bring the biggest impact.
  2. Finish the work already in progress, even if its impact was smaller. In other words, follow through on things.

With these two prioritization criteria agreed on with the departments, we began structuring our portfolio management.

Important: having a big spreadsheet with all the requests doesn't mean emergencies stop showing up, or that hallway requests, chat messages or informal conversations go away.

This is a long effort we'll cover more in future articles.

Conclusion

Structuring a Project Portfolio service in a low-maturity environment is a challenging and rewarding journey. There's no magic formula or one-size-fits-all recipe that applies to every context.

My experience showed that the starting point is always the same: visibility.

Starting simple, by creating a spreadsheet that captures the current reality, is what let us see the size of the challenge and, more importantly, start an honest conversation with the business areas about what could realistically be delivered.

The prioritization process, starting with quick wins and finishing work already underway, was key to building initial credibility and showing practical results.

Transformation doesn't happen overnight. Breaking old patterns, like the persistence of informal requests, is ongoing work that takes patience, persistence and, most importantly, building a relationship of trust with people (your stakeholders).

This was just the first step in structuring the Portfolio & Projects area.

There's a long road ahead, and I'll share the next steps, but by starting with visibility, you'll be building a solid foundation for the success of your portfolio and project service, and in turn, for your organization's strategic alignment.

Have you already taken the first step? Then you'll like the follow-up in this article. Check it out!

If this article was useful in any way, share it with a colleague!

Take care,

Share WhatsApp

Keep reading