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

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!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again. -
Is Your Development Portfolio Balanced Across Different Time Horizons?

Development is the way to transform company from the current state to the future to-be state. One of the challenges in many portfolios is to focus too much on initiatives developing short term solutions: current products and offerings, existing processes and ways of working. Continuous improvement is super important, but if there is lack of development initiatives building future competitiveness, it is a good time to look if portfolio would need rebalancing.
I will review here some models for mapping your portfolio content based on the different horizons:
McKinsey Three Horizons model
McKinseys Three Horizons model introduced in The Alchemy of Growth (Bahai & Coley, 2000) divides investments into three horizons:
- Horizon 1 – focus on growing and defending a company’s core businesses to ensure near-term success. Investments are typically well known and there is a low uncertainty. This is a kind of comfort zone for many portfolios – examples of investments could be enhancing existing products and offerings and improving current operating model, and IT systems.
- Horizon 2 – investments are focusing on scaling new revenue streams, perhaps a bit outside of core offerings with higher investments and longer investment horizons than in horizon 1. New capabilities needs to be built to support horizon 2 investments.
- Horizon 3 – investments in horizon 3 have high level of uncertainty, high level risk, and often high level of research and development required. These development initiatives could lead to creation of completely new markets for company – and potentially there could be a very high profits available in the future.
Investments into horizon one feel safe – this the comfort zone for many of us – we know this staff well and there is not so much risk. However, if all investment money is spent in Horizon 1, your portfolio may be already late with your Horizon 2 or Horizon 3 investments – too much investment into short term may damage future competitiveness. Some companies have a practice to create own portfolios for Horizon 2 or Horizon 3 investments – to give an own investment bucket for forward looking initiatives.
SAFe Investment Horizon Model – Guiding Investments by Horizons

Scaled Agile Framework has also adapted three horizons model with some enhancements. In addition to horizons 1-3, also Horizon 0 for retiring products and solutions was added – this is good, as it is important to also decommission old solutions. Horizon 1 is also split into two categories: Investing and Extracting solutions. Horizon 2 solutions are emerging next generation horizon 1 products, where as horizon 3 is focusing on new opportunities with longer return of investment time.
Categorizing investments into different horizons is a great tool – as a one time effort or even by adding horizon into your portfolio data.
Scaled Agile Framework (SAFe) – Guiding investments by Horizon Exploit and Explore Portfolio by Strategyzer

The idea within Exploit and Explore Portfolios by Strategyzer’s The Invincible Company is to divide portfolio into products, offerings or solutions belonging to either Explore or Exploit portfolios.
Within Explore portfolio, there are new initiatives, perhaps belonging to Horizons 2 and 3. Items are mapped based on the Expected return and Innovation risk – a visual tool to map the different products and services.
Within Exploit portfolio, there are existing products and solutions – perhaps Horizons 1 and 0 might belong here. Items are mapped here based on Return and Death & Disruption risk.
For product portfolios, also product life cycle stages are commonly used tool to balance product portfolio across Development, Growth, Maturity and Decline stages.
Key takeaways – is your portfolio balanced across time horizons?

A good practice for any development portfolio is to check when doing long range planning or yearly budgeting work, how much money you are spending on each time horizon. This is a good agenda item to be also discussed during the quarterly review (See my previous post – Time for a quarterly portfolio review?) If you do not have this information gathered in your portfolio data, this can be done as one-time analysis for example yearly.
Also in enterprise level, this is a good exercise to look into as part of the strategy implementation – how much are our development portfolios spending on developing Exploit portfolio or Horizon 1 and 0, and how much are we investing into future competitiveness?
The balance between different time horizons depends on each portfolio vision, as well as company strategy and risk tolerance.
References
Baghai, Mehrdad, and Steve Coley. The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise. Basic Books, 2000.
Scaled Agile Framework (SAFe) – Lean budgets / Guiding investments by Horizon
-
Developing your E-shaped portfolio management skill set

This is the time of the year when many of us are looking into individual development plans. One of the challenges for portfolio management professionals working with large and complex development portfolios is the need to master so many different skills! On the other hand, working in portfolio management area is also a great opportunity for personal development, as there is a lot of room to build expertise on both methodologies but also related to portfolio content!
In my current workplace, E-shaped skill set with strong core skill and building up also supporting skills was recommended. I like this concept a lot and started to think, what are the core skills needed in development portfolio management and on the other hand, what are the supporting skills many portfolio managers really benefit from?
Core skills for portfolio managers – building a strong I
There are many great backgrounds for portfolio management professionals. Moving towards portfolio management is a natural development path for many project and program managers. Some of the great portfolio management colleagues have also business or product management backgrounds or experience from business controlling.
There are few core skills, I would say are very important to master, such as development methods – how to manage portfolio, program and projects. In addition to understanding the theory, it is really helpful to have practical experience from running different types of development initiatives. Also good understanding of portfolio finances is one of the key areas, linking to company financial processes, developing planning and benefit tracking practices.
Furthermore, lean and agile methods have become common in many organizations, and for example decision making and governance may be significantly impacted by lean and agile ways of working. Also developing portfolio management ways of working should follow lean and agile principles – finding ways to lean portfolio management processes and ensure still good governance.
By default, portfolio prioritization should be strategy driven, and understanding business strategy well to with portfolio decision making is critical. In addition to strategic thinking, also operational capability to make things happen. Combining the two approaches is not always easy!

