I love charts, and this is one I’ve used a lot. It’s designed to show resource usage to a management team that wants to start too many projects. The chart is therefore designed to enable intelligent decisions around prioritisation. (And a note before I go on: yes, “resource” here really does mean “people”. I don’t particularly like that, but that’s how the people I meet speak, so it’s infected me, too, and it’s not the most important battle right now.)

Here’s the problem in more detail. Once a project is kicked off, I typically find there is some interest from the management team in its progress, but there is an almost total disconnect between that activity and the capacity impact it has on the rest of the team. The result is the management team seems to want to start one project after another, and are puzzled when either a programme manager says No, or previous projects take forever (because their teams have been salami-sliced to make new ones).

But it’s easy to understand why that happens. They’re not on the ground, working with the teams every day, dealing with the daily issues. They just don’t have a sense of these things.

To help convey some sense of project scale and resource impact I usually use a particular chart. I call it a geological resource map, because its strata remind me of geological maps. It’s very simple. Each row is a project. Each column is a week or a month. Each cell contains the number of people expected to be on that project in that week. Something like this:

This the data I would expect most project or programme managers to be using already, although the table above is likely to be running off several more complicated tables. No matter. What’s important is that we have these numbers set out like that.

Then this is represented as an stacked area chart, like this:

If we’ve got a total team size of about 20 then we can see we’re not going to be able to start our User profiles and iPhone app projects when we’d like. And then we can have a conversation about priorities and timescales.

The visual nature of this means it conveys the landscape in a single glance. It shows resource commitment over time, including the long term consequences of starting a project.

There are a few important rules of thumb I stick to when using this. First, as ever, this is not science, and we should not expect perfect accuracy in the numbers. People will go off sick, or on holiday, delays will occur, life happens. But it gives us a substantially better feel for the landscape than just talking about it.

Second, I don’t try to include everyone in the chart. I often find QAs and front-end people are working across several projects because there are too few of them. In those cases I chart only back-end developers. That’s not a slur on QAs and front-end devs, but rather it’s using back-end development effort as a proxy for total effort. It’s not totally accurate, but it’s usually more than enough for the purpose in hand — having the management team make choices about prioritisation of effort. If they want to get into the details of individual people then I push back. I need that team to make high level strategic decisions and leave the day to day management to those on the ground.

These resource maps can also be used to show historical data — actual resource usage — which also helps to inform future expectations.

This is a very simple tool, and it does gloss over details, but I find it’s an effective way to enable the right conversations.