OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Agile projects are those whose goal and or solution are not clearly defined. These projects dominate the project landscape.

Usually some agile or extreme model is used to manage them. They are high risk, high change and their outcomes are not at all certain. Managing portfolios of these projects is very complex and will challenge even the most experienced among us. In priority order the major challenges are:

1. Organizational support
2. Project governance
3. Measuring performance
4. Meaningfully involving clients
5. Structuring the project team
6. Estimating business value
7. Eliciting requirements
8. Scheduling constrained resources
9. Improving process design
10. Improving product design

This article describes each challenge and offers strategies for dealing with each one.

ORGANIZATIONAL SUPPORT

Organizational support extends from the very highest management levels in the organization all the way down to the project sponsor and the management team to whom the project manager reports. A Project Support Office (PSO) should be in place to offer not only the vetted processes and practices that are needed in an agile environment but also the training and consulting support that a complex project manager and team might require in the discharge of their responsibilities.

PROJECT GOVERNANCE

Complex projects are high risk projects. To mitigate some of that risk decisions should be made as close as possible to the expertise for making those decisions. That responsibility should be assigned to the team. But not just any team. The only decisions that should be made above the team level would be those decisions to adjust priorities, postpone the project or terminate the project.

MEASURING PERFORMANCE

The one common thread that links all projects is the business value that each expects to bring to the client and the organization. Business value would have been the deliverable that was used to approve the complex project and its plan. That might seem like the problem has been solved. Don’t be too quick to judge however. There is much yet to be done. Project performance is the variable that we will use to compare each project, program and portfolio in the enterprise portfolio. That comparison will be used to decide project status for the coming iteration. So we have to include not only past performance but also the prospect for future performance.

MEANINGFULLY INVOLVING CLIENTS

In the traditional project world clients were involved at the requirements elicitation phase and after that only for status reporting and deliverables approval. In the complex project world that is no longer effective. In its place the client must be meaningfully involved even to the extent that they will have management and decision making authority as members of the project team. They are the product experts and will have responsibility for managing the deliverables. The process expert on the team is the traditional project manager. They and the product manager have co-equal management responsibilities for the project.

STRUCTURING THE PROJECT TEAM

To be most effective a complex project team should count among its members those who possess all of the skills and competencies needed to succeed. That includes the decision making needs of the project. The project team template is shown in Figure 1.

Figure 1 ECPM Project Team Template

For a detailed discussion on the Co-Manager Model see Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model, (PM Times Oct 24, 2015 and PM Times October 28, 2015).

ESTIMATING BUSINESS VALUE

Every project is approved based on the business value it is expected to deliver. In the complex project world the solution is usually not completely known at the outset and must be discovered through iteration. That makes the expected business value that will be delivered very difficult to estimate. As iterations proceed the estimated business value may be different than the expected business value of an acceptable solution. The estimated business value that a project will deliver is often the primary factor underlying approval of the project business case. In a complex project that is seldom more than a best guess. As the project work commences and the solution begins to take shape that estimate is revised. It can change and so can the priority of the project.

ELICITING REQUIREMENTS

In the complex project world it may not be possible to elicit complete and clearly defined requirements. This step is designed into the ECPM Framework. The design is a two-step process that totally eliminates the current problem of incomplete requirements. The first step is a high-level identification of the set of necessary and sufficient requirements for achieving the expected business value delivered by an acceptable solution. How these requirements will be met is left to the second step. The second step is relegated to the iterations and stages of the framework. For details see A Fresh Look at Requirements and Requirements Elicitation in Complex Projects (PM Times, July 28, 2014)

SCHEDULING RESOURCES

If all active complex projects are identified within a portfolio the problems associated with resource scheduling are somewhat reduced. Unfortunately that situation rarely exists. Instead a number of projects that are defined and staffed within a single business unit are not part of any portfolio. While that may be true of a project it isn’t necessarily true of the resources that staff these “below the radar” projects.

IMPROVING PROCESS DESIGN

Complex projects don’t seem to follow any predictable process. Each project presents the team with a unique set of circumstances and challenges them to respond accordingly. That is why the ECPM Framework includes a continuous process and product improvement program. Figure 2 is the continuous process improvement program that has been integrated into the ECPM Framework.

Figure 2: The ECPM Framework continuous process improvement process

In time the organization will build a comprehensive collection of responses.

IMPROVING PRODUCT DESIGN

Figure 1 has also been integrated into the ECPM Framework but adapted to product improvement rather than process improvement. The Probative and Integrative Swim Lane process is the heart of that product improvement effort. It is unique to the ECPM Framework and will not be found in any other project management process.

IN SUMMARY

The ECPM Framework was designed with these challenges in mind. Most of the challenges are mitigated through ECPM Framework design features (Project governance, Measuring performance, Meaningfully involving clients, Structuring the project team, Eliciting requirements,

Scheduling constrained resources, Improving process design, Improving product design). Others are mitigated through the execution of the complex project.

How all of this happens requires a book length discussion and is out of scope for this article.