Managing an Agile Project Portfolio

30 July 2007

Jochen Krebs
Incrementor

Numerous articles and books have been written about proper project management techniques and how to steer a project from start to finish. Many of them offer help in maneuvering a floundering project back on track. What is mind-boggling, however, is that despite receiving so much help and advice, so many IT projects are considered failures, even those that were delivered on time and on budget. Furthermore, if you add the project evaluation criteria “Did the stakeholders get what they initially asked for?” or “Were the stakeholders’ voices always heard?” to measure the success of IT projects, it’s likely that the list of success stories would shrink even further.

One reason for all this dissatisfaction is that many customers initially don’t even know what they want, or more importantly, they don’t know what they could get for their money. Once a project starts, however, customer expectations often rise while scope creep and churn take the energy out of the project team. On an individual project level, agile software engineering addresses these concerns and seeks to develop project iteratively as a way to better serve the customer’s true needs. But what about the projects themselves? Could applying agile concepts to how we balance the mix of a company’s IT projects ensure that we choose to work on the projects that will be successful and meet customer needs? Absolutely.

Challenges of Traditional Portfolio Management

Consider a project that is miserably late and over budget. After a certain point, management usually decides to cut their losses and perhaps start all over again with a different approach. Management still believes in the idea, but needs to make sweeping changes.

Unfortunately, halting a project when it gets to this point causes frustration, a sense of personal failure, and guilt. The further the original project has progressed, the worse it is. Since the majority of canceled projects are troubled projects, terminating a project is perceived as a negative reaction, a last resort that is necessary to prevent further damage. Why wait until a project has reached this point to cancel it?

Figure 1 depicts a typical troubled project. When a project begins, there’s a honeymoon period where it flies under management’s radar. Status reports usually consist of “on track” and everything appears to be fine. At some point, a troubled project begins to show signs of pressure and will begin to “report” problems (Circle 1). Management may begin to actively “monitor” the project at this point, but even so the problem typically grows over time (Circle 2). The problem slowly grows until it reaches a point where management is concerned enough to set parameters for the project, usually strict limits: “Until here, but no further!” (Circle 3). Executives, who have hardly any time to review and compare the project metrics (as is/to be), begin to supervise the project. In the time it takes reliable information to be gathered and the management board to have the chance to review the situation, the problem is much bigger and has often exceeded the limit set by management (Circle 4).

Figure 1

Not only has the project not been canceled before it exceeded its limits, the organization has now lost extensive time and resources that could have been used towards their strategic corporate goals. Even when it is canceled, you cannot get back the resources spent on the wrong idea that could have been spent on the right idea! There has to be a better way!

A Better Way

Most product development companies strive for a well-filled funnel of product ideas, project proposals, features, or change requests. Typically, the funnel’s contents exceed the resources available in the organization. Picture yourself in the shoes of the portfolio manager who is in charge of the funnel. Which projects would you initiate when resources become available? Most likely you would rank the projects and pick projects that reflect the desired balance of the portfolio, typically with a focus on high value of returns.

Some of the proposals in the pipeline are of such small business value that many portfolio managers fear the moment where there is nothing better in the portfolio of higher importance. They hope that newer, better, and more promising project ideas will always push those negligible projects back in the hierarchy. Then on the other hand, there are also high-ranked projects which are not necessarily important in terms of business value, but need to be materialized by law or regulations. Managing this funnel, or portfolio, of projects is not an easy task. Situations constantly change and as a result, the decision for project selection process must constantly adjust. Being dynamic and agile with the project selection process is therefore essential. Sounds a lot like a project backlog, doesn’t it? So, let’s treat it like one.

You heard right. I’m proposing we treat projects just as agile software engineering treats stories. Just like stories, projects should live in the company’s IT backlog. And just like stories, these projects should be reviewed on a set schedule (an iteration, if you will). And just like stories, projects should be accelerated, shelved, halted, or even abandoned completely. Yes. We can abandon a project. It’s not an indication of failure. It’s iterative project management. And it can help you avoid death march projects, wasted resources, and the circle of doom.