Supporting skills for portfolio managers – building E shaped skills profile
In addition to strong core skills, there are other important areas to build sills when working in portfolio management roles. Here is some thinking:
Understanding the content is important – what are the products and offerings developed, or for example solutions and platforms in the scope of the portfolio? How is operating model, processes and IT tools impacted by the development initiatives? Understanding the content well enough is often extremely critical, especially when facilitating difficult prioritization discussions. For big portfolios, it is impossible to know everything, and here networking skills play a key role – knowing who knows within your organization.
During the past years, I have started to emphasize the importance of Change management and Communications skills. Even though you would develop beautiful new solutions, without communications the rest of the organization will not be aware of all the great achievements within your organizations. And without change management, even the best technical solution will not bring business benefits, if there is no buy in and adaptation of the new solution will not scale up. Even though I have learned a lot from great colleagues about these areas during the past years, definitely still a lot to improve for myself for these skills!
Portfolio management requires also a lot of leadership, coaching and networking skills! No matter how you are organized within your portfolio, strong leadership is required. Sometimes, when working with decentralized portfolios, where development is happening across different units and functions, networking and coaching skills become super relevant – leading without line management mandate is not easy, but very much needed to create clarity and focus! Also new type of leadership is needed when working with agile development – giving clear guardrails, but still empowering the teams with the decision making.

What does your E-look like?
We all work in different environments, and your E shaped skill set may look a bit different from what I drafted. Also, many portfolio management professionals have multiple hats, and role may be combined with business development or other duties.
What areas would you like to develop further this year, perhaps learn more about change management or further develop your coaching skills? Or learning about lean portfolio management?
Take a few minutes to think – what does your E-look like? What are the areas where you would like to grown and learn more? If you like, you can take a template from here:

-
Bright Future Ahead – Creating an Inspiring Development Portfolio Vision!

Sometimes when we are busy with day-to-day work, it is not so easy to take time for thinking about development portfolio vision – what would bright future look like! However, if clear inspiring vision is missing, prioritization may be difficult as there are many potential future visions to look into. A common vision creates also motivation across teams – our development work will contribute to this cool future vision – it really matters in a big picture! And my contribution counts!
I will summarize couple of tips how to work on your development portfolio vision. These methods work well for transformation programs or large projects too! Or even for your personal development – why not?
The Bright Future Method
My former colleague Mirette Kangas has been teaching The Bright Future method, which is one of the great tools, I recommend getting familiar with. You can find lots of great content, also The Bright future materials Yle Lean Culture Toolkit 2.0, but here is a short summary of the method also in English:
The idea is simple, gather your team, and start to systematically think about what the bright future will look like.
Let’s jump into the bright future now!

Even though it is not always easy, this workshop should not focus on current state challenges, but focus on the bright future ahead.
For each round, it is good to start alone and ideate (writing items into post-its physically or via online white board). Next step would be the share the ideas in pairs, discuss and create more ideas together. The it is time to consolidate ideas within your group – share highlights and put post is to the canvas. If you are working with a large workshop, whole group can also have a short round table to share the highlights. Tip for facilitator – remember strict time boxing, to have time for each round!

Round 1: Thinking
- What kind of thinking and beliefs guide the creation and behavior of structures (and how does it differ from how people think today)?
Round 2: Structures
- What structures do we have in our bright future that enable and promote the activities and behavior we describe?
Round 3: Behavior
- How should we act (and how is it different from the current state) in order to produce the kind of results we describe?
Round 4: Ideas about the Results
- What value do we produce for our customers and other reference groups?
- What kind of outputs and services do we produce?
Summarize and prioritize development items into your roadmaps and backlogs
Summarize your results together to create an inspiring bright future vision!
And remember to use the workshop results actively – consolidate development ideas into backlog, and prioritize – do you have low hanging fruits, do you identify new development epics to reach your bright future vision? Also updating your future roadmaps to achieve the future vision is important – tips related to road mapping will be covered in the next blog post – stay tuned!
For me, a temptation is to skip rounds 1-3 and move directly to the Results part – however, thinking also about change of thinking, supporting structures and behavior are super important. So follow the process!
For Finnish speaking readers, strong recommendation to check out Yle Lean Culture Toolkit 2.0 by Mirette Kangas with the original materials for The Bright Future method – also lots of other great materials I recommend to look into!
Portfolio vision in Scaled Agile Lean portfolio management

