Monthly Archives: October 2014

Why Implement Product Portfolio Management?

 

The reality is that any business which has more than a single product implements some form of Product Portfolio management, but that implementation may not be formalised or even recognised as such. Product Portfolio Management is after all fundamentally about choosing which products to make, how to market/price them and when to stop selling them. So if a business can survive without formal Product Portfolio Management, why should anyone bother implementing it? To search for any answer to this question, it is first important to understand some of the factors which can make a product business successful such as:

  • It brings superior products to market.
  • It maximises business potential with a well-structured product range.
  • It can react to changes in the market faster than competition.
  • It can nurture and most importantly bring to market new innovations.

At the root of success of course are managers in the business who understand the market they are in, can anticipate its requirements and carry the organisation in the same direction with full force. In a business without a formalised portfolio management process, these key managers may struggle to get heard; struggle to create focus for the organisation and ultimately become very frustrated. Senior management may also become frustrated for slightly different reasons; their struggle is to get clear visibility of what the current state is in product development and then to have decisive levers to direct the business in the correct direction. Therefore in essence Product Portfolio Management is a framework which enables a business to get the best out of the management resources it has. So what are the key features of a Product Portfolio Management framework which can deliver these benefits?:

  • Provision of clear decision and review points which consider the totality of the product undertaking.
  • Direct linkage to company strategy which has been endorsed by the most senior management.
  • Bonding between the various stakeholder functions which means they all operate together in lock step.
  • Visibility into the current state in development and sales in a structured way.
  • By creating balance in the portfolio enabling innovation to bubble to the top as well as making incremental products.

These benefits seem pretty compelling but it remains that Product Portfolio Management is really a means to get the best out of the people who run the organisation. At the end of the day good decisions are needed and while the framework can potentially maximise the probability of making a good decision it does not substitute good market instincts or leadership qualities. So are there great costs implementing a Product Portfolio Management Framework? The fundamental answer is that the biggest part of the cost is the change needed to bring the organisation to a common way of working. A well designed Product Portfolio Management Framework will be customisable to a given organisational scenario to focus change only on those areas which need addressing. Once implemented the clarity and clear target setting it delivers will mean that the overall organisation can operate at a greater level of effectiveness. If the benefits are so clear then why doesn’t every business implement Product Portfolio Management in a formalised way? Well this is another story and the subject of my next blog post.

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..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.