Tag Archives: risk

Missing the opportunity

Missing the opportunity: The under discovered benefits of Product Portfolio Management.

Product Portfolio Management is a discipline which can deliver great value for a business and ensure the firm gets the best return from its resources and opportunities. However, despite this clear benefit, many businesses either do not even have Product Portfolio Management as a recognisable process or have adopted an ad-hoc methodology.

At the root of this status quo are two factors:

  • Businesses can ‘survive’ without Product Portfolio Management.
  • Product Portfolio Management is very difficult to do well.

This paper explores these two factors.

Why it’s often not even implemented

It’s often overlooked

Product Portfolio Management is a task which is so deeply integrated into the overall operations of a business that it often is overlooked as a separate competence which needs to be developed and improved in order to make the overall business perform better. In many cases the decisions and choices which should be curated by a Product Portfolio Management function are instead driven by a dominant function (such as Development or Marketing) or alternatively handled without any joined-up ownership on a decision by decision basis.

Its benefits are seen more in the long and medium terms

The choices and decisions driven by portfolio management tend to derive value over some substantial period of time driven by the product development time to market. Therefore in a busy firm, there are always more pressing priorities – be it a product launch or sales firefighting – than to implement a well-structured process for managing the Product Portfolio.

It requires effort to implement well in an organisation

Product Portfolio Management is by its nature a cross functional undertaking requiring full buy-in from participating stakeholder functions. Therefore it is not in itself a new function but a very important process existing in the organisation. While the people tasked with running the process may be hosted by one function or another, it cannot be implemented by a single traditional business function alone.

A growing business does not realise the potential

A business starting out is usually small enough not experience any of the complexity which Product Portfolio Management sets out to clarify. However as business grows, products get added and the business opportunities become more sophisticated, there is a growing increase in complexity and potentially a loss of clear line of sight of on-going product operations. Rather like the metaphorical ‘boiling frog’, the business does not realise that adding structure and process would improve its business results.

‘We’re using Agile we don’t make long term plans’

The popularity of using Agile techniques for software development often creates questions whether any long term plans (such as a portfolio plan) can be made at all. However while Agile does address the issues of making sure a product is ‘about right’ before over-committing resources and not making unrealistic development predictions, there remains a need to allocate resources to different projects and set the overall aims of a product development if not the feature detail.

Why it’s hard to do well

It’s like trying to hit a moving target

Product Portfolio Management is not about meeting the present day requirements of customers and competing against today’s competition rather is it about anticipating future customer requirements and battling against tomorrow’s competition. The longer the new product development cycle the longer the delay between specifying a product and it reaching the market place.

Since predicting the future is not normally a gift bestowed on most human beings, a great deal of effort is required to understand the possible future scenarios and make choices according to that understanding. The aim of Product Portfolio Management is to improve the probability of hitting the target when it is time to market the product.

Developments do not always go as expected

Not only does Product Portfolio Management need to cope with changes in the outside world, there are those changes arising from problems and delays in product development. The result may be that a product is missing attributes associated with its expected success or come to market so late its specification is no longer relevant.

Significant plan changes often precipitate the need to make tough decisions such as a project cancellation or significant re-direction. These are decisions which typically face significant resistance within the organisation and are often unpopular.

It’s often difficult to get functions to commit and co-operate

As a fundamentally cross functional process, success and failure is often tied up with the attitude present in the key contributing functions. It’s a reasonably normal situation than rivalries exist between functions or that hidden agendas exist which may not be aligned with the good of the business as a whole.

A key to success is therefore the ability to inspire stakeholder functions to commit to the common good of the business in an integrated plan.

Getting the balance right in the portfolio

While many aspects of a portfolio are clearly measurable, balance is one aspect which is perhaps more art than science. The term balance can be applied to several aspects of a portfolio design including: the balance between new product development and existing product engineering, the time balance of the portfolio in terms of when products are expected to come to market or the balance across different segments or price points.

At the end of the day, balance is really an informed management judgement which needs to be facilitated by the right information and informed views of the market; it is never a ‘black and white’ decision.

Conclusion

While there are multiple reasons a business does not adopt well defined Product Portfolio Management techniques, in many cases those businesses are missing out on creating a much clearer and strategy linked way to run their businesses. There is no doubt that Product Portfolio Management is a difficult discipline to master but the potential results far out-weigh the effort to implement it.

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.