Creating portfolio transparency – how to create meaningful portfolio structures?

Posted on by Heli Hiisilä

Communicating about development portfolios is often tricky – there may be a lot of ongoing development projects and activities, and if there are no portfolio structures, such as programs grouping projects, it is difficult to present high-level portfolio updates. The last blog post was focusing on designing portfolios in Enterprise level – let’s now focus on a single portfolio design and meaningful portfolio structures.

Here are a few tips which have been helpful for me and my colleagues!

Portfolio level – Large single portfolio, or multiple portfolios?

By definition A portfolio is a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives (The standard for portfolio management – Project Management Institute, 2017). The definition is quite wide and each portfolio needs to define how to structure the development happening within the portfolio with a meaningful value adding way.

Sometimes portfolios may develop content across businesses, but also quite often there are own development portfolios for different businesses and functions. In addition to business-driven portfolios, often large development organizations, such as R&D and IT, also have their own portfolios. These portfolios may have own strategic targets, or work may be delivered to one of the business portfolios by the technology units. Also global functions, such as marketing or finance, often have their own development portfolios. First thing to consider is, do you manage a single portfolio, or would you have actually multiple portfolios with different objectives in the scope of discussions.

Sometimes there are clearly defined project portfolios, a group of individual projects, without any need for program structures – and this is completely fine, too. When dealing with larger portfolios, it makes sense to manage group development activities as sub-portfolios, programs, strategic initiatives, or via value streams. Let’s review different options:

Sub Portfolio – Grouping of development based on unit, department or theme

Let’s start with sub portfolios!

For large development portfolios, sub portfolio structures truly make sense – there is just too much different types of contents to be managed with flat hierarchy. On the other hand, for smaller portfolios, splitting content too much may create additional bureaucracy and silos within organization – so please be careful with the design!

Here are couple of tips for large portfolios with different types of development contents:

  • Sub portfolios for different units: Do you have have a big development portfolio developing content for different units? For example, if your portfolio is focusing on development within global functions, development content within marketing, finance and IT would deserve to have own sub portfolios to keep the content well grouped and managed.
  • Department level sub portfolios: For big business portfolios, does it make sense, to create a sub portfolios for development work different departments are focusing? Sub portfolios may help to create structure and show logically development projects focusing on development of each area. Sub portfolios may also serve well for allocation of funding and governance, if decision makers and key stakeholders vary a lot. Also, one very important aspect is the resourcing – each department needs to have a clear view of all development they need to resource.
  • Strategic theme based sub portfolios: Do you have big investment areas including multiple interlinked programs you need to present together? Sometimes sub portfolio may be also created based on the strategic development themes, to be able to easier follow up on

Development Programs – managing complex dependencies

Development programs are widely implemented across various industries as a common and well-known approach. The fundamental concept behind programs is to consolidate interconnected projects with shared objectives into a unified program, which can be managed as an entity. One particularly appealing aspect of development programs is the incremental delivery of benefits, as individual projects or activities within the program are completed over its duration.

Sometimes projects and other development activities within program have complex dependencies – and the completion of one activity may be a prerequisite for another. One of the benefits with program structure is the possibility to manage dependencies systematically – this is especially important, if development is happening across different organizational units.

Some programs may have more loosely interlinked projects based on a certain theme or topic – this could be for example projects linking to the same technology. Also the investment decision approach may vary – if each project within the program has an own business case, investment decisions can be made also incrementally over time – this helps to get things started, when in the early phase investment approval is only for the first scope items.

Strategic Initiatives – aiming at reaching strategic targets

Strategic development portfolios often encompass strategic initiatives, such as large transformation projects, strategic technology programs, must-win battles, or major product development initiatives. These initiatives are typically characterized by a strong focus on outcomes, aiming to develop new offerings, introduce new business models, or enhance organizational capabilities.

Sometimes strategic initiatives are governed as an entity, with a clear funding, steering and reporting practices, but often there is more loose practice, mainly focusing on strategy implementation progress – development is happening within each responsible organization. What ever the structure you may have, creating transparency on strategy implementation progress is usually a must have need!

Value streams

Today, value streams developing end-to-end chains delivering customer value have become popular, especially when enterprise agile practices are widely used in the organization.

Some portfolios are fully organized around value streams, and in a sense, value streams may be seen as mini-portfolios. There is typically a higher level decision-making on the portfolio level, but also teams working within value streams are empowered to make decisions about content prioritization. If you want to learn more about portfolio approach using value streams, Scaled Agile Framework Portfolio pages include great examples.

Smart portfolio views – other portfolio grouping attributes

In addition to official portfolio structures, such as Sub portfolios or Programs, there are often also other needs to create views of development portfolio content. Optimally, your portfolio management tool may help with this, to avoid maintaining roadmaps for different purposes.

These are the commonly needed views I have come across to:

  • Department or unit work view across development portfolios – what are the projects and other work ongoing with your own unit? Which projects are you leading, where are you contributing and your team member contribution is needed? This view is especially important for common functions, such as IT departments or marketing, where there is always high demand for your experts time, and need may be coming from many different portfolios.
  • Strategy view – which development initiatives across all portfolios are contributing to a strategic theme or must win battle? There is often strategy progress reporting also consolidating status from different units, and great approach is to link strategy reporting to development portfolio reporting to avoid double reporting.
  • Product line, Platform or Solution area roadmap view – also a typical need is search for all development initiatives linked to a certain Product line, Platform or Solution area. With this view it is possible to manage development dependencies for a certain area.

Backlogs and my own tasks…

The need for managing the work does not end to portfolio level. Development teams have needs to manage their own roadmaps, backlogs or Kanbans – and the same applies to all of us – we need to manage our own tasks systematically. We all hate, if we need to create additional documentation manually to report our progress – and here is an opportunity to use integrated portfolio and backlog management tools.

