What is this text about?
This blog describes the Portfolio Management (PFM) Process that was introduced in our team in 2012.
The process aims to better balance our service innovation strategy, create more transparency on requirements and decisions and to foster cross team work.
What is our job within SAP?
Our team provides Continuous Integration (CI) and Delivery Services (CD) within SAP. Many SAP teams use our technical infrastructure like Source Code Management Systems. We host a large scale build server farms to run builds for various programming languages. We develop ready-to-use production processes for main stream technologies like Java, SAP Fiori or SAP Mobile applications. In addition our team develops self-services to enable DevOps teams to orchestrate delivery pipelines efficiently.
What is my job?
Our service area consists of eight teams at five different locations working hand in hand all around the globe. All teams provide services like consulting or infrastructure operations and at the same time work on infrastructure development topics. The teams organize their workload using agile methods, either Kanban or Scrum.
I am the “Area Product Owner (APO)” of a Service Area within SAP SE. In my role, I am responsible for the overall strategic direction of our unit. What does this mean? As explained above our “product” is a set of development services. Therefore the key “strategic” question for us is: “How do we need to adjust our existing service portfolio to support SAP development teams best?”
This question comes along with a couple of challenges. The field of Continuous Integration is very dynamic and innovation comes at fast pace. New open technologies need to be offered quickly within SAP. We have many different stakeholders with completely different needs.
What to do first? Which stakeholder wins, which one has to wait? How do we come to a global ranking that makes sense? And even more difficult: if we know what needs to be done, how do we quickly bring the people together to get the job done? Or to express it in business terms: how do we “allocate human resources” quickly to solve a topic or work on a new opportunity.
In this text I describe the Portfolio Management Process we introduced in our team to find the best answer to the questions above.
We are running this portfolio process since more than three years now and I will as well summarize some of the results in this blog. In my opinion they are pretty positive.Therefore, this idea might be of value for other teams in similar situations.
Consequences from rigid team structures
Historically, the starting position of our service area was difficult. We started as a melange of specialized teams, working on specific services or tools, very often even working for particular stakeholders. That is also a consequence from mergers with SAP Acquisitions. Organisationally the teams were combined; a service and tool consolidation however often takes many years.
In such situations it makes no sense to introduce “Scrum of Scrum” like methods. Forcing two product owners working on different topics to sit in one room and discuss their backlog has led to frustrating waste of time, in the past. However, completely decoupled teams of course indicate a lack of common goals and a missing common strategy.
If there is no sense in bringing product owners together, as an APO I started talking to Product Owners face to face. This in turn leads to micro management. Of course, each team and Product Owner only has little available capacity and therefore investment decisions can only be small. I found myself discussing small backlog items, while urgent topics that required focussed and quick breakthrough actions piled up.
Instead of asking “what needs to be done by our team to best support SAP” I was asking “Which tiny little thing could be done next by team X” to solve a problem. I felt like somebody being able to buy one glass of milk after the other, instead of buying a required cow.
The idea in a nutshell
The book "Portfolio Management for New Products, Robert Gravlin Cooper, Scott J. Edgett, Elko J. Kleinschmidt, Basic Books, 2001" describes Portfolio Management for large organizations in detail.
Our team tried to break down the described large scale methodology to our “small world”. One method described in this book is called “strategic allocation of business resources”. The process describes the change from the current portfolio to the new “balanced portfolio” in two phases.
Phase 1 is the top-down approach.
This phase is “strategic”. This part of the process completely ignores concrete existing to-dos, requirements and opportunities. Instead, a group of experts defines how to distribute the available budget.
To do so, an understanding of relevant budget categories is required. The categories need to be carefully chosen, they need to have a link to the strategy. The categories are named as strategic buckets and they express “where the organization wants to spend its money for”.
For example, a company operates in different market segments. This company now has the strategy to extend a certain segment. They most likely chose strategic buckets according to their market segments. Many other examples are outlined in the above mentioned book.
The entire discussion in phase 1 circles around the question: “how do we better distribute the budget in order to reach our strategic goals”.
This discussion is done until a consensus is found. The result of phase 1 is a new target budget distribution.
Phase 2 is opportunistic.
In the second phase of the process all concrete topics, requirements, to-dos are considered. The goal of this phase is to fill adequate concrete topics into the buckets worked out in phase 1. This is done - again - in a round of experts.
This discussion starts with all topics ranked according to formal criteria. This requires that all experts have agreed on a list of concrete and appropriate ranking rules.
Example: the formally calculated Strategic value could look as follows:
| Criteria | Ranking Points |
|---|---|
| Topic has strong fit with new SAP product strategy (HANA, Cloud, Mobile) | 10 |
| Topic has good fit with a key element of the product strategy | 4 |
| Topic has only peripheral fit with the SAP Product Strategy | 0 |
This “formal” starting point avoids having “political discussions” right from the beginning. The formerly ranked backlog is called “value maximized portfolio”. It is generated arithmetically on agreed conventions and ranking rules.
However, this “value maximized portfolio” cannot be executed, because in real life, there are constraints. For example the required know-how to execute a certain topic might not be available. Or a certain task needs to be executed at a certain location, but the relevant experts are blocked with something else.
Theses constraints enforce an iterative shuffling and shifting of topics until it fits. Sometimes it is as well required to downsize things.
This iterative procedure leads to the new ranked list of topics. The list is now called “balanced portfolio”.
The iterative process and discussions as well reveal that certain domain experts have to work for a certain period in some other team to get the job done.
Mapping this idea to our team
In our we decided to start with fairly unsophisticated set of non-technical buckets:
Bucket 1: Keep the System running (KSR)
This bucket covers all investments we need to make to safeguard the level of quality for services we already provide. This covers operations, support, configuration management, maintenance, bug fixing and so on. Everything in this bucket is not subject to a management decision. It simply must be done or we risk to badly disappointing our service consumers. The largest percentage here is unplanned, reactive work, but the amount of time spent on it can be well estimated based on the workload in the previous months.
Bucket 2: Innovation
This bucket contains the new stuff! It contains all the things that we do to adjust our service portfolio to new stakeholder requirements.
Unfortunately, any innovation leads to a higher KSR (bucket 1), because an innovation brings about new tools that have to be maintained or services that raise total cost of operations.
Bucket 3: Improvement
This bucket covers everything we do to lower our KSR (bucket 1).
In general, a tool that we develop lives as long as the product stays on the market. SAP products sometimes have maintenance agreements for more than 15 years. Therefore, over time we have to maintain more and more tools. This means: if we do not continuously invest into the improvement bucket, the cost of operations increases. In other words: “the KSR bucket will eat up everything”. Therefore, continuous Improvement is our daily bread. This is why the “Innovate” and the “Improvement” buckets always have to be balanced out.
Bucket 4: team local consulting and enhancements (C&E)
Bucket 2 and 3 are explicitly reserved for larger activities. If too small investments are made subject to the portfolio process, we would again end up in micro management. In addition, it is required that POs stay flexible enough to take team local ad-hoc investment decisions.
Bucket 4 can be compared to a flexible “call money account” (Tagesgeldkonto) that is owned by the PO. It can be used to trigger smaller investments into urgently needed requirements, quick wins etc.
Wording
Within the PFM process we decide about so-called activities. An activity gets a go or a kill decision.
An activity is formally described, using a very simple "Lean Canvas".
Activities are time boxed and should be finished after 3 months. The done criteria are adjusted accordingly. This period of 3 months is called a wave.
Decisions are taken by the Production Product Team. It consists of POs and all Line Managers.
In order to roughly estimate the required investments for an activity we ask the question:
How many people would have to work during one wave to complete this activity?
We call the amount of work that can be done by one person in one month 1 PersonSprint, in short 1PS.
Of course, 1PS is some artificial and maybe over-simplifying unit; however, it allowed us to introduce simple estimation procedures.
We defined as well that the size of an activity has to be at least 6PS to be funded from the Innovate of Improve bucket.
How we live the process
The PFM process runs every 3 month to prepare the upcoming wave. The entire cycle currently takes about 2 weeks’ time. It is shown in the picture below.
New activities are prepared continuously. They are first reviewed in our weekly meeting. Afterwards a direct early go/kill decision is taken.
If an activity gets a “go” decision a team of 2-3 POs are defined to continue working out activity details together.
Step 0: collect the budget for the coming wave
Line-Managers together with POs are asked to estimate, how much capacity (in PS) they have in total available for the next wave. In addition, the PO estimates how much capacity his team requires to keep its system running (KSR).
If the product owner wants to reserve capacity for his team local C&E bucket he is asked to make transparent what it will be required for.
The final word on the capacity distribution is with the Line-Managers. This is simplybecause the Line-Manager is responsible to make sure that enough capa is available to “Keep the System” running.
Step 1: kick off the next wave
A list of relevant activities is presented to the product team. The goal and the problem this activity should solve have to become clear. “go”, “kill” or downsizing decisions are made.
Step 2: Activity Walkthrough
The entire team is invited and the new value maximized portfolio is presented.
Feedback is collected, deep dive sessions are offered for those who want to understand in more detail what is behind a certain activity.
Step 3: Portfolio Discussions in the Product Team
The Product Team starts identifying the things that SHOULD be done and the things that MUST be done.
The “should haves” are compared and arguments are exchanged on the importance of a certain topic.
We take further kill decisions or again downsize activities. The goal is to fit the activities into the capacity distribution. It might as well be required to downsize the team local C&E bucket, requested by a PO.
It becomes clear, who in person would be a good candidate to work on a certain topic. Candidates who might need to support another team for a wave are identified. Line Managers get in contact to the candidates and to trigger appropriate change management activities.
After several discussion rounds the new Portfolio is ready.
Step 4: Decision Rollout
The portfolio decision is rolled-out for all teams adn to stakeholders. It is explained how we will invest in the next wave. Kill decisions are explicitly listed. It is outlined why certain topics have to wait and others have priority.
Tracking
During the wave we run a weekly sync meeting, comparable to a daily stand-up meeting in a scrum team. The key messages are presented and documented.
Blockers are identified and follow up actions triggered. The idea of this meeting is to identify activities that are not on track anymore, early.
Global Review Meeting
At the end of a wave, there is a so called global review meeting. The entire team, our L2 Manager and the stakeholders are invited. Team members demo what has been achieved and we determine the wave end status of an activity.
Results
The new portfolio process makes our global backlog explicit and transparent. This backlog abstracts over teams. It becomes clear what needs to be done as cross work.
We asked our teams on feedback. A survey was initiated after the first rollout of the new portfolio process.
In 2012, about 50% of the colleagues worked in cross-team activities. The most “mind-blowing” experience I made is that we did not really have to "force" people leaving a team for a couple of months. We have people in our team, willing to do and learn something else.
I discussed why the colleagues did not address this before and in general received the following answers:
“I fear that I need to change into a new organizational setup.”
“It was never clear to me, what the other teams have to do.”
In particular the second statement was a learning. The best way to break up team silos is to foster employee exchange between the teams. One of the reasons why the silos exist is simply resulting from a mistake of the past: I have missed to appropriately communicate our global backlog.
The measurement of "KSR" investments have become a nice management tool to track our overall cost of operations and to identify areas where improvement investments will bring a good and quick return.
We take investment decisions together in the Product Team, this means we argue on the importance of different projects. This simply requires one PO to understand the needs and goals of topics of another PO outside his scope. Otherwise, it will be hard to participate in the investment discussion and it is likely that the projects he is proposing will not make it. Justifying the investment in front of the people who as well apply for “a piece of the cake” is a nice exercise. Backlog that fits to a team but not to the strategy have become almost impossible.
Based on this new cross work we finally managed to fund some overdue hang-overs, topics we did not manage to touch since years. In the meantime we are scaling up the service model to further service areas in our orgnization.
- SAP Managed Tags:
