What Can Darwin Teach You About Project Management?

The other day, I read about a profoundly insightful study: the best way to understand human behavior is to imagine that somebody is trying to steal your bananas.

Seriously. Every last banana. Somebody wants to steal them.

More seriously, the point of the article was that, deep down, we're all following some simple genetic programming designed to keep primates alive long enough to reproduce. And when we're threatened -- when someone's edging in on our territory, when it feels like losing a job might lead to losing a home, or when life is just plain stressful -- those primate emotions rush to the surface.

This is not the time to shake your head and wish things were different, or to marvel at the wonderful diversity and weirdness of humanity. No, this is your chance to shine! How will you keep your monkey colony happy and productive, even when they're acting like monkeys?

The study offers a simple trick:

• Maintain eye contact: if you're the boss, other people will look up to you -- literally. Look back. Make sure they know you care.

And here are a few more:

• Don't give anyone life-or-death projects, unless you want sloppy, life-or-death work: when your employees are in maximum fight-or-flight mode, they'll be willing to take huge gambles. If you're relying on a large, coordinated team, that's the last thing you want.

• Use short-term rewards to keep people interested in long-term tasks: you may not know for a year whether or not your latest project will turn out well -- but you can see day to day whether people are doing their best. In the short term, reward effort to keep up interest. In the long term, reward success. Monkeys have a short time preference, so give an immediate payoff whenever possible.

• Remember that you're a monkey, too: probably the most important tool. Instead of using evolutionary psychology to muck around in someone else's subconscious, ask yourself what primitive primate mind-games you're playing with yourself.

If you're ready to dive in to evolutionary psychology, there's one thing you absolutely must do first: read The Selfish Gene. For anyone intellectually curious person, it's a fun romp through evolution from a fairly interesting perspective. For anyone who deals with people on a daily basis, though, it's a peek at our collective source code -- what really makes us tick. Understand that, and you understand how to lead.

Burn Your Gantt Charts

Let's say you're in the ditch-digging business. Day in and day out, the team you manage digs ditches from one place to another. If you're managing a team like that, you probably want to allocate resources in a certain way: you have to know when the shovel-repairman will need to be at work, when the wheelbarrowers will need to do their wheelbarrowing, and how many ditch-diggers it will take to dig Ditch #713 by the end of the week.

If you're digging ditches, you can probably use a Gantt chart to plan the project. If you're doing anything that involves a spark of creativity, a confluence of talent, or a unique skill -- keep Gantt charts as far away as possible. Start your project off right by finding a big stack of illegible, impenetrable, utterly obscure and useless project management charts, and setting it on fire.

Gantt charts track predictable progress towards measurable goals. That's dandy, but more and more of the economy is based on unpredictable projects and unpredictable goals. Building a car, a house, or something else nobody wants to buy lately is a linear project with fairly interchangeable inputs. There's complexity, sure, but it's the kind of complexity you can bury under extra resources.

But building a new website, or an internal HR application, or a CRM system? That's a nonlinear task. That's a task that might spawn a brilliant new feature if your main software developer grabs a cup of coffee with the UI designer. A flash of insight might cut the necessary database coding time by 50%, or an unexpected flaw could mean that 5% of the features require 150% of the work.

The last thing you need in that case is great big sledgehammer of a Gantt chart to pound the fun and creativity out of your project. Instead of framing things in terms of Gantt-based projections, throw out the projections entirely: start a project by building the smallest application you can build that would make a positive difference in user's lives. Then, let them use it. Then, ask them what features they want next.

And when you're done, find the ashes of those Gantt charts from a couple paragraphs ago, and bury them. You can never be too safe.

New Project Management Blog!

I thought I had a good collection, but looks like I missed a few. I've just added Harwinder Bhatia's PMBOK Preb blog to my sidebar. Actually, one of the things I found interesting about this was not just the content -- which is mostly study prep materials, and sundry links -- but the format: Bhatia has actually set up a handy table of contents, so you can see what he's been up to. This is a great idea for blogs that are less chronological in nature.

Project Management Blog Posts You Can't Miss

Here are ten of the last week's most insightful, challenging blog posts from the project management field. This week saw a flurry of discussion on Kanban (here's my contribution to the Kanban debate). Other highlights include a reflection on costs and benefits (particularly how hard it is to convince someone that the costs are real!), and a lecture that started off great and then fell flat.

Without further ado, and in no particular order: ten great project management blog posts you can't miss:

• Eight to Late on "Why visual representations of reasoning are more effective than prose". I actually disagree with this one a bit: I'm suspicious of any argument that can't (or won't) be boiled down to simple language. But visual aids absolutely do help enhance an argument.


• Rob Bowley: "Kanban is just a tool..." kicking off the recent Kanban debate, Rob Bowley articulates the "Not so fast!" side. It's always good to have a reality check like this: Kanban isn't going to make you an extraordinary performer, and it isn't even a necessary component of many methodologies. But take heart, Kanban fans! Rob is not completely negative:
  

  If you’re getting into Kanban, be warned. Kanban is just a tool and in my opinion no more important than say, pair programming, unit testing or domain driven development. It is certainly a lot less important than the white elephant in the room which very few people seem to be addressing which is building the right thing in the first place. As Peter Drucker famously said: “There is nothing so useless as doing efficiently that which should not be done at all”.

  
  That's a sane, balanced view.


• Round Two in the Kanban Fight: David J. Anderson of Agile Management: "Is Kanban Just a Tool?" David explains why using Kanban has such a huge impact on project management success:
  

  Pull changes everything! When implementing pull, you first have to embrace the concept (or paradigm) of flow. Flow and Pull are two of the 5 pillars of Lean. The other three being Value, Waste Elimination and Continuous Improvement.



• W. Scott Cameron, writing at PMHut: "Lessons Learned Again and Again and Again." I don't want to spoil the whole thing, but Scott spots a common problem with explaining projects to another party: people are much happier visualizing benefits than costs, so if you tell them about both, they're likely to become much more attached to the benefits! True and trivial, but it has a big impact. As Scott puts it:
  

  The reaction was, “I love the scope but hate the cost.” My response was if you like the scope, then this is the cost.



• From The Art of Project Management: "Risk? What Risk?" This piece analyzes two diametrically opposed, comletely wrong attitudes towards risk: the happy-go-lucky, "I can't control anything, so why bother?" attitude, and the "We must reduce all risk to zero" attitude. While nobody seriously articulates either side, people do tend to lean pretty far in either direction. The risks are huge for both: overreaching is as bad as inaction.


• The Tao of Project Management: A Matter of Life and Death. Great concept, great writing. This post is actually closely related to the previous one from The Art of Project Management: accepting the existence of risk means doing something about it, but knowing that what you do might not work out in the end.


• Via Bob Sutton: Julia Kirby at the Harvard Business Review warns you to "Beware the Baboon Boss. Julia looks into how evolutionary psychology comes into play, especially in tough economic times.
  

  Humans have evolved a bit beyond the need to check on the boss every 20 seconds, but the basic phenomenon remains that subordinates in an organization study the behavior of bosses far more closely than bosses study subordinates. Bob Sutton of Stanford University, who's writing a book on bad bosses and how not to be one, told me this is the key to understanding why bosses so frequently disappoint--and why it's almost impossible for them to do anything but disappoint their charges in a downturn. The boss's natural tendency to be inattentive seems like brutal callousness at a moment when people are feeling vulnerable. And, with the sense of danger in the air causing everyone to watch the boss even more closely than before, no dopey moves go unnoticed.



• Paul Ritchie discusses "CIO job rotation and commitment to IT value" based on an interview here. The key takeaway? Developing a sense of "shared urgency" (more than "We're all in this together," but less than "We're going to die!") can enhance productivity. It's a tricky balance: the extra stress on a team can make this counterproductive, especially when everyone's worried about the broader economy. But this is a useful concept.


• At A Girl's Guide to Project Management, a great summary of this year's Lovelace Lecture, by Maurice Perks, standing in for Tony Storey. Perks gives a solid speech, about -- breaking big projects down into small tasks. Yes, that's true, but where's the insight? Someone that experienced, standing in front of a large and highly qualified audience, should go to the trouble of outraging a few of them.


• And finally, at Better Projects, a visual aid to answering the question: "Agile, Waterfall, or Something else?" In this case, a visual aid does a good job of illustrating the question: how does complexity and available domain knowledge affect which techniques are more effective for completing projects? This led to a great discussion in the comments.

That wraps up this week's top ten. If I missed anything, please drop me an email: pm.revolutionary@gmail.com .

Project Management Cartoon

Yes, it's infamous. Yes, you've seen it before. But ask any project manager: cartoons are a great way to memorably make a point. Project management cartoons are few and far between, but there's a good reason for that: this one said all that needs to be said about the subject.

Kanban: It's a Tool, and There's No Such Thing as "Just" a Tool

Kanban is just a tool! No, Kanban is a way to achieve pull and flow!

We need to step back here and ask if, just maybe, everyone involved in this debate is saying roughtly the same thing. Rob Bowley's view is, basically, that Kanban is overhyped. Yes, it's useful, but not that useful. David J. Anderson explains his understanding, that Kanban disperses information and decision-making power throughout an organization, and thus keeps projects on track and gets attention to them before they go off the rails.

Here's what neither of them would disagree with: Kanban is part of a set of best practices, and it's especially good at getting people to focus on what resources or efforts are needed.

Kanban might be "just" a tool, but tools are hugely important. Learning is a process of picking up new tools, most of which you store in your head, some of which you keep on your hard drive. Learning to see things with a new perspective, to see the goal and not just the process, and to act as a leader when leadership is what's called for — that's what Kanban brings to everyone on a team, and that's why it's so powerful. The tools you use define how you think (whether they're the words you use to talk or the project management tools you use to lead your team).

In an early post, Rob Bowley nailed it (quoting from this discussion from The Toyota Way):

TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System. Kanban is a fascinating concept and it is fun to watch… When is the kanban triggered? How are the quantities calculated? What do you do if a kanban gets lost? But that is not the point… The challenge is to develop a learning organization that will find ways to reduce the number of and thereby reduce and finally eliminate the inventory buffer… So kanban is something you strive to get rid of, not to be proud of.

There it is. Like magic. Kanban is a tool for spotting problems. Not something you want to be part of your life forever. Once your team has established some serious Kanban momentum, you don't have to push the process so much. Instead, you can just watch the results.

Kanban is a great tool for bringing out the leaders in your organziation. It's not going to turn people into leaders, and it's not going to magically improve your productivity. It is one more tool you can get a lot out of. And that's something worthwhile.

Project Management Tools: What Your Features Cost You

So, you're managing three people. Or a dozen. Or a hundred. You've gotten yourself some souped-up and studly project management tools that claim to do 90% of the work for you. And yet, you don't get to spend your time cooking up visionary new plans with your clients. You don't get to provide leadership, or high-level guidance.

Your project management tools fired you as project manager, and hired you back as a typist.

"How did my project management tools take over my life?

You have to hand it to the folks who develop project management tools. Something big like Teamcenter or MS Office Project Server has everything -- kitchen sink included. If you want to track something unusual, deal with complex resource allocation, crank out Gantt charts, standardize reporting, define metrics, contact stakeholders, and map out dependencies, you can do it.

The problem is, if you can do it, nobody wants to give you a system that doesn't force you to do it. Sure, you can produce awesome charts of your progress -- but only if you put that progress on hold in order to input all the data that necessary for those charts. What if you just want to get started? What if you don't know how many resources you'll need, or how you want people allocated? What if you're dealing with a dynamic competitive situation, and you need the flexibility to change course halfway through, repurpose resources and projects towards new goals, and respond to new threats.

In other words, what if all the assumptions that go into your project management tools have a nasty encounter with real life?

Changing the direction of a huge project is like trying to steer the Titanic (and the result is often the same: in the end, you sink it). The problem isn't projects, though: it's the fact that your average project management tool does more than it needs to instead of doing the same stuff better.

"How can I take control again?"

In the short term? You can't. Big project management tools impose a huge amount of overhead. You spend so much time filling out forms, pushing buttons, flipping switches, and fiddling with settings that you can't get your head above water long enough to invest in something new.

What you'd like to be able to do is start over with something small and simple, that gets the job done. You'd like to start over, defining small tasks and handing them off to people who can get them done, getting status reports when you can use them instead of when your software thinks you need them -- of feeling a sense of accomplishment when you get something done, not when your project management tools leave you alone.

Our little secret

You can't start over -- but you can start somewhere. Carve out a sub-project, give your people some autonomy, and (pssst!) don't tell your project management tools what you've done. The carve-out can start small, and grow from there. And when you start your next project, you'll know for sure whether you want the project management tools that can do everything, or the ones that can do one thing right.

Don't let project management tools demote you, especially if they're supposed to make you a more effective at your job. Don't fall for the promise that your software can do it all. 10% more features mean 100% more headaches. Pick the project management tools that treat you like an adult. You can't go wrong with Basecamp.

Project Managers: Stop Managing Projects!

What is the number-one problem project managers face?

Insufficient resources? Hardly. Scaled down, bootstrapped-up projects get notoriously great results.

Fickle client/management expectations? Grow up. If you're in the business of pleasing clients, make them happy. If you need to get things done, learn to tell them when they're getting in the way.

No, the biggest obstacle to successful projects is too much management. Nine times out of ten, the manager who thinks like a coach ought to act more like a referee. It's better to spend time giving people goals and measuring results than to spend that time nitpicking over details and quibbling over techniques.

Historically, the most successful projects are the ones with the least management. Not the worst, the least. Great managers lead, but most managers simply manage. The difference? They're both out in front, but leaders are moving ahead, while managers just get in the way.

Who really manages projects that way?

• Andrew Carnegie, son of a peddler, once the richest man in the world: "Here lies a man who was able to surround himself with men far cleverer than himself."
• Jack Welch, who led GE to become the largest company in the world: " Don't manage - lead change before you have to."
• Peter Reade, co-founder of the Heifer Project, a charity that empowers others to escape poverty: "We listen to what people want and teach them how to do it."

But what about me?

Can you do it? Could you try? Every project that takes more than five minutes can be broken down into simple steps. Why not carve out a small segment of a large project, and turn people lose? Instead of step-by-step instructions, try a timeline, a goal list, and a question: "Can you do it?"

The answer will be a pleasant surprise.