If you have possibility to use the same set of tools within company – managing work from different projects or areas may become easier for the individual, when all tasks can be found from the same tool. The same applies also for the portfolio level – especially for agile development, creating transparency on progress of roadmap items is crucial. Many portfolio management tools today enable integration or have great inbuilt functionalities for managing backlogs.

If you are interested to learn more, check these out:

The standard for portfolio management – Project Management Institute, 2017

Development portfolios in large companies – what is your viewpoint?

Designing Development Portfolios in Enterprise Level – What is your approach?

Scaled Agile Framework Portfolio pages

Golden Eggs Or Rotten Tomatoes – Managing Portfolio-level Risks

Posted on by Heli Hiisilä

One of the portfolio management objectives is to maximize the value of the portfolio – this requires balancing between the opportunities and threats. Also, portfolio management should foster a culture embracing change and risk, while also navigating complexity and enabling successful outcomes (based on Standard For Portfolio Management). That is a lot, especially for large complex portfolios!

Let’s have a look at the portfolio level risk management from the different perspectives!

Golden Eggs or Rotten Tomatoes in the development portfolio?

When working with large complex portfolios, large transformation programs may be impacting the future of the whole organization – business models, operating model, ways of working, operations or sales… Huge transformation or system renewal programs may have huge impacts into organization operations, but also even shake the financials of the whole organization.

When I was quite fresh from the university, I was once working for a large development program, which had been ongoing for several years. Close to the planned go-live, severe issues were identified from the core of the solution, and the whole program was killed without ever going live. Even though this was terrible, that project was a also a learning experience.

I think one of the most challenging things for teams working on such initiatives is to be brave enough and say out loud if there are severe concerns. One of the experienced management consultants working in this crisis program gave us an advice: “You know, management is like a herd of sheep – we do not want to scare them off – so let’s not flag the performance issues.” Now many years and projects later, I still disagree with that advice.

One of the duties of portfolio management is to create objectivity and an environment, where concerns can be shared. Especially for large transformation programs, there should be transparent and active risk management in place. Also looking periodically, e.g. monthly or quarterly into portfolio level risks is a great practice.

Unexpected surprises

Even though good risk management practices would be in place, unexpected surprises may happen.

In another transformation program, we were preparing for corporation finance ERP renewal at the year end. In December, we were informed, that the whole production environment with all our carefully prepared and tested configurations for ~100 companies had been incorrectly setup, and it had to be redone. Oh nooo! New try next year?

Management supported the team by encouraging us to fix the issue, and stayed calm! A lot of team effort during the weekends and some pizza was required, but the team made it. My learning was, that no matter how well we try to prepare, always something surprising happens. But luckily, often times there are also solutions to fix the issues. Good governance should also support managing this type of unexpected surprises and give to support for the needed decision making.

Market Risks – What Is The Risk Appetite?

The recent years have been challenging time for many companies – how to deal with the uncertainty and how to reduce the market risks in the development portfolio?

For the dynamic development portfolios facing also uncertainty within the

  • Portfolio reviews & adapting to market changes, see the previous post related to Quarterly portfolio reviews!
  • Using scenarios for planning – possibility to look into different alternatives for investments.
  • Balancing the development across different geographical areas/segments/technologies – not to put all eggs into one basket
  • How much to invest right now? How much to capitalize development?

Portfolio level risks vs. project, program and operative risks

When discussing about the risks in the portfolio context, there are different viewpoints to consider:

  • Risks derived from the portfolio components – e.g. risk of cost overrun in portfolio level due to large transformation program or risk of portfolio level delays due to complex dependencies between the initiatives
  • Risk of not balancing the development portfolio – too much focus on certain product line, selecting not winning technology, or developing only
  • Failure in portfolio execution result into operational risks – example of such case could be failure of core IT systems after the go-live preventing business processes
  • Risks of not reaching strategic goals – is the portfolio truly taking the strategy into action?

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Golden Eggs Or Rotten Tomatoes – Do You Manage Portfolio-level Risks?

Posted on by Heli Hiisilä

One of the portfolio management objectives is to maximize the value of the portfolio – this requires balancing between the opportunities and threats. Also, portfolio management should foster a culture embracing change and risk, while also navigating complexity and enabling successful outcomes (based on Standard For Portfolio Management). That is a lot, especially for large complex portfolios!

Let’s have a look at the portfolio level risk management from the different perspectives!

Golden Eggs or Rotten Tomatoes in the development portfolio?

When working with large complex portfolios, large transformation programs may be impacting the future of the whole organization – business models, operating model, ways of working, operations or sales… Huge transformation or system renewal programs may have huge impacts into organization operations, but also even shake the financials of the whole organization.

When I was quite fresh from the university, I was once working for a large development program, which had been ongoing for seven (7) years. Close to the planned go-live, severe issues were identified from the core of the solution, and the whole program was killed without ever going live. Even though this was terrible, that project was a also a learning experience.

I think one of the most challenging things for teams working on such initiatives is to be brave enough and say out loud if there are severe concerns. One of the experienced management consultants working in this crisis program gave us an advice: “You know, management is like a herd of sheep – we do not want to scare them off – so let’s not now flag about the performance issues.” Now many years and projects later, I still disagree with that advice.

One of the duties of portfolio management is to create objectivity and an environment, where concerns can be shared. Especially for large transformation programs, there should be transparent and active risk management in place. Also looking periodically, e.g. monthly or quarterly into portfolio level risks is a great practice.

Unexpected surprises

Even though good risk management practices would be in place, unexpected surprises may happen.

In another transformation program, we were preparing for corporation finance ERP renewal at the year end. In December, we got the information, that the whole production environment with all our carefully prepared and tested configurations for ~100 companies had been incorrectly setup, and it had to be redone. Oh nooo! New try next year?

