Category Archives: Project Management

Lean PMO: Managing The Innovation Portfolio

One of the first exercises I run with executive teams is mapping their business portfolio to visualize current work in progress and how it aligns to the overall business strategy. Without exception, every time I run this exercise the gap between current state and desired state is far wider than every executive believed, hoped or even imagined.
lean portfolio mapping

Portfolio mapping requires taking an end-to-end view of the lifecycle of initiatives in your organization. Lean Enterprises’ consider four main domains:

  • Explore early stage initiatives that are bets for the future with high degrees of uncertainty
  • Exploit initiatives that have achieved product-market fit and the organization wants to grow and scale
  • Sustain initiatives that have become repeatable and scalable business models, products or services that drive the majority of revenue for the organization
  • Retire initiatives that are long lived, no longer beneficial (even limiting) to the organization future success or strategy and should be sunset from the portfolio

Lean Enterprise

Initiatives that do not achieve desired outcomes in any domain should be killed, and their investment transferred to other initiatives.

High performance organizations focus on building capability to continuously move initiatives through the model from Explore to Retire. They understand that using the same strategy, practices and processes across the entire portfolio will result in negative outcomes and results.

Poorly managed organizations tend of use the same standardized approach for all domains. They fail to recognize the need to adapt their analysis, evaluation and control mechanisms to design a system that will provide the correct amount of governance and measurement to enable business leaders make high quality decisions based on learning outcomes and data derived from executing the work in each domain.

Typically these companies portfolios are orientated solely toward high revenue generating initiatives. Valuable cash cows that become prized assets, protected and milked dry. Lean Enterprises’ however know that one day the milk will run dry.

Explore

New initiatives are inherently risky. When aiming to explore a new business model or product it is imperative investment is limited by setting boundaries around time, scope, financial investment and risk. We do this not because we are cheap. We do this to create ‘safe to fail’ experiments and build in quick feedback loops to understand if we are achieving the desired outcomes.

Lean Enterprise portfolio

In the Explore domain our goal is to test the business or product hypothesis at speed using a cross-functional team to experiment with the customers the solution is targeted at. By designing fast and frequent feedback loops into the team’s exploration we can limit investment, maximize learning and avoid creating ‘bet the business’ scenarios that are too big to fail.

Also, by limiting investment into smaller bets allows us to make more bets, enabling us to test many ideas to discover what works and what doesn’t. This is the principle of optionality applied to business model innovation and product development.

Lean Enterprise Book

Most of the ideas that we believe are great aren’t actually that great at all. By creating optionality in how we design our testing process we can create many opportunities to learn, not just one.

Yammer used a concept of 10×2 to design feedback loops and limit investment in early stage ideas. Their approach constrained teams to no more than 10 and no fewer than 2 people when exploring ideas. Also their iterations could be no longer than 10 no shorter than 2 weeks before teams had to demonstrate their achievements designing feedback loops directly into the development system.

Principles and capabilities of Explore

  • Cross-functional multidisciplinary teams
  • Make lots of small bets
  • Boundaries of time, scope, financial investment and risk
  • Design experiments are safe to fail (the only true failure is the failure to learn)
  • Create a sense of urgency
  • Demonstrable evidence of value to proceed

Exploit

For those few initiatives that achieve escape velocity and exit the Explore domain, teams can continue with a sufficient level of confidence that they are building the right thing, now they must embrace building it the right way.

Lean Enterprises understand the project paradigm is broken only further propagating organizational silos, conflicting priorities and measures of success. They understand the importance enabling cross-functional teams to experiment directly with their customers and users. Effort and measures of success are tied to business outcomes not output.  

As the team collects data from experimenting with real customers and users it improves its understanding of how the business model, product or service is performing. The team can then develop more targeted and sophisticated hypotheses based on the knowledge created from genuine user feedback.

Lean Enterprise pmo

Amazon designed the concept of Two Pizza teams – independent, long lived customer facing teams that were small enough to be fed by two pizzas. This enables context to be held within the group as the business model, product or service grows, while also allowing the team to become autonomous and learn together at speed. Leadership can then continuously evaluate how the initiative is performing based on frequent feedback loops, and can help to make further investment decisions on how to scale it up, down or to kill it based on the outcomes achieved.

Principles and capabilities of Exploit

  • Create end-to-end customer facing teams, not project teams
  • Continuous evaluation funding model
  • Target condition is to achieve break-even point
  • Data-driven, fact-based decisions based on accumulated knowledge
  • Maintain a sense of urgency
  • Set a vision, trust the team to get there, clear blockers and support as they proceed
  • Make knowledge sharing and organisational learning easy

