Circular Logic in Project Management

Listening to one of my favorite public radio programs (The World) while carting the kids around this weekend I heard about an interesting study by the Max Planck Institute for Biological Cybernetics. A team of biocyberneticists wanted to find out how well people navigated. They hired a bunch of hikers, gave them each a GPS, and one simple instruction: Go straight that way.

Tracking the GPS devices from the comfort of the lab the researchers discovered that people don’t navigate so well on cloudy days or dark nights. Without an external frame of reference, like the sun or a mountaintop, people tend to walk in circles. Even people who claim to have a great sense of direction.

After reading more about the study I realized that people don’t tend to walk in circles. People only walk in circles. With out an external reference point the natural human programming is to only go so far, turn around, and go the other way.

And this makes perfect sense. Over millions of years, if an individual strayed out of his natural habitat without a good reason, that individual seldom got to reproduce. Our natural inclination is to stick to our territory, to the known, and within boundaries. Even when we think we are on a new path.

The mind is not exempted from this bit of hard coded behavior. I see it in others and myself all the time. In programming we call this recursion when we mean it and a bug when we don’t. In business it’s know as “once size fits all”, “if it plays in Peoria”, and “if it ain’t broke, don’t fix it.” Actually, I wish the business world had relegated circular thinking to tired old cliches. But insidiously it’s in your MBOs. It’s in you mission statement. It’s in your strat plan. Any goal that isn’t externally verifiable is a carrot on a stick.

The typical recursive program looks like this (pseudo code):

function DoIt() {
	If(GetData()) {
		DoIt();
	} else {
		exit();
	}
}

As long as there is data DoIt() will call itself. The data is the external reference point, the mountaintop. Remove the call to GetData(), or if it fails to return false, the function DoIt() will do it forever (or until the stack overflows-which ever comes first).

What is interesting to me is how strong the impulse to think in a circle really is. Many times we ignore the Sun or miss the mountaintop.
I have so many specific examples that I can hardly choose one but this is my favorite: The project is behind schedule so we need to:

• Add more resources: The team is swamped so adding more should help!
• Spend more money: More hardware, more consultants, more tools ought to help!
• Work more hours: We just need find another 12 hours in a week to get back on track!
• Motivate more: Obviously the team doesn’t understand how critical the project is to the company!

All of those solutions are examples of circular thinking because they seek to resolve the problem with more what the team is already doing.

When a project is late (and the calendar is the ultimate external reference point for any project) you have stop. Break the sprint. Reverse course. Look up for a guiding star that points to true north.

This is what works for me:

• Shuffle the project’s management: Poor execution usually means one thing-Poor leadership. Good leaders take poor plans and make them successful (or change them until they are successful). Poor leaders complain about the plan, the team’s skills, and the design of the product.
• Hold the budget: Throwing hardware, consultants, and tools at the project usually just makes it more complex. Sometimes running on a faster CPU will temporarily buy time for your pokey little puppy of an app server. But you’re just making some other project late down the road. You should only spend more budget if you inadequately budgeted beforehand.
• Work 9-to-5: I know I’m going to get a lot of tech management mad at me but I’ve seen this go on for 20 years. Working 12-hour days just buys you bugs and burn out. You can do it for a short “sprint”, maybe at the end of the project. But you can’t sprint your way out of a hole. The secret here is to make sure the 8-hour days are not interrupted by meetings, fire drills, and shop talk. Engineers shouldn’t go to very many meetings, outside of the daily scrum. They get bored and ask silly questions.
• Admit it’s not going anywhere: The current team is your greatest resource. They’ve been working on the problem, they know why the project is late, and they feel bad or mad or just resigned. Get their help and really listen to the suggestions. Honesty will get you for free what bonuses can’t buy. The team should be working for long term company success not a short term project bonus.

These techniques are counter-intuitive, and that alone probably means we are on the right track for breaking out of a recursive situation. As you can probably guess I’ve had more than a few projects go circular over the years. In the end there are no quick fixes. When you finally figure out that you are lost the realization doesn’t make the problem go away. It’s usually a long walk home-even when you are on a straight line.