Management supported the team by encouraging us to fix the issue, and stayed calm! A lot of team effort during the weekends and some pizza was required, but the team made it. My learning was, that no matter how well we try to prepare, always something surprising happens. But luckily, often times there are also solutions to fix the issues. Good governance should also support managing this type of unexpected surprises and give to support for the needed decision making.

Market Risks – What Is The Risk Appetite?

The recent years have been challenging time for many companies – how to deal with the uncertainty and how to reduce the market risks in the development portfolio?

For the dynamic development portfolios facing also uncertainty within the

  • Portfolio reviews & adapting to market changes, see the previous post related to Quarterly portfolio reviews!
  • Using scenarios for planning – possibility to look into different alternatives for investments.
  • Balancing the development across different geographical areas/segments/technologies – not to put all eggs into one basket
  • How much to invest right now? How much to capitalize development?

Portfolio level risks vs. project, program and operative risks

When discussing about the risks in the portfolio context, there are different viewpoints to consider:

  • Risks derived from the portfolio components – e.g. risk of cost overrun in portfolio level due to large transformation program or risk of portfolio level delays due to complex dependencies between the initiatives
  • Risk of not balancing the development portfolio – too much focus on certain product line, selecting not winning technology, or developing only
  • Failure in portfolio execution result into operational risks – example of such case could be failure of core IT systems after the go-live preventing business processes
  • Risks of not reaching strategic goals – is the portfolio truly taking the strategy into action?

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

3 Steps To Improve Your Portfolio Roadmaps

Posted on by Heli Hiisilä

Development roadmaps are a great tools to create transparency across organization. However, when reviewing roadmaps, sometimes one does not really understand what will actually be developed. What will be outcomes from the initiation state, explore phase or product development stream? Also, roadmaps are not always easily available and up-to-date – and there may be hundreds of different formats used across company. Here are 3 easy steps to improve your portfolio roadmaps:

1. Focus on development outcomes

In global roles within large corporations, I have seen hundreds of roadmaps for different development areas. I have seen many excellent roadmaps, but also some, which are not easy to understand. Instead of showing project stages or program phases or streams within your portfolio roadmap, show what concrete outcomes will be achieved during the project, program or other development initiatives. Best roadmaps are often defining development outcomes – what are the results of the development? In a sense, outputs of the development are easier to define and measure, but real benefits come from outcomes (see link in the references blog text Outcomes vs Outputs). As portfolio level is heavily focusing on benefit realization, portfolio roadmaps could also focus more on real development outcomes.

One of the frequently asked questions is what is the correct level of transparency in portfolio level, and what should be visible in the project plans or team backlogs? Each portfolio may have own definitions for this part, but a good rule of thoub is to include all bigger entities such as programs, projects or other larger initiatives and, value streams/ continuous development teams and portfolio epics if used in your company. Also, sometimes other larger development activities may be visible in the portfolio roadmaps, if they have business importance or complex dependencies. Each development team or project will maintain their own plans via backlogs, kanbans or other task management system, which can be linked to portfolio plans to create full transparency. Portfolio financials play also a key role – typically all items which have significant external budgets or internal work costs are visible in the portfolio level.

A bit similar idea is also with goal oriented roadmaps, with a healthy reminder – roadmap is not yet a commitment: Comic Agilé no. 78 – The Goal-Oriented Roadmap:

The Goal-Oriented Roadmap

For those, who are interested in Scaled agile framework, the difference between different planning horizons is also defined here.

2. Update and review roadmaps quarterly

Roadmap creation should not be once a year activity to get funding. It is actually a huge effort to do as one time activity – and the benefits of the hard work will be lost, if roadmaps are not updated regularly.

My recommendation is to update roadmaps at least quarterly – within quarter updates are usually still quite small, and easy to manage. Quarterly cycles are a good fit for many organizations due to financial processes, and also a great cadence for portfolio reviews and planning, see my previous blog post: Time for quarterly review? Reviewing a common roadmap is a great tool to create alignment across the stakeholders – if item is not visible in the roadmap, it is not included into the plans – and prioritization discussion may be needed.

Also a good practice is to update portfolio data and roadmaps during the monthly portfolio catch ups with different teams – this can be a standard item in agenda – do you have something new in your plans or has something changed in the timelines? It is a small effort to change few dates or add a new project as needed, and as an end result, your portfolio roadmaps will stay up-to-date!

3. Share roadmaps to create transparency

One of the key benefits of roadmaps is to create alignment and transparency across organization. Even though a single portfolio would have great practices for managing own development roadmaps, there is a need to share plans across different units, to manage dependencies and ensure alignment. If roadmaps are scattered around different power points, it is difficult to find roadmaps and keep them up-to-date. Portfolio management tools provide great help – and today have also nice visualization capabilities for road mapping. When data is maintained in the tool, it is possible to create smart portfolio views for different purposes and use cases. These smart views help to reduce creation and maintenance of road maps via power points or other presentations.

Optimally all development roadmaps within company are in the same tool, and can be found there to create transparency across different portfolios, units and functions. For the top management, it is great, if different units have same format and way to share development roadmaps. If every unit has an own format, level of detail and approach, it is really difficult create a consolidated view in the enterprise level portfolio management. Using common tools helps also in the capacity management and financial processes – for example long range planning and yearly planning may get easier, when data is updated in the same place, with the common cadence.

For smaller companies or single portfolios, there may be lighter approaches, such as common road mapping template to create a common way of working. Projects or agile teams have their own roadmaps, with more details, in addition to high level portfolio view. Some organizations have created a integration between portfolio and backlog management tools, to support with drill down into more detailed plans. Even a link to teams power point roadmap in the portfolio tool is a great practice – those who are interested, can go an check out the details!

Recommended reading

The Business of IT Blog: Outcomes vs Outputs: What’s the Difference?

Scaled Agile Framework – Portfolio Epics

