Agile Project Portfolio Management? Demand management

This is the second article of a series around agile project portfolio management. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods like Scrum, Kanban, LeSS etc. This article will discuss the first step of the project portfolio management process: demand management.

PMI calls this project identification, but I think this is not covering everything that is needed in this step and propose demand management as a better term.

Demand consolidation

The very first step of demand management is consolidating all existing demand. Typically this is stored in many different applications and files, and you should put them in one single place. If this is a fancy project portfolio management application or a spreadsheet does not matter for now. You just must have to make sure you have captured everything in one place. And with everything, I mean operational projects, strategic projects, upgrades, office moves, office closings, even the secret pet project of the CEO with that funny code name. As soon as you have done this, that list becomes the single truth. In other words, any project that is not on that list does not exist, and will not get any resources (people or money).

Demand collection

After you have consolidated all demands you have to set up a process for collecting new demands. Else you will find yourself very soon in the same situation as before you consolidated all existing demands. New project ideas and demands are often collected in the form of project proposals. The demand collection is known as the proposal submission process. Within organizations, this is frequently done ad hoc and lack formality. Besides not capturing all demands in a single place, the lack of a well-thought-out process will reduce the number of proposals, or inputs, into the portfolio selection process.

As with most processes, reducing the number of inputs can reduce the quality of the outputs. Having a limited list of ideas hinders any project portfolio. In the extreme, if the number of ideas you have matches the number of projects you can complete, then the portfolio selection process is obsolete. Without a list of ideas larger than you can do, you cannot make trade-offs between ideas. You would just implement all ideas, and the quality of the portfolio will suffer.

Although there is clearly no shortage of ideas within an organization, unfortunately, these ideas are seldom captured in most organizations, except in the few cases where a handful of employees are sufficiently entrepreneurial to drive their own ideas through to implementation. This can happen in spite of the organization, rather than because of it.

Organizations are effective at focusing employees on their daily tasks, roles, and responsibilities. Organizations are far less effective at capturing the other output of that process: the ideas and observations that result from it. It is important to remember that these ideas can be more valuable than an employee’s routine work. Putting in an effective process for capturing ideas provides an opportunity for organizations to leverage a resource they already have, already pay for, but fail to capture the full benefit of—namely, employee creativity.

To assume that the best ideas will somehow rise to the top, without formal means to capture them in the first place, is too optimistic.

Providing a simplified, streamlined process for idea submission can increase project proposals and result in a better portfolio of projects. Simplification is not about reducing the quality of ideas, but about reducing the bureaucracy associated with producing them. Simplification is not easy, as it involves defining what is really needed before further due diligence is conducted on the project. It also means making the submission process easy to follow and locate and driving awareness of it.

Necessary proposal information

In terms of a simplified proposal, a relatively brief description with broad estimates of key parameters, such as budget and headcount, is all that is needed. In fact, sometimes all that is needed is the idea, and the budgetary angle can be left until later in the process. Then as the proposal moves through the process and gets closer to implementation, more detail can be added—perhaps by introducing a step to develop a detailed business case into the process, assuming the idea is selected at an initial stage.

In this way, no proposal is more detailed than it needs to be. In addition, less effort is wasted on filling out what might be superfluous information because the proposal may not make it that far during the selection process.

Another benefit of a simplified project proposal process is that contributors are not locked into specific but inaccurate estimates at an early stage. Keeping estimates range-based makes it more likely that estimates can converge toward their true value as more data are obtained. If a point estimate must be provided early in the process, it is less likely to converge on the true value. This is partly due to the psychological effect of anchoring (i.e., when an estimate that is introduced into the process gains some credibility), regardless of the accuracy of the underlying assumptions, and the estimate is then less likely to move than if no estimate existed. Having no estimate whatsoever poses its own problems, so using a range-based estimation process is the best approach; the issue of anchoring doesn’t disappear but it is less acute with a range rather than a point estimate.

Create a Project Backlog

If you implemented the two steps discussed before, you now have an ever growing list with existing projects and new project proposals. Similar as the management of a Product Backlog you could manage this list as a Project Backlog. So what is the difference between the before mentioned list and a backlog?

The Project Backlog in agile PPM is a prioritized project list, containing short descriptions of all unfinished projects and ideas in the organization. When applying agile project portfolio management, it's not necessary to start with a lengthy, upfront effort to document all details. The Project Backlog is then allowed to grow and change as more is learned about the projects and its benefits.

Is this different from traditional PPM? For most companies it probably is, hence I would categorize this under an agile PPM technique.

The owner of the Project Backlog is the Portfolio Owner. For most organizations, this would be a new role. The responsibilities belonging to this role will be defined in the upcoming articles. The Project Backlog needs to be an ordered list based on priority. So now is the question how can we prioritize the Project Backlog in a meaningful way? That is not so easy and will be covered in the upcoming articles.

The next article in this series will be about project categorization. The first step in linking your projects with your strategy.

Saturday, May 06, 2017

Agile Project Portfolio Management? Demand management

Demand consolidation

Demand collection

Necessary proposal information

Create a Project Backlog

Other articles in this series