Again, Scaled agile framework (SAFe) includes great tools for portfolio vision definition. Here are my favorite ones:
- Postcard from the future – wish we were here! You could use Postcard from the future to summarize your Bright Future workshop results.
- Portfolio Canvas (adapted from The business Model Canvas) – creating current state and future state portfolio canvases – good tool for portfolio managers working with agile or hybrid development portfolios!
- TOWS Strategic Options Matrix based on SWOT analysis – familiar idea for many of you, always a great way to summarize options
- Identifying portfolio epics and enablers based on the future vision – if this step is forgotten, it is unlikely to actually reach the future vision!
Making the bright future concrete via Objectives and key results (OKRs)

Objectives and key results are a great tool to setup time bound objectives – and are a great match to make vision concreate and measurable. Have a look at the tips related to OKRs via the previous blog post!
References
Yle Lean Culture Toolkit 2.0 by Mirette Kangas – also lots of other great materials I recommend to look into!
Scaled Agile Framework (SAFe) Lean portfolio management includes great tools to support portfolio vision definition:
Scaled Agile Framework – Portfolio vision & tools to support Blog post – Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs) -
Digital Servitization – How to make introduction of new digital services to markets easier?
This blog post is from November 2020, when I completed my MBA thesis related to Digital servitization framework, but I think it is still valid, and added also here! During the spring 2023, Helsinki is hosting also The Spring Servitization Conference, and it is good time to review some old notes now.

Servitization is not a new phenomenon, and many manufacturing companies have already experienced servitization in the context of repair and maintenance services. Servitization was described by Vandermerwe & Rada (1988, p. 314) as “increased offering of fuller market packages or ‘bundles’ of customer focused combinations of goods, services, support, self-service and knowledge in order to add value to core product offerings.” In this early article, servitization was considered as a key strategy for organizations to adapt to a new kind of economy, where services play a key role in value propositions.
Another definition by Baines et al. (2009) highlights the importance of organizational capabilities and processes: “Servitization is the innovation of an organization’s capabilities and processes to better create mutual value through shift from selling products to selling Product-Service Systems.”
Developing digital services vs. digital servitization
Digitalization brings also a new view point to servitization: “Digital servitization is viewed as the use of digital technologies to create an appropriate value from product-service offerings; thus, digital servitization is understood as the interplay between digitalization and servitization” (Kohtamäki et al., 2020).
Research indicates that digitalization of manufacturing without servitization capabilities can lead to negative returns, i.e. digitalization paradox – thus, servitization is needed to create positive financial performance from digitalization (Kohtamäki et al., 2020). That is, even though you would have fantastic digital service product, without servitization activities it may be difficult to bring a new solution to markets successfully.
The digital servitization journey may not always be straightforward, due to many transformations needed in the technologies and commercial models, in different business lines and functions, across country organizations, operating model processes, roles, data and IT tools, and supply chain.
Combining physical and digital – productizing services vs. servitizing products?
One of the biggest challenges for the manufacturing companies in the digital servitization journey may be to combine physical hardware and digital services and setup up seamless end-to-end processes for running the services.
There may be complex dependencies between the physical hardware components and digital services. Also, in in the world of existing installed based, customers may have a large number of different types of hardware setups. Furthermore, when considering end-users using for example mobile apps, the variety of different types of end user devices may be huge.
If approaching digital servitization from the traditional hardware product view point, commercial model could be to servitize the product, e.g. introduce value added services to offer increased value towards customers. If approaching the phenomenon from the service offering view point, approach could be to productize the service – implement great commercial models and robust processes for the digital services. Both viewpoints are needed, and this is the fun part!
In practice, digital servitization may be seen as a journey to implement digital services and solutions into end-to-end processes: development, deployment and run phase of the digital services needs to be systematically managed.
Focus on customer value – but who is your customer?
For companies working with traditional B2B setup, digital services may introduce completely new type of customer groups. Digital services may be sold for different customer roles and decision making process may vary from the familiar ways. Also the end-user groups may be completely new with new type of support needs.
In order for customers to invest in digital services, clear customer value should be continuously delivered. Understanding the customer need and use cases, validating the customer value and also ensuring customer success plays a key role.
How to make it easier?
The recommendation from my MBA study is to develop company methods, practices, processes, tools and governance to enable fast, but systematic digital service development, deployment and a run phase with continuous improvement loop. The process was seen iterative by nature, and digital product, commercial models and end-to-end processes should evolve over time.
As introducing digital services may require changes in many different areas, there is no easy way. However, defining a simple framework including a set of templates and examples may help new teams, while working with commercialization and end-to-end processes. Also creating a common service concept and business model for a group of services, may help with the implementation and ramp up of the services.
In addition to a global view point, also service deployment and localization in the country organizations is extremely important. One model does not fit all, and thus optimizing go-to-market activities in the country is critical. When introducing new digital services, almost all roles in the organization need to be aware of the new offering, many roles are significantly impacted and new capabilities are needed.
Perhaps the most important thing, based on my opinion, is to build new collaboration between different teams, business lines, solution and offering areas and end-to-end process steps. This is not always easy as different functions may have different ways of working, but absolutely necessary and offers incredible learning opportunities!
References:
Baines, T.;Lightfoot, H.;Benedettini, O.;& Kay, J. (2009). The servitization of manufacturing: A review of literature and reflection on future challenges. Journal of Manufacturing Technology Management, 547-567.
Kohtamäki, M.;Perida, V.;Patel, P. C.;& Gebauer, H. (2020). The relationship between digitalization and servitization: The role of servitization in capturing the financial potential of digitalization. Technological Forecasting and Social Change.
Vandermerwe, S.;& Rada, J. (1989). Servitization of business: Adding value by adding services. European Management Journal, 314-324.
-
From Managing Past Costs to Rolling Forecasting – Development Portfolio Finances (part I)