Sustain

The majority of large organizations have built their entire business on a single business model and/or supporting products that achieved product-market fit and continued to grow beyond early expectations. They have extended their market, region, and/or sector to achieve exceptional financial success and achieve wide customer adoption and reach.  

Lean Enterprise program

The challenge they meet is how to avoid ‘feature fallacy’ – the fallacy that simply adding new features will add more value. This manifests itself as overloaded products with features, tools and customizations that customers often never use or are even aware of.

Think of a product you have used for a number of years. Are you aware of all the new useful additions to it? Adding new features does not equal adding more value to customers and users. The feature fallacy often represents wasted effort and investment that could be spent elsewhere.

Etsy design for continuous experimentation. Teams at Etsy work closely with product, marketing, and engineering to scout, build, instrument and improve Etsy’s product portfolio to make sure that they are improving business outcomes for all their stakeholders – customers and users included.

The goal is to use data-driven decisions based on usage and profitability to enhance what customers desire – not just copy what competitors release or what HIPPOs (HIghest Paid Person’s Opinion) want to have.

By continually adding more and more features to existing products, organizations end up with huge monolith applications that are difficult, slow and costly to change or build upon.

The trick is to break out new ideas,  implement them as an Explore initiative and drive them through the end-to-end lifecycle flow again. This provides all the benefits and rigor of each stage while building the capability to continually create new business opportunities for future on-going success.

Principles and capabilities of Sustain

  • Beware of the feature fallacy
  • Focus on what is valuable – where can we win?
  • Don’t get lazy. Success hides suboptimal issues
  • Keep discipline with fact and evidence-based decisions
  • What is being used, improved or removed?
  • How could we disrupt or get disrupted?

Retire

All good things must come to an end. The difficulty for most organizations is that many systems in their portfolio are not well understood. Often the people that built the original system long ago on a ‘project’ have left the company. No one knows how to change, adapt or turn off the system or what impact it may have. Fear runs through the organization because the entire company’s business model is dependent on a COBAL program running on a 486. It may sound like a joke, but this is the reality for most organizations.

High performance organizations continuously seek to reduce the complexity of their systems to free up people and investment to Explore new opportunities. By simplifying their systems they are able to innovate faster, cheaper and more frequently.

Ask yourself the question “When was the last time we sunset a system, product or feature in our team?” If you can’t remember then it is a smell. Over time the weight to legacy systems and technical debt will grind your innovation capability to a halt. Keep it within control. Remember that effort not spent on keeping legacy systems alive frees up opportunity to focus on new initiatives.

Principles and capabilities of Retire

  • Has it served its purpose? Can we sunset it?
  • It is providing value? Kill it if it is not.
  • Are there better opportunities to invest in?
  • Continually look to reduce product and system complexity
  • Simplifying helps to support further innovation
  • Free up funds and capability

Conclusion

Business models are transient and prone to disruption. If your organization is reliant on a single business model, product or service to guarantee its on-going survival then safe to say it is in a precarious state. You’re only one technology innovation, customer loyalty switch or economic decision from irrelevance.

Lean Enterprise Disrupt

To be successful, a company should have a portfolio of products with different growth rates and different market shares. The portfolio composition is a function of the balance between cash flows. High growth products require cash inputs to grow. Low growth products should generate excess cash. Both kinds are needed simultaneously.

Lean Enterprises know that building the capability to continuously seek out new business models, products and services is the key to ensuring their future business relevance, growth and evolution.

If your executive team is unclear on how your portfolio is performing and what initiatives you are exploring, exploiting, sustaining and retiring, get a cross-functional group together and map out your portfolio to visualize your work in progress. Ask if it is achieving the desired outcomes and aligned to your business strategy and objectives.
Share the results of the exercises with your teams and business leaders. Then starting getting deliberate about investment of time, effort and people in becoming the business you want to be.

References

Why we carry watermelons?

I was working with a client recently that had decided to start a program of work involving 15 independent project teams, all working together to deliver a few key business objectives. 15 project teams comprised of roughly 140 people, all co-ordinating and collaborating together from different departments, locations and functions across a global organization with a few external vendors thrown in to add a little spice.

A challenging mission at best, I was keen to understand how the Program Management Office would measure progress towards the identified outcomes, while ensuring that individual teams shared information across the program of work.

