Tag Archives: programs

Prioritising development initiatives..part1

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 great learning exercise, so part 1 of the post covers “what did I learn?”

Answer the “so what”?

Don’t invest too much time without first gaining a clear understanding of the purpose and intended outcomes from the exercise. Stakeholder contribution to this type of exercise is highly important and although I found stakeholders generally supportive, their main concerns were “What is going to happen in 1 week, 1 month or 6 months’ time as a result of this work?”

Be pragmatic

Projects and program briefs come in all shapes and sizes. Even with best intentions, the result is likely to be imperfect due to misunderstandings and the level of information available. By being pragmatic and giving fast feedback, the value obtained will track the 80/20 rule. As an example, it is very important to get the top 10 project rankings correct, but another thing entirely to try and fine tune project priorities lying in the 50th to 60th rankings.

Note, I am not suggesting there should be no clarifying dialogue between parties along the way, just that the act of providing the feedback ‘fast’ is a good way to flush out any major misunderstandings.

Decisions require preparation

It is hard to get time from senior stakeholders and harder still to sync their diaries to meet at the same time. A direct discussion of priorities is a challenge without having first developed the proper context. So, the approach for establishing priorities is likely to be an important point for the senior stakeholders along with the consequences of any decision options.

Therefore it is worth establishing a small core team to build and test a prioritisation framework and drive the significant ground work prior to any proposal. More on this in a later post.

Present versus future

“If we don’t secure today’s business then there is no tomorrow”. People tend to attribute higher value to items appearing in the immediate future rather than those slightly further away. This is natural and also a consequence of the time value of money or NPV. However, it is a bad sign when all risk and change gets pushed forward (delayed) further into the future. A balance is necessary and the core team should take care of the present vs. future investment balance according to the industry change clock cycle.

Prioritising development initiatives..part2

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.

pmap3

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.

projmap3

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.