Portfolio finances is one of my favorite topics – but also a complex and difficult one! I have had super interesting discussions about financial forecasting with many smart colleagues, and I will share some of my key learnings and practical tips here!
Managing development costs is important, but if we only focus on actuals, we always look into the past – and there is usually very little we can do for the past costs.
One of the good practices I would recommend for any development portfolio is financial forecasting. Forecasts are never 100% accurate, but they are the best understanding from the organization for the future costs (and benefits). There may be changes happening in different programs or projects – some work may progress faster than anticipated, and some may be delayed – this gives an opportunity in the portfolio level to take best use of available funding and for example initiate new prioritized work.
Different time horizons – from next month to long range planning
In the portfolio context, there are different time horizons to look into:
- How are we doing today – is the portfolio progressing according to our forecast? Do we have changes or delays, or an unused budget frame? What are the actuals compared to forecasts – are there significant differences?
- Current year – how is our forecast against our yearly frame? Do we have unused funding enabling a new high priority initiative?
- Planning for the next year – what are the portfolio level development initiatives for next year plans?
- Long range planning – what are the key development initiatives or themes for the next 5 years? Understanding the investment levels needed for future big initiatives is enough – no-one can give accurate forecasts for such a long time period.

Forecasting – different viewpoints
Finance processes in many companies have yearly cycles – whereas development portfolios are continuous by nature – projects start and end in the middle of the year, and some costs land to one year and others to the next year.
From the project viewpoint, the project typically has an approved budget including planned operating costs and capital investments. The cost may be divided into multiple years, but quite often finance process is looking for the annual cycles. If the project has changes or delays, also the cost may be pushed from one Calander year to another. These cases may cause headaches for financial controllers – if funding is reserved for one year, it may not be straightforward to push it to next year.
If the financial forecasting is focusing on current year or rolling five quarters, also some of the project costs may be out of the scope of financial process. However, from the portfolio viewpoint forecast (and business case) are needed for the whole entity and for the whole project duration. Both viewpoints – portfolio management and finance processes are important – it is just good to acknowledge, that sometimes there may be a bit different thinking and needs also for the forecasting.

