Sunday, May 07, 2017

Agile Project Portfolio Management? Categorization

This is the third 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. The second article discussed demand management. This article is about categorization.

The Project Management Institute (PMI) defines categorization as: "The process of grouping potential components into categories to facilitate further decision-making", and it defines a category as: "A predetermined key description used to group potential and authorized components to facilitate further decision-making. Categories usually link their components with a common set of strategic goals."

I disagree with the categorization process descriptions of PMI, but the actual definition of categorization holds up. Since we defined that all our existing projects and new proposals are captured in a Project Backlog (see demand management) I will be talking about Project Backlog items, and not about components. An item is or an existing project or a project proposal. A program will never be an item on the Project Backlog. You could group a set of projects or proposals in a program by categorizing them like this, but a program by itself is not an item.

There are a number of steps that we have to do in order to categorize our Project Backlog. The first is linking Project Backlog items with strategy goals. Many organizations have a well-defined and well-scoped strategic process. This can be augmented by better and broader idea capture to provide supportive tactics, but the execution of it is the critical challenge. Indeed, as is widely recognized, weakness in execution, not a weakness in strategy, is a primary reason for business failure. Knowing this, it is important to tie the strategic theory governing the business to the experience of project management. Without this linkage, either the project portfolio is blind to the needs of the business or the strategic goals are empty, with no support at the execution level. It is clear that this is an area that businesses must get right for long-term success.

The second step is mapping the projects and proposals on other categories that we would like to use for our decision-making process. In order to do so, we have to define attributes for our project backlog items and define categories within these attributes.

Linking project backlog items with strategy

Defining strategy needs to come before portfolio categorization. In order to select the right set of project proposals to execute, the strategic goals must be defined in advance. Furthermore, the strategic goals should ideally be relatively limited: three to seven goals are best so that project proposals can be consistently benchmarked across all of the strategic goals, and the effort of doing this is not overwhelming. It helps to think of it as a matrix, with 100 proposals and 7 strategic goals, creating 700 mappings between projects and goals that must take place. With 20 goals, the number of mappings required would be 2000. This is not the only reason to keep the number of strategic goals low, but it is a relevant factor.

Having a small number of goals also helps to keep the goals memorable and at the necessary high level, thus avoiding strategic goals blurring with the tactics from their implementation. Of course, the process of linking project proposals to strategic goals is critical. If the projects you execute don’t reflect your strategy, then what does? It is much less likely that operational work has a strategic impact relative to projects, which are more likely to create some level of change within the organization.

This process also entails that the strategic goals are reasonably broad—the sort of goals that are likely to remain valid for the next three years or longer, rather than the next three months. The duration of your strategic goals should be at least as long as the time required to implement projects and realize the benefits from the projects that support them. If strategic goals are narrowly defined and numerous, then they are unlikely to be applicable to a broad portfolio of projects and proposals.

It is also important that the strategy is at the same altitude as the backlog of projects being reviewed. If the Project Backlog items are from across the business, then the strategy, too, should apply to the entire business; but if the Project Backlog items are just a subset of all proposals and projects, such as only IT projects, then prioritizing them against IT’s strategic goals makes the most sense. The correct way to perform the prioritization is to have the Project Backlog and strategic goals defined at the same level.

A simple example. Let's take a company that has defined the following business strategy. I know it is a very boring one, but it will work for our purpose.

1. Expand globally. Existing markets are North America and Europe. Target market is Asia.
2. Be profitable.
3. Maintain our financial position.
4. Leverage success without leveraging assets.

You could translate this into the following strategy goals:

1. Market penetration
2. Return on Investment (ROI)
3. Low up-front investment
4. Use existing technology

Once strategic goals have been defined, which is itself a nontrivial process, linking them to project proposals and your existing projects is relatively straightforward. Each project can be examined to see the extent to which it supports each of the strategic goals. This will be a key step in the prioritization process. The goal is not to choose the 10 project proposals with the highest return on investment, but to ensure that the projects map to the strategic goals of the business. The actual linking can be done by the Portfolio Owner.

