-
Focus on Value!
One of the key portfolio management goals is to maximize the value of the development portfolio – I reviewed some methods to achieve this during my previous post (See 4 Goals of Portfolio Management). After this post, I have had great discussions about maximizing value. Again, this is a tricky topic, and I share some of my learnings while studying this a bit.
Let’s look into value creation from a strategic initiative viewpoint, taking step by step approach.
Step 1: Identify The Value
One of the great articles I would recommend for you is Deloitte’s Linking Strategy to Value Published in Journal Of Business Strategy 2012, if you are not yet familiar with the thinking. The article introduces a a clear framework to map Shareholder value, but also liking Strategic Vision, Objectives and Initiatives to value created.
The article provides also model to map strategic initiatives to business capabilities, enabling IT capabilities, applications, technology and to organization. I think this approach may be helpful for example for IT organizations struggling to connect enabling IT development to strategy.
Strategic initiatives may create different type of value for different stakeholder groups, and not everything can be easily measured with financial numbers. The traditional approach is to look into increased business profits or decreased costs – what is the financial value of the initiative? This is important – development should create tangible benefits. However, there may be also other type of value, not only ‘hard financial numbers’.
How is the value created?
It is not always easy to describe the value created from complex initiatives. Here are a few questions to ask, if you struggle with defining the value of your development initiative:
- Are you solving customer challenges? Creating financial value to customers?
- Are you exploration of new ideas and opportunities? Investing into future horizons? Learning and exploring new customer opportunities, markets or segments? Learning about the new markets and opportunities is valuable as such, even though you would not yet have a perfect business case.
- Are you moving towards long term vision & strategic goals? Building future competitiveness step by step?
- Are you providing better service towards customers? Keeping existing customers or being able to sell more towards current customer base?
- What is the value created towards different customer groups? Can you validate your value propositions with customers?
- Are you enabling other strategic initiatives?
- Increased quality of products or services? Enabling needed quality certification?
- Leaning or automating business processes? Increasing productivity with improvements?
- Reducing or mitigating risks? Enabling business continuity within x years time frame?
TIP! In my previous role, Development Management Office team had gamified the the definition of soft benefits – I think this is a really important topic to look into and also spend some time to think about.
Step 2: Prioritize development within initiative! What is your Minimum Viable Product (MVP)?
Next, once we have identified how our initiative is creating value, it is also good to look into the scope of the development, too. Within your initiative, what is creating value to the customers, end-users and other shareholders? I am a firm believer of developing first Minimum Viable Product (MVP) – a working solution, with just a bare minimum of functionalities.
Look critically also into you development initiative scope – is everything needed to create the value?
- What is the absolute minimum, to create value to customers and end-users? Think about the scope from the customer or end-user use cases or process view point.
- What you need at the beginning, what could be developed in the next releases? Do you have DLs to meet for example based on the yearly clock?
- Don’t build something someone might need some day, perhaps. Be brave with prioritization, simple is beautiful!
Step 3: Deliver Value Incrementally
One of the typical challenges with large transformation programs is the long development time, followed by sometimes even longer deployment phases, resulting in a delay in creating value and delivering benefits. A risk with large and lengthy development programs is, that business, environment, and customer needs change over time, and finally, when going live, the solution built with great effort is already somewhat outdated.
One of the great approaches is to break down large initiatives into smaller pieces, which are easier to manage and start to receive benefits incrementally. Sometimes this requires also a bit of creativity. Here are few questions to consider:
- Can you break down the large entity into meaningful smaller pieces? Can you find quick wins?
- Can you test your concept with customers with a light back-end or even with manual processes?
- Can you you start your ERP transformation/large initiative with the green field units to start to get benefits, and then move to more complex existing units?
- Can you develop a long end-to-end business process piece by piece and start to get the befits for the first parts as soon as possible?
- Can you lean the existing business process before starting the IT renewal?
- Can you prioritize the work based on the urgency of the solutions, if you have critical timelines? Are there solutions, which could be implemented later?
For large transformation programs, there is a huge difference, if we start to receive value incrementally already at the early phases of the program, when compared to big bang approaches.
Step 4: Communicate about the value!
One of the areas, I admit I would need to focus more on, is to communicate about the value. WHY is this important? What is the value towards different stakeholder groups? What is the value towards customers?
This is so important for motivation. Many different stakeholder groups need to work hard to develop and deploy the new development initiative, and they have tons of other priorities, too. When we all understand the value, we are also more willing to give our full support! Here are few topics to consider:
- Communicating the value towards development teams – we all get motivated when we understand why!
- What is the value for different stakeholder groups?
- Creating crisp marketing materials for new offerings to communicate about the value propositions
- Creating great materials to support change management when deploying new solutions
To be able to communicate the value clearly requires typically a lot of hard thinking and also several iterations with the different stakeholders. If you struggle to communicate about the value, you might need to iterate with the step 1.
Step 5: Remember to measure!
Measuring the created value is often a really difficult topic, and requires also often several iterations to find the best approaches. How can we measure the value?
- Objectives and key results (OKRs) are great tool for development initiatives, as the measurement of key results is in built into the model. You can read more about OKRs via a dedicated blog post!
- If you are introducing a new offering, can you setup a simple dashboard to see the sales ramp up? Can you measure the profitability of your first pilot cases? Can you get measurable the value towards customers?
- Key Performance Indicators (KPIs) are a common approach to measure progress. In addition to lagging indicators looking into past progress, are you able to define and follow up on leading indicators – looking to future outcomes?
- There are also tons of super good resources for product management KPIs. If you are developing new products or services, select the best ones fitting your area.
- Follow up on your business case – how is the benefit realization progressing? One of the portfolio management tasks is to follow up on benefit realization, and value created, even after the project team might have moved to new projects.
This topic would deserve an own dedicated blog!
References
Eugene G. Lukac and Don Frazier. Deloitte: Linking Strategy to Value, Published in Journal of Business Strategy, Vol. 33 Issue: 4, pp.49-57 (2012). https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Strategy/2012_linking_strategy_to_value_deloitte_ireland.pdf
Interested to learn more about Strategic Portfolio Management?
-
Finding The Balance – Centralized vs. Decentralized Portfolio Management
The role of portfolio management differs a lot based on how development is organized within the company. If development funding is centrally managed, the role of portfolio management is to drive decision-making. If development funding is fully decentralized across the organization, and development budgets are managed within different units and departments, the role of portfolio management is more about creating alignment and networking across the organization.
Sometimes organizations also move from one end to another – first centralized approach may seem too heavy and a bit bureaucratic, and to bring decision making closer to business, portfolio management is decentralized. This blog is reviewing the different approaches and where could be the balance – and also some thinking related to agile ways of working in the portfolio context provided.
Ultimately, the choice between centralized and decentralized development portfolio management depends on the organization’s specific needs. Each organization is unique, and perhaps something between fully centralized and completely distributed may be a good spot – finding the balance, and enjoying the benefits of lean but powerful governance, but also managing portfolio dependencies well across the company.
Centralized development portfolio approach
When development funding is centralized, portfolio governance is typically managing investment decisions, and driving development roadmaps. In a decentralized approach, portfolio management is focusing more on creating alignment, networking across organizations and coaching. Let’s review a bit more what could be potential benefits and challenges for fully centralized portfolio management approach:
Potential benefits
- Driving development based on strategic priorities in enterprise level
- Prioritization of development across different business areas and business units
- Common governance model, standardized processes and ways of working
Potential challenges
- Decision making may be far away from the business units or teams
- May feel bureaucratic, and slow; lack of agility in decision making
Decentralized development portfolio approach
On the other hand, if development funding is fully decentralized across different departments and cost centers, decision-making is typically close to the business, but seeing the big picture in business or in enterprise may be challenging. Let’s review the potential benefits and challenges:
Potential benefits
- Increased agility and responsiveness to the change
- Possibility to find ways of working, which work well in a specific business unit or function
- Decision making is close to the business teams
Potential challenges
- Lack of transparency in enterprise level & across untis
- Sub optimization in enterprise level due to optimization in units and functions
- Lack of common ways of working due to the freedom and autonomy
- Challenges to manage common resources across different portfolios
How is agile development impacting portfolio management?
Also lean and agile ways of working are changing the role of portfolio management – instead of driving decision making via project gates approvals, agile teams typically have own budget frames or guardrails, and decision making for development priorities is happening within the team and stakeholders.
Tip! For organizations using Scaled Agile Framework, a good read for evolution of Lean Agile Center of Excellence: https://scaledagile.com/blog/how-to-start-and-grow-lean-agile-center-of-excellence/
What would be optimal in your organization?
How do you see your organization – where are you now in the scale from a fully centralized vs. fully decentralized approach? Is everything working smoothly, or could there be some actions to find a better balance? Where would you like to be within a 3-year time frame?
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. -
Ideas To Build Offering Portfolio – Which Offering Portfolio Dimensions Are Relevant For Your Organization?
There are many ways to look into offering portfolios, and I tried to summarize different viewpoints and dimensions, which may be helpful for communication. The challenge may be, that there are many different needs to group or categorize the same offering. Also, the viewpoints when looking into Strategic Development Portfolio developing new offering and available offering portfolios are quite different!
I started to look into my notes from my MBA studies and found many different dimensions which may be relevant. Let’s look into different dimensions – and I would love to hear also how you see this in your context!
New Offering Portfolio vs. Available Offering Portfolio
Different view points to offering portfolio – new offering development portfolio vs. available offering portfolio When developing new offering, the traditional approach has been to projectize work and develop new products and offering via a stage-gate project model (e.g. Discovery to launch process). In large organizations, hundreds of projects or activities may be ongoing to develop new products and offering. Project gates are important steps for gate-driven portfolios – each gate will include a go/kill decision point – and offering development initiatives, which are not technically or commercially viable should be killed. Project development often ends at the Launch of the new offering to the markets.
Today, as agile development via product development teams has become more common, epics or activities may be used as vehicles to develop new offering, without stage-gate project model. Development portfolio is feeding into the available offering portfolio – introducing completely new offering, or extending the existing offering with new features, use cases, or packages for example.
The viewpoint with the available offering portfolio is a bit different – the idea is to look into all the available offering in the markets and optimize the portfolio by bundling offering to meet customer needs and boost the sales of the existing offering.
Also, the offering life cycle viewpoint is important – some of the offerings may be in the scale-up phase, whereas some of the offerings may require boosting or relaunching and others may be in the retirement/replacement phase.
But let’s now look into different dimensions, which are coming up when discussing with the different stakeholder groups!
Products, Services, Solutions and – Offering
First dimension to look into is the products, services and solutions.
Different companies may have different definitions for offering, products, services and solutions. See more about product portfolio management in the previous blog post”.
So what is the difference between products, services, and offering? An offering may be combining products and services, bundled to create additional customer value and make customer life easier and more convenient. This is an area where offering development can create value – developing offering content from the existing product and service offerings to package or bundle in new appealing ways and introduce new interesting offering concepts. And naturally, creating interesting customer offering is a great opportunity to boost sales.
Product Lines and Families
Many traditional companies may have a strong foundation in product development – creating high-quality products, with rich product features. Products are typically categorized based on product lines or product families. There may be also for example technical platforms or enabling technologies to group the products. Also, development organization structure is often aligned across product families or product lines.
Offering may be product line specific or available across different product lines. This is also important aspect to consider and communicate – is the new offering available for all, or are there some limitations also from the technical view point?
Geographical differences in offering portfolio
One of the dimensions for offering portfolio is also the availability of the offering in different geographical areas and countries. There may be significant differences in the customer needs across the different areas, as well as legislation and standards. Also to enable the sales of a new offering may require deployment activities locally, for example to enable sales, supply chain an operations.
Offering themes
Let’s continue with the different dimensions. There may be a need to also present the offering based on different offering themes, such as Sustainability or Energy efficiency: what are the different offerings which are solving a specific challenge customer has across different business units and product lines? For large companies, it may not be a trivial thing to identify all the relevant offerings linking to a specific theme.
Offering bundles
Another dimension to look into is offering bundling: which offering components, products, or services are often sold together, or which offering components would create more value to be offered as a bundle? There may be also bundle pricing – getting discounts for buying more at once.
Standardized Offering vs. Customized Content
When developing an offering it is good to consider also how standardized the offering is or how customized. If selling for example business consultancy, there may be high-level offering packages, but each customer may have customized service in the end. This is quite business specific and linked closely to product strategy, but in the end, also has a major impact on how scalable the offering may be.
Offering categorization based on customer segment
Another dimension for the offering is to whom the offering is targeted – to which customer segments or micro-segments? Is offering relevant only to one customer segment, or is it available across all segments? The needs of different customer segments may vary and the products may need to be packaged in different ways for different customer segments.
Offering based on customer profile & role
Also categorizing the offering based on different customer profiles may be an important way to target for example marketing to exactly correct customer profiles. Offering may be a bit different for example for early adapters or for customers who want to ensure smooth operations.
Customer role may also play a significant role, in terms of interest. Customers may have for example technical roles, roles focusing on profitability and growth, or roles focusing on strategic development. How to offer and what to offer to different roles may vary across different customer roles.
Other dimensions: customer journey, life cycle and profile
There are also several other important dimensions to look into, when developing offering to to serve customers better:
- Offering based on the customer journey – grouping and bundling offering to support the customer journey and moments that matter
- Offering based on the product life cycle – offering targeted at customers with products in different life cycle phases, e.g.
- Offering based on customer value created: commodity/must have, value-adding, cost saving offering…
Recommendations
All in all, there are several viewpoints to look into the offering portfolio, and the same offering may be presented for different purposes based on these different dimensions. One of my recommendations would be to choose which dimensions to use and perhaps start with only a few. If there are too many dimensions or viewpoints, presenting the offering may become a bit messy and confusing.
Also it is good to look into what do you have currently in the tools and systems – do you already use certain categorization and is your offering data up-to-date in the tools and training materials to enable smooth sales? If not quite there, working on data quality is also a great place to start.
I would love to learn more about this – which offering portfolio dimensions are relevant for your organization? Also, do you use tools to manage these different dimensions?
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. -
Don’t forget deployment!
People working with projects, programs, and agile teams have typically a development mindset – we love to develop new things. However, one of the key learnings for me has been the importance of the deployment of the changes we have developed. If deployment is missing, it is unlikely to actually reach the aimed business benefits.
With Strategic Development Portfolios, there may be many different types of changes to be deployed across the organization, here are few examples:
- Strategy deployment – creating awareness and aligning the organization to strategic targets
- Introduction of new IT tool impacting business processes and ways of working
- ERP rollout to a unit
- Introduction of new offering, products or services to markets
- Replacement of a legacy IT tool with SAAS service – impacting also business logic and processes
- New pricing model changes
- Changes in the roles and organization
- Cultural changes or changes in the ways of working (e.g. leadership behavior, lean and agile)
It is not enough to send a newsletter or create 10 min online training to be successful with this type of change. I will go through some of my key learnings from the deployments, I hope this helps!
People side of the change
One of the challenging parts in any strategic initiative is people side of the change. We tend to be so busy with the hard staff – concepting solution, negotiation with the vendors, development and testing and keeping the schedule that there may not be enough time to focus on change management. Today, many large transformation have also change management leads, which is wonderful – the importance of change management has been recognized.
Here are couple of things, which I have seen very beneficial:
- Engaging key stakeholders already during the development phase – co-creation, info calls, news letters, engaging teams early on in testing…
- Communications or support package for people managers – how is the change impacting our team, how to go through the change in our team meetings, how to follow up on change.
- Role based training materials – thinking about the messages and training materials from different roles view point, not just using generic materials which may not be a perfect fit for anyone. Creating modular materials, from where you can choose materials relevant for different roles.
- Feedback loops & retrospectives – when developing something complex and new, it is important to continuously improve. Collecting the learnings from the pilot phase and improving both the content and ways of working makes the rest of the deployments smoother.
- Overall high quality deployment package makes the change management easier – let’s review that part next!
Making it scalable via high quality deployment package
Documentation from the development project is not a proper deployment package. Deployment package should be created from the perspective of the receiving organization and to support the change adaptation within the unit.
Here are few components, which might be relevant for a deployment package:
- Task list
- Training materials (role based)
- Communications package
- Change management package for line manager
- Marketing materials
- Technical product & sales documentation
- Value proposition and sales support materials
- KPIs & criteria for success to be followed
- Supporting tools or IT solutions
Deployment planning as a collaboration
Organizations have also limits, how many changes can happen in parallel while running also sales and business operations.
- Align deployment plans with the units to collect also feedbacks on priority of your development, and other parallel activities. What would be optimal from the unit perspective?
- Budget also funding for deployment – do you need a rollout coordinator? Would you need to translate some of the marketing materials to different languages? Would you need a project manager or a new key user hiring in some units?
- Sometimes with large transformations, deployment may take years, as there are many organizational units to be considered. However, this may be also dangerous – business benefits are delayed, there are old and new solutions to be maintained, and also more and more changes may be required as time goes by. How to make deployment as smooth as possible – creating waves for deployment? Or perhaps engaging area organizations to scale up?
When would we need a rollout project and when release communication is enough?
If there is an existing solution or process, with well functioning regular release practices and an existing community of practice or a network of experts, there may not be need for a rollout project. Release communication may be enough to keep people informed, and key users or other experts are taking the needed training actions within the units.
However, rollout project may be a great approach, when:
- Change is impacting significantly one or more organizational roles
- Completely new IT solution is rolled out across different units
- Introducing a completely new business model or new type of offering, products or services
- Extensive training is needed or building up new competences within organization
I think deployment of new offering deserves an own blog, I will come back with that topic later!
Did you already notice the Free Online course? Have a look!
Check out also the latest blog posts!
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. -
Strategic Portfolio Management, part I
So what is this strategic portfolio management? How is it different from project portfolio management? Let’s have a look!
Strategic Portfolio Management (SPM)
I have been reading through great articles related to Strategic Portfolio Management (SPM), and also a new book “Strategic Portfolio Management in the Multi-Project and Program Organization” was published in early spring 2023 bundled with the latest research. In the book, Strategic Portfolio Management (SPM), is understood as a collection of projects and programs delivering strategic objectives. Within strategic portfolio, there may be tactical portfolios, including programs, projects or sub portfolios. The definition for strategic portfolios takes even a wider approach of including all the “organizational work”, not only projectized development work:
I like this definition, as it is wide enough – development can happen today via projects and programs, but also via agile development or other work activities within the organization.
Taking Strategy to Action via Development Portfolios – Focus on Development outcomes and benefits
This is how I see it!
Strategic Development Portfolio is developing new products, services and offering, new or enhanced business models, transforming ways of working, enhancing processes, operations and IT tools and operating model, developing technology and platforms needed in future, and even impacting culture – moving the company towards strategic goals.
As a result of the development, development outcomes, such as new beautiful customer offerings are introduced to markets and deployed across the organization. Via the outcomes, such as enhanced business model or new offering or operating model, also business benefits are received. Development outcomes are contributing to the strategic targets, and transforming company towards the bright future – to wished to be state.
Strategic Portfolio View
So let’s have an illustrative example, what strategic portfolio could look like. In the example, portfolio is grouped into two sub portfolios focusing on business unit A and B strategic initiatives.
Within strategic portfolios, there may for example transformation programs, must win battles, individual projects or other initiatives, and different type of other development activities. Also work may be organized around value streams, and portfolio epics for agile development teams. Also product development may be organized around projects or via product development teams.
Work may be required from many different units and functions, and such other business units, IT, R&D, marketing, or finance. Thus, close collaboration with different units is required to ensure the smooth execution of strategic portfolios. Sometimes this is solved via cross functional development teams, and in some other cases, transformation programs may include projects delivered by different units. Read more about different view points from a previous post: Development Portfolios in Large Companies – Different viewpoints.
Building Strategic Portfolio – way of thinking
The thinking behind Strategic Portfolio Management is a bit different, even though Project, Program and Project Portfolio Management, and PMO activities are an important foundation for SPM. Here is the summary of Strategic Portfolio Management characteristics Garfein (2005); I think this is summarizing the way of thinking well:
Strategic Portfolio Management – It is all about saying NO
Strategy is all about making choices, saying YES to some of the opportunities, but saying NO to others, even though they are super interesting. This is especially important for strategic development portfolios: to be selective, to prioritize; this will help organization to focus on most important items. Read more about Prioritization from the previous blog post!
What does the strategy mean in practices for our development portfolio? Is our portfolio strategy driven, or can we loosely link all types of development to our strategy? One of the great tools, I recommend for strategic development portfolios is Objectives and Key results – if you want to learn more, have a look at OKR blog text too!
Do you want to learn more? Sign up to new online course!
I am super proud to present the first version, Minimum Viable Product, of Strategic Portfolio Management Fundamentals course via Udemy platform. Couse includes ~2 hours of video lessons, Strategic Portfolio Management maturity model, and an extensive workbook you can use to develop your portfolio management practices further!
References
Strategic Portfolio Management in the Multi-Project and Program organization. Edited by Katy Angliss and Pete Harpum.
Williams D., & Parr T. (2004) Enterprise Program Management: Delivering value. Palgrave MacMillan.
Garfein, S. J. (2005). Strategic portfolio management: a smart, realistic and relatively fast way to gain sustainable competitive advantage. Paper presented at PMI® Global Congress 2005—North America, Toronto, Ontario, Canada. Newtown Square, PA: Project Management Institute.
Sing up to monthly news letter to get the latest blog updates!
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 Tips for Smoother Long Range Planning for Development Portfolios
Many organizations have Long Range Planning (LRP) during the spring, and this may be sometimes a source of confusion and also – frustration.
Here a few typical questions and concerns: Why do we need to do this? Who needs this information? We already have our roadmap, so why use the planning template? What, no template provided this year? We do not yet know the details of next year, as we are working with agile methods. Our strategy will be updated this year, so we cannot yet do planning for the next strategy round… Really, do we start the budgeting already in April this year, we just finally concluded this year’s funding details!!!
Yes, creating future plans is never easy, but the whole process can be made a bit smoother. I try to summarize 5 tips for Smoother Longer Range Planning for Development Portfolios! Would you have other tips to share?
What is this LRP?
When discussing with different teams, a common question is, what does LRP actually mean. Here is how I usually explain it:
Many organizations have bi-annual planning cycles – first looking into long range plans (LRP) during Q2, and budgeting at the end of the year. The idea is not to do detailed budgeting in the spring but to identify big development initiatives, which would create significant business benefits, and also require investment funding. And also to make prioritization decisions of what is not in the plans, to create focus and alignment.
Planning cycles in many companies – Long range planning in Q2 & budgeting in Q4 The long range planning process is focusing on the future – what are the key development initiatives and programs, new product lines, or offerings planned? Typically the planning horizon for LRP is 1-5 years – plans are more accurate for the next year, and more indicative for the next 2 or 5 years.
Long range planning (LRP) is typically lead by the finance function, although development portfolios contribute significantly by providing planning scenarios.
Long range planning (LRP) is typically looking into 1-5 years horizon. Long range planning scenarios
One of the tools for Long range planning is building different kinds of scenarios. Here are few scenarios, which might be interesting to look into:
- If we can do all we want -scenario – what would we develop?
- If we keep the current investment level – scenario – what would be included in our plans?
- If we need to do budget cuts of x% scenario – which items are must haves?
- If we invest into new offerings or business models scenario – where would we invest in?
- If we do this huge ERP renewal consuming a lot of resources – what should we leave out?
So depending on the portfolio, different planning scenarios may be good openings for discussion and prioritization. Also many portfolio management tools provide support for scenario planning.
How about agile teams?
For agile teams, backlog and features are often prioritized quarterly, or monthly. However, it is good to have also high level roadmap and vision. Let’s review what LRP could me for different agile teams?
- Agile Program teams – what is the high level roadmap or vision for the program? What key business outcomes planned? Big epics or themes part of the future vision?
- Continuous development teams – will the development need be stable, or is there a need to grow the team due to increased demand? Or is the solution already in a mature phase, and less development is needed?
- Agile product teams – what is the high level roadmap and vision for the product line? Developing new products or launching new offerings? Retiring some products? Changing a technology platform or building strategic partnerships?
But let’s have a loot at the 5 tips to make LRP process smoother:
1. Start early enough
Align with your finance team on schedules and start early enough, so that you will have enough time to prepare for LRP.
If the time for creating the plan is very short, key stakeholders get stressed, and the end results may not reach your quality standards. Typically also several iterations and discussions are needed.
2. Find the correct level of detail – top down or bottom up approach?
Think about what is the correct level of detail for your LRP – would a high-level understanding be enough, and use a top-down approach for collecting the development ideas with the leadership? Or would you like to involve smart team leads, program managers, and owners in the discussion, as they know the content best?
If you involve all teams for collecting the ideas, and do the planning bottom-up, the work may be quite heavy and take a lot of time across the organization.
So my recommendation would be to keep it as simple as possible, but involve the people, who have the vision!
3. Use a tool or simple template for consolidating the information
If every team provide the information in a different format, it is impossible to see the big picture. Apples are compared to bananas and what ever fruit salad.
If you have a portfolio management tool in use, look into options to utilize the scenario planning functionalities. When using the same format for roadmaps tools provide, pulling information together is also easier. I have been looking into the ideas module and road mapping of our portfolio management tool this year and will try to utilize those for data consolidation.
If you do not have a tool available, simple template may be helpful to keep the development plans in a similar format. Some people hate the templates, others just need to have them to provide guidance.
4. Schedule reviews and prepare for iterative alignment
Schedule reviews and prepare for iterations – typically the discussions related to LRP may take several iterations, as it may be the first time to bring the plans from different teams together.
Long range planning is a great time to create alignment across business and technology units and in the enterprise level:
- What are our development portfolio focus areas for the next years? What planning scenarios do we have?
- What are other business units focusing on? Can we find synergies? Do we have dependencies?
- What would be the investment funding need for the next years?
- Is our portfolio balanced? (See the previous blog post: Is your development portfolio balanced across different time horizons?)
- What support would we need from other units and functions, e.g. from R&D or IT to be successful?
- And other way around, what demand do we get from different business units? Do we need new technology investments or build up new capability areas?
- What new content will be deployed to our sales organizations from different global portfolios?
- What run cost impacts would we expect from the development roadmaps?
- And in enterprise level – can we afford to do all of this development? Should we sequence some of the big initiatives?
This is actually really important, and for me, in the heart of the LRP process. It is not only about the finances, it is about the content.
5. Keep portfolio pipeline up-to-date and adapt to change!
If you have a portfolio pipeline up-to-date throughout the year, LRP would focus more on prioritization and look further into the future. Read more about the portfolio pipeline from the previous post!
If your portfolio data gets out of shape during the year, it will always be a big effort to create your plans. First for LRP, and then for budgeting, and again next year…
Also typically first changes or surprises happen already in January – a new must have project or M&A, or something similar happens. The past years have been full of big surprises from the market and political environment – and impacting also the plans. When you have transparency on your current plans, it is easier to also change the plans. Quarterly reviews and rolling planning are also great approaches (see previous blog post: Time for Quarterly Portfolio Review? and From managing past cost to rolling forecasting). I would love to learn more about integrated business planning (IBP) and how it works in the big complex organizations, too.
Check out also the latest blog posts!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.Other potentially interesting blog posts
-
The Biggest Challenge For Development Portfolios is…
prioritization. This is the answer I receive when I am discussing with portfolio management professionals. And let’s be honest, it is really difficult. There are so many different viewpoints to consider when prioritizing a development portfolio, and not one method fits all.
After my previous post related to portfolio funnel management, I have had great discussions about prioritization. I will open up some of the portfolio methods identified in the literature, and also some practical tips, which have been useful for me.
Management decisions – creating focus across the organization via prioritization
Without management decisions for prioritization, organizations end up into a chaotic situation – there are too many initiatives ongoing, everything is number one priority, and development slows down when resources are too thinly spread across initiatives. Setting up clear priorities is one of the most important tasks for senior management sponsoring development.
One of the great professionals I have had an opportunity to interview, summarized the responsibility of senior management:
Senior management, be kind to your organization, and make prioritization decisions!
Interviewed portfolio management professional
Prioritization creates focus across the organization, and ensure we are taking strategy into action.Experienced leaders have good personal judgement and previous experience to support portfolio decision making. However, we all have blind spots and biases in our thinking. Even though different portfolio methods are not by all means perfect, and not always easy to implement in real life scenarios, different methods provide support to make better decisions.
So let’s review some of the commonly used methods!
Step 0 – Create transparency before prioritization can start…
Before prioritization work can really start, it is important to create transparency across all development happening. One of the challenges in many organizations is, that in addition often well-known project portfolio, there is a number of other development activities ongoing with agile development teams, and also other non-projected activities, which are not always visible at the portfolio level. Transparency can be created via a common tool, or via an excel sheet or portfolio Kanban board, depending on what size of portfolio you are looking at.
Once transparency is created, learning begins! Here are typical points to discuss, when seeing the whole portfolio scope:
- What are all of these things we are developing? Why do we need to develop all of this?
- How much are we spending?
- How are these initiatives linked to our strategy? Are these all must haves?
- Do we have enough capacity to execute these plans? Could we sequence some of these?
- What are the dependencies between these items? If we save from an enabler initiative, would it delay some strategic initiatives?
- What are our colleagues in another business unit planning to develop in parallel? Could there be synergies?
Business Cases
Business cases are a well-known and popular method for understanding both business benefits as well as costs linked. Initiatives with the best business cases should be selected for the portfolio scope.
But… how many really well conducted business cases have you actually seen? The ones which have been also followed up systematically throughout the benefit realization phase? And when looking into different initiatives across portfolio, are business cases comparable?
Typical challenges with business cases are:
- Difficulty to estimate the realistic costs at the time of investment decision
- Unrealistic benefit assumptions without validation
- Difficulty to include also soft benefits into the business case
- Business case is not reviewed and re-evaluated when scope or budget is changes or benefits are re-estimated
- Lack of run costs in the business case (e.g. new head counts needed to support the solution, or continuous licenses)
- For big legal or mandatory initiatives, difficulty to find benefits, and reluctance to create any business case estimates at all
Even though acknowledging these challenges, I would argue that business case is a great tool. We did a case study analyzing how to better support large complex development initiatives (Hiisilä et al, 2016), and one of the recommended practices was to iteratively review and improve business case throughout multi-year development initiatives. When working with large development initiatives, at the beginning of the journey, business case numbers are the best estimates, and should not taken as facts. Understanding of the content evolves, when specifying the solution and receiving vendor quotations, and business case becomes more concrete over the time.
If you are planning to update your business case practices, I would also recommend to look into lean business case from Scaled Agile Framework for inspiration. Lean business case has numbers, but it is also defining the verbally solution scope and for example leading indicators.
Voice of the customer
Is the voice of the customers used in the prioritization of your development initiatives?
One of my previous managers shared a good practice he had learned earlier – there was a small bell, and if development initiative was creating customer value, one should ring the bell. If no bell ringing can be heard, should the initiative be prioritized at all?
Strategic buckets
When working with large development portfolios, allocation of funds into strategic buckets may make sense. For example, to ensure enough money is spent on future horizons (see a previous blog post on Balanced portfolio) or investments are balanced across different product lines, strategic buckets may work well.
Traditional Portfolio Methods
There are many portfolio methods to support with prioritization, such as net present value, or payback period. Even though article is quite old, interesting insights of how widely different portfolio methods are used across business were provided by Cooper et al:
- Financials methods such as Net Present Value (NVP), Expected Commercial Value (ECV), Return of Investment (ROI), Economic Value Added (EVA) or payback period – widely used (~77% of businesses used such methods based on the article)
- Strategic approaches – money is allocated across different types or projects or strategic buckets (~65% of businesses used these methods)
- Bubble diagrams or portfolio maps (~40% of businesses used these approaches)
- Scoring models (~38% of businesses used these approaches)
- Check lists to evaluate projects (~18% of businesses used these approaches)
I have seen successful implementations of each of these – here, as with the business cases, the usefulness of the method is linked to the reliability of the data. If you have too good to be true payback period, you should always look into the source data assumptions. And if management is not using these tools in decision making, then does it make sense to create the content. Tools can also help by automatically calculating financial metrics, based on the business case details.
Budget cut scenarios as a prioritization tool
Many organizations have experiences from budget cuts, while going through rough times. Somehow, surprisingly, when absolutely needed, it is possible to reduce the development costs significantly, even though it is painful. Here are few approaches, which I have seen used:
- Building different types of budget cut scenarios, e.g. what would be your development scenario be, if you have 10% or 30% smaller budgets may help to find the key priorities.
- Categorizing initiatives into must have to keep business running, strategic initiatives and continuous development categories
- Reviewing the whole portfolio and setting all initiatives into priority order – if we would have x budget, which items would fit in from the priority order?
And as many of us have experienced, it is better to truly prioritize and leave out some of the initiatives, than to cut budget frames from all areas evenly.
Other prioritization methods
There is a number of other methods for portfolio prioritization too. I will add here few:
- Voting – each member of the portfolio governance body has a vote for prioritization
- Priority categories – assigning initiatives to priority categories such as High, Medium and Low – commonly used approach. Priorities can be used when communicating about the portfolio content, but also in case there are resource conflicts between the initiatives.
- Top 3 or Top 10 key initiatives – this approach is good, when portfolio is large, and organization wants to have special focus on certain key initiatives. Other initiatives are important too, but there could be more focus and communication about these priority initiatives.
- Weighted Shortest Job First (WSJF) – So how is prioritization done in agile? A popular approach is to continuously prioritize backlog based on the WSJF – weighted shortest job first (by the way, very difficult to say out loud for me at least). The WSJF takes into consideration relative user and business value, time criticality, risk reduction and/or opportunity enablement, and also the job size. This totally makes sense, even though it takes a bit of time to really understand the concept, at least for me it did. If you are interested in this, here is a link to a posting explaining WSJF via agility.im!
I think this topic would deserve a series of blog posts… Let me know, what prioritization methods you are using – this is an area, I would love to learn more about!
In the end, what ever method you use, portfolio prioritization comes back to management decision making. Referring back to the quotation from the anonymous portfolio management professional: So please, senior management, be kind to your organization, and make prioritization decisions!
References
Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success.” The PDMA ToolBook 1 for New Product Development 9 (2002): 331-364. Link
H. Hiisilä, M. Kauppinen and S. Kujala, “An Iterative Process to Connect Business and IT Development: Lessons Learned,” 2016 IEEE 18th Conference on Business Informatics (CBI), Paris, France, 2016, pp. 94-103. Link to abstract
Check out also the latest blog posts!
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. -
4 Goals of Portfolio Management
Portfolio management is challenging by nature, as it is dealing with future events and opportunities – information in project selection is often uncertain and sometimes even unreliable. The decision environment is typically also dynamic – the status and prospects of projects are changing and also market environment. And resources are always limited – resource transfers between projects are not always seamless. In this blog, I wanted to share 4 goals of portfolio management from a classic article Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success”.
Even though article is quite old, and focusing on product portfolio management, I think these goals are still quite relevant. I will highlight some of the key learnings from the article and also add on some reflections. I hope this is useful, and I would also recommend to check out the original article with a lot more insights!
Let’s go through the four goals!
Goal 1: Value maximization
The number one goal of portfolio management is to maximize the value of the portfolio. How to actually do this?
Simple approach used by many companies is to calculate Net Present Value (NPV). For each project in the portfolio, Net Present Value is calculated and projects, with the highest value are selected into the portfolio scope. NPV works well in theory, but in real life, defining the business benefits is always tricky – and not always fully objective. Oftentimes also in the portfolio level, different projects are not easy to compare against each other.
Another method defined in the article is Expected Commercial Value (ECV) – this method takes into consideration probability of technical success as well as commercial success. This is really important, as even the best product or service will not have high commercial value, if commercial model is not successful, and other way around – if product or service is not working well, commercial model cannot fix the issues. Another method, called Productivity Index (PI), tries to maximize the value of the portfolio for the given resource constraints. Calculation within these methods seems to be a bit complex for practical implement, but conceptually really good food for thought!
There are also other scoring models as portfolio tools, where projects are scored on each criteria, such as strategic alignment, market attractiveness, or reward vs. risk. If you are interested to learn more, have a look at the article!
Goal 2: Balance
The second goal is to develop a balanced portfolio. There may be different attributes to achieve balanced portfolios, e.g. balance across different time horizons (See previous blog post: Is Your Development Portfolio Balanced Across Different Time Horizons?), balancing the risk level of portfolio, or balancing across different markets, technologies, product categories or project categories.
A typical scoring model for project selection summarized in the article includes the following factors with scaling from 1-10, anchored scale points 1,4, 7 & 10:
- Reward
- Business Strategy Fit
- Strategic Leverage
- Probability of Commercial Success
- Probability of Technical Success
The article has also nice examples with traditional bubble diagrams, if you are interested to learn more.
In real life, as resources are always limited, portfolios tend to be easily unbalanced. There may be too much investment into certain business unit or product family and lack of investment into some others. There may be too much investment into products and services needed in one geographical area or market and not enough focus on other high potential markets. There may be too much focus on certain process areas and IT tools, and lack of focus on some other equally important. If the lack of balance is due to strategic priorities, that is fine – but if portfolio is not balanced unintentionally, this might cause issues in a long run.
A good practice is to review the portfolio periodically, e.g. quarterly (See previous blog post: Time for Quarterly Portfolio Review?) and check if any balancing actions would be needed.
Goal 3: Strategic direction
The article states that Strategy becomes real when you start spending money! This is true, development portfolios are key vehicles to take strategy into action. Here are two ways to ensure the portfolio is aligned with the strategic direction:
- Strategic fit – are all projects consistent with your business’s strategy?
- Spending break down – does the breakdown of your spending reflect your strategic priorities?
As tools to manage these aspects, two approaches are defined:
- Bottom-Up approach – Strategic criteria is built into project selection tools, such as scoring factors introduced earlier
- Top Down Strategic approach – Strategic Buckets Model – based on the business strategy, buckets of money are enveloped for different types of projects. Examples of strategic buckets defined in the article were buckets per different product line, own buckets for new product projects, platform projects or other (e.g. extensions, improvements or cost reductions).
Typically, when discussing with practitioners, having a clear strategic direction may be one of the challenges: company strategy is so wide, that is not really giving guidance for portfolio prioritization – all of our projects are linked to strategy one way or another. Some organizations have solved also this issue by creating a more detailed portfolio vision (See blog post: Bright Future Ahead – Creating an Inspiring Development Portfolio Vision) or even more concrete Objectives and Key results (See blog post: Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs))
Goal 4: Right number of projects
Most companies have too many projects in the pipeline and due to limited resources, resulting in pipeline gridlock. This is also one of the key challenges almost every portfolio management practitioner highlights during the discussions.
To solve this challenge, there are two questions:
- Do you have enough of the right resources to handle projects currently in the pipeline?
- Do you have enough resources to achieve your new product goals?
As a solution for both questions capacity planning is based on the current project’s roadmap and future development needs. Mapping resource demand and available capacity is a significant effort with large portfolios and big organizations – portfolio management tools may support these views!
In addition to capacity management, I would also strongly link this goal to prioritization! It is really important to create limit the number of new projects initiated and also kill unsuccessful projects.
Tip! Check out also the blog post: Do you manage a Portfolio Funnel, or Tunnel?
References
Cooper, Robert G., Scott J. Edgett, and Elko J. Kleinschmidt. “Portfolio management: fundamental to new product success.” The PDMA ToolBook 1 for New Product Development 9 (2002): 331-364. Link
Previous blog posts, which might be also interesting:
Blog post related to product and offering portfolio management Blog post related to Quarterly Portfolio Reviews 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. -
From Idea to Value: Leveraging Business Technology Standard in Portfolio Management
Have you heard about the Business Technology Standard?
Many large companies and organizations in Finland are applying the framework to support demand, development, and service management, especially within the business IT context. Over the last ten years, the standard has significantly influenced my thinking—I tend to see its structure everywhere I go!
I had a wonderful sparring discussion with Business Technology Forum Executive Tia Jähi, and we agreed, that even though standard is originated from the business IT, the same principles would apply also for other contexts, such as our life cycle business and offering development!
Demand
First, we need to start with the demand portfolio. New ideas or development needs come from many different sources, and we need to create a systematic way to process, analyze, and prioritize this demand.
Development
Next, we move to the development portfolio. Development can occur through projects or programs, as well as continuous improvement activities. The Business Technology Standard framework can be applied to both traditional project portfolios and agile setups, which is fantastic!
Services
Last but not least, the service portfolio. This is the phase where we start to realize business benefits—when our new IT system is operational or our offering is sold and used by our customers. Having well-defined service management processes helps development teams focus on new demand and development and ensure good care of the customers and end users.
Governance
Creating clear governance over the entire end-to-end chain helps to create transparency, smooth decision-making, and a focus on value and strategic objectives. This includes well defined roles and responsibilities and also clear prioritization of demand, development and also service management activities.
Have you been applying the standard successfully? What are your key takeaways?
If interested to learn more, have a look: https://www.managebt.org/
-
Do you manage a Portfolio funnel, or Portfolio tunnel?
Smart people with a development mindset contribute to a large amount of development ideas. There may be innovative ideas related to new products and services ideated with customers, new business models to be experimented or process improvements. Also new IT solutions supporting business processes and improvements to existing solutions are typical content of large development portfolios. Strategy driven initiatives may also have significant impact on many different elements, also on operating model and ways of working. In addition to large development initiatives, there are also different types of development ideas to enhance current ways of working via processes or IT systems.
Systematical way to manage Portfolio Funnel
Systematical way of working to track and manage new development ideas is important – not only for budgeting purposes, but not to miss excellent ideas! Agile teams maintain also their own development backlogs, including new requirements, features, or use cases for developing for example an IT solution. Items in the portfolio level should be of a size of a project, or portfolio epic – an item with specific business objectives and typically significant work required from multiple teams.
Portfolio funnel – smart people contribute to a large amount of development ideas Managing portfolio funnel, not a tunnel
One of the key deliverables of portfolio management process is the support for prioritization of the development ideas in the portfolio level. For all ideas, it is good to do a brief analysis – is this idea viable, and where would this belong to – to be implemented as project or as a part of agile development teams. Also, is the idea something we would like to proceed in a near future, or should we park it?
Prioritization of the development ideas is also needed. Prioritization could happen within regular governance meetings, e.g. monthly or quarterly or during the planning processes such as long range or mid-term planning or yearly budgeting. Saying no to development ideas which are not part of the portfolio scope or priorities is important, to create clarity and focus. Also parking ideas, which are not viable right now, but could be worked in in the future is also beneficial.
Managing portfolio funnel – also saying no or parking ideas is important What is in your portfolio funnel?
One of the key challenges many organizations struggle with is the pipeline gridlock – there are too many development initiatives ongoing at the same time and nothing gets completed as planned as capacity is too thinly spread across initiatives. Also, if there are many small items consuming time of the development teams, there may not be enough focus on big important items. Key topics to look into
- How many initiatives and how big initiatives do you have in the pipeline? If there are too many small initiatives in the funnel, difficult to get large important initiatives completed!
- How many big initiatives can manage simultaneously?
- What is the available capacity?
- What are the key constraints? Experts? Money? Would you need to have extra help for for the critical areas, where experts would be needed?
What is in your portfolio funnel – understand the constraints and make space for big important items The first step to solve this challenge is to create transparency across the portfolio pipeline – this is a great tool for the senior management also to start to work on prioritization.
Portfolio Kanban for visual management
One of the great tools for visual portfolio management is Portfolio Kanban. The idea is, that within portfolio Kanban, you may include different types portfolio level ideas, epics or other initiatives, such as projects, and systematically evaluate the prioritize the different ideas – and see different portfolio items visually via the Kanban board. It is good to keep the Kanban as simple as possible; also Kanban can be used for portfolio idea funnel only, if execution is happening via portfolio roadmaps as a part of different programs, projects and agile development work.
For project stage gate models, the idea is other way around – project has own phases, which are driving the portfolio process. However, also a systematical process is needed for other development ideas, which are not projectized and not following project model.
Tip! Scaled Agile Framework (SAFe) Lean portfolio management includes also Portfolio backlog – have a look, if interested to learn more about how development organized there!
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.
Strategic Portfolio Management
Taking strategy into action via development portfolios – sharing best practices via a blog
Strategic Portfolio Management 