Utilisation, Teams and "Resources"

In many companies, especially those who provide services to external clients, the main focus from a project management perspective seems to be on resource allocation and utilisation. People are viewed as individual “resources” and an important goal is to maximise people’s utilisation (Before you say this is not true, think about how important this metric is at your company and that people tend to optimise what is being measured).

I know that especially for vendors who often charge by the hour or have to keep cost down in a fixed price and scope scenario, utilisation is hugely important. That’s fair enough. However, making utilisation the main driving factor, will backfire and ultimately lower utilisation.

Why is this a problem?

By foregoing the team approach, aiming to maximise utilisation and piecing together projects through dynamically allocating and re-allocating people we:

• Take away the focus from the real end goal which is delighting our customers (people who either pay for, use or support our application).


• Inadvertedly sub-optimise individual parts of the system such as e.g. design, frontend development or database design by isolating them from the whole product.


• Miss out on optimising the development of the whole product or project.


• Ignore the fact that software is developed as one-of-a-kind, which causes variety and makes predictive planning impossible. Honestly, stuff often gets finished either earlier or later than initially planned and there’s nothing we can do about it.
  
  
• Have difficulty absorbing this inevitable variety if resource utilisation is too high as people will either be idle or unavailable as a consequence of variety and lack of slack (This is bad for utilisation and people will either be stressed out and over-worked or bored. Also, no slack makes it difficult to deal with emergencies and opportunities).


• Run the risk of cascading delays within projects: If one part of the project is delayed dependent parts will be delayed as well, leading to a cascading effect.


• Run the risk of cascading delays between projects: Projects waiting for a particular person to come free will be delayed, again potentially causing a cascading effect on other projects’ schedules.
  
  
• Create an increased need for handovers between individuals. Handovers are regarded as one of the biggest causes of waste in software development and come with the added danger of losing valuable tacit knowledge. Handovers also often cause misunderstandings through ambiguity and are plain evil.


• Miss out on the advantages of working in teams. A well-functioning team collaborates to a level where the sum is way bigger than its parts. Well functioning teams create magic - much like the All Blacks on a good day.


• Make bad decisions: Without teams each individual on a project will only have part of the picture and it is almost impossible to make good decisions without knowing the history, background and reasoning behind all the other little decisions that have been made on the project so far. Also, diverse groups of people are usually superior in decision making ability to individual experts.
  
  
• Incentivise people to care about their particular part only, which leads to behaviours that are detrimental to the success of the overall system. For example, if I reward a football player for the number of goals he scores he will most likely engage in egoistic behaviour that damages team performance. The same is true for software development teams - especially if people’s utilisation is linked to their salaries.


• Waste time allocating and re-allocating people to projects and trying to get the impossibly complex and variable puzzle to work out.

What to do?

If we, instead of the above, provide a group of people with a shared vision, collective responsibility, the authority to design their own processes and ways of working (the essence of self-organisation) while incentivising them as a team and giving them the all the support they need they will have a much greater chance in achieving the end goal of delighting the customer.

So, let’s:

• Organise people into feature teams and give them the freedom to succeed


• Focus on improving the boundary-spanning handovers within the organisation (just as Mary Poppendieck says!)

People will also be happier and love their jobs a lot more if we let them experience the magic of a team and “move work through people, not people through work”.

For further reading about building teams and organisational structures and behaviours that support teams I highly recommend Esther Derby’s blog.