I carried a watermelon?

I carried a watermelon?

“We’ve a program dashboard that each team populates with project status, progress, risks and issues each week”. I looked at the dashboard. “Everything is on track, and has been since we started a few weeks ago. We’re confident we’ll deliver everything within the program time line and constraints”, said the Program Lead. All the initiatives were green. “I think you’re carrying watermelons”, was my response.

What is a watermelon?

Green on the outside but with orange or red cores, watermelons are a nice analogy for healthy looking project reports served to PMOs on a weekly basis. In an environment of mistrust, fear or bureaucracy watermelon serving is rife. Teams tend to suppress or hide information that may highlight that everything isn’t executing as defined in ‘the plan’ – especially when everyone else in the program is serving up fresh green goodness too!

No one wants to be the focus of management never mind the PMO, they paint the happy, healthy and wholesome picture, avoid discovery and convince themselves everything will work out before the next checkpoint. The Eye of Sauron moves onto the next green blip and the team hopes to pull back the difference by the next time the dark lords glare comes around.

HealthCare.gov was a $93.7 million investment that turn into a $292 million failure for the US Government. People and teams within the program were aware that the initiative was not in a good state, yet they continued to report that everything was running to schedule, on track and green — even though inside the projects people knew the reporting was a fallacy and the status was red.

They lived their days hoping that everything would turn around, that they would reach the dates, and deliver the system. No one wanted to be the bearer of bad news. No team wanted to highlight that they had an issue, they were waiting for someone else to blink – why, so everyone could blame someone else for the failure that was about to happen?

Breaking open the watermelon culture

Visibility, transparency and the appropriate level of decision making lead to better choices. But yet, there are prerequisites that must be in place to get there.

To calibrate openness and safety teams monitor the response of leadership to difficult situations and emergent circumstances. Teams adapt the quality and detail of information they share in relation to the actions, not the words, in response to the information.

Encourage teams to cut the watermelon open and have a conversation about what you find inside. Then by working together to eat up what you find it encourages others to do the same.

Team will always encounter problems on any delivery initiative. Our mission is to create willingness to take accountability for the challenges faced and find the best solutions together.

Decisions on how teams work towards solving the challenges should be made by the teams doing the work, not someone in management located on the other side of the world.

However, these teams are then responsible for the outcomes of their decisions thus empowered to be accountable to do the right thing. The job of leadership is to provide support, space and remove blockers in their way.

In my experience programs based on cultures of fear tend to follow the pattern below

Transparent, trusting and teamwork based programs tend to be this pattern

We need to change the way our people think and work together towards a common goal. To do this, we need to address a few aspects;

  • Clarity of Purpose – clear direction from leadership and the team on the outcome (or target condition) to achieve
  • Alignment – collaboration and agreement on the tactics to achieve the target condition
  • Engagement – regular feedback loops with everyone involved in achieving the target condition. Then adjust and adapt based on the information we are learning from performing the work to address the issue at hand

When working with teams, I favour a “Go to Green” strategy by reviewing all aspects of the current situation including data presented by other team leaders in the program. By creating visual artifacts (not paper reports) where teams can meet, share and collaborate on current state and circumstances we can make better decisions that will improve outcomes for the entire initiative. It also serves to foster transparency and trust between all parties as they work together to solve problems and win.

Plan, assign and execute those decisions in an agreed time frame, then set a frequency to review outcomes, share successes or revise activities based on what we’ve learnt from doing the work.

Conclusion

If you have a culture based on fear, you will never have true information flowing through your organizations network. People will share the right information, not the correct information.

The role of leadership is encourage transparency and recognize that their actions in response to negative news is what will create an environment of safety. When people feel secure to share real information on the situation, knowing that leadership will work together with them to identify strategies directed to solutions not blame, the system improves for everyone.

Encourage teams to work together to solve problems, thus building relationships and trust with one another to achieve successful outcomes for all by eating up those watermelons together!

melon-shark

References

The first time I heard the term ‘Watermelon Reporting’ was from Marc Loffler when he got on the stage at ALE 2011 with a meat cleaver and a bag of watermelons. I’ve kept it with me since then.

All watermelons from http://www.whataboutwatermelon.com

Tradition vs. Lean and Agile PMO and Organisations