Time for A Quarterly Portfolio Review?
https://www.scaledagileframework.com/roadmap/
Scaled Agile Framework – Roadmaps

3 Steps To Improve Your Portfolio Roadmaps

Posted on by Heli Hiisilä

Development roadmaps are a great tool to create transparency across organization. However, when reviewing roadmaps, sometimes one does not really understand what will actually be developed. What will be outcomes from the initiation state, explore phase or product development stream?

Also, roadmaps are not always easily available and up-to-date – and there may be hundreds of different formats used across company.

Here are 3 easy steps to improve your portfolio roadmaps:

1. Focus on development outcomes

In global roles within large corporations, I have seen hundreds of roadmaps for different development areas. I have seen many excellent roadmaps, but also some, which are not easy to understand. Instead of showing project stages or program phases or streams within your portfolio roadmap, show what concrete outcomes will be achieved during the project, program or other development initiatives. Best roadmaps are often defining development outcomes – what are the results of the development? In a sense, outputs of the development are easier to define and measure, but real benefits come from outcomes. As portfolio level is heavily focusing on benefit realization, portfolio roadmaps could also focus more on real development outcomes.

One of the frequently asked questions is what is the correct level of transparency in portfolio level, and what should be visible in the project plans or team backlogs? Each portfolio may have own definitions for this part, but a good rule of thoub is to include all bigger entities such as programs, projects or other larger initiatives and, value streams/ continuous development teams and portfolio epics if used in your company.

Also, sometimes other larger development activities may be visible in the portfolio roadmaps, if they have business importance or complex dependencies. Each development team or project will maintain their own plans via backlogs, Kanbans or other task management system, which can be linked to portfolio plans to create full transparency. Portfolio financials play also a key role – typically all items which have significant external budgets or internal work costs are visible in the portfolio level.

A bit similar idea is also with goal oriented roadmaps, with a healthy reminder – roadmap is not yet a commitment: Comic Agilé no. 78 – The Goal-Oriented Roadmap:

The Goal-Oriented Roadmap

2. Update and review roadmaps quarterly

Roadmap creation should not be once a year activity to get funding. It is actually a huge effort to do as one time activity – and the benefits of the hard work will be lost, if roadmaps are not updated regularly.

My recommendation is to update portfolio roadmaps at least quarterly – within quarter updates are usually still quite small, and easy to manage. Quarterly cycles are a good fit for many organizations due to financial processes, and also a great cadence for portfolio reviews and planning, see my previous blog post: Time for quarterly review? Reviewing a common roadmap is a great tool to create alignment across the stakeholders – if item is not visible in the roadmap, it is not included into the plans – and prioritization discussion may be needed.

Also a good practice is to update portfolio data and roadmaps during the monthly portfolio catch ups with different teams – this can be a standard item in agenda – do you have something new in your plans or has something changed in the timelines? It is a small effort to change few dates or add a new project as needed, and as an end result, your portfolio roadmaps will stay up-to-date!

3. Share roadmaps to create transparency

One of the key benefits of roadmaps is to create alignment and transparency across organization. Even though a single portfolio would have great practices for managing own development roadmaps, there is a need to share plans across different units, to manage dependencies and ensure alignment. If roadmaps are scattered around different power points, it is difficult to find roadmaps and keep them up-to-date.

Portfolio management tools provide great help – and today have also nice visualization capabilities for road mapping. When data is maintained in the tool, it is possible to create smart portfolio views for different purposes and use cases. These smart views help to reduce creation and maintenance of road maps via power points or other presentations. Optimally all development roadmaps within company are in the same tool, and can be found there to create transparency across different portfolios, units and functions.

For the top management, it is great, if different units have same format and way to share development roadmaps. If every unit has an own format, level of detail and approach, it is really difficult create a consolidated view in the enterprise level portfolio management. Using common tools helps also in the capacity management and financial processes – for example long range planning and yearly planning may get easier, when data is updated in the same place, with the common cadence.

For smaller companies or single portfolios, there may be lighter approaches, such as common road mapping template to create a common way of working. Projects or agile teams have their own roadmaps, with more details, in addition to high level portfolio view. Some organizations have created a integration between portfolio and backlog management tools, to support with drill down into more detailed plans. Even a link to teams power point roadmap in the portfolio tool is a great practice – those who are interested, can go an check out the details!

Do you want to learn more about Portfolio Management?

Fundamentals online course available via Udemy platform:

Check out Strategic Portfolio Management Fundamentals course!

Recommended reading

The Business of IT Blog: Outcomes vs Outputs: What’s the Difference?

https://strategicportfoliomanagement.wordpress.com/2022/11/05/__trashed/

Don’t forget deployment!

Posted on by Heli Hiisilä

People working with projects, programs, and agile teams have typically a development mindset – we love to develop new things. However, one of the key learnings for me has been the importance of the deployment of the changes we have developed. If deployment is missing, it is unlikely to actually reach the aimed business benefits.

With Strategic Development Portfolios, there may be many different types of changes to be deployed across the organization, here are few examples:

  • Strategy deployment – creating awareness and aligning the organization to strategic targets
  • Introduction of new IT tool impacting business processes and ways of working
  • ERP rollout to a unit
  • Introduction of new offering, products or services to markets
  • Replacement of a legacy IT tool with SAAS service – impacting also business logic and processes
  • New pricing model changes
  • Changes in the roles and organization
  • Cultural changes or changes in the ways of working (e.g. leadership behavior, lean and agile)

It is not enough to send a newsletter or create 10 min online training to be successful with this type of change. I will go through some of my key learnings from the deployments, I hope this helps!

People side of the change

One of the challenging parts in any strategic initiative is people side of the change. We tend to be so busy with the hard staff – concepting solution, negotiation with the vendors, development and testing and keeping the schedule that there may not be enough time to focus on change management. Today, many large transformation have also change management leads, which is wonderful – the importance of change management has been recognized.