Agile portfolio management opens doors to possibilities you couldn’t consider under a traditional portfolio management system. It gives you more options in managing projects, fewer and more transparent metrics, more frequent and productive management meetings, and more opportunities for innovation.

More Options

Treating your project portfolio like a backlog of stories means you are able to say, “no” to projects earlier, releasing resources to other projects. That’s good; but what’s better is that, instead of a black or white world, where projects are being canceled or not, you have more options. Consider these scenarios.

A portfolio manager realizes after two iterations that Project A will not return the promised marketing forecasts. The project’s priority drops and its resources are freed for other more lucrative projects. The project’s achievements, though, are stored; the project has simply been moved into the agile portfolio—returned to the backlog, so to speak.

The originally proposed features list for Project B is 80 percent complete. The project is far beyond delivery date and the competition has announced an impending release whose features are similar to the ones that have been completed to date. The portfolio manager decides to stop the project

Project C is a proposal that initially sounded very promising and relatively easy. After only one iteration, though, reality has proven the feasibility study wrong. Rather than waste any more time, executive management decides to cancel the project and remove it from the agile portfolio entirely.

Notice how in all of these scenarios, there was no stigma attached to modifying, delaying, or canceling a project. “No” has lost its sting. Because the investment in each project was minimal, the cost of returning it to the backlog or changing its parameters was also minimal. That’s powerful. That’s agile.

Fewer, More Transparent Metrics

Having an agile portfolio allows you to extract metrics that are more up-to-date and focused. Just like a newspaper, which is already outdated when published, project metrics often do not reflect the real health of a project. Extracting reliable metrics from a project is hard enough, but once the metrics are extracted it can be even more difficult to compare the results to other projects because of the lack of consistency.

An agile selection process should be founded on lightweight metrics that focus on one important area (e.g., measured in delivered use case points, features, risk list management, etc.). Streamlining and standardizing the metrics will allow portfolio managers a quick and transparent overview within review meetings.

Frequent Review Meetings

Executive management needs to be actively involved rather than being informed. They need to meet together once a month in a hands-on review meeting instead over passively exchanging metrics. With an agile portfolio, they can do that. Since projects are no longer assumed to be continued, these meetings provide a forum to measure each project’s progress and demonstrate it in working software (e.g., implemented use case scenarios, etc.). The review meeting itself could be a fixed date and gateway in an agile project selection process. For example, always at the last Wednesday of the month at 9:00 a.m. in room xyz. This would give management twelve opportunities a year to actively influence the balance of the portfolio.

Management will need to buy in to an agile selection process for this to work. Remind them that frequent project reviews are important for resource allocation, but also are motivational for the project. Nothing is more rewarding than when management agrees with the direction of a project and continues to fund it. Do not wait for a no—request a yes!

Innovation and Productivity

Agility in the project selection process not only addresses issues in the current process, it also opens new doors, especially towards innovation and productivity. With an agile selection process, the portfolio manager can explore new project proposals with relatively little risk. The shorter decision intervals inherent in the agile process allow the decision maker to test an idea for a shorter period of time before larger investments are made. He can then review each project’s progress and its effect on the value of the portfolio. An agile selection process fits elegantly with a competitive business environment. For example, an organization might fund two proposals for the same idea for a short period of time to review how each of them materializes the strategy. Tabling the less promising project allows
management to go with the better idea!

Don’t forget that with agile portfolios, projects may be released even when the entire list of features has not been implemented. This is a tremendous opportunity for organizations who want to release in a stepwise approach.

Conclusion

Agile software projects allow portfolio managers to treat their selection process in an equally agile fashion. Iterative, incremental development allows for projects to be rolled out in manageable pieces. That concept motivates an earlier
return on investment by receiving earlier feedback and reactions from the customer base and learning if the features are accepted in the marketplace. This is exactly in line with the viewpoint of a portfolio manager. Adding an agile project selection process to the portfolio can help direct and steer the projects to a given vision.

Editor's Note: This article originally appeared in the spring issue of Agile Alliance's online PDF magazine Agile Development. The new summer issue was released in mid-July. Members of the Agile Alliance can download that issue and back issues at www.agilealliance.org.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.