How Black Hat thinking helps resource management

 
I admit it.  I’m a black-hat thinker.  I think I always have been but many years ago, my first partner gave me a copy of Edward de Bono’s “Six Thinking Hats”.  sixthinkinghats.jpgThe book is tiny but the impact was profound.  De Bono was interested in how people think and in how people could train themselves to think more creatively; more laterally.  There’s no one hat that’s perfect of the six, each has its own attraction and its own power but of them all, being a contrary thinker as you would be while wearing the black hat has always been my favorite.  Someone says “that’s impossible” and I reflexively say “I don’t think so” but then have to defend my position and this makes me think much more creatively.  If you’re a regular reader of my column, you’ve no doubt seen this flavor of analysis in the way I approach project management and managing enterprise project management systems.

Sometimes, attacking our resource capacity challenge with counterintuitive responses can reap huge rewards.  Here are a couple of examples of how wearing the black hat might help us if we are struggling with the common issue of having insufficient resources:

Don’t manage everyone

I’ve worked my entire career implementing enterprise project and enterprise timesheet systems and while many aspects of each deployment are unique, one thing is universal: management feels compelled to manage the resources of the entire enterprise.  If you’d like to get a room full of managers salivating over an enterprise project resource management system, tell them they can see the work and plans of each and every individual.  Showing management how you can drill down from the project portfolio level all the way to someone’s daily to-do list elicits a visceral response.

But…

This may not be the most effective thing to do.  Over the years I’ve found that organizations that try to centrally manage resource levelling to the individual level end up tremendously frustrated or, worse, terribly ineffective.  When you dissect the challenge the organization is facing it is apparent why it is not easy.  Enterprise level analysis of each and every person generates so much management effort that we’d almost need a manager per person to follow people around to make sure they do what we were hoping they’d do.

There is a counter-intuitive cheat for resource levelling that is almost always tremendously effective.

Don’t manage everyone.  Instead.  Pick the small number of absolutely key people who have that unique combination of skills and knowledge that makes them critical to the most important projects and centralize the management only of them.  Now, when I’m talking about a small number, I don’t mean 20% of the team.  For a 200 person department, I’m talking about 5-7 people.

A couple of very interesting things happen:  First, the project managers who had been hoarding these key resources for their own projects will now only get them for the time they need.  That makes these key people suddenly available for other projects.  Surprise, surprise, that makes the whole organization more effective.  Secondly, we don’t adopt an incredible burden of managing everyone else down to the minute.  Instead, we let department or project managers assign those people however they do.  This also makes us more effective.

Smaller teams

“We’re going to need a lot more people,” I’m often told.  “No, you don’t,” is my reactive response.  But do you?  I have been on project after project where we were up against a resource challenge and instead of increasing team size, we reduced it.  It’s counterintuitive but I’ve found over the years that there is a tremendous overhead for certain kinds of project such as software development when the team is large.  A development team of four people can be twice as fast as eight or four to five times as fast as twenty people.

That doesn’t seem to make sense, I know.

But, putting four key people into a co-located environment and removing all distractions can produce startling levels of effectiveness.  I’ve done this myself on a number of occasions and there is no formula for it.  Each type of project and industry will have its own rules for this but my message is that you shouldn’t automatically assume that more people means faster development.

So, when confronting demands for making the team larger, consider at least, the possibility of going the other way.  You might be startled as I was at first, that this can often deliver big benefits in throughput.

Don’t finish everything

If you work in a strongly Agile software development environment then you might think like this already but for many project managers we tend to fall into the pitfall of assuming the scope is immutable.  “There’s nothing we can do about reducing the scope.  It’s a given,” I’m told.  “I doubt that’s true,” I automatically respond.  In fact, if you bring some Agile thinking to your project’s scope you might find your client is inclined to participate.  I have worked with several project managers who were facing projects where they worried they would have long delays if they couldn’t get many more resources.  In these situations where I encouraged a discussion with the client, it was common to get an unexpected response.  “Here’s where we’re at,” I would explain to the client.  “If you want all of what you originally described, it’s going to take a number of months and we’re not even certain of how many.”  At this point, the feeling of hopelessness of the client would be palpable.  “But,” I would continue, “If you could take what we are describing here,” we could deliver *that* next week.”  Now there is a look of hope with the client.

A couple of interesting things happen here.  First of all, the client gets the partially completed product into production.  And, it should be no surprise, once they have it in production, they think of even more or different things they’d like done to it.  Perhaps the original idea will never come to fruition because the client themselves pushes the project into a different direction.  It’s a very Agile concept but Agile isn’t just for IT and I predict we’ll see more and more of this kind of thinking in the future.

What hat are you?

So, there it is, three resource management tips from wearing the thinking hat.  But de Bono’s concepts have other ways of making you think about how you think.  You can find your own copy of the Six Thinking Hats on Amazon.