Part way through my career, I was asked to work on a change activity. One of its goals was to bring together the business priorities for a suite of about 100 software development initiatives which supported the end offering of products and platforms.

This was a historical exercise, but how might I approach matters now? With the benefit of hindsight, I would consider the approach:

• Establish a core team
• Map the projects to aid understanding
• Interpret the strategy to build a framework
• Make trial rankings and test result
• Prepare for the senior stakeholder review

 

1. Core team considerations

Fair representation of the business. Functional area owners want to be consulted on matters that impact on their responsibility areas. If you require strong endorsement of the results, you will need representatives of these different functional owners to take part. Enough representation to build a “wide enough” business view, but not so much as to bring the impression of a fully democratic exercise. The functional representation is there to bring insight into relevant areas of the business, not necessarily to pass judgement on the whole spectrum of activities.

Calibre of resources. The qualities of the resources could be summarized as: motivated, capable, respected, possessing a broad knowledge and impartiality. Do the best that you can in ‘borrowing’ resources.

2. Map and understand the projects

The objective here is to make more sense of the project portfolio prior to ranking. The value is in the discussion for the core team, building an understanding how the initiatives create value for the business, their timing, mutual relationships and how they impact across the business.

The precise approach taken will vary somewhat depending on the nature of the precise question being asked and the stakeholders involved e.g. involving the whole business vs. only the product related functions. Some thoughts on potential candidates to include in mapping:

Project Value

Project Investment

Market risk

Technology Risk

Current project timelines

Future projects pipeline

Independent projects

Projects with dependencies

Mutually exclusive project options

Project duration

Resources involved

# Independent teams  involved

# New assets created (or types of assets created)

Product type architecture e.g.

Market type architecture e.g.

Core plat-form

Messag-ing /CRM

Scale data support

Customised  visualisations

Professional Services tools

Core product platform

Customisation enablers

EMEA projects

APAC projects

NAM Projects

A couple of project maps to show how visualisation can help understanding:

Value vs. Technology risk and Market risk map.

This is a good method to test the rationality and balance of the project approach against the market opportunity. It captures the business value of projects by the radius of the bubbles, so the most valuable projects stand out.

But it is sometimes hard to give every project a business value. An alternate view is to use project investment to scale the bubble radius.

Projects resource/investment vs. timeline map.

This is a good method for seeing the relative and cumulative project resource in use on deliveries now as well as the anticipated future commitments. It is a useful view for testing portfolio “options”, although with future project estimation a challenge, project categories or templates maybe necessary.

3. Interpret strategy to build a prioritisation framework

The business strategy should provide clear guidelines as to what is important to the business, both now and for a few years into the future. Thus for prioritisation of projects/initiatives, strategic alignment is a key criterion. However, strategy alignment can be captured through a variety of measures, so general guidelines for the prioritisation framework include:

Clear meaning for individual criteria	Readily understood by all of the core team
Independent criteria	Cover clearly separate issues
Criteria have different priorities	Some criteria clearly more important in prioritisation
Individual criterion has “values”	Enables ranking on 1 criterion (even if  high/mid/low)
Enough elements as necessary	But as few as possible to avoid fatigue with large portfolio

It is especially important that core team members representing the business function stakeholders are fully understanding and supportive of the framework selected.

4. Issues in trial ranking of projects

Fatigue. Large portfolios take time to discuss and must be split over several sessions. Ideally this happens over consecutive days to maintain a consistent “mind set” for the work. Energy is needed to combat fatigue, so the project content should be ordered so that the most relevant (however judged) projects are dealt with first, creating high value and building confidence in the approach.

Maintaining Cadence. Within sessions, it can be useful to “time box” individual project discussions and place those projects that lack conclusion into an open category. If many projects keep getting put in the open category then this can be a sign of:

• Low quality project descriptions
• Too complex prioritisation framework
• Too many people participating

The project lead can directly address the last two issues e.g. by opening up the framework or using a smaller size team to build the draft proposal & review with the wider core team.

Handling “open” category projects. The lead should judge if it is worth investing more time to clarify “open” projects/ priorities or to prepare to return such projects without overall priority but within some identifying category e.g.

• Projects lacking in description/benefits
• Projects lacking agreement on business priority

Rationality and balance of the result. The trial project rank result should appear to make sense logically. If there are some anomalies, then it is worth rechecking for consistency of prioritisation criteria. The other test which is less obvious is to look for balance using the earlier project mapping. If only the top 25% of projects are considered, what would the portfolio then look like when mapped? This approach picks up cases when there is not enough in effort anticipating future problems e.g. paying back technical debt.

5. Preparing for the senior stakeholder review

The ultimate approach taken for the review depends on the nature of the original question asked and therefore if any explicit decisions are required. The normal recommendations apply e.g. gaining feedback when possible from impacted functions, ensuring issues have solutions for mitigation and that the consequences for decisions are outlined.

It is important to be able to briefly show the “workings” how the team came to its proposal e.g.

• This is the issue e.g. project portfolio load unsustainable
• Here are the people / functions engaged in this activity to address the issue
• Here is the prioritisation methodology used
• And here are the conclusions & key decisions…

The visualisations built used for initially understanding the project portfolio are very valuable as a way of communicating the consequences of different options.