We are in one of the most interesting and disruptive eras of business change the world has known. The landscape and competitive environment is evolving at rates we have not seen before, and it’s only going to accelerate. The average life expectancy  for an organisation is plummeting from 67 years in the 1920s to 15 years today, according to Professor Richard Foster from Yale University. At the current churn rate, 75% of the S&P 500 will be replaced by 2027.

Below I have included a deck contrasting the differences between traditional and Lean/Agile PMOs and organisations, outlining the value a Lean/Agile approach can bring. I have been able to extended the deck with the help of David Joyce and Ian Carroll in order to start a discussion on how the future can look for organisations as they attempt to scale lean and agile practices and principles across the entire organisation.

Even though traditional models of how projects, portfolios and organisations are governed represent thinking that originated in the 1890s with Taylor (fixation on efficiency and utilisation) and Gantt (of Gantt chart fame) they seem remarkably impervious to change. Our challenge for organisations today is that they need to change to keep pace with our ever evolving business environment, otherwise we can never achieve true business agility.

I plan to post deeper insights into each area over the coming weeks, however for now I will paint the boarder picture of where the majority of organisations are at today, and how they need to start changing and learning to move forward and be competitive in this era of disruptive change.

As W. Edwards Deming said, “Learning is not compulsory… neither is survival”.

Key concepts;

  • How traditional PMOs and organisations are setup
  • Legacy mindset that are alive and still driving the majority of portfolio/organisation behaviours
  • Comparisons of traditional and lean/agile mindsets
  • Principles of lean and agile portfolio/organisation management
    • Organisational structure
    • Annual vs Incremental funding (Beyond Budgeting)
    • Limiting Work in Progress i.e. its only matters how many projects you finish, not start.
    • Managing and visualising capability
    • Coping with portfolio complexity through experimentation and validated learning
    • Removing the concept of projects and focusing on continuous delivery of value
  • Benefits of lean and agile portfolio/organisation management

The Systemico Model

Manage value not cost

One of the foremost challenges we constantly encounter on development projects is the focus of teams and product managers on managing cost rather than value. In its most basic form this manifests itself daily in user stories where teams tend to concentrate on prioritisation, scope management and throughput in terms of the size of the work. The usual question I hear once a story is described is ‘What size it is?’, in short – how much is that going to cost?

Fundamentally these teams see software development as a ‘cost’ that must be managed. They forget that software development is a value creation process and hence the goal of our approach should be focused around creating and realising value, especially from the perspective of our users.

As Warren Buffet stated, ‘Price is what you pay. Value is what you get’. What is needed is a change in mindset toward value creation, or at least exposing and making the idea of value visible to these teams and the wider organisation.

Realising Value

Unlike waterfall approaches where all value is delivered at the very end of a long linear process of project analysis, development, testing and deployment, agile development emphasises the realisation of value much earlier and more often.

Agile Development Approach

Using techniques such as iterative development – always having working software, continuous design and delivery – the value created can be more frequently realised during the development process itself. However, challenges still exist in how to prioritise value for the user.

Teams continuously put energy into prioritisation and focus on throughput to achieve efficiency, but lose sight of effectiveness. No matter how efficiently we work, if we are continually building software that is of no value to our end users we are essentially creating waste, regardless of the pace we achieve.

Teams and product managers need to take a holistic view of the entire product to support a user-centric approach to understanding, capturing and delivering value.

Challenge to prioritising value

Teams and product managers tend to favour grooming the product backlog through prioritisation and story sequencing to create a production line of user stories for the development team to consume. This approach appeals to the rational human mindset that development is a linear process. We create stories for the team to pick up one at a time, as prioritised in sequence. But this approach is flawed in the context of value creation. Value is not linear, and thus we need to take a systemic and holistic approach to application development when looking to create value for our users.

Systemico Model

To visualise the concept of value creation as systemic, holistic and in terms of the user, we have developed a framework we call the Systemico Model. The name is designed to reinforce the idea that value creation is not an isloated linear process. The model aims to make the requirements of the product visible to teams and product managers in terms of how it addresses user goals and engagement levels. We have found the Systemico Model to be especially useful when working on new products and domains that need to be customer and/or user-centric, especially when there is little or unknown validated learning in the product space.

Systemico Model Grid

User goals

Traditional analysis and design methods are often application-centric, defining the product in terms of what it will do, followed by how the user will interact with it. Instead, user-centric methods focus on why we should have a piece of functionality and how we can implement it.

To support the latter approach we define the product in terms of user goals and how it will assist the user in meeting those goals. This helps to focus our understanding on what motivates a user to use our product, and what features they will find valuable.