Here are couple of things, which I have seen very beneficial:

  • Engaging key stakeholders already during the development phase – co-creation, info calls, news letters, engaging teams early on in testing…
  • Communications or support package for people managers – how is the change impacting our team, how to go through the change in our team meetings, how to follow up on change.
  • Role based training materials – thinking about the messages and training materials from different roles view point, not just using generic materials which may not be a perfect fit for anyone. Creating modular materials, from where you can choose materials relevant for different roles.
  • Feedback loops & retrospectives – when developing something complex and new, it is important to continuously improve. Collecting the learnings from the pilot phase and improving both the content and ways of working makes the rest of the deployments smoother.
  • Overall high quality deployment package makes the change management easier – let’s review that part next!

Making it scalable via high quality deployment package

Documentation from the development project is not a proper deployment package. Deployment package should be created from the perspective of the receiving organization and to support the change adaptation within the unit.

Here are few components, which might be relevant for a deployment package:

  • Task list
  • Training materials (role based)
  • Communications package
  • Change management package for line manager
  • Marketing materials
  • Technical product & sales documentation
  • Value proposition and sales support materials
  • KPIs & criteria for success to be followed
  • Supporting tools or IT solutions

Deployment planning as a collaboration

Organizations have also limits, how many changes can happen in parallel while running also sales and business operations.

  • Align deployment plans with the units to collect also feedbacks on priority of your development, and other parallel activities. What would be optimal from the unit perspective?
  • Budget also funding for deployment – do you need a rollout coordinator? Would you need to translate some of the marketing materials to different languages? Would you need a project manager or a new key user hiring in some units?
  • Sometimes with large transformations, deployment may take years, as there are many organizational units to be considered. However, this may be also dangerous – business benefits are delayed, there are old and new solutions to be maintained, and also more and more changes may be required as time goes by. How to make deployment as smooth as possible – creating waves for deployment? Or perhaps engaging area organizations to scale up?

When would we need a rollout project and when release communication is enough?

If there is an existing solution or process, with well functioning regular release practices and an existing community of practice or a network of experts, there may not be need for a rollout project. Release communication may be enough to keep people informed, and key users or other experts are taking the needed training actions within the units.

However, rollout project may be a great approach, when:

  • Change is impacting significantly one or more organizational roles
  • Completely new IT solution is rolled out across different units
  • Introducing a completely new business model or new type of offering, products or services
  • Extensive training is needed or building up new competences within organization

I think deployment of new offering deserves an own blog, I will come back with that topic later!

Did you already notice the Free Online course? Have a look!

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

The Biggest Challenge For Development Portfolios is…

Posted on by Heli Hiisilä

prioritization. This is the answer I receive when I am discussing with portfolio management professionals. And let’s be honest, it is really difficult. There are so many different viewpoints to consider when prioritizing a development portfolio, and not one method fits all.

After my previous post related to portfolio funnel management, I have had great discussions about prioritization. I will open up some of the portfolio methods identified in the literature, and also some practical tips, which have been useful for me.

Management decisions – creating focus across the organization via prioritization

Without management decisions for prioritization, organizations end up into a chaotic situation – there are too many initiatives ongoing, everything is number one priority, and development slows down when resources are too thinly spread across initiatives. Setting up clear priorities is one of the most important tasks for senior management sponsoring development.

One of the great professionals I have had an opportunity to interview, summarized the responsibility of senior management:

Senior management, be kind to your organization, and make prioritization decisions!
Prioritization creates focus across the organization, and ensure we are taking strategy into action.

Interviewed portfolio management professional

Experienced leaders have good personal judgement and previous experience to support portfolio decision making. However, we all have blind spots and biases in our thinking. Even though different portfolio methods are not by all means perfect, and not always easy to implement in real life scenarios, different methods provide support to make better decisions.

So let’s review some of the commonly used methods!

Step 0 – Create transparency before prioritization can start…

Before prioritization work can really start, it is important to create transparency across all development happening. One of the challenges in many organizations is, that in addition often well-known project portfolio, there is a number of other development activities ongoing with agile development teams, and also other non-projected activities, which are not always visible at the portfolio level. Transparency can be created via a common tool, or via an excel sheet or portfolio Kanban board, depending on what size of portfolio you are looking at.

Once transparency is created, learning begins! Here are typical points to discuss, when seeing the whole portfolio scope:

  • What are all of these things we are developing? Why do we need to develop all of this?
  • How much are we spending?
  • How are these initiatives linked to our strategy? Are these all must haves?
  • Do we have enough capacity to execute these plans? Could we sequence some of these?
  • What are the dependencies between these items? If we save from an enabler initiative, would it delay some strategic initiatives?
  • What are our colleagues in another business unit planning to develop in parallel? Could there be synergies?

Business Cases

Business cases are a well-known and popular method for understanding both business benefits as well as costs linked. Initiatives with the best business cases should be selected for the portfolio scope.

But… how many really well conducted business cases have you actually seen? The ones which have been also followed up systematically throughout the benefit realization phase? And when looking into different initiatives across portfolio, are business cases comparable?

Typical challenges with business cases are:

  • Difficulty to estimate the realistic costs at the time of investment decision
  • Unrealistic benefit assumptions without validation
  • Difficulty to include also soft benefits into the business case
  • Business case is not reviewed and re-evaluated when scope or budget is changes or benefits are re-estimated
  • Lack of run costs in the business case (e.g. new head counts needed to support the solution, or continuous licenses)
  • For big legal or mandatory initiatives, difficulty to find benefits, and reluctance to create any business case estimates at all

Even though acknowledging these challenges, I would argue that business case is a great tool. We did a case study analyzing how to better support large complex development initiatives (Hiisilä et al, 2016), and one of the recommended practices was to iteratively review and improve business case throughout multi-year development initiatives. When working with large development initiatives, at the beginning of the journey, business case numbers are the best estimates, and should not taken as facts. Understanding of the content evolves, when specifying the solution and receiving vendor quotations, and business case becomes more concrete over the time.

