Portfolio Management

Making sense and value-driven are undoubtedly the most used two words in Agile. All the people aspects (PX), customer-centric issues (CX), and process optimizations (SX) are well documented. But in a business context, you find a lot of incoherence when considering budgeting, funding and return-of-investment.

One of the most common misleading assumptions I meet in my consulting is that a line of business is a service for the organization. That idea is one of the oldest and most resistant beliefs in enterprises. It assumes that those lines are at the service to the “real” value creation flow or to clean up the enterprise from all risks and threads. That’s a valid argument. The problem comes when the budget run starts.

Budgeting is a weird process if you are looking deeply on it. You have to know much you spend a year to run. You have to plan projects, and you have to know how much people you need to cover both activities. Once you finished negotiating that budget (mostly your headcount), then you start your year until next quarter. Every quarter, controlling is coming back to you and asks to reduce your budget by x %. In between, you have new customers, and board demands to fulfil. So, you are cutting all the necessary budgets, starting with third parties. But, on the other hand, you keep the pressure on your team to meet the plan you designed with additional demands and less budget than expected. And because the team is agile and that you learnt that Less is More (fewer people for more work), you believe that the magic happens.

This example sounds quite harmful, and I’m feeling sorry about that. But it is 99% the reality.

Why portfolio management matters?

Portfolio management is part of the Enterprise Experience (EX) aligning the metrics from Organizational Experience (OX) with the Enterprise business strategy: The strategy is deployed top-down from EX to OX. OX design tactics to enable the approach.

The portfolio management approach collects data from such strategies and all other initiatives like transactions or Platform activities to address adequate funding for the right investments. Like any investments, you need to know actuals, expected outcomes, ROI and time-to-market at least.

Examples:

Some of my customers had very detailed metrics in their portfolios like the names of all sponsors during the whole project/program lifecycle, multiple stages, multiple KPIs. An example from a governmental portfolio was:

  • Key Success Factors
  • Critical Success Factors: manage capacity, identify outsourcing candidates (projects, tasks)
  • Possible Success Factors: workflow consolidation, workflow optimization, set up a governance model
  • Necessary conditions
  • Workflow has be visible and known by the whole stakeholders
  • All work is made explicit
  • Visualize flow
  • Measure and remove constraints

Another example of portfolio management in Finance:

Benefits:

Points of attention:

  • Strategical project selection (sorting): strategic alignment, investment value, project risk control, project prioritization
  • Maintenance optimization: maintenance budget lead through strategy deployment, consolidation of maintenance budgets
  • Projects optimization
  • Dynamic leadership and governance: right resources at the right time, portfolio governance, regular projects follow-up

In 2008, I discovered the work of Tamara Sulaiman and Brent Barton on AgileEVM. The idea was to use the old concept of Earned Value Management and to adapt it to agile projects (AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle, InfoQ, T.Sulaiman 2007). It has been designed to:

  • “Be lightweight. AgileEVM leverages already existing work metrics, adding little to no work to the current processes.
  • Add value to Agile teams and stakeholders by providing data for decision making.
  • Be cost-effective to implement.
  • Be at least as accurate as current methods.”

In the agile context, most of the team are using artefacts which are “native agile indicators” like:

  • A Product Backlog: a list of functional requirements delivering value for the customer, and experience for the users.
  • Velocity: the amount of work that a team delivers during a sprint (iteration, feedback loop).
  • Backlog Size: the sum of all functional requirement estimated in “business value”. “Business value” is an empirical number usually from 999 to 0, helping the customer to prioritize from the must-haves to the nice-to-have.
  • Backlog Size/Velocity = number of sprints needed to deliver the project.
  • Story: stories are “user stories” or a reduced form of a functional requirement from a user perspective. Non-functional requirements like TechStories (technical development), Support, Tasks are never counted; they consume the velocity (sum of delivered stories).
  • Story points = allocated team effort to a story.

The objective of Agile Portfoliomanagement is:

Using key earned value management concepts

Metrics

I’m quite sure that the Portfoliomanagement purist will have a chock, but the concept is to keep things as simple as possible. Most of these data are available and doesn’t need more than to add the simple formulas in an Excel sheet. If you are smart, you can easily program a query in a tool like Jira to generate those data automatically. It should not be time-consuming but help to see where you have to improve your workflow.

From my experience, here are some simple points to take care of:

Crowd or organization or even program is the upper level of portfolio management. In the Agile portfolio management approach, Product backlogs or Team backlogs (multiple projects, swarms, transactions) are considered like Portfolios.

The “Simple rule” approach inherits the idea to use precisely the same spelling and same format each level.

From an AO perspective, the experiences can also be visualized in those boards. That visualization will cluster the activities through swim lines to measure the efforts in:

  • Customer experience: mostly swarms and projects
  • Service experience: projects, classes of service
  • Organizational Experience: at “Crowd” to distinguish team activities

Originally published at https://myao.blog on January 9, 2020.

--

--

--

On my business card, I wrote Agile Coach. My Agile coaching is an evolution of systemic coaching putting myself in the system and not as an outstanding observer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Communications Introductions: Cath Anderson

The next generation of kind leaders

How To Overcome Any Challenge As A Second-In-Command

Nonprofit Mission, Vision, and Values

Culture: A Product Of Organizational Structure!

Why Every Business Needs HR Management Software

“Fixing stuff around yourself”, experiencing leadership without an authority

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Pierre Neis

Pierre Neis

On my business card, I wrote Agile Coach. My Agile coaching is an evolution of systemic coaching putting myself in the system and not as an outstanding observer

More from Medium

The Three Laws of Scrumpany

What you need to know about Scrum-part I

The Use of Spikes in Sprints

Requirement Life Cycle from Start to Market