Project portfolio management is in most organisations all about the strategic projects. Naturally, the focus is on getting as many of these, mostly far too many, projects through the development organisation as possible and spending as little resources on minor functional improvements, upgrading systems/platforms, and fixing bugs as possible because that is considered less valuable. It is rarely understood that the starvation of these other tasks leads to less overall value and congestion of portfolio planning. In other words, strategic portfolio management is an enemy of itself: too many large strategic projects lead to starvation of other tasks, which again leads to even more strategic projects, more starvation, and a vicious cycle starts.
This article will introduce The Portfolio Circle, which is a more holistic understanding of portfolio management, and it will explain why this is a necessary approach for those organisations who want to maximise value for their customers as opposed to just executing single projects.
The goal in developing this model has been to reduce the complexity of portfolio management, and through deliberate simplicity, create a level of understanding that can contribute to a more holistic use of the resources available to create value for users and customers.
A second article (found here) will cover how The Portfolio Circle changes portfolio management and the implications on development teams.
Challenging Tradition
Organisations are so comfortable with prioritising based on cost/benefit calculations on projects and control these from a project board or whatever they call the forum, where high-level managers meet to prioritise and follow up on projects. Their focus on the project delivery pipeline is so high that they lose sight of the real value stream experienced by their customers.
I claim that the project mindset is a significant obstacle to delivering maximum value to customers, which should be the actual goal of every organisation. I know this may be a provocative statement for many readers. Still, I invite you to read through this and understand how much larger the potential of your development organisation is if you change your mindset.
To support the mindset shift, I will introduce you to The Portfolio Circle, which will provide a more holistic view of the value creation, the delivery process, and resource allocation in your development organisation. It will incircle every activity that creates value to your customer, both short term and longterm, both direct and indirect.
I challenge you to leave your project mindset aside while you read through this article, and try to feel empathy with your customers and only think in terms of value for them. Try to take outset from their perspective, which is the product they use every day, and forget the internal view: the changes you have to deliver.
The Portfolio Circle
The project paradigm has put an equal sign between the strategic project portfolio and the value creation in the organisation. Are projects the only way to create value? Is that the only value your development organisation creates?
When you raise your focus from strategic projects and look at your organisation as a whole, you will probably find that a large part of your employees is not fully occupied with strategic projects. The wast majority of employees will spend hours every week on something else than projects. Many will even spend the majority of their time on something else.
I am pretty sure that your employees spend their time on the four types of work depicted on The Portfolio Circle to the right. The area of the circle corresponds to the total capacity of your development organisation, and the size of each area indicates how much capacity is used on the different types of tasks.
How large each area is will be very different from organisation to organisation, but the four are all there, and the total matches the total capacity. Every large or small task will be in one of the areas.
Let’s start with the definitions of the areas before digging deeper.
STRATEGIC INITIATIVES (RED):
Strategic Changes, i.e., they change the business from the perspective of the customers. Strategic initiatives typically have the attention of higher management and are subject to strategic portfolio planning. They generally are significant investments over longer periods. Traditionally these are the projects.
IMPROVEMENTS (BLUE):
Improvements to your systems/services that help to keep customers/users happy and secure the flow of internal processes as business slowly changes.
UPGRADES (GREY):
Upgrading the systems you have bought to support business, e.g., ERP-/CRM-systems to take advantage of new functionality and upgrading your development platform to newer versions.
SUPPORT (GREEN):
Fixing bugs and supporting users who cannot complete their tasks without help. These are the task that cannot be postponed without threatening the life of the organisation or its customers. Be aware that this is a much narrower definition than used in most organisations.
The definitions of the areas are important because it allows us to see clearer in which ways they are different and why it has led us to separate them to different groups of people, e.g., in strategic initiatives.
The work in the four areas differs in four ways:
- The value they create
- The urgency of a solution
- How resources are allocated
- Who makes decisions on when and how
Let’s dive a bit deeper into the differences between the different colours.
The Enterprise Portfolio
At the Enterprise level, the area of The Portfolio Circle corresponds to all the resources available for you to solve the different tasks in your organisation, and the areas of the different colours correspond to the allocation of resources to the different kinds of work.
STRATEGIC INITIATIVES:
We all know the strategic initiatives. They are the most substantial investments in the organisation and are also considered the most valuable work in most organisations. They are prioritised by management and have first access to resources. Initially, the urgency surrounding the initiatives is very high, and every other type of work must leave space for these, even (or especially) when they get delayed.
In many organisations you’ll find “strategic” projects that are not really strategic for the business – they are merely bundles of improvements or large upgrades that are camouflaged as strategic to be able to attract the necessary attention.
A paradox with the strategic initiatives is that despite the initial urgency, the organisation can lose interest in them and stop them before they have delivered the promised value.
IMPROVEMENTS:
Improvements to your products/services might not be significant, but they can be very valuable to different user groups, sometimes even crucial for different parts of your business to grow. Nonetheless, improvements have a hard time being prioritised in organisations with a high focus on strategic initiatives. Value is rarely compared relative to effort across the different types (colours) of work, improvements rarely have high urgency, and mostly they are left to lower management to prioritise. Therefore they suffer when resources are scarce, which they almost always are.
Some organisations try to work around their preference for strategic initiatives by reserving some capacity for Improvement task, so the business doesn’t starve completely. Often it doesn’t last longer than until the first strategic initiative suffers, or a new strategic initiative that cannot be postponed shows up.
Starvation of Improvements is the root of conflict in many organisations because the business and product managers struggle to see through the priority mechanisms and often blame IT for inflexibility because they do not understand why IT cannot just find a few hours of development.
As mentioned, starvation of Improvements can lead to more Strategic initiatives because Improvements are bundled to disguise themselves as strategic.
UPGRADES:
When you use software developed by someone else – no matter if it is a small open-source library or a large enterprise system – there will continuously be upgrades to perform. Upgrading is a good thing since it provides new options for business and developers, removes bugs, etc. Nonetheless, organisations consider upgrading to have little value because it mostly comes out of need, not a desire. Therefore, it’s the least urgent task, and the value will not be apparent until later.
The decision to upgrade is mostly given to middle management in the IT department, and it must often fight, cheat, or whatever trick in the book that works in their organisation to get capacity free to perform the Updates. Lack of power in the organisation and lack of urgency of the tasks are against them.
SUPPORT:
The Support definition used here only includes tasks that are threatening the business of your organisation or your customers. Therefore fixing bugs and supporting users is the most urgent kind of work, and it must be handled immediately, and hence the decisions are made by the employee who gets the call/ticket. If tasks are postponable, they belong to Improvements because it is a choice when they are solved.
This strict definition means that Support tasks on one side essential for the business/customers, but on the other hand, they appear to have no value for the organisation. They are the interest rate that needs to be paid for not delivering complete and bug-free solutions. It also means that you cannot decide how much capacity you invest in these tasks. The quality of previous deliveries determines it.
In many organisations Improvements and Support is left to a non-strategic part of the organisation. They invest a fixed and low capacity, and they defer decisions to the “factory floor.”
The table below summarises the difference between the different types of tasks regarding value, urgency, allocation, and decision making.
The Dynamics of The Portfolio Circle
So far, The Portfolio Circle could as well have been a traditional pie-chart, but as we now turn to the dynamics of The Portfolio Circle, it’ll be clear why it looks like it does.
The circle is cut by two horizontal and one vertical line. The horizontal lines separate the portfolio by decision-maker: Top management decides the Strategic initiatives, middle management, the middle, and Support is handled reactively by employees. The vertical line separates what is typically decided by middle management in the business (Improvements) and IT (Upgrades).
Arrows illustrate the dynamics of the lines in the figure below. How an organisation chooses to balance the capacity for the different tasks is not without consequences. Some of these consequences form a vicious cycle.
The upper horizontal line can be pushed down by a decision to focus more on strategic initiatives, or up to leave more capacity to improve and update existing products (red arrow). Most organisations try, as mentioned above, to maximise the capacity used for Strategic initiatives for the apparent reason that it has top management’s attention and has the highest perceived value. Pushing down the upper horisontal line down starves capacity for Improvement and Upgrades.
Sometimes both are reduced (the upper horizontal line goes down). Other times only Upgrades are postponed (the vertical line goes right) because it is perceived to have no consequence.
What happens when the capacity for Improvements is reduced? Will the business units just resign and give up asking for the changes that are crucial for them to reach their goals? I know a few business people who will do that. Either they will use all their informal connections in the development organisation to have their stuff done anyway, or they will inflate the size and importance of their work to bring it forward as a Strategic initiative. The latter means the need for more capacity for Strategic Initiatives, and the vicious circle is spinning.
When Upgrades are postponed in favour of Strategic initiatives and Improvements, it seems at first to have little consequence, because nobody asked for the new possibilities following the upgrade. The real price of postponing Upgrades is too abstract a value proposition to be taken seriously.
It is more expensive to wait and do several Upgrades at the same time than it is to take them one at a time. It might be contra intuitive, but as time goes, the complexity of an upgrade increases because of dependencies. Examples of dependencies that cause the increased complexity are
- previous Upgrades to the same system
- integrations from proprietary software
- Integrations to other systems/components that require upgrades
- Data used in other places, e.g., your data warehouse
- etc
Unfortunately, it often ends in extensive complex platform projects when some vendor ends service on the old version. The upgrade of that system cascades to upgrading a lot of other systems and proprietary interface development. I think that anybody who has tried to postpone upgrading a system several versions, remembers how large and complex it was for both developers and business people when it became inevitable to upgrade. It ends up as a strategic initiative to get capacity – and the vicious circle continues.
The bottom horizontal line is defined by the quality of your products as mentioned previously, and the needed capacity not really up for decision. It will require investments in Improvements and Upgrades to reduce Support.
I am aware that some organisations deliberately leave bugs behind in their software and leave their users without help when they need it. If you don’t help your users, you not only lose business at the moment, you also miss the opportunity to fix the problem and avoid it from bothering other users. In these organisations bugs usually pile up at a cost they do not realise.
Fixing a bug just after it was released will typical take minutes, while the same bug half a year later might take days because the system was changed many times, the data involved in the bug was changed, the developer has forgotten all about what he initially programmed, etc.. Poor business.
Not fixing your bugs is like not paying the interest rates on your debt. It just means higher interest at a later time. In software development, that means longer development time on new stuff due to the insecurity among the developers because they are afraid to make more bugs. Slower development time results in an increasing queue of Strategic initiatives, more pressure to finish them fast, and following from that: more bugs – the vicious circle spins.
In summary The Vicious Cycles could look like:
Breaking the Vicious Cycle
You are lucky if you’re not, to some degree, caught in the vicious cycle by the choices made in your organisation over the many years.
If an organisation has run many waterfall projects with tight deadlines, chances are, that they are left with a lot of debt. The projects didn’t have time to finish all the desired features, or the user experience was less than optimal, and quality suffers from insufficient time for bug fixing. That leaves a significant demand for Improvements and Support.
If you, on the other hand, are among those who have realised that bug fixing takes less than an hour if it is brand new and you have invested heavily in automated test and deployment, there is a good chance that you spend a few percents of your organisation’s resources on Support. You can say that today’s cost in Support was your own choice – years back. To break the vicious cycle here, jeopardising quality must stop, and investments must be made into automation even though it takes capacity from Strategic initiatives.
Likewise, Upgrades are determined by previous decisions: If you have bought a lot of third party systems and components and have invested in the integration of these, you will have a heavy burden in upgrading — hopefully, a deliberate choice you made as you considered the lifetime cost of your investments. Opposed to the Support, you can decide when to Upgrade, which makes it possible to finish Strategic initiatives/Improvements before you have to jump to it. Ignoring it, however, just makes it more expensive, as explained above. Never get more than one version behind if you have a complex system landscape, is the best way to stop the vicious cycle.
If you want to reduce the effort spend on an Upgrade, automation of the upgrade process and verification is a good idea. You can also continuously look to simplify your systems landscape by switching components. Sometimes the functionality you have purchased in two different systems can be handled (almost) in one of them because one vendor has released a new module. So if you are prepared to change the business processes, they are performed within the one system with whatever compromises it may require, you can also reduce complexity and break the vicious cycle.
Both Strategic initiatives and Improvements are new stuff, just sliced in different sizes. Following the previous discussions, the best advice to break the vicious cycle is to act against the dynamics of traditional project portfolio management that leads to large projects and realise that any Strategic initiative is a large number of smaller strategic improvements. Smaller increments free up capacity in the portfolio more often and thereby make it possible to prioritise what is most valuable without increasing the capacity for Strategic initiatives and thus avoid starving the other types of work and start a vicious cycle.
What is the optimal balance in The Portfolio Circle?
Balancing the capacity of the different parts of an organisations portfolio is not really about avoiding getting into the vicious cycle. It is about generating as much value as possible.
Most portfolio management is about optimising the value from Strategic initiatives, leaving the value optimisation of Improvements to another process and other people, Upgrades to a third, and Support to a fourth.
It is pure luck if the capacity for each type is balanced such that the organisation gets the most value from a customer’s perspective because prioritisation does not happen in the light of the whole value stream. Byte size strategic improvements make them comparable with all other types of improvements and it’s possible to maximise value creation across all changes instead of just projects. There is little correlation between the value and the size of a task, which is another reason not to distinguish between strategic initiatives and improvements.
To be able to make the optimal prioritisation of value, organisations should not optimise each type of tasks separately. Instead, the organisation should assign capacity according to the total value created within each value stream, and all four types of work should be prioritised together within each value stream. The figure below illustrates how the full capacity is assigned to three different value streams while having responsibility for all four types of work.
The second article (found here) will go deeper into the implications of The Portfolio Circle to portfolio management and on development teams.