If you are planning to update your business case practices, I would also recommend to look into lean business case from Scaled Agile Framework for inspiration. Lean business case has numbers, but it is also defining the verbally solution scope and for example leading indicators.

Voice of the customer

Is the voice of the customers used in the prioritization of your development initiatives?

One of my previous managers shared a good practice he had learned earlier – there was a small bell, and if development initiative was creating customer value, one should ring the bell. If no bell ringing can be heard, should the initiative be prioritized at all?

Strategic buckets

When working with large development portfolios, allocation of funds into strategic buckets may make sense. For example, to ensure enough money is spent on future horizons (see a previous blog post on Balanced portfolio) or investments are balanced across different product lines, strategic buckets may work well.

Traditional Portfolio Methods

There are many portfolio methods to support with prioritization, such as net present value, or payback period. Even though article is quite old, interesting insights of how widely different portfolio methods are used across business were provided by Cooper et al:

  • Financials methods such as Net Present Value (NVP), Expected Commercial Value (ECV), Return of Investment (ROI), Economic Value Added (EVA) or payback period – widely used (~77% of businesses used such methods based on the article)
  • Strategic approaches – money is allocated across different types or projects or strategic buckets (~65% of businesses used these methods)
  • Bubble diagrams or portfolio maps (~40% of businesses used these approaches)
  • Scoring models (~38% of businesses used these approaches)
  • Check lists to evaluate projects (~18% of businesses used these approaches)

I have seen successful implementations of each of these – here, as with the business cases, the usefulness of the method is linked to the reliability of the data. If you have too good to be true payback period, you should always look into the source data assumptions. And if management is not using these tools in decision making, then does it make sense to create the content. Tools can also help by automatically calculating financial metrics, based on the business case details.

Budget cut scenarios as a prioritization tool

Many organizations have experiences from budget cuts, while going through rough times. Somehow, surprisingly, when absolutely needed, it is possible to reduce the development costs significantly, even though it is painful. Here are few approaches, which I have seen used:

  • Building different types of budget cut scenarios, e.g. what would be your development scenario be, if you have 10% or 30% smaller budgets may help to find the key priorities.
  • Categorizing initiatives into must have to keep business running, strategic initiatives and continuous development categories
  • Reviewing the whole portfolio and setting all initiatives into priority order – if we would have x budget, which items would fit in from the priority order?

And as many of us have experienced, it is better to truly prioritize and leave out some of the initiatives, than to cut budget frames from all areas evenly.

Other prioritization methods

There is a number of other methods for portfolio prioritization too. I will add here few:

  • Voting – each member of the portfolio governance body has a vote for prioritization
  • Priority categories – assigning initiatives to priority categories such as High, Medium and Low – commonly used approach. Priorities can be used when communicating about the portfolio content, but also in case there are resource conflicts between the initiatives.
  • Top 3 or Top 10 key initiatives – this approach is good, when portfolio is large, and organization wants to have special focus on certain key initiatives. Other initiatives are important too, but there could be more focus and communication about these priority initiatives.
  • Weighted Shortest Job First (WSJF) – So how is prioritization done in agile? A popular approach is to continuously prioritize backlog based on the WSJF – weighted shortest job first (by the way, very difficult to say out loud for me at least). The WSJF takes into consideration relative user and business value, time criticality, risk reduction and/or opportunity enablement, and also the job size. This totally makes sense, even though it takes a bit of time to really understand the concept, at least for me it did. If you are interested in this, here is a link to a posting explaining WSJF via agility.im!

I think this topic would deserve a series of blog posts… Let me know, what prioritization methods you are using – this is an area, I would love to learn more about!

In the end, what ever method you use, portfolio prioritization comes back to management decision making. Referring back to the quotation from the anonymous portfolio management professional: So please, senior management, be kind to your organization, and make prioritization decisions!

References

Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success.” The PDMA ToolBook 1 for New Product Development 9 (2002): 331-364. Link

H. Hiisilä, M. Kauppinen and S. Kujala, “An Iterative Process to Connect Business and IT Development: Lessons Learned,” 2016 IEEE 18th Conference on Business Informatics (CBI), Paris, France, 2016, pp. 94-103. Link to abstract

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

4 Goals of Portfolio Management

Posted on by Heli Hiisilä

Portfolio management is challenging by nature, as it is dealing with future events and opportunities – information in project selection is often uncertain and sometimes even unreliable. The decision environment is typically also dynamic – the status and prospects of projects are changing and also market environment. And resources are always limited – resource transfers between projects are not always seamless. In this blog, I wanted to share 4 goals of portfolio management from a classic article Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success”.

Even though article is quite old, and focusing on product portfolio management, I think these goals are still quite relevant. I will highlight some of the key learnings from the article and also add on some reflections. I hope this is useful, and I would also recommend to check out the original article with a lot more insights!

Let’s go through the four goals!

Goal 1: Value maximization

The number one goal of portfolio management is to maximize the value of the portfolio. How to actually do this?

Simple approach used by many companies is to calculate Net Present Value (NPV). For each project in the portfolio, Net Present Value is calculated and projects, with the highest value are selected into the portfolio scope. NPV works well in theory, but in real life, defining the business benefits is always tricky – and not always fully objective. Oftentimes also in the portfolio level, different projects are not easy to compare against each other.

Another method defined in the article is Expected Commercial Value (ECV) – this method takes into consideration probability of technical success as well as commercial success. This is really important, as even the best product or service will not have high commercial value, if commercial model is not successful, and other way around – if product or service is not working well, commercial model cannot fix the issues. Another method, called Productivity Index (PI), tries to maximize the value of the portfolio for the given resource constraints. Calculation within these methods seems to be a bit complex for practical implement, but conceptually really good food for thought!