In addition to projects, forecasting is a good practice also for value streams, continuous development teams, or other agile development teams. The agile way of budgeting may sometimes conflict with the standard finance processes many organizations have, but forecasting is also a good tool for agile teams – as a part of quarterly planning practices, it is good to check the forecast, too. And when updating future roadmaps, it is good to look at what would the impact into the future development forecasts.
Tips for projects and development teams – forecasting becomes easier over time!
- Creating the financial plan or forecast for the first time is usually difficult – especially at the beginning of the project, when scope and vendor contracts have not been defined yet.
- Create the first forecast with the team – this is a good opportunity for you to align together on your plans. Think forecasts from different viewpoints – include different vendor costs, but also consider internal work and other important elements.
- Think forecasts from the different viewpoints – include different vendor costs, but also consider internal work and other important elements, such as lisences.
- Accept also, that your forecast is not perfect, it is your best understanding at the moment!
- Next rounds of forecasting are already easier – previous forecast can be adjusted based on the new increased knowledge.
- Take forecasting into your routines – you could look into the forecast for example once a month in your core team meeting.
Tips for portfolio management and finance controllers – support the teams with forecasting, especially when getting started!
- What is the correct level of detail in forecasting for your organization and doable with your development teams? Too detailed forecasting may be difficult to introduce and manage in a long run.
- What is the correct cadence for your organization? Many organizations have quarterly or monthly cycles.
- Do you first focus on external cost forecasting, or include also internal work? Do you take a financial approach for internal work or plan for future FTEs?
- If development forecasting is new to your organization, accept, that it takes couple of forecasting rounds for organization to learn. Forecast accuracy improves over time, when development teams become familiar with the practice!
- At the beginning, help and support teams – people want to do good work, but they often need advice. If and when challenges are identified during the forecasting, take these as learning opportunity as an organization.
- Forecasts change over time – important to have regular checkpoints (e.g. monthly or quarterly). Regular cadence and friendly reminders to update forecasts help busy development teams to do the forecasting on time. Forecasts will not be useful if they are not updated systematically.
- Forecasting is a great tool for managing project or program finances, but also at portfolio or business unit level – if some projects or programs are delayed there may be opportunity initiate new prioritized projects – to take best use of available funding. Many organizations have quarterly forecasting cycles – quarterly cycles are also a great fit for portfolio level decision making. More about quarterly portfolio reviews here: Time for A Quarterly Portfolio Review?
- Also consolidated view of development portfolio forecasts in enterprise level gives an opportunity to see the big picture and do planning and prioritization across portfolios to ensure best use of capacity and ensure smooth execution for the most important initiatives.
- Portfolio management or financial planning tools provide also great support for managing different time horizons, rolling up via portfolio hierarchies, and managing different versions – but you can also start with simple tools, such as excels or SharePoint.
- Look into consolidated portfolio forecast carefully – typically development teams tend to be optimistic at the beginning of the year on all the development planned for the year and sometimes costs are moving towards the end of the year. If you notice something like this, discuss the teams, are they committed to all of the work with the remaining time, or should the forecast be updated.
- Instead of looking strictly at annual cycles, a rolling forecast typically fits better for development. Would this approach be good for your organization, too?
- This post was focusing on forecasting of development costs, but equally important are also expected benefits and development impact on run costs. This will be covered in the future blog posts!
I hope this helps, and I would love to hear your tips or viewpoints, too!
Check out also the latest blog posts!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again. -
Time for A Quarterly Portfolio Review?

Autumn is a busy time in many organizations due to yearly planning. However, development plans tend to change, and typically already in January some parts of the yearly plan require updates. One of the good practices I would recommend for any development portfolio is quarterly reviews.
Quarterly cycles work well in many organizations, as typically financial processes are quarterly based. A quarter is already a long enough time period to see progress happening within portfolio, but it is still possible to also take action, if progress is too slow in some areas or key results are not met. Furthermore, if operational portfolio governance is monthly based, quarterly cycle works well for tactical or strategic portfolio reviews.
In addition to portfolio level governance, quarterly cycles work well for hybrid portfolios including projects and agile work. Agile teams have often quarterly planning practices, and there may be needs to support planning with portfolio level decisions and prioritization.
Quarterly portfolio review – WHY?
Here is a list of why quarterly portfolio reviews may be helpful – but also a checklist for you to think for your own context:
Transparency and visibility
- Reviewing roadmaps & progress – how are we doing?
- Reviewing portfolio funnel of new ideas – what is new in the pipeline?
- Managing dependencies and alignment across initiatives
- Communication towards larger stakeholder group – creating transparency among the stakeholders
- How are we doing with portfolio finances?
Optimizing portfolio
- Optimizing and balancing portfolio content – is current portfolio reflecting strategy, and support future competitiviness?
- Feedback loops to business case updates & following up on benefit realization
- Killing projects or putting projects on hold if needed
Adapting to changes
- Adapting to changes in market environment
- Prioritization of new initiatives
- Allocation and reallocation of frames
- People side of the change – identifying focus areas and portfolio level impacts
Planning capacity
- Sequencing & prioritization of large initiatives to enable good resourcing
- Scaling capacity as needed based on future demand
- Ensuring resourcing for cross unit/function development initiatives
- Leaders supporting teams removing obstacles and ensuring resourcing
Continuous improvement
- Sharing key learnings from the portfolio – key takeaways from projects or programs
- Sharing good practices & ways of working
- Feedback loop to improve portfolio practices – where to focus on, what to end, what to keep doing
Quarterly portfolio review + quarterly planning for teams
Quarterly cycles are great also for development teams to look into roadmaps, aligning on priorities and balancing demand and capacity. Many agile teams also have quarterly planning practices to prioritize back log and to plan for the next quarter development work.
If teams have quarterly planning practices, good steps may include 1) Preplanning, 2) Planning with teams, 3) Quarterly portfolio review. Sometimes the order or portfolio review may be before the teams planning – what would be the best order for you?

Focus areas & agenda for quarterly review?
Quarterly review agenda may be planned based on the yearly portfolio clock. For many organizations, Q2 review could be focusing on long range planning, whereas Q4 review could be celebrating current year successes and next year plans. It is also important to keep benefit realization in the agenda, so that could be a focus area for Q3 and Q1 reviews.
All portfolios are unique – for a large and complex portfolio quarterly process may include many meetings to clarify plans and align with the stakeholders, as well as own meeting focusing on decision making. For smaller portfolio, review may be also much lighter checkup – are we reaching our key results, how are with benefit realization, and do we need to change priorities. Here is an idea, what your agenda could look like for portfolio review:

