-
Finding Your North Star – Creating a Shared Long Term Vision
In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.
The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.
The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.
Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.
Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!
Let’s have a look at the steps to identify your North Star!
Steps to Identify Your North Star
1. Understand the purpose
Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?
This understanding forms the foundation for defining the North Star!
2. Identify long-term goals
Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.
3. How to measure?
To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.
Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.
4. Align with stakeholders
Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.
5. Iterate and refine
Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.
6. Communicate and share the North Star
Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.
Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.
North Star – examples from leading companies for inspiration
The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:
- Google: “Organize the world’s information and make it universally accessible and useful.”
- Tesla: “Accelerate the world’s transition to sustainable energy.”
- Airbnb: “Create a world where anyone can belong anywhere.”
- Spotify: “Unlock the potential of human creativity.”
- Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
- Netflix: “Delight our customers with great content anytime, anywhere.”
- Apple: “Design innovative products that enrich people’s lives.”
Conclusion
Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.
-
Finding Your North Star – Creating a Shared Long Term Vision
In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.
The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.
The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.
Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.
Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!
Let’s have a look at the steps to identify your North Star!
Steps to Identify Your North Star
1. Understand the purpose
Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?
This understanding forms the foundation for defining the North Star!
2. Identify long-term goals
Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.
3. How to measure?
To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.
Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.
4. Align with stakeholders
Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.
5. Iterate and refine
Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.
6. Communicate and share the North Star
Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.
Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.
North Star – examples from leading companies for inspiration
The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:
- Google: “Organize the world’s information and make it universally accessible and useful.”
- Tesla: “Accelerate the world’s transition to sustainable energy.”
- Airbnb: “Create a world where anyone can belong anywhere.”
- Spotify: “Unlock the potential of human creativity.”
- Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
- Netflix: “Delight our customers with great content anytime, anywhere.”
- Apple: “Design innovative products that enrich people’s lives.”
Conclusion
Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.
-
How Is M&A Impacting Your Development Portfolio?
Strategic portfolios are looking into opportunities related to Mergers and Acquisitions (M&A). Big Mergers & Acquisitions may have significant impacts on development portfolios – even redoing the development plans totally. M&As tend to come as a surprise, as there are strict regulations on how to handle such sensitive information. Let’s review some of the common M&A scenarios from the development portfolio view point.
Scenario 1: Merging two large companies
This is a really big deal! Merging two big companies has huge impacts on development portfolio plans and structure, data, and tools, organization, ways of working, and even company culture. Also completing the merge may take even several years, if there is a lot of overlap.
Here are a few things to consider from a development portfolio viewpoint:
- Uniting development portfolios over time, or keeping separate portfolios?
- Keeping different brands or uniting the brands?
- Selecting which product lines to continue, and which should be ramped down over time – not an easy task, especially, if some of the product lines are overlapping.
- Are customers and customer segments overlapping, or creating synergies – are there new opportunities to create end-to-end value towards customers? How about business models and way to sell towards customers?
- Business processes and operating model – area with endless opportunities, but also a lot of complexity due to differences in the businesses.
- Finding synergies from IT tools, migrating data, ramping down parallel systems, and integrating systems and processes. Big companies may have thousands of applications, and even this IT stream may be a really big thing!
- Ways of working – a significant change management and training may be required, if companies have different ways of working, for example the use of lean and agile vs. traditional ways of working.
Scenario 2: Merging a smaller company
A common scenario familiar to many – a bigger company buys a smaller company to acquire new products or services, technology, or other capabilities.
Here are a few things to consider from the development portfolio viewpoint:
- M&A is often a must-to-do – do we need to change priorities in our development plan to support M&A activities?
- Are there overlapping products, services, and offerings?
- How closely should the smaller company be integrated? If there is a strong company way operating model, deployment of the common processes, tools, and way of working may require a lot of effort for example from IT units, but also from the business process view point.
- There may be a need to rollout also corporate ICT and core solutions, such as ERP and CRM for the unit.
- Building a roadmap for all needed changes may be required.
- Will the newly purchased business unit have its an own development portfolio, or will development be part of one of the existing portfolios?
Scenario 3: Integrating a new unit fully into the main business
This scenario may happen years after the original M&A. Business has grown, and opportunities to bring the acquired business unit closer to volume businesses may require full integration of operating model, ways of working, and also different systems and tools.
Topics to consider:
- Requires full integration of organization, processes, ICT, and IT solutions, as well as products, services, and offerings – maybe even a dedicated transformation program to ensure smooth change management.
- Merging also development portfolios together, and aligning ways of working and priorities.
- How to keep the strengths of the unit to be integrated, while also getting the benefits of closer integration? Should something change also in the main businesses?
Scenario 4: Buying a promising start-up
Buying a start-up is a great way to get new competencies to the company. Often also start-up strength is the agility and possibility to pivot different types of opportunities quickly, whereas established companies have their scalable processes and ways of working.
Things to consider for development portfolios:
- What is the end goal for the start-up – integrating into the main company and scaling the offerings, or continuing as a start-up within a corporation?
- If the start-up approach is selected, the start-up may continue to manage development portfolios as previously, with strategic alignment on corporate development portfolios. There may be a conflicts between the cultures, and ways of working.
- In a long run, when scaling up is required, there may be a need to integrate the start-up closer to the corporation and also merge development portfolios.
Scenario 5: Carve out of existing business
This is also a rather common scenario – part of the business no longer fits well to company strategic targets, and there is another company, which is looking for such a business opportunity! Optimally, this is a win-win situation for all parties!
When one of the business units or parts of the business is sold out, there are impacts on the development side too.
- Organization – a big change for the people impacted!
- Data, ICT & IT systems – the transition of all IT to the buyer and cleaning up also the data from the corporate systems – may be a big and complex effort.
- Is the change impacting also development portfolio priorities?
This is again one of those areas, where I would love to learn more! If you have good learnings to share, I love to catch up!
-
How Is M&A Impacting Your Development Portfolio?
Strategic portfolios are looking into opportunities related to Mergers and Acquisitions (M&A). Big Mergers & Acquisitions may have significant impacts on development portfolios – even redoing the development plans totally. M&As tend to come as a surprise, as there are strict regulations on how to handle such sensitive information. Let’s review some of the common M&A scenarios from the development portfolio view point.
Scenario 1: Merging two large companies
This is a really big deal! Merging two big companies has huge impacts on development portfolio plans and structure, data, and tools, organization, ways of working, and even company culture. Also completing the merge may take even several years, if there is a lot of overlap.
Here are a few things to consider from a development portfolio viewpoint:
- Uniting development portfolios over time, or keeping separate portfolios?
- Keeping different brands or uniting the brands?
- Selecting which product lines to continue, and which should be ramped down over time – not an easy task, especially, if some of the product lines are overlapping.
- Are customers and customer segments overlapping, or creating synergies – are there new opportunities to create end-to-end value towards customers? How about business models and way to sell towards customers?
- Business processes and operating model – area with endless opportunities, but also a lot of complexity due to differences in the businesses.
- Finding synergies from IT tools, migrating data, ramping down parallel systems, and integrating systems and processes. Big companies may have thousands of applications, and even this IT stream may be a really big thing!
- Ways of working – a significant change management and training may be required, if companies have different ways of working, for example the use of lean and agile vs. traditional ways of working.
Scenario 2: Merging a smaller company
A common scenario familiar to many – a bigger company buys a smaller company to acquire new products or services, technology, or other capabilities.
Here are a few things to consider from the development portfolio viewpoint:
- M&A is often a must-to-do – do we need to change priorities in our development plan to support M&A activities?
- Are there overlapping products, services, and offerings?
- How closely should the smaller company be integrated? If there is a strong company way operating model, deployment of the common processes, tools, and way of working may require a lot of effort for example from IT units, but also from the business process view point.
- There may be a need to rollout also corporate ICT and core solutions, such as ERP and CRM for the unit.
- Building a roadmap for all needed changes may be required.
- Will the newly purchased business unit have its an own development portfolio, or will development be part of one of the existing portfolios?
Scenario 3: Integrating a new unit fully into the main business
This scenario may happen years after the original M&A. Business has grown, and opportunities to bring the acquired business unit closer to volume businesses may require full integration of operating model, ways of working, and also different systems and tools.
Topics to consider:
- Requires full integration of organization, processes, ICT, and IT solutions, as well as products, services, and offerings – maybe even a dedicated transformation program to ensure smooth change management.
- Merging also development portfolios together, and aligning ways of working and priorities.
- How to keep the strengths of the unit to be integrated, while also getting the benefits of closer integration? Should something change also in the main businesses?
Scenario 4: Buying a promising start-up
Buying a start-up is a great way to get new competencies to the company. Often also start-up strength is the agility and possibility to pivot different types of opportunities quickly, whereas established companies have their scalable processes and ways of working.
Things to consider for development portfolios:
- What is the end goal for the start-up – integrating into the main company and scaling the offerings, or continuing as a start-up within a corporation?
- If the start-up approach is selected, the start-up may continue to manage development portfolios as previously, with strategic alignment on corporate development portfolios. There may be a conflicts between the cultures, and ways of working.
- In a long run, when scaling up is required, there may be a need to integrate the start-up closer to the corporation and also merge development portfolios.
Scenario 5: Carve out of existing business
This is also a rather common scenario – part of the business no longer fits well to company strategic targets, and there is another company, which is looking for such a business opportunity! Optimally, this is a win-win situation for all parties!
When one of the business units or parts of the business is sold out, there are impacts on the development side too.
- Organization – a big change for the people impacted!
- Data, ICT & IT systems – the transition of all IT to the buyer and cleaning up also the data from the corporate systems – may be a big and complex effort.
- Is the change impacting also development portfolio priorities?
This is again one of those areas, where I would love to learn more! If you have good learnings to share, I love to catch up!
-
Golden Eggs Or Rotten Tomatoes – Managing Portfolio-level Risks
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!
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. -
Golden Eggs Or Rotten Tomatoes – Do You Manage Portfolio-level Risks?
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!
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. -
3 Steps To Improve Your Portfolio Roadmaps
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:
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:
Recommended reading
The Business of IT Blog: Outcomes vs Outputs: What’s the Difference?
-
3 Steps To Improve Your Portfolio Roadmaps
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:
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
Scaled Agile Framework – Roadmaps -
Principles of Good Portfolio Governance
Development portfolio governance is one of the areas, which might cause headache in in many organizations. I wanted to have a look at the what standards say about the good governance, and reviewed briefly ISO 37000 – Governance of organizations standard focusing on governance principles. The standard may be applied for any type of organizations, and I think the guiding principles are also good food four thought for portfolio governance.
Primary governance principle – Purpose
Primary governance principle in ISO 37000 is the Purpose – there needs to be a clear purpose why organization exists and the same applies also for development portfolios. What is the purpose of the portfolio? What is the reason of existence from different perspectives?
Clear purpose statement defines, specifies and communicates the value the portfolio intends to generate for specified stakeholders. Clear purpose is really important: to be able to communicate the purpose & WHY portfolio exists.
Supporting questions:
- Have you defined a purpose for your development portfolio?
- Have you communicated about the purpose with different stakeholder groups?
4 Foundational Principles – Value Generation, Strategy, Accountability and Oversight
Next, standard defines 4 Foundational Principles. Let’s look into those, too.
Value Model – the elements comprising value creation and value generation which are required to fulfil purpose. Value generation model provides basis for innovation and also for collaboration with the stakeholders.
Supporting questions:
- What value is the development [portfolio] creating to customers, business, organization, and even in a wider context to other stakeholders?
Strategic development portfolios should be by definition, strategy driven. One of the foundational principles for governance is Strategy – engaging strategies in accordance with the value model.
Supporting question:
- Is your portfolio strategy driven or loosely linked to strategic goals?
- What does the company strategy mean in practice for your development portfolio?
Accountability – Accountability engenders trust and legitimacy, which leads to improved outcomes. Those responsible for managing the portfolio must be held accountable for their actions and decisions. This includes ensuring that there are clear lines of responsibility and authority, as well as systems for monitoring and evaluating performance.
Supporting question:
- Are the roles defined clearly for your portfolio, so that accountable members know their responsibilities?
- Do you systematically create transparency across the stakeholders on your development portfolio progress and plans?
- Do you actively engage stakeholders?
- Do you collect feedback and improve ways of working systematically?
The Fourth Foundational Principle Oversight is important to ensure the governance is appropriately designed and operating as needed. This principle is overseeing portfolio performance and enduring portfolio is fulfilling the expectations. As a good practice, there is an internal control system implemented for oversight.
Supporting questions:
- Do you have a definition for your portfolio governance model available for different stakeholders?
- Are the stakeholders aware of your governance model?
- Are you following up, that governance model is used in practice? What happens, if there is an exception?
- Do you have clearly defined guardrails for financial decision making and internal control system it is followed?
6 Enabling Governance Principles
ISO 37000 standard includes also 6 Enabling Governance principles: Stakeholder engagement, Leadership, Data and decisions, Risk Governance, and Social Responsibility. I will review also these in the context of development portfolios!
Stakeholder engagement – Member, reference, and relevant stakeholder engagement are key. Transparency is a key element of effective governance, and stakeholders must have access to information about the organization’s goals, strategies, and performance.
Supporting questions:
- Who are your development portfolio key stakeholders?
- How do you engage with the different stakeholder groups?
- Do you create transparency on development portfolio plans, progress and outcomes?
- Are you meeting the expectations of different stakeholder groups?
Leadership – The governing body should lead by example to create a positive values-based culture, set the tone for others, and engender trust and mutual cooperation with the organization’s stakeholders. Effective governance requires strong leadership, with clear roles and responsibilities defined for all stakeholders involved.
Supporting questions:
- Are you leading by example?
- Is the portfolio decision making ethical?
- Is the portfolio decision making efficient?
- Are you creating an positive environment, building trust and good cooperation with the stakeholders?
- Are you following company leadership principles also in the context of the development portfolio?
Data and decisions – The governing body should ensure that the organization identifies, manages, monitors and communicates the nature and extent of its use of data.
Supporting questions:
- Is your portfolio data up-to-date, e.g. the project schedules, approved budgets and business cases?
- Do you use actively data in the portfolio decision making?
- Do you maintain presentation materials and meeting minutes for the portfolio governance body?
One of the goals of portfolio management it to maximize the portfolio value – this also requires taking some risks. Governance is not just about compliance. It is about managing risk in a way that ensures the long-term success of the organization.
Risk governance – Value is generated when appropriate risk is taken, transferred or shared in a timely manner. This happens when the governing body balances risk effectively.
Supporting questions:
- Are you reviewing portfolio risks regularly?
- Do you have clear practices, for mitigating risks and reporting risks?
- Are you balancing the risks?
The guidance explains what good governance looks like across eleven mission critical topics:
Social responsibility – The organization should proactively contribute to sustainable development by generating value in a manner that meets the needs of the present without compromising the ability of future generations to meet their own needs.
Supporting questions:
- Are the decisions made ethical and considering also the social responsibility?
Viability and performance over time – portfolio should ensure viability over the time without compromising current and future generations.
Supporting questions:
- Are the decision made today enabling also the future success?
- Is portfolio balanced across time horizons?
By following these principles, development portfolios can enhance decision-making processes, manage risk more effectively, and achieve long-term success.
References
-
Principles of Good Portfolio Governance
Development portfolio governance is one of the areas, which might cause headache in in many organizations. I wanted to have a look at the what standards say about the good governance, and reviewed briefly ISO 37000 – Governance of organizations standard focusing on governance principles. The standard may be applied for any type of organizations, and I think the guiding principles are also good food four thought for portfolio governance.
Primary governance principle – Purpose
Primary governance principle in ISO 37000 is the Purpose – there needs to be a clear purpose why organization exists and the same applies also for development portfolios. What is the purpose of the portfolio? What is the reason of existence from different perspectives?
Clear purpose statement defines, specifies and communicates the value the portfolio intends to generate for specified stakeholders. Clear purpose is really important: to be able to communicate the purpose & WHY portfolio exists.
Supporting questions:
- Have you defined a purpose for your development portfolio?
- Have you communicated about the purpose with different stakeholder groups?
4 Foundational Principles – Value Generation, Strategy, Accountability and Oversight
Next, standard defines 4 Foundational Principles. Let’s look into those, too.
Value Model – the elements comprising value creation and value generation which are required to fulfil purpose. Value generation model provides basis for innovation and also for collaboration with the stakeholders.
Supporting questions:
- What value is the development portfolio creating to customers, business, organization, and even in a wider context to other stakeholders?
Strategic development portfolios should be by definition, strategy driven. One of the foundational principles for governance is Strategy – engaging strategies in accordance with the value model.
Supporting question:
- Is your portfolio strategy driven?
- What does the company strategy mean in practice for your development portfolio?
Accountability – Accountability engenders trust and legitimacy, which leads to improved outcomes. Those responsible for managing the portfolio must be held accountable for their actions and decisions. This includes ensuring that there are clear lines of responsibility and authority, as well as systems for monitoring and evaluating performance.
Supporting question:
- Are the roles defined clearly for your portfolio, so that accountable members know their responsibilities?
- Do you systematically create transparency across the stakeholders on your development portfolio progress and plans?
- Do you actively engage stakeholders?
- Do you collect feedback and improve ways of working systematically?
The Fourth Foundational Principle Oversight is important to ensure the governance is appropriately designed and operating as needed. This principle is overseeing portfolio performance and enduring portfolio is fulfilling the expectations. As a good practice, there is an internal control system implemented for oversight.
Supporting questions:
- Do you have a definition for your portfolio governance model available for different stakeholders?
- Are the stakeholders aware of your governance model?
- Are you following up, that governance model is used in practice? What happens, if there is an exception?
- Do you have clearly defined guardrails for financial decision making and internal control system it is followed?
6 Enabling Governance Principles
ISO 37000 standard includes also 6 Enabling Governance principles: Stakeholder engagement, Leadership, Data and decisions, Risk Governance, and Social Responsibility. I will review also these in the context of development portfolios!
Stakeholder engagement – Member, reference, and relevant stakeholder engagement are key. Transparency is a key element of effective governance, and stakeholders must have access to information about the organization’s goals, strategies, and performance.
Supporting questions:
- Who are your development portfolio key stakeholders?
- How do you engage with the different stakeholder groups?
- Do you create transparency on development portfolio plans, progress and outcomes?
- Are you meeting the expectations of different stakeholder groups?
Leadership – The governing body should lead by example to create a positive values-based culture, set the tone for others, and engender trust and mutual cooperation with the organization’s stakeholders. Effective governance requires strong leadership, with clear roles and responsibilities defined for all stakeholders involved.
Supporting questions:
- Are you leading by example?
- Is the portfolio decision making ethical?
- Is the portfolio decision making efficient?
- Are you creating an positive environment, building trust and good cooperation with the stakeholders?
- Are you following company leadership principles also in the context of the development portfolio?
Data and decisions – The governing body should ensure that the organization identifies, manages, monitors and communicates the nature and extent of its use of data.
Supporting questions:
- Is your portfolio data up-to-date, e.g. the project schedules, approved budgets and business cases?
- Do you use actively data in the portfolio decision making?
- Do you maintain presentation materials and meeting minutes for the portfolio governance body?
One of the goals of portfolio management it to maximize the portfolio value – this also requires taking some risks. Governance is not just about compliance. It is about managing risk in a way that ensures the long-term success of the organization.
Risk governance – Value is generated when appropriate risk is taken, transferred or shared in a timely manner. This happens when the governing body balances risk effectively.
Supporting questions:
- Are you reviewing portfolio risks regularly?
- Do you have clear practices, for mitigating risks and reporting risks?
- Are you balancing the risks?
The guidance explains what good governance looks like across eleven mission critical topics:
Social responsibility – The organization should proactively contribute to sustainable development by generating value in a manner that meets the needs of the present without compromising the ability of future generations to meet their own needs.
Supporting questions:
- Are the decisions made ethical and considering also the social responsibility?
Viability and performance over time – portfolio should ensure viability over the time without compromising current and future generations.
Supporting questions:
- Are the decision made today enabling also the future success?
- Is portfolio balanced across time horizons?
By following these principles, developmen portfolios can enhance decision-making processes, manage risk more effectively, and achieve long-term success.
References
Strategic Portfolio Management
Taking strategy into action via development portfolios – sharing best practices via a blog
Strategic Portfolio Management 