Is Demand Management Failing You?
In traditional project management, one of the first things the team does is participate in a risk workshop. And you would never lose money betting that “resourcing” in some form will be one of the top risks, no matter what the project.
Project Managers have a justified fear of not being able to call on the skills they need when they need them. Inadequate resourcing leads to a high likelihood of delays, cost overruns, scope cuts or cancellation. Sometimes all of them, one after the other.
This happens despite having an approved business case, an activist sponsor, a PMO looking after the Portfolio of change, and a decent risk register. The risk will still materialise for the PM. Again and again for the same project.
Pull the lens back a bit, take in the whole forest. We can now see that tweaking resource management cannot solve the problem. The failure is much further upstream, in the demand management process: how does work get into the system, and why is there is so much work in progress in the system?
House of PMO carries out regular polling of the PMO community. In those polls, Resource Management is ranked as one of the top concerns of the PMOs. Info-Tech Research Group have found amongst their clients that IT departments have on average six times more demand than resources available across their Portfolios.
You probably do have a demand management process in your organisation, and it is perhaps failing you.
How to Slow Down Delivery and Antagonise your Stakeholders
The Myth of the Lifecycle
Lifecycle methods and standards came into wide use about 50 years ago. The corporate environment and change disciplines have evolved, but this thinking still assumes a linear process of change, which starts at a defined time from a well-defined baseline.
This is not the case: the process of change (and the demand for it) is continuous, perhaps it has ‘seasons’, such as the advent of the annual plan, but it has no beginning and no end.
The collection of possible projects has no fixed scope and cannot be reasonably managed by change control, which assumes it deals with exceptions – not the rule.
In a ‘lifecycle’ mindset, demand management happens at the “start” of the process, a funnel narrowing the options through early-stage gates that ‘vet’ the proposed business case of a project according to a variety of criteria.
A new project gets launched inside this linear model, assuming a predictable Portfolio and using priorities rather than capacity as the trigger. Later, those charged with execution and delivery will get hit by a perfect storm of all too predictable risk.
Not Necessarily Predictive
The lifecycle paradigm was designed to solve the problems of another organisational era, but let’s not digress into that topic. The lifecycle paradigm for the management of change assumes that most projects benefit from a predictive approach. Most projects do not benefit from a predictive approach, even if a few do. This error is quite significant in the context of demand management.
The same applies to other forms of managing change, not just projects. A PMO should assume that the majority of the Portfolio they support will be better suited to adaptive approaches, not predictive ones.
What does this mean for demand management? It means that effort spent in forecasting resource demand in great detail, far in advance, is most likely a waste of effort. Therefore, the detailed resource profile should not be a criterion used in the gating process that allows a project to proceed.
The most common situation, and one of the critical reasons stakeholders ignore the demand process, is that the criteria used for gating are so contested and artificial that the real decisions are made on other criteria, such as the influence of proposers or the preferences of the suppliers.
Stakeholders have a permanent emotion of annoyance as the baseline from which they get further annoyed about specific things. Could it be because the whole delivery pipeline is like a motorway on a bank holiday?
That’s the effect of an amateur demand management process: speeding up the start of work and delaying the delivery of work to the point of cancellation.
A Better Approach is Available
The pre-condition for making demand management work is to discuss the situation with the stakeholders of the delivery unit in the context of organisational strategy – not individual projects or other initiatives.
The PMO should be able to demonstrate alternative ways of viewing the delivery situation so that stakeholders’ views can evolve. The concept of the traffic gridlock mentioned above, the idea of excessive WIP (work-in-progress), is well known in Lean-Agile approaches, Product Development, the DevOps movement, and the Critical Chain / ToC approach.
It is not a sudden flash of insight; it is backed by much evidence. I won’t cover that now, just to say that the mindset work needs to support the specific techniques that I will cover next.
Dr Phil Driver published “Validating Strategies: linking projects and results to uses and benefits” five years ago. It arose from his work in large-scale industry-sector strategies and later with the more complex public sector strategies. The record of translating strategy to the delivery of what the organisation needs is dismal.
The key insight around which he has designed his OpenStrategies system doesn’t seem earth-shattering until you work out the implications for processes like demand management and the role of the PM, for instance. This is what he calls PRUB-Logic, which represents the universal sequence of “create assets/outputs and enable and motivate their uses to create outcomes/benefits”.
Driver’s universal sequence is what a PMO would recognise as Change Management, such as a Transformation Programme, with projects inside it to create various assets and change managers guiding the significant work that leads users to generate benefits. Sadly, most methods, frameworks and standards decouple the creation of the assets (projects, products) from the usage of the assets, which is the only thing that leads to benefits and, therefore, to the delivery of the strategy. As a side note: it is ludicrous to make a PM accountable for benefits realisation. Think about it. Long gone…
But the compelling insight for me is the requirement to plan from right to left over the PRUB delivery sequence. (to BURP?).
A PMO/Portfolio Office, working with the relevant Strategy Planning area, needs to translate the components in the current strategy iteration into benefits that can be agreed upon. Then, we should find out, design, and envisage who would use what assets/processes to generate the desired benefits.
What would they do, that they don’t do now, to make value that doesn’t exist now? How would they do it?
One of the outcomes of this analysis is a list of possible assets/outcomes that need creating or improving. From this list, the optimal mix of programme, project, and product delivery is set up as demand.
Now we can talk about Demand Management. We are starting from a backlog aligned to strategy, so the fundamental questions for the first stage gate deal with relative contribution to the benefits profile and timing. These conversations at the right level allow the PMO and stakeholders to set up the proper bottleneck for the delivery pipeline, based on available funds and skills and the level of change that the organisation wants the affected user to absorb over the planning period.
We will discuss Benefits Management another time, but for now, keep this in mind: projects never deliver benefits. They are not even meant to.
This technique comes from a different point of view, although it shares the same insight.
If I remember right, it is based on work by Ingrid Domingues in the Test-Driven Development (TDD) domain. The Impact Mapping technique and its variety of applications have grown around the book by Gojko Adzic: “Impact Mapping: making a big impact with Software Products and Projects“.
The Lean-Agile Product Development community uses it extensively. The diagram below comes from Tom Donahue‘s website and is based on the book.
The most powerful insight for me is that Impact Mapping directs you explicitly to focus on behaviour change first and then explore ways we can support that behaviour change. The ‘how’ question here refers to behaviour, not to how we can deliver functionality.
Regarding Demand Management, the technique can be used to work through the strategic goals, asking the questions about actors (users) and behaviours (uses) that lead us to the list of possible deliverables that could help those actors create value. Specifically, the value envisaged by the strategy as benefits.
Note that list of candidate initiatives for Demand Management to winnow is primed and validated to give the value the organisation needs, whether projects or continuous product work. An Impact Map ends up looking like a directed mindmap.
The next step is to decide which deliverables to try first. You may achieve the goal (benefit) a lot faster than you expected. If not, you have at least delivered something of value. For this approach to work, if you are using traditional projects, these must be defined at the end of this analysis to be efficient and aligned. Please note how superior this approach is to hastily written Business Cases for pre-defined projects, using made-up benefit of great vagueness.
A PMO/Portfolio Office can use Impact Mapping at lower granularity levels to validate value questions when making priority calls. It has many documented applications, but it is vital to consider the context to understand how and why the technique will yield what results. Adzic, Domingues and Berndtsson wrote a whole article on the four different contexts. Maybe for another day…
There are many suitable methods and techniques, aside from these two that I’ve worked with. What they all have in common is an understanding that continues to escape the major frameworks and certifications relating to project management: that benefits give rise to projects and not the other way around.
It’s not a good idea to treat this journey I’m describing as something that is easily fixed. It is not. However, there is much that you can do right now.
Why Resource Management is Not the Answer
Resource Management or Demand Management?
If demand management is not fit for purpose and you have a permanently blocked pipeline, there is no point talking about resource management. Instead, the PMO/Portfolio Office should challenge the assumptions in play about things like matrix management, the existence of self-managed teams, the mix of work where selected team members go to the work, and work where the work packages are assigned to teams that stay together.
Technical Debt and Business-As-Usual in the Mix
In general, for old-school projects that get their resources assigned to them, query the assumptions around technical debt very strongly. Is it clear what technical debt affects the new work?
There are also assumptions around what happens to BAU work customarily carried out by team members assigned to projects. In the case of both BAU work and technical debt work, the problem is that the business case for any new project will not have costed that effort as part of the project, so it becomes SEP: someone else’s problem.
In effect, strategic decisions get pushed down to the lowest level, where random team members will decide what to work on and when without anyone else up the chain interested in recording those decisions.
Resource management tools make the situation worse because their reports give the impression of being based on data that carries meaning. Everyone will waste significant time discussing things that mean nothing, given that the assumptions are wrong.
Where to Start?
Just to stress again: the work on changing minds must start before, or at least progress in parallel to, introducing new processes and tools.
In this context, “changing minds” means that the stakeholders of change management understand the relationship between strategy, benefits, continuous demand, and delivery flow. Otherwise, the introduction of new processes and tools will be for nothing. But assuming that we are doing that…
The very first step is to clarify how much “headroom” you have as a PMO to try something new. You may need to stop the overwhelm first. If that is the case, don’t go the extra resource requirement route, or you will be caught in a Catch-22 trying to justify resources to justify new work.
The way out is to cut out the low-value activity.
These are the rituals and reports that are only done because they’ve always been done. Another way to pinpoint them is to ask, or verify via minutes, what action decision-makers take as a result of the report such and such.
If little or none, either archive it or make it available on-demand, with an SLA attached that includes the question: “what decision-making does this report support?”. There are many ways, and the right way will depend on your context and how much headroom you need.
Experiment and remember: it’s easier to seek forgiveness than permission.
Start laying the foundations for a better approach. Most of the foundation work is helping stakeholders see things differently. Presentations and documents will be of limited value.
One good way is to start using a technique such as PRUB or Impact Mapping to validate the work already in the pipeline. You will never get a clean slate to start from. It’s a hard battle to get to the situation where you no longer have a mass of non-strategic, low-value work eating up money and skills. Use these techniques to rate the initiatives in play when you don’t have a clean slate to design them.
You can be polite but insistent. It could be a new report or dashboard that rates initiatives against two risk themes:
- Whether they have a clear line of sight to a strategic benefit with a metric that the Board actively measure
- Whether the target population for the change are aware of it, agree that they can use the output, and agree that using it they can deliver the benefits that the Board will actively measure
These are new powerful lenses for your PMO, but not mirrorshades or rose-tinted.