The development manager walked into my office and asked, "Can you take on another project?" I didn't know what to say. She went on to explain: "We need a list of our preferred customers. Another partner wants to extend them a discount. It's just a data dump and we're really in a bind. Can you take it? It'll be very part-time to start; they are just getting started with planning."
You may be working in a different environment, but the scenario of too much work, uncertain priorities and unrealistic deliverables is probably familiar in some way. Project portfolio management, sometimes called PPM, is one way to address the problem. Today I'll describe a road toward PPM that you can take no matter your role, one that does not have to involve creating an office, new job descriptions or large capital investments.
Project portfolio management defined
The PPM analogy recasts money spent on projects not as expense, but as investment, and challenges its supporters to come up with ways to manage that investment just as they might a financial portfolio.
Let's start with the toughest case, working as an individual contributor, multitasking with priorities that are less than clear. If you are in that position, one thing you can do is start taking notes about what you are actually working on and how long things are actually taking, along with some projections for when projects should wind down. The goal here is to create a spreadsheet something like this:
Armed with this spreadsheet, the next time your manager enters your office and asks if you can you take on a new project, you can look at the data and say something like, "Actually, I'm doing a little bit of overtime as it is. I could start doing some exploratory meetings the week of Oct. 15, then I have some time on Oct. 22 … unless you can take something else off my plate?"
That brings things back to reality. In order to invest in a new project, the company needs to either wait for a project to wind down, or slow or stop work on something already in progress. In financial terms, it means that to buy stock you need to either sell an existing stock or spend out of cash reserves. Keep in mind, if you slow work on projects, those projects become late and cost more in the long run.
Of course, these are projects. It is always possible that the ERP upgrade takes longer than expected, but when that happens, you can deal with it, make a cutline of forty hours (or forty-five) and ask the manager what you should not do.
If you've been in management, you know that you get the same questions from senior management: "Can you take on a new project?” -- with even more vaguely defined scope and timelines than contributors. If your team can make a spreadsheet like the one above, or you can at least talk them through it, then you can turn around and create something like this, the same sheet at the team level:
In this example, the team of ten people is currently understaffed, which means projects are either going to be late, buggy or both.
At the IT department level
Once each team does this kind of work, it doesn't take much to roll up the numbers and report them for the next level. Here's an example for a small IT department with a half-dozen teams:
With this spreadsheet in hand, we suddenly understand the reason for pressure, and, perhaps, the core of the problem.
Right now the business analysts and the project managers have availability, which means they are looking for work. Application Development, on the other hand, does not have work, which means we'll create a bottleneck on the programmers. In order to create the appearance of forward progress, the programmers will multi-task, which will make everything late. Meanwhile, the analysis work is done, and the analysts want to get on to the next project, so they ask, "Do you have time for one more project?" The line managers say, "I guess so" ... and you know the result.
Project portfolio management changes all that. It allows you to look at the department holistically, realize that the bottleneck is in test, and change your investment (hiring, staffing) strategy to align with the company's need for staff. On top of that, it changes the "it seems like we spend a lot of time on maintenance" discussion. If support is creeping up because of shortcuts and technical debt, making the cost visible on the spreadsheet will force the tough conversations.
Remember, I started the discussion with the worst case. Let's spend a little time talking about the best.
A different way to think about it
One common strategy for stocks is to not invest in a bunch of things, but instead take a step back and select four or five mutual funds, each with a fund manager to do the active managing. The software analogy is to build multi-disciplinary project teams. Each team might have three programmers, a Web developer, a DBA, an analyst and so on.
Portfolio management allows you to look at the department holistically.
This means you won't always have the right people for the job. Sometimes, a project will be Web-heavy and a programmer may need to step in. Likewise, a project might not require much DBA work and the database may not be 100% busy all the time.
The tradeoff here is that instead of picking and choosing projects when the right staff is available ("We need one more DBA to get project FOO going"), we can instead start a real project when a team is available. Moreover, we can actually measure the results of a team like a real investment: What did team venture actually get done in the third quarter? This helps decide if teams should get team-based rewards, if we should do additional investment (hiring) or create a new team.
A way forward
If you are an individual stuck in multi-tasking land, you can track your time for a week to create that first spreadsheet based on what you are actually doing, not what you are supposed to be doing. Yes, it will be approximate. Yes, a forecast is not a promise, but it's a start.
If you are a manager, you can work with your teams to create the spreadsheet, just like a director can. Johanna Rothman and Esther Derby describe how to do this step by step in their book Behind Closed Doors: Secrets of Great Management.
Beyond the planning for people, though, my personal interest is in managing integrated teams, and figuring out how to value the work they are doing and adapt the portfolio. Rothman has another book, Manage Your Project Portfolio, that goes into a little more depth, but it is an area where the body of knowledge is still being invented.
If you are doing work in this area, drop me a note, or leave a comment. I'm sure we'd all like to hear about it.
Dig Deeper on Building Software Project Teams
Matt Heusser asks:
Has your team benefited from portfolio management?
0 ResponsesJoin the Discussion