By defining and prioritising the requirements of the product in terms of the users’ goals, we ensure that only functionality relevant to the user is created and visible to the team and product manager. Examples of user goals for a website may be to find content, add content, or purchase.

A challenge when assigning user stories to user goals is that there is not always a direct mapping of individual stories to goals – in some instances user stories can support multiple user goals. In this situation, we advise the team to agree on the goal that it believes to be the most appropriate based on the project landscape and customer insights they currently have. Should that view change in the future, the story can be moved to the most relevant user goal to reflect the latest available information.

User engagement

Along with user goals we consider the perspective of user engagement to analyse the level of interaction between the user and the product. We associate different observed behaviours with different degrees of user engagement.

Core: Functionality that satisfies the users’ basic needs. These are the minimal expected features that users believe are standard on all products in a specific context e.g. user login/logout

Use: Enhanced functionality that increases usability of the product. Without these features the product has minimal appeal to the user e.g. displaying content on a page, user editing/manipulation features

Engage: Functionality that draws the user to interact further with the product. These features draw the user to return the product in the future e.g. contribute to a site, provide reviews/ratings

Explore: Functionality that entices the user to go beyond simple interactions. These features build the strength of connection between the user and the product e.g. personalised services or recognition/rewards

The varying degrees of user engagement are not designed to indicate an increasing level of value from ‘Core’ to ‘Explore’. Instead they are designed to support the focus of the product proposition to resonate with the users’ interaction with the product, thus offering value for the system.

A challenge when defining the degrees of user engagement is that they are subjective. This requires conversation between the team and product manager to create a shared understanding and definition of each category.

Applying user stories to the Systemico Model

By using the two perspectives of user goals and user engagement we are able to attribute extra value dimensions to user stories, aside from the requirement and size or cost of the work. This provides a deeper insight into the value a story will deliver, and will support the team and product manager to understand where to prioritise and invest effort.

We ask the product manager to prioritise what they believe to be the key user goals of the system and assign each story to a goal. Then we challenge the product manager to define the level of engagement each story is targeted at, in order to provide a second dimension to the user story.

The end result is a value map of all user stories defined with extra dimensions beyond cost that relate specifically to the user of the product.

Visualise value and effort

Another feature of the Systemico Model is its function as a visual tool to represent how and where effort has been invested in the product.

All user stories are mapped on a wall against the framework to visualise the user goal and engagement they are targeted at. We use blue cards to represent user stories that have not been picked up, replacing them with a yellow card when they enter our story wall.

Systemico Model

By providing more dimensions to user stories and mapping them to the framework, the team are provided with a visual, holistic, systemic and engaging view of the entire product which is centered on the user.

This serves as a visual reminder to the team of what areas have been worked on to date. It also supports decisions on how much effort should be invested in each user goal/engagement component to satisfy a user requirement before focusing on other areas of the product.

Good enough to go live

The Systemico Model also reinforces the concept of creating just enough functionality to showcase a value proposition to the user for validation before investing further in the feature.

We challenge our product managers to release the product as soon as viable combinations of user goals and user engagement components are completed by the team. In many instances, especially when working on new product development, completing the “Core” engagement component of a user goal should be sufficient to release the product to gain validated learning and insights from the market place.

Systemico and Release

A danger with traditional approaches to software development is that teams and product managers spend too much time and effort drilling into features that support individual user goals before presenting it to users for feedback and validation e.g. trying to make it perfect before release. This can lead to large amounts of waste if users later deem the feature undesirable or of low value.

By focusing on completing thin user goal/engagement combinations of the product and then releasing immediately, rapid feedback can be collected from user themselves on which features are appealing or more desirable. Once we obtain this feedback we can clarify and validate our user goals, and build greater depth to features that further enhance the users’ engagement in that component.

The concept is referred to as ‘do less [of what doesn’t matter], deliver more [of what does]’. By focusing on what is truly important to our users we eliminate the creation of value propositions that are undesired and not useful to our customers.

The key concepts to remember are;

  • the sooner the product is delivered
  • the sooner you can get feedback from users
  • the sooner you can improve it

Conclusion

The Systemico Model and user goal/engagement components are designed to support the team and product manager along the value creation process by providing a visual framework that allows further dimensions to be added to value propositions. The goal is to enable the team to leverage their development process to maximise value realisation, while minimising waste and over-engineered solutions that do not fit user needs.

Tagged ,