The linking process is the first step in aligning the Project Backlog items with the strategic goals of the business and, ultimately, determining the extent to which each project will advance the strategy.

Defining project proposal attributes

Besides the strategy goals discussed above, there are other attributes that can help you in your portfolio decision-making process. Especially when we create meaningful categories within these attributes. What we have to keep in mind here is that we have to make the proposal submission process as simple as possible. This means we should limit the number of attributes that the submitter has to fill in to the minimum that is necessary. But if the submitter wants to add meaningful additional information to the proposal we should make that possible.

So, in my opinion, a good proposal submission form has a number of mandatory and a number of optional attributes. The further we will come into the portfolio selection process the more information will be needed. Since we can request this when we need it, there is no need to burden the submission process with too many mandatory attributes.

Let's start with the mandatory attributes of a project proposal. In my opinion, three mandatory attributes are enough:

1. Name: A short name for the proposal.
2. What?: This is the description of the idea/proposal and is free text. You should offer the possibility to add an attachment to this field.
3. Why?: This is the reason why the submitter thinks it is a good idea/proposal.

When we use a simple online form application to capture this information we get the information about the proposal submitter and the date it was submitted for free.

So what could be some other meaningful attributes? Of course, what is meaningful or not depends on your organization and your portfolio altitude, so you should think about it thoroughly. A few examples:

Technological uncertainty: does the technology already exists in the organization? is it new technology? do we have the expertise in the organization?

Regulatory/Compliance: Is it forced upon us because of regulatory/compliance reasons?

Time criticality: should it be executed in a certain timeframe in order to give benefits?

Client impact: would there be a lot of change for our clients? Discontinuing a service could have a very high impact for some clients.

Employee impact: would there be a lot of change for our employees? For example, a new ERP system would have a very high impact.

Market Penetration: would this help us enter a new market, or sell more in an existing market?

Estimates: Estimations of costs, project team size, savings, additional revenue. In my opinion, all estimates at the proposal level should be range based estimates.

Range based estimates

We should assure in the project proposal process 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. An example for costs estimations:

< 500K
500K - 1M
1M - 5M

Defining meaningful attribute categories

After we have defined the attributes we would like to use for our proposals the next step would be to create meaningful categories for them. Meaningful in this context means that they can be used to group proposals and authorized backlog items in order to facilitate further decision-making. Let's have a look at the example attributes we discussed.

Technological uncertainty: A categorization that I have used many times is the following: 1) Technology exists in the organization, 2) Technology is easily acquired, 3) Technology is hard to acquire, 4) Technology needs to be created, 5) No technology needed

Regulatory/Compliance: A simple yes or no would work fine here.

Time criticality: A simple but effective categorization could be: 1) None, 2) Delivered within 3 months, 3) Delivered within 6 months, 4) Delivered within a year.

Client impact: A very effective categorization can be 1) No client impact, 2) High Impact for few Client, 3) High Impact for many clients, 4) Low impact for many clients, 5) Low impact for few clients.

Employee impact: A simple 1) None, 2) Low, 3) Medium, 4) High could do the trick. Always give four options with this kind of scales, else always the middle one will be chosen.

Market Penetration: A simple but effective categorization could be: 1) No new markets, 2) Growth in existing market(s), 3) Intro into target market(s), 4) Intro in non-target market(s)  

The Portfolio Owner can do a lot of the categorization him/her self. Also automation based on simple IF/ELSE rules can support the categorization process. When the proposal is lacking information and will be selected for further evaluation you can always request for additional information from the submitter. Of course, also the proposal submitter can already have categorized the proposal himself. But this categorization should be validated by the Portfolio Owner.

The next article in this series will be about portfolio evaluation. In other words, which criteria can be used to evaluate the project proposals. But evaluation will not be limited to the proposals. Since we plan to review or portfolio on a regular base we also need to evaluate projects that are currently executed.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment
7. Agile Project Portfolio Management? Authorization
8. Agile Project Portfolio Management? Monitoring
9. Agile Project Portfolio Management? Conclusion
10. The Agile Project Portfolio Management Framework Guide
Posted on Sunday, May 07, 2017 by Henrico Dolfing