Matrix Management and Getting things Done

People not resources

Many organisations in New Zealand, and in particular the Wellington government sector, apply a matrix management and cost recovery method to IT delivery.

In summary, this structure looks like this. People of similar skill sets (such as developers as one example, or testers, as another) are organised around practice managers.

These practice managers have numerous responsibilities. Firstly, they hire’em and they fire ‘em. Their specialised knowledge of the roles allows them to hire the right people. Secondly, they standardise practices across the roles. This allows them to standardise training and development, but it also has the effect of enabling people to be interchangeable in roles, at least in theory. You could, in theory, pluck out a developer from a project and replace them with another, with little or no impact to the execution of work. Thirdly, the practice manager has responsibility to ensure that all people, usually referred to in these environments as ‘resources’ are fully utilised. In effect this usually means 80%, with 20% left spare for training and development, and other internal work.

The focus of a practice manager is usually to protect their people from being used outside their remit (ie prevent developers from doing testing) and to cost recover. That is to say, ensure that the cost of maintaining a cohort of specialists is recovered from the customers. In the case of matrix cost-recovery organisations, the customer is usually a handful of business units, who have an allocated IT spend and compete via the PMO to have their work prioritised.

So the question must be asked - is this model any good? to which the answer is - it depends largely on what you care about.

Matrix management with cost recovery is great at;

1. Cost recovery

2. Standardisation of roles so people can be resource levelled

3. Keeping people busy

   
   

It is weak at;

1. Completing end to end work

2. Eliminating dependencies

3. Creating effective long standing teams

4. Matching demand to capacity

5. Minimising complexity

   
   

Let’s look at each one of these in turn.

Cost Recovery This model is optimised for cost recovery, so it is very good at it. My observation would be though, that the organisation is simply clawing back cost from itself. The cost of the IT department is usually fixed in any case, so this is really just a game of free-market theatre, pretending we are buying from a vendor, but a vendor who is monopolistic, and has no ability to shrink or grow according to need.

Standardisation of roles This can be a genuine benefit when hiring. Deep knowledge of the skillsets in a practice can help identify the right people.

Keeping people busy It is a common delusion that maximising business neccesarily leads to maximising outcomes. There is a large body of knowledge, largely ignored in New Zealand, that suggests that this is not the case. In fact there is strong evidence that high levels of utilisation lead to much lower levels of completion, even in some cases a complete collapse of outcomes. As the saying goes, a highly utilised motorway is a carpark.

Completing end-to-end work There is a lot of evidence that long-standing, cross-functional teams massively outperform every other type of organisational form. This is for two key reasons - reduced dependencies and increased trust. Matrix management slotting people in and out of teams as the enterprise resource plan allows means teams never get to go through the Tuckman model of Form, Storm, Norm, Perform, and remain stuck in a cycle of form and storm. Drama ensues, which at least gives the delivery practice something to focus on.

Eliminating Dependencies This structure in fact artificially creates dependencies between otherwise unrelated projects. If I must wait for another project to finish with, say, a group of testers, then if that project is delayed. And then as my schedule is pushed out, i in turn delay the project which was to use those testers after me. Or, even worse, my priority is too low, the testers go elsewhere and I am stuck in a holding pattern until there is enough spare capacity to allow me to proceed. 

Usually it is not as black and white as that of course - the more common occurrence is the Project Manager is given less than what they need, and then asked to still meet their timelines with less. Smart Project Managers (and I confess to having been guilty of this in the past) anticipate this and pad their estimates of what they need, on the expectation they will be shortchanged. Now we are in a game of bluff with our practice managers, and trust is quickly eroded amongst managers who ideally would collaborate.

Creating Effective Long-Standing Teams Because people are shuffled in and out of short lived project teams, they do not have an opportunity to interact, build trust, and create shared accountability. Relationships by neccessity remain transactional. Tuckman’s model again, as well as all of the disfunctions laid out by Lencioni. Absence of trust leads to fear of conflict, which leads to lack of commitment, which leads to avoidance of accountability, leading finally to inattention to results. Failure becomes highly likely, but is then quietly swept under the rug.

Matching Demand to Capacity A system overloaded beyond its capacity will run much slower than one that is not. Paradoxically in most systems limiting the amount of work being done will actually allow more work to be completed in the longer run. Think again of the metaphor of traffic - civic engineers put systems in place to limit the amount of simultaneous traffic (traffic lights, especially at on-ramps, for example) to avoid a traffic jam. In a traffic jam there are lots of cars on the road, and everyone is busy, but nobody is reaching their destination. Oh, and they are all burning fuel as well.

In a cost recovery matrix model, practice managers and It teams are incentivised to take on more work than they can handle because they need a charge code to bill their time towards. When a piece of work gets blocked, they need a backup piece of work they can bill to so they can recover their 80%. Paradoxically, the additional work they take on leads to an increased likelihood that work ends up delayed or blocked, which leads to a downward performance spiral. Finance people who cannot understand how projects in the technology portfolio can simultaneously be individually massively over budget, but collectively massively underspending, this is why.

Minimising Complexity This model introduces a large amount of complexity, and that complexity needs to be managed. Usually this takes the form of detailed hundred-line excel resource plans, and detailed annual resourcing plans. Because they often detail work across hundreds of projects for hundreds of people across 200 or so days, they are both massively complicated, and swiftly get out of date. And in most cases, they are based so much on false assumptions that they are worse than useless for anything other than giving senior management a false sense of security that everything can be done. In any case, this detailed planning and updating of detailed artefacts requires an army of PMO workers, who of course are additional cost. 

So what is the solution?

• Fund IT

It is a meaningless game to charge back. Simply fund the IT function. If you have competing needs, apply a percentage allocation to the work - we will do 20% to you, 30% for you, 20% on support, etc. Track that percentage. Each business unit can prioritise within its allocation, reducing conflict. In cases where there is high priority work outside that percentage, the PMO can bring together the necessary parties to agree an adjustment to the allocation, and agree where the extra capacity is to come from. 

An added bonus is that dry PMO governance approval boards become redundant.

• Look for Products

Internal IT departments are a lot more like a factory delivering invisible work, than Apollo space missions. By which I mean, aside from some relatively small unique aspects, the same sort of work is often done over and over. Rather than assemble, disassemble, and reassemble teams around this recurring work, let them stand as-is and learn to deliver in a more effective way over time. Work with the practice managers to permanently assign people to these product teams and seek their feedback on the impact of this on the practices.

If at all possible, align these product groups to the value streams (flow of value from the organisation to the customer) so that the benefits of the product delivery is directly experienced by the customers or clients.

• Reduce Cycle Time as a priority

Cycle time is the time between when a piece of work is started to when it is completed, and when this concept is applied in conjunction with value streams, it becomes the time from when we first become aware of a customer or clients needs, and the time we satisfy them. 

This gives us a number of benefits. We end up managing a lot less work at once. We finish work faster and can learn from the experience. The customer or client gets value from us faster. It requires and enables us to reduce the amount of work we do at once, reducing the overhead of managing complexity. And it makes the work cheaper to complete - eliminating wastes around dependencies, switching between work, and delays around over-utilisation.

If these observations resonate with you, and you would like to talk more about how I can help you achieve better outcomes, please reach out to me at russell@flowspring.nz to book a call.