I would love to hear also what works for you – let’s get in touch!
Additional reading
Scaled Agile Lean Portfolio Management – Strategic portfolio review practice as a reference!
-
From Project Portfolios to Product Portfolios – Focus on Development Outcomes


Strategic development portfolios include often the development of new products and services and the introduction of new offerings to the markets. Traditionally projects have been widely used in new product development, to ensure systematical development process and quality. Today, also agile development practices have become common – instead of focusing on project gates, the focus is on development outcomes – products, services, and sellable offerings.
Do you manage product portfolio, offering portfolio or both?
Product development teams are introducing new products, features, and functionalities via regular product releases – there may be physical hardware components, software, and services included. The product portfolio is also linked to product life cycle management – new products are introduced, further developed, and old ones are retired. In parallel to product portfolio, business teams are also looking into offering viewpoint – how to price, sell, package, and servitize customer offerings.
Definition of products, services, solutions and offering differs from company to company. However, there may be need to manage these different viewpoints:
- Product roadmap – new product releases, hardware, software and service development, dependencies between development entities, enabling product deliveries via the supply chains and service operations
- Offering roadmap – sellable offering towards different customer segments, which may be bundles of physical product features and services combined with new pricing and business models
Sometimes these viewpoints may be the same, but often both are needed in parallel. Even the best product will not be a success without good commercialization work and the other way around – even though the business model would be perfect for the new offering, if the physical product does not meet customer requirements, the offering will never be successful.
In large global companies, offering may also vary significantly from geographical area to another, from country organization to another. Furthermore, the needs for offering development may vary from area to another, and also when planning and prioritizing new offering and product development, different types of roadmap views may be needed.

Linking development portfolio closely to development outcomes – products and services and offering New product development portfolio management
In the context of scientific literature, new product portfolio management is its own field of study. Cooper et al. (2002) define new product development (NPD) portfolio management with similar terms as portfolio management is typically defined:
Portfolio management is a dynamic decision process, whereby a business’s list of active new product (and R&D) projects is constantly updated and revised. In this process, new projects are evaluated, selected, and prioritized; existing projects may be accelerated, killed, or de-prioritized; and resources are allocated and reallocated to the active projects.
Good practices for product portfolio management
I will list key things, which I learned are really important, when managing development portfolio including new products and services – I hope these are useful for you:
- Build roadmaps together – building a roadmap is a joint effort between business and product development teams. Even though part of the content may be confidential or secret, sharing roadmaps with the key stakeholders is really important to create alignment.
- Evaluate commercial value early and do not be afraid to kill or rethink ideas. Sometimes it is difficult to make a killing decision, but this is part of good portfolio management. Service design can provide great tools to understand customer needs better.
- Regular prioritization – review and prioritize your product development portfolio regularly. Monthly or quarterly cycles work well in many organizations. Make bold prioritization decisions – if you try to do too many things at the same time, expert resources may be too thinly spread around impacting negatively your portfolio success.
- Create transparency via demos and regular communication – show your achievements and share progress with your stakeholders, and leadership – and receive feedback!
- Remember quality checks – even though development would happen via agile product development and project quality gates are no longer applied, ensure certain quality checks are done systematically across all products in the portfolio and quality checks are inbuilt into your process.
- Focus also on offering development and commercialization – even the best product will not be successful without good business model. Experiment and learn what works – for example growth hacking has great tools for this part!
- Don’t forget deployment! If you are introducing completely new types of products or services with new business models, significant process and tooling development, as well as training and change management effort are needed. If you are introducing incremental changes to existing products, remember still the importance of great communications materials to make best out of your product releases or launches!

Good practices for product portfolio management – 7 areas to focus on Additional reading
Cooper, Edgett, Kleinchmidt: Portfolio management for new product development: Results of and industry practice study, December 2002, R& D Management 31(4):361 – 380
Jarno Vähäniitty’s doctoral thesis from 2012 was focusing on agile product and portfolio management. Literature review and results provide good insights:
Jarno Vähäniitty: Towards agile product and portfolio management, 2012, Aalto University publication series DOCTORAL DISSERTATIONS, 15/2012
Extra tip for additional learning: Explore and Exploit portfolios from Strategyzer – The Invincible Company

Check out also Strategyzer – The Invincible Company Explore and Exploit portfolios! I will later come up with a post focusing more on literature related to new product development portfolio management and one of my favorite topics – servitization and developing complex hardware-software-service systems!
Check out also the latest blog posts!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again. -
Portfolio management – 5 to-do’s before tool implementation!
There are great tools to support strategic portfolio management in the markets with advanced portfolio management and visualization capabilities. Portfolio management tool helps to create transparency across organization – business and technology units, finance, and support functions. When development work is needed from many organization units, such as different business teams and functions, IT and R&D and external vendors, managing the big picture via clear roadmaps helps a lot. Furthermore, having a common tool for managing portfolio finances supports financial planning and helps to create visibility on costs and benefits.
However, tool alone does not solve everything, and there are few things to look into before actually starting tool implementation. Here are couple of key learnings what to do from the buyer organization viewpoint, before kick starting actual tool development!
Have a look! If you have other tips to add, I would love to hear from you!

