What’s wrong with typical resourcing

Oftentimes people are assigned into projects by looking into resource pools and determining some key characteristics of each resource: what is the current utilization rate, what do reservation calendars look like and on some more sophisticated scenarios, also each person’s skill sets are taken into consideration. But this model is far from ideal for numerous reasons.

Skill sets

First of all, the skill sets that really are taken into consideration, are mostly technological. Like “Sally is a java programmer, Joe is database administrator specializing on Oracle and Harry is a tester while Sophia is a UI designer”. Someone has somehow calculated how many units of each resource type project needs and thus a project team is formed.

This model doesn’t take into account what kind of personality types the specific project needs. Should we take Sally the java programmer who is not comfortable with iterating but usually produces error-free code from decent design, or Scott the java programmer who is at his best at trying different things out but doesn’t want to wait for design to be finished? Should we take Sophia the UI designer, who is considered more senior and competent on her own but is unable to work with customers or should we take Chris the UI designer who shines with customers but who often gets to argue with other team members?

Furthermore, this model completely ignores the fact that a team is more than the sum of it’s parts. A team may vastly benefit from a person who is complete junior on every technological aspect but really makes the people work as a team.

If these decisions are not made consciously, the project will most probably meet unexpected challenges in getting into working effectively.

Productivity differences

In any given resource pool you have many people with similar skill sets. Are each of them similarly productive? We have significant evidence that between two programmers there can be 20-time (the multiplier varies from 10 to as far as 50 on different studies) difference in their productivity. Do you know the productivity characteristics of each member on your resource pools?

Team is more than a group of people

By assigning project teams merely resourcing each member from their respective pools you do not get an actual team. Instead you’ll just put up a group of people who are not enjoying the empowering effects of a well-working team. A team in which every member knows each other will have productivity that is far more than the sum of its each individual member.

Teams are not something that any single person can mandate to exists: a group of people decides to work as a team or the do not. Finally, if you happen to come up with a jelling team, resource pooling often breaks each team after every project. So you’ll face the team building phase on every project. It’s not the most efficient way of working.

So what to do about it?

1)       Forget resources

The first step into the right direction is to quit speaking of people as resources. Considering people as resources proposes the usage of resource pools and ignores the notion of a well-functioning team. Instead of focusing on setting up resource pools and optimizing individual utilization we should focus on building highly efficient teams that are capable of organizing themselves at all times. Teams should be big enough to allow assigning the best person to any given task but small enough so that the number of communication channels does not overwhelm the benefits of people knowing each other.

2)      Consider organizational structure

Do you have your workforce organized by functional expertise? Project management team, UI design team and development team, database team and testing team? This grouping doesn’t encourage self-organization and introduces many possible bottlenecks to your workflow. People working together should stay together and have a common organizatory goal.

3)      Let teams build themselves

A jelling team can typically consist of 10 or less people. Bigger than that and the communication channels get far too many and the diversity of the persons get in the way of efficient collaboration. You may have organization units that are bigger, but inside units you may have more teams. If you as a unit manager see some people getting along especially well, why not letting them work together as a team?

4)      Emphasize specializing generalists, not pure specialists

Each person who has strictly limited expertise is a bottleneck to productivity. Specialists need a well-defined role, they need a project that can use a specialist of his profession. When your people are capable, and willing, to act on a multitude of roles, your staffing problems get a lot easier.

A group of specialists can make – and usually do – products in which any given area is crafted well, but the product as a whole doesn’t work at all. To make anything remarkable you need a group of people who understand what others are doing, people who understand the product as a whole.

Surely you need the specializing part, too. A group of pure generalists will surely do something that works somehow, but it won’t shine on any aspect. The optimal situation is having a team full of generalists, each of which could carry any role in the project, but where each has her own specialty on top of good general knowledge.

=>  Sami’s first law of productivity: Productivity is directly proportional to the amount of overlap in team members’ skill-area / expertise-level –space.


Tags: ,