There are also other scoring models as portfolio tools, where projects are scored on each criteria, such as strategic alignment, market attractiveness, or reward vs. risk. If you are interested to learn more, have a look at the article!

Goal 2: Balance

The second goal is to develop a balanced portfolio. There may be different attributes to achieve balanced portfolios, e.g. balance across different time horizons (See previous blog post: Is Your Development Portfolio Balanced Across Different Time Horizons?), balancing the risk level of portfolio, or balancing across different markets, technologies, product categories or project categories.

A typical scoring model for project selection summarized in the article includes the following factors with scaling from 1-10, anchored scale points 1,4, 7 & 10:

  • Reward
  • Business Strategy Fit
  • Strategic Leverage
  • Probability of Commercial Success
  • Probability of Technical Success

The article has also nice examples with traditional bubble diagrams, if you are interested to learn more.

In real life, as resources are always limited, portfolios tend to be easily unbalanced. There may be too much investment into certain business unit or product family and lack of investment into some others. There may be too much investment into products and services needed in one geographical area or market and not enough focus on other high potential markets. There may be too much focus on certain process areas and IT tools, and lack of focus on some other equally important. If the lack of balance is due to strategic priorities, that is fine – but if portfolio is not balanced unintentionally, this might cause issues in a long run.

A good practice is to review the portfolio periodically, e.g. quarterly (See previous blog post: Time for Quarterly Portfolio Review?) and check if any balancing actions would be needed.

Goal 3: Strategic direction

The article states that Strategy becomes real when you start spending money! This is true, development portfolios are key vehicles to take strategy into action. Here are two ways to ensure the portfolio is aligned with the strategic direction:

  • Strategic fit – are all projects consistent with your business’s strategy?
  • Spending break down – does the breakdown of your spending reflect your strategic priorities?

As tools to manage these aspects, two approaches are defined:

  1. Bottom-Up approach – Strategic criteria is built into project selection tools, such as scoring factors introduced earlier
  2. Top Down Strategic approach – Strategic Buckets Model – based on the business strategy, buckets of money are enveloped for different types of projects. Examples of strategic buckets defined in the article were buckets per different product line, own buckets for new product projects, platform projects or other (e.g. extensions, improvements or cost reductions).

Typically, when discussing with practitioners, having a clear strategic direction may be one of the challenges: company strategy is so wide, that is not really giving guidance for portfolio prioritization – all of our projects are linked to strategy one way or another. Some organizations have solved also this issue by creating a more detailed portfolio vision (See blog post: Bright Future Ahead – Creating an Inspiring Development Portfolio Vision) or even more concrete Objectives and Key results (See blog post: Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs))

Goal 4: Right number of projects

Most companies have too many projects in the pipeline and due to limited resources, resulting in pipeline gridlock. This is also one of the key challenges almost every portfolio management practitioner highlights during the discussions.

To solve this challenge, there are two questions:

  1. Do you have enough of the right resources to handle projects currently in the pipeline?
  2. Do you have enough resources to achieve your new product goals?

As a solution for both questions capacity planning is based on the current project’s roadmap and future development needs. Mapping resource demand and available capacity is a significant effort with large portfolios and big organizations – portfolio management tools may support these views!

In addition to capacity management, I would also strongly link this goal to prioritization! It is really important to create limit the number of new projects initiated and also kill unsuccessful projects.

Tip! Check out also the blog post: Do you manage a Portfolio Funnel, or Tunnel?

References

Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success.” The PDMA ToolBook 1 for New Product Development 9 (2002): 331-364. Link

Previous blog posts, which might be also interesting:

From Project Portfolios to Product Portfolios – Focus on Development Outcomes
Blog post related to product and offering portfolio management
https://strategicportfoliomanagement.wordpress.com/2022/11/05/__trashed/
Blog post related to Quarterly Portfolio Reviews

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

From Project Gate Approvals to Portfolio Reviews – Which approach is better for your portfolio?

Posted on by Heli Hiisilä

Traditionally governance of project portfolio has been organized around gate decisions – scope, budget, business case and go-live decisions have been approved by passing a specific project gate. Today, as agile development teams have become more and more popular and many organizations are managing hybrid portfolios with projects and agile (See the previous post related to Hybrid development portfolios) or fully agile ways of working, also governance is impacted.

My search for interesting portfolio management literature continues! One of the golden nuggets from Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success” is the definition of two alternative portfolio approaches: 1) Gate dominate approach and 2) Portfolio review dominate approach. This article is focusing on pros and cons of both approaches, and could these be combined?

Stage-gate project models have been used traditionally in project portfolios. The idea with the gate model is that if process is working well, gate decisions are driving portfolio decision making. If you have strong gate model practices, this approach may your portfolio governance well!

However, today, many organizations have moved towards product portfolio management, and agile ways of working. Instead of stage-gate-projects, development may be driven by product development teams. For such portfolios, Portfolio review dominate approach might work better. Instead of focusing on individual project gate decisions, portfolio reviews are periodic meetings, which serve as check on portfolio: reviewing all projects together, checking priorities and making balancing decisions.

Stage-Gate driven Portfolio Process

Stage-gate projects have been used widely across industries and there are good reasons for the popularity of the model! By following the model, different stages of product development are systematically implemented, and between each stage, there are Go/Kill decision points, gates. Process starts typically from Discover stage with ideation focus followed by the first gate – if idea is promising, quick investigation and scoping stage of the project is done, typically mainly desk research. Again, if idea is considered viable after the scoping phase, next phase is focusing on Design. Design stage includes already a detailed investigation focusing on customer needs, markets and and technical solution, and results in business case and project plan among other outcomes. Typically gate decision before Develop stage is really important, as more resources and budget is typically needed for actual development work. During the Scale Up stage, new product is tested also commercially to ensure new product has a good go-to-market approach also solid production and operations plans. The full scale commercialization is part of the Launch stage. Read more about Stage-Gate model: The Stage-Gate Model: An Overview