Portfolio management tool – 5 to-do’s before tool implementation 1. Start with the process!
Before initiating your tooling project, it is good to go through your key process steps. Here is a simple checklist:
- Do you have a common process defined for your portfolio or across organization? Process can (and should) be simple, but it is needed to setup the tool for you.
- What are the phases and gates for your projects – do you have one model or several?
- Do you have agile work or continuous development – do they follow for example portfolio kanban process?
- If you have an existing process, what is the feedback from the practitioners? Can you simplify your process? Are all project gates still actively used?
- Do you have a defined portfolio structures (e.g. portfolios, sub portfolios, programs or other strategic structures)? If not, it is good to check the needs with different portfolios. This step may require some iterations, if tool has not previously been used.
- What are your financial portfolio cycles, e.g. yearly, quarterly or monthly? How do you want to follow up financials?
Note! Even though it is important to work on process, one should not get stuck with process definition details – basic definition is enough, and details should be also checked while implementing the tool, as each tool has some unique features – sometimes also impacting process.
2. Understand complexity & portfolio structures – one portfolio or multiple portfolios with complex dependencies?
Complexity of portfolios varies a lot from company to another. Large corporations may need to manage many different types of portfolios or manage the same data from different viewpoints (see linked post Development portfolios in large companies – what is your viewpoint?).

Development portfolios in large companies – which portfolios are you focusing on? Thus, it is good to align on scope and structures at the beginning of the work! Here are couple of questions to look into:
- What is the scope of your portfolios to be implemented – do you include business and IT development, R&D, customer delivery portfolios, product portfolios, innovation portfolios etc.?
- Do you implement tool for a single portfolio or across the whole company? Do you need to look into enterprise view, too?
- If you manage a single project portfolio, a simple and cost-efficient tool works well. If you operate in a large corporation, where you have many portfolios and work is executed by many different units, more advanced features may be needed.
3. Define use cases & roles – what tool capabilities do you need?
Different tools have a huge variety of functionalities, and one gets easily overwhelmed by all the possibilities.
What tooling capabilities are you looking for?
As each of the tool capability requires also some deployment effort, good practice is to start with a prioritized set of capabilities – Minimum viable product. What are the key capabilities tool should support with?
On the other hand, when implementing the new tool, it is good to look into future needs as well, so that tool also has capabilities to support more extensive use. Typically, these capabilities could be more extensive integrations, product or application portfolio management, scenario planning, and more sophisticated functionalities related to strategic objectives. To give you some inspiration, you can use the below picture to prioritize and sequence your tool planning:

Typical portfolio management capabilities to plan tool implementation – what are your focus areas and what are the future capabilities tool should support with? Define user roles
Another important step during the planning phase is to define user roles – who would be actually using the tool – which roles would update the data and which roles would need transparency? Sometimes it may make sense to start with a small group of heavy users, e.g. introduce the tool for portfolio and project managers only, and then extend the use for a wider group of people. Here is the checklist:
- Define user roles for the tool (e.g. portfolio managers, program managers, project managers, finance controllers, line managers; owners, sponsor and leadership roles; how about team members for hourly reporting?)
- Think also about user groups, who would need transparency to portfolio roadmaps even though not actively editing the data (e.g. portfolio owners, business and technology leaders)
- Do not forget key user and admin roles!
- Good to do also a rough estimation of how many users would belong to different user groups – this may be helpful for the tool license discussions.
Define use cases
Based on the tooling capabilities and user roles, what are the use cases you would like to get started with? Few questions to think about:
- Define use cases – what are the important use cases you need to get started with?
- Identify also use cases, which might be useful for the future, but you do not need them right away (for example future needs to integrate the tool to other systems)
- Remember to get inputs also for technical things, like access management, configuration and tool maintenance from your IT partners
4. Check your data!
Before tooling implementation, it is good time to check what data you have. The approach is a bit different, if you are replacing an existing tool to a new one, when compared to a situation, where portfolio data may be in different excels and may lack common field definitions. Here are couple to things to consider:
- Where is your data? In an old tool or multiple tools, or in different places such as excel sheets? Or do you need to start by collecting the data into once place?
- Do you have similar data available across portfolio or across portfolios or does each portfolio have different data sets?
- Do you have relevant data gathered? This is a good time to see, if all current data fields are relevant and meaningful.
- Is your data up to date? This is a good time to update data, before new tool setup!
- Are you able to consolidate all available data to excel or other format for migration purposes?
- Are roles clear – who is responsible for portfolio data in each organization or portfolio? Tool will not help, if no-one is updating portfolio data.
Check out also other blog text related to Portfolio data – 5 tips from practitioners!
5. Draft your deployment approach
In addition to technical tool implementation, organizational change management, training and alignment plays a key role when implementing common tools across enterprise. You may want to avoid big bang type of deployment, if possible.
- Do you have pilot portfolios you would start with?
- Can you sequence other portfolios based on the interest and urgency?
- Which user groups and roles would need trainings?
- Would you create modular training materials or videos, which would be available also for new team members in the future?
- How about change management? If the way of working is changing, line managers may need strong support during the implementation phase.
Bonus tip – learn about tool concepts
There are plenty of great portfolio management tools full of interesting functionalities! Before you initiate your project, get familiar with the tool concepts, how they work and how they would support your needs. Tool data models may also bring really great possibilities for you to create transparency across organization or sometimes include some limitations. If possible, look for videos, demo to try the tool out or create a proof of concept!
Here are links to some of the portfolio management tools I have used or got familiar with:
Also for example JIRA has been used successfully to connect development work to portfolios.
If your favorite tool is missing for the list, I would be happy learn more and to add it here!
Check out also Gartner Strategic Portfolio Management reviews and rating!
-
From project portfolios to hybrid portfolios – combining projects and agile work


