-
10 Ways How Business Agility Transforms Strategic Development Portfolios
Business agility refers to an organization’s ability to quickly and effectively respond to changes in the business environment – by being agile, organizations can adapt to change more effectively, capitalize on opportunities, and stay resilient in the face of disruptions.
Technology organizations have been working with agile methodologies for quite some time, but what does business agility mean in the context of strategic development portfolios?
1. Adapting to change
Adaptability to changes is an important benefit of business agility for development portfolios. Organization needs the capacity to anticipate and respond to market changes, customer needs, as well as emerging trends. An agile business is proactive in identifying opportunities and is willing to adjust its products, services, or operations accordingly.
Development portfolios can respond to changing priorities, market demands, and customer needs by adjusting the project portfolio content, timelines, and resourcing. If portfolio plans are fixed during the long range planning or yearly budgeting, it may be difficult to adapt to the change. One of the good practices I would recommend is portfolio reviews, see more via previous blog post: Time for a quarterly review?
2. Faster time to market
Agile approaches emphasize iterative development and frequent releases. By breaking projects and other initiatives into smaller, manageable chunks and delivering incremental value, agile enables faster time to market, allowing organization to seize market opportunities and gain a competitive edge.
So how to speed up development and go-to-market from the development portfolio view point?
- Developing minimum viable product – being brave with prioritization of the content
- Breaking down big initiatives into smaller, faster to implement work packages
- Ensure smooth decision making – lean but powerful governance is blessing for the whole organization
- Make go-to-market process fast and smooth – and Don’t forget the deployment!
3. Customer co-creation
Agile methodologies prioritize customer collaboration and feedback. By involving customers early and continuously throughout the development process, development portfolios can ensure that the delivered products or features align with customer expectations, resulting in higher customer satisfaction and loyalty.
Hearing the needs and feedback from the customers (or internal customers) is super important driver – and also reduces the risks of developing something, which is not actually valued by the customers and end-users. We may think we know what customers want and need, but do we really know if we don’t ask or validate the idea?
Customer engagement should be built into the development portfolio processes:
- Do you co-create development concepts with customers? Do you validate the concepts with customers?
- Do you have pilot customers to receive early feedback? Do you also have time to develop the solution based on the feedbacks?
- Do you continuously collect feedback from the customers related to your products and services? Do you have a systematical process to analyze the feedbacks and take action?
Service design and growth hacking methods provide great support in this area!
4. Transparency
Agile methodologies promote transparency and visibility through practices like sprint reviews and demos. This enables stakeholders to have a clear view of project or team progress, impediments, and upcoming deliverables.
In the portfolio level creating transparency on agile team outcomes is also important – this may sometimes be a bit tricky, if the development portfolio has been mainly focusing on project portfolio view only. More ideas related to how to combine projects and agile available via the previous blog post: From project portfolios to hybrid portfolios – combining projects and agile work.
In the portfolio level, here are few topics to consider, when working with agile teams:
- How much are we funding different agile teams?
- Would there be a need to scale team capacity up or down in the future?
- What does the high level roadmap look like for the agile team?
- What are the key priorities and outcomes from each team for the next quarter?
- How are different teams creating transparency across the organization for the great content delivered and also receiving the feedback (e.g. demos)?
5. Incremental benefit realization
One of the great benefits of agile approaches is delivery of smaller working products and solutions, which already enable benefit realization.
When compared to traditional waterfall development approaches with big-bang go-live, agile approaches may enable benefit realization for key parts of the delivery even years earlier. Over the time, this really adds up! If you have a massive transformation program with waterfall delivery, could you break down large entities to smaller incremental deliveries? This may not be always easy, but also reduces the risks of big-bang go-lives!
6. Reducing risk by learning fast
Agile embraces an iterative and incremental approach, allowing for early identification and mitigation of risks. By experimentation and feedback loop, it is possible to learn faster, and reduce the risks.
By regularly assessing and adapting development plans and priorities, development portfolios can address potential issues proactively, minimizing risks and maximizing project success.
- Do you regularly discuss about the risks and also plan how to mitigate the risks?
- Is it ok to kill a initiative in your organization, if you see, it is not commercially or technically fit for purpose?
- Do you have experimentation culture to learn fast?
7. Collaboration – cross functional teams empowered with decision making
Promoting a culture of collaboration and cross-functional teamwork is crucial for business agility. This involves breaking down silos, fostering effective communication, and encouraging employees to share ideas and work together towards common goals.
By empowering teams to make decisions, collaborate closely, and take ownership of their work, development portfolios can foster a culture of innovation, creativity, and high performance. Here are few topics to consider:
- Do you have truly cross functional teams?
- Do you have clear guardrails for the team decision making?
- What can be decided in the team level and which topics are decided in the portfolio level?
8. Continuous improvement
Embracing a mindset of continuous learning and improvement is fundamental to business agility. Agile organizations encourage experimentation, embrace failure as a learning opportunity, and constantly seek ways to enhance their processes, products, and services.
Agile promotes a culture of continuous learning and improvement. Development portfolios can regularly reflect on their processes, gather feedback, and implement changes to enhance efficiency, quality, and overall project outcomes.
- Do you have feedback loops inbuilt for different development activities to collect the feedback, learn and improve?
- Do you systematically collect and analyze development ideas and have capacity also for continuous improvement activities?
9. Resource utilization & prioritization
Agile methodologies emphasize prioritization, allowing development portfolios to focus on high-value initiatives and allocate resources accordingly. By optimizing resource utilization and reducing unnecessary work, Agile helps maximize productivity and ROI.
In practice, this also requires clear prioritization work in the portfolio level – which helps to create clarity and focus. More about the different prioritization methods for portfolios in a previous post: The Biggest Challenge For Development Portfolios is … Prioritization.
10. Employee engagement
Improved Employee Engagement and Satisfaction – agile methodologies empower team members, promote collaboration, and value individuals and interactions. This leads to increased employee engagement, job satisfaction, and retention within development portfolios.
This topic would require an own blog post in the future…
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. -
5 ways to improve go-to-market of new offering
Previous blog post was focusing on important of deployment and people side of the changes (Don’t Forget Deployment!). Strategic development portfolios include also often development of new offerings, products, and services. How about the deployment of a new offering? What kind of approaches may work there?
It has been fun to work again more with offering development! One of the key topics for offering development teams is to ensure a successful go-to-market for the new offering. This is actually quite tricky – how to ensure busy sales teams get familiar with the new offering and feel comfortable and motivated to sell – especially if the new offering is outside the comfort zone of the sales force.
I have been working with many different types of offerings, some with complex hardware solutions, and some other purely service based. I will share 5 ways which I have seen have been useful, I hope this is helpful!
1. Offering catalog & news letters
When the offering is standardized, and familiar to organization and there are only small changes to way of working, well maintained offering catalog and news letter may work well to keep organization up-to-date.
An electronic version of the offering catalog works best, and with large offerings, there should be great searching functionalities to find easily what is needed.
Newsletter could include the following highlights:
- What is new? And where to find additional information?
- Pricing guideline updates
- Sharing value proposition for new offering
- Sharing learnings and tips related to sales of new offering
- If there are any actions to be taken locally
- Targets for sales
The challenge with the news letters in large organization is how to reach the correct people and to ensure busy sales and offering management personnel have time to actually learn what is new.
2. Community of practice
Communities of practice are one of the great approaches to keep the stakeholders engaged with the development, share learnings and feedbacks from the markets. Communities of practice are great for new growing areas, where content is further developing, and there are rapid cycles for learnings, but also for mature areas. Participants may join to community of practice from many different locations around the globe virtually to meet people with similar role and interest in other locations.
Optimally communities are not only information-sharing channels to introduce new changes, but also a forum to share learnings peer-to-peer and get expert advice as needed. A common platform or channel for discussion may be helpful especially when working with geographically distributed teams, to bring people together. Asking and commenting should be easy, and there should be also experts to find the answers even to tricky questions! Communities of practice are also great for onboarding new team members – it is great to be able to ask from other more experienced colleagues.
There may be for example community calls, to gather together to share best practices and discuss timely topics. Planning the content and facilitating for the community requires always some work, but is often worth the trouble!
Community of practice approach works well also for digital services, where there may be frequent releases happening bringing small changes.
3. Offering release
The third approach, which can be also combined with the first and second approaches is to consolidate all new offerings into offering releases. The frequency of offering releases may vary, and could be held quarterly, bi-annually, or annually, depending on the need and organization’s ability to absorb new offerings.
The benefit of offering releases and dedicated info sessions is to bundle offering changes together so that it is easier to get information on all new things at the same go. Release package may include for example training package, which can be used also for local trainings, as well as new beautiful marketing materials, as well as needed technical documentation.
4. Offering Launch
We have all seen beautiful offering launch events from different companies, e.g. Apple or Tesla. Offering Launches are great for public relations and to create excitement among the customers, but may be also a powerful tool to create excitement within customers, and media, but also among the own organization. Offering launches are also great kickstarts for marketing campaigns.
Offering launch alone is not enough, though! When introducing a completely new type of offering, rollout projects may be needed, too.
5. Rollout project
When introducing completely new type of offering to markets, there may be a need to develop many different capability areas within organization. Setting up a rollout project to ensure good training, change management, go-to-market, sales and operations may be a good choice, when:
- Significant changes for local roles, e.g. new activities needed for sales roles, customer service or operations roles
- New supply chains built to support completely new type of offering
- Organization requires extensive training to sell, install, maintain or service new offering
- New IT tools are needed for example to support sales and operations
- New pricing model, new business model configurations or
- New Go-to-market approach is introduced
- Local legal requirements, or area specific standards
Within rollout projects; this was covered in the previous post (Don’t Forget Deployment!).
-
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?
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?
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
Strategic Portfolio Management
Taking strategy into action via development portfolios – sharing best practices via a blog
Strategic Portfolio Management 