Key topics to consider, if you have Stage-gate driven portfolio process

  • Gate model gives a good framework to do systematical development work – process guides to take into consideration important decision points and also quality gates are typically built into the process.
  • Go/Kill decision points – the idea within stage-gate process is that projects may be killed at any gate – if there is no business case, commercial or technical viability, project implementation should not continue. Kill decisions are typically difficult, and killing a project should not be seen as a failure of the project team – rather as an opportunity for learning as an organization.
  • In some organizations, project models have become quite heavy over the time with many gates to pass, extensive check list and must have deliverables – collect feedback and see, if some leaning could be done. Consider also, how many gates are needed in your process and are all gates relevant for the portfolio governance.
  • Different project types may also have different types of gate models, and based on the need, and one process does not need to fit all scenarios. See a great summary picture at the end of blog text: Stage-Gate International: What is the Stage-Gate®  Discovery-to-Launch Process?
  • Today, as agile ways of working have become more and more popular, stage gate models are often criticized as being too waterfall based – once scope is defined, there is no going back in the process, or once design has been frozen, no changes are allowed. For IT projects, a common model seems to be have a simple and lean state gate model, combined with agile implementation phase – actual development work may be carried out via iterations or increments. The benefit of having clear decision points to ensure good governance and also supporting phase deliverables is to ensure all important activities, such as architecture reviews and security checks are implemented and solution can be safely taken into service management scope.

Portfolio review driven approach

For dynamic portfolios, where business environment is rapidly changing, portfolio reviews may be a great approach!

Here are topics to consider, if you have a portfolio review approach in your portfolio

  • One of the challenges with Stage-gate process is, that product development does not end at the Launch phase, especially when developing complex digital services. Agile or continuous development teams or DevOps teams have become more and more popular. Gate approval driven portfolio process does not support optimally continuous nature of agile development work.
  • If you have in parallel also gate process, could you simplify the governance by reducing the number of gate approvals needed or delegate decision making responsibility?
  • For rapidly changing business environments, it is healthy to have a critical view over the whole portfolio periodically, not only once a year for budgeting purposes.
  • Also balancing the portfolio, if needed, should happen during the portfolio reviews.
  • Portfolio reviews could be considered as an event for mass approving (or killing) new initiatives (Cooper et al., 2002).
  • For large portfolios with many projects ongoing, gate approvals can also happen regularity to keep projects running, where as portfolio reviews could focus on strategic and tactic level. See also previous blog post related to Quarterly reviews (Time for Quarterly Review?) on this topic!

References

Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success.” The PDMA ToolBook 1 for New Product Development 9 (2002): 331-364. Link

The Stage-Gate Model: An Overview

State-Gate International: What is the Stage-Gate®  Discovery-to-Launch Process?

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Portfolio management challenges – what is new?

Posted on by Heli Hiisilä

One of the classic portfolio management articles (Cooper et. al, 1997) analyzed portfolio management challenges many companies struggled with. Here is the top 5 challenges identified:

  1. The portfolio of projects does not reflect the business’s strategy
  2. Portfolio’s quality (performance of projects) is poor
  3. Go/Kill decision points are weak and Poor projects are not killed
  4. Resources are scarce, and there is lack of focus
  5. Too many trivial projects and too few projects aiming at real breakthrough

After 25 years, these challenges are still relevant for many organizations. It is still difficult to prioritize portfolio based on the strategy, portfolios still tend to have bad projects or agile initiatives, it is still extremely hard to kill projects, it is still difficult to prioritize and it is still easy to select quick wins over initiatives to build future competitiveness. Good food for thought for any practitioner!

What are the key challenges today?

During my interviews with experienced portfolio management professionals, classic challenges mentioned above were highlighted many times. But also many things have changed since 1997. Here is a collection of challenges many organizations may identify today:

A. Hybrid portfolios including projects and agile initiatives are difficult to manage – instead of managing traditional project portfolio, portfolio may include a mix of projects and agile initiatives with different ways of working. Many organizations have traditional planning, budgeting and governance processes, but part of the organization is rapidly transitioning towards Lean and agile ways of working. (Read more via dedicated blog post: From project portfolios to hybrid development portfolios combining projects and agile.)

B. Creating transparency across organization – managing dependencies and complexity. When products and services, processes and tools have become more and more complex, managing development and deployment of complex hardware-software-services solution requires a lot of alignment and communications across the organization.

C. Managing capacity for strategic initiatives hard, when development work needed from many units. Within large organizations, strategic transformation initiatives my require work from many units: different business units, R&D units, IT teams, global functions, sales organizations, and operations.

D. Portfolio priorities not up-to-date due to rapid changes in business environment. During the past years, business environment has changed rapidly for many companies. If portfolio priorities are not regularly reviewed and updated as needed, development portfolio may have

E. Lack of investment into future horizons and innovative solutions – portfolio not balanced. As development is the way to build the bright future and meet strategic targets, enough development capacity should be allocated to build future horizon competitiveness, not only focus on quick wins. (Read more via dedicated blog post: Is Your Development Portfolio Balanced Across Time Horizons?)

And then one more bonus challenge, which is also relevant for many organizations:

Bonus: Portfolio management fundamentals – improving organizational maturity across all portfolios. Good portfolio management practices help organization to make data-based decisions and created transparency and focus – if fundamentals such as processes, governance, discipline, communication and common tools are not in place, or each unit has different practices, managing portfolios may become difficult. (Read more via blog post: Developing Strategic Portfolio Management Maturity Step by Step)

Portfolio management challenges – and what is new?

Do you relate to these, or do you have other challenges?

References

Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management in new product development: Lessons from the leaders—I.” Research-Technology Management 40.5 (1997): 16-28.