Hybrid development portfolio combining traditional projects and agile work Many companies have well established practices for managing project portfolios. Projects are followed up and governed based on the stage-gate model – and portfolio may include for example a collection of projects, programs, and other activities. There is an own standard for project portfolio management (PPM), which has been taken widely into use.
On the other hand, agile practices and continuous development teams have become more and more common. Popular Scaled agile framework (SAFe) has introduced a great set of practices for Lean portfolio management (LPM) – in SAFe development is organized via value streams and executed fully in agile mode.
However, most of the organizations are somewhere between – having still plenty of projects (often with agile execution), but also continuous development executed by the agile teams, continuous improvement or devops teams. Where is your organization now, somewhere in between? Where would you like to be in the future?

Scale from traditional project portfolios to hybrid portfolios combining projects and agile to lean portfolios – Where are you now, and where would you like to be in the future? Typical challenges for hybrid portfolios including projects and agile work
Managing a hybrid portfolio including projects and agile work is not completely straight forward – there are typically several challenges from the development portfolio view point:
- Transparency – project portfolio includes projects, but continuous development may lack visibility in terms of development roadmap, outputs, outcomes and benefit tracking
- Finance – Stage gate projects have gate approvals for financing decisions, where as agile teams have other means for prioritization and allocation of finances; also company budgeting and cycles may be sometimes conflicting with lean budgets and guardrails
- Governance – practices are quite different in traditional project steerings, when compared to quarterly practices many agile teams are committed to
- Ways of working – Different units within company may have different ways of working, e.g. some units have adopted agile ways of working, where as others are still working with project models – also project may need work from many continuous development teams
I will go through some practices, which have been helpful when managing hybrid portfolios:
Building MVP with a project and ramping up continuous development capabilities
When developing something completely new, for example a new IT solution or getting started with a new innovative product or service, there may not be a continuous development team available, who could take the lead on development. In these cases, it has been a good practice to build Minimum Viable Product (MVP) and capabilities to start continuous development during the project phase – project resourcing is helping, as it may take some time to define the concept, hire team members, select technology and make needed decisions. This works especially for hybrid portfolios, where both models are actively used.

Project may be a great way to develop Minimum Viable Product (MVP) for a new solution and ramp up continuous development capabilities Another case, where projects have been helpful are complex process or technology changes, where development is needed from many different teams and there is a lot of integrations or changes in business processes, and project may be combining business and technology development across different areas together. Also, if the people side of the change is significant, and the there is need for deployment within the units, rollout project with systematical change management approach may help a lot.
Creating transparency to continuous development
Even though continuous development teams prioritize content via backlogs or Kanban boards, there is a need to communicate towards a wider group of stakeholders what are the key themes or epics continuous development team is focusing on. This is especially important for teams serving many business units, to create trust and transparency. One option is to create high level transparency to continuous development roadmap also in the portfolio level – without going to too detailed level.

Creating transparency on continuous development roadmap in portfolio level – Epic term from Scaled agile framework may be useful Great Lean portfolio management practices for hybrid portfolios
Scaled agile (SAFe) includes an extensive framework of practices for lean portfolio management. Here are couple of practices, which I feel work very well even for hybrid portfolios, have a look!
- Portfolio vision & canvas
- Strategic themes
- Quarterly portfolio reviews
- Epics
- Measuring portfolio performance
- Forecast and budget dynamically
- Guardrails for financial decision making
- OKRs (see the previous post about OKRs for development portfolios)
If you have good tips to share for managing hybrid portfolios, I would love to hear from you!




