~ By Johanna Rothman
You've got a ton of projects. You can't do them all at once because you don't have the people to do them. You know better than to ask people to multi-task on more than one project, no one will get anything done. One tactic is to organise the projects into a portfolio and rank them by priority.
When most people slot their projects into a portfolio, they easily have 12-18 months worth of work. At some point, way before the 12 months is over, something happens and you'll need to readjust the portfolio.
You plan for the adjustment in a portfolio review, but how often should you review the portfolio? Too often, and you aggravate everyone involved, because nothing has changed. Not often enough and what's actually happening has no relationship to the portfolio. Is there a just-right amount of time? Yes, and it depends.
You might need to review the portfolio when release dates change, when your customers want something new, when your competitors announce or release new products, or when new technology is possible. Because you can't control most of these events, you'll need to choose a flexible review cycle. But you do have ways to decide when is the right time to review the portfolio.
The ideal time to review the portfolio is:
These cycles are interdependent. Here's a true story about how one group recognised the interdependencies.
Leah, a product manager at A Large Company was talking with Alex, another product manager.
Alex, I need the development team to work on my product upgrade. When are they going to be done with your product?
Not for another three months.
Wait a minute. You've had them for six months already. My product needs another release sooner than that. I have requests from our customers, and the corporate roadmap says I need to release in just three months. If they can't work on my project, how can I get a release out in three months? What's the delay from?
Well, we had trouble getting the requirements done, so that was a delay. Then we had trouble with the functional specs. It turns out the requirements were still a bit vague, so we had to revisit everything during the spec stage. I insisted that they work on all the features at the same time, so the testers can't start because nothing is done enough for them to test.
Leah told me later she felt like bopping Alex on the head.
Alex made several classic mistakes:
If Leah and Alex had reviewed the portfolio more often, Alex would have avoided the first mistake, and would have had a chance to revisit the other mistakes earlier in the project.
If your project takes longer than six months to complete, the project team can't start work on another project until the first project is done. You'll need to help the project team choose a lifecycle that fits your business requirements of when the project needs to finish.
If you use a serial lifecycle, such as a waterfall or phase-gate, the project cycle is the entire duration of the project. If you contain the requirements, and the team is familiar with the product, and they don't run into technical difficulties, and the schedule is short enough, you can make this lifecycle work for you.
But too often, I see time-bound projects with high technical risk try to fit everything into a serial lifecycle for a project that's more than three months long. That's not a recipe for success. Instead, consider another lifecycle.
If you use an iterative lifecycle and integrate the product as you proceed, leaving only final testing for the end, your project cycle can be as short as the time it takes to implement one feature, integrate it and test it. If you use an incremental lifecycle, such as staged delivery, your project cycle can be as short as the time it takes to finish one feature. If you're using an agile lifecycle, your project cycle is the duration of one timebox, not more than four weeks long.
So the more immature your product is, the more you want to consider an agile or incremental lifecycle, because you have the most flexibility in replanning the project portfolio. You might not care what kind of a lifecycle you use for a relatively mature product, assuming you don't want to release it more often than once a year or so, and you don't need that project team for other work.
It makes sense to make your planning cycle, the readjustment of the product roadmap (which features you want in which quarter) be every quarter, especially for less mature products or for a market in flux. If you're using an agile lifecycle, you can readjust the roadmap every timebox, fine-tuning which features the project team will finish when, and when you can release the product.
With an incremental lifecycle, you have almost the same flexibility as with an agile lifecycle, but you'll have the project startup time, plus the varying time to complete a feature. For an iterative lifecycle, you'll have to allow for the time to add in all the prototypes for a given feature and test it. For a serial lifecycle, you'll have to restrict the number of requirements you can address in one project.
In my work, I meet many companies who budget once a year. Everyone is supposed to pull out their magic wands and crystal balls and see the future perfectly.
Well, I don't understand how to predict the future when I can't tell what the competitors are going to do, and neither do my clients. The result is that managers and project managers spend crazy amounts of time forecasting the budget, and by the third month into the fiscal year, the budgets are all wrong.
Since the budget is off in three months, it makes sense to use a budget cycle of three months, and only budget for three months at a time. If you're using an agile lifecycle with a shorter timebox than three months, you can have a budget cycle as short as the timebox.
A side benefit of re-budgeting more often is that you don't have to budget everything, you just have to budget for the foreseeable future. You'll spend less time budgeting and more time seeing just what you need.
An additional benefit is that for a non-agile lifecycle, the project team has to re-estimate how much longer they will need to finish the project. Too often, project teams have no idea how much time they need. If their estimates are off, they will gain feedback on their estimates and become better estimators.
The problem with setting a quarterly planning and budgeting cycle is that you need your projects to deliver some finished set of features by the time you get to the review. Many organisations spend more than three months getting started on a project, which is quite common in waterfall or iterative lifecycles. Only agile lifecycles, with their short timeboxes and emphasis on finishing pieces inside the timebox can work with quarterly planning and budget cycles reliably. If you're careful with an incremental lifecycle, you can make a quarterly planning and budget cycle work.
After Leah and Alex learned about the different lifecycles, they replanned how they approached product management. First, they created quarterly product road maps, with a list of features for their products by quarter. They drafted requirements statements for each item in the list, updating the requirement as they learned more about the requirement.
They worked with senior management to define when senior management wanted to release the products, and developed a "desired" project portfolio. They also created an "as-is" portfolio, to show the current reality.
And, they worked with the project managers to make sure the project managers understood when they were time constrained and when they were not. Here's a conversation from their monthly review meeting with the project managers:
I emailed all of you our current portfolio and product road maps from Alex's and my products. Let's look at the second quarter. Senior management wants us both to release products in that quarter, but that's not going to happen given our current portfolio. Senior management also said Alex's product is a higher priority than mine. Leah made a face.
How do we resolve this?
If you two move to shorter timeboxes, certainly no longer than four weeks, and maybe two weeks, you can work on my product for the first part of the quarter, release it, and then go on to Leah's product. If we run into trouble, we'll know early because we'll know what we finished and what we didn't. We can update the portfolio and see what else we can do. How will that work for you?
At the end of the conversation, the project managers had committed to three-week timeboxes and a re-evaluation of both the roadmap and the portfolio at the end of each timebox.
You've probably noticed two issues about the project portfolio. The first is that the portfolio provides a way to see the organisation's strategy. Making a portfolio and deciding which projects need to be completed when makes the strategy visible to everyone. The second issue is that each project's choice of lifecycle has a huge impact on how often you can review the portfolio. I lean towards agile, or at the least, incremental lifecycles because they allow the organisation the most flexibility. But those two issues are fodder for other columns.
Thinking about all these cycles bring us back to the original question: How often should you review the portfolio?
Review as often as you can and no more often. Consider working with the other project managers, the product managers, and the senior managers to organise your projects so you could release something at least once a quarter. You don't have to actually release, but if your project is in a releasable state, you have the option of moving a project team to another project, satisfying the needs of the project portfolio. Then you'll be able to review the portfolio and know you can make new choices about the work the organisation is doing.
I thank Dwayne Phillips and Gerald M. Weinberg for their review.
Johanna is the author of Manage It! Your Guide to Modern Pragmatic Project Management. She is the coauthor (with Esther Derby) of Behind Closed Doors, Secrets of Great Management, and the author of Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People.
Copyright © 2008 Johanna Rothman. Used with permission. All rights reserved.