Project Decision Jenga

You have probably played Jenga.  It’s a game in which players take turns pulling rectangular wooden blocks out of a stacked tower of such blocks until, eventually, one player pulls out the block that causes the tower to collapse.  They lose the game.  But there is a built-in, certain end to this game.  If you pull out enough blocks, the tower will fall down.  Each block you pull on might be the best choice you can make, but eventually the structure will fail.  Either by somebody choosing the wrong block or by a lack of skill in removing the block they’ve chosen or just because the tower eventually has to fall.

If you weren’t constrained by the game’s rules, and both players were considered losers if the tower falls, how could you make it a win? You could help each other hold up the tower while the other pulls out a block. You could decide together on the right block to remove.  You could build a cage around the tower to keep everything in place. You could superglue certain blocks together to provide structural stability to the whole and limit removal choices.  You can probably think of other ways as well.  Some of these ways modify the structure of the tower – what keeps it up.  Some of them address the decision-making process.

The same can be true with your project.  If you don’t have the right project structure, a cooperating team, and effective decision-making processes, your project will eventually fail or fall over.  Regardless of how good the individual decisions are.  In systems thinking this is called sub-optimizing the system.  I once assessed a project in which a handful of key decisions were made at the beginning of the project.  Each of those decisions seemed reasonable to the person making the decision at that point in the project.  Each decision could be justified.  Yet, because of their impact on the way the project was structured or the way it was executed, these decisions led to the same destiny as the block tower in Jenga.  The project failed.  The company eventually completed the project but with massive delays and a 300% overrun of the approved budget.  Part of this overrun was due to approval spin (read more about that here).  But part of it was due to these “reasonable” decisions.  It was not unreasonable to do what they did.  But it was unreasonable to expect different results than they got as a result.  This process of sub-optimized decision-making, in a project organizationally designed to fail, is unfortunately more common than it should be.  Projects are not designed for success because the emphasis of project management has been on tasks, forecasting, and monitoring rather than the design of the organization, the social system, that will be accomplishing those tasks.

If you are interested in learning more about these ideas, check out my book, Projects on Purpose 2.0, available here.

If you are are managing a project or projects and are interested in learning more about joining a project manager mastermind workshop – to gain continuing ed credits and work with other PMs and myself to learn to better overcome project challenges, email me at msteele@quintainprojectsolutions.com and put “PM mastermind query” in the subject line.


Questions to avoid “approval spin”

Children’s tops spin well.  But when the spin is spent they fall over.  Too many projects go the same way.  Estimates and schedule forecasts are the subject of “spin” to match the business case and receive approval.  This might be intentional or unintentional.  With intent, the one seeking approval wants the approval but knows their numbers are probably not accurate.  When the spin is unintentional, often, confirmation bias plays a role in that the organization’s management really wants to do the project and is looking for evidence to confirm that they can do it within the constraints of the business case.  Of course, the third option is that there is not even a solid business case for the project at all but that goes beyond the realm of spin and into mismanagement.

In order to avoid spin, ask the following questions and dig in to find solid, evidence-based answers:

1.  What are the assumptions included in your business case relating to project justification, scope, estimate, and schedule?  Follow-ups include:

  • Do you understand all of these assumptions?
  • Have assumptions, sometimes in the form of caveats or boundary conditions to estimates and schedules, made it all the way to the decision-making level?  Many times they are present in the actual act of estimating but get dropped off the reporting as it moves through the layers of an organization.
  • Are there any hidden or unidentified assumptions that are critical for success?
  • Are there implied assumptions that must be true for the project to be successful but which are not certain and have not been questioned?

2.  How sensitive is your decision to changes in any one (or, most likely, more than one) of these?

3.  How quickly can you discover whether your assumptions are valid?  Schedule a decision point and plan to make a tough decision if needed.

4.  What is your walk-away number for your project?  Ensure that you know at what point it is not worth it to continue this project based on your business case justification.

5.  Does everybody involved in this process share the same agenda?

  • How committed is everybody to the organization’s overall goals?
  • Does everybody understand the full ramifications if this project is tried and is not successful?
  • Is everybody trying to contribute to a rational, objective decision?
  • Can anybody still win if the project turns out to be a loss?

If you approve a project based on the way it’s spun, you are likely to be unsuccessful!  Make sure you are asking the tough, right questions about your project.  At a high level, these are some of them, but it can also help to have an objective and experienced team member capable of asking more detailed questions and digging more deeply for answers.  If you need help, reach out to me.




Are you ignoring key system elements?

What happens when managers ignore a key element of a system?

If you visit the Sequoia National Forest in California and spend any time walking around, you will see that the lower sections of many of the giant redwood trees are charred.  The history behind this provides insight into what happens when managers ignore a key element of a system.

For decades, the forest service attempted to prevent and put out forest fires in the sequoia forests.  Then, a survey by biologists discovered a disturbing fact.  The forest was not reproducing itself.  There were very few young redwood trees.

Further investigation revealed that by eliminating fire, the forest service had eliminated a key element of this natural system.  Heat from the fire enables Sequoia pine cones to open.  The fire burns away the underbrush that would prevent light from reaching the Sequoia saplings.  In addition, the chemical properties of the burnt soil provide the right environment for the growth of the Sequoias.  Furthermore, the more mature Sequoia trees themselves are almost impervious to fire.

The forest managers had attempted to remove a perceived “negative” and had, instead, removed an element integral to the effective functioning of the system.  Other examples of this abound in nature.  Remove gravity (in space travel for instance) and the body atrophies.  Remove common germs and immune systems remain undeveloped.

How many times do project managers remove a critical system element, one previously ignored or unidentified, only to wonder why their project fails?


Are your critical assumptions valid?

Project decisions are fueled by assumptions. But are they valid? One of the keys to project success is to make each critical assumption transparent and then to try to validate it or invalidate it as quickly as possible.

When you’re using a map and a compass to get from point A to point B, you also rely on assumptions. But the map and compass provide you with a way to confirm or deny those assumptions if you know how to use them. Am I really traveling on a 175-degree azimuth? The compass can show you. Is this the east-west trail I was seeking? The compass tells you that it’s going roughly east-west into the wood line on each side. The map tells you that if you go west, and you are where you think you are then the trail will curve to your right. The contour lines on the map tell you that it will begin to go up a gentle slope. And, if you travel a few hundred meters, you should see a small stream on your right going down the hill and at an angle away from the trail.

So you head out. You think you are going west. And you think you were starting from the right spot on the right trail. Your job at this point is to confirm or deny those assumptions as quickly as possible. If you go into the wood line and the trail begins to slope downhill and curve to the left then something is wrong. Continuing to go that way will not get you to the point you are trying to reach.

In orienteering, the sport of finding points in the woods with a map and compass, one of the problems competitors face is that they try to make the landscape around them fit the map. They might be completely turned around and going the wrong direction, but that’s sort of uphill with a right curve. Sure, it curved a little to the left but then came back, didn’t it? It’s a form of confirmation bias to try to conform what you are seeing with what you thought you would see. But it will get you lost.

Project teams can do this too. They look for the facts that support the narrative they thought they would see and miss the danger signs. This sort of confirmation bias can be dangerous to your project because it prolongs the effect of flawed decisions based on invalid assumptions. You keep going toward what you think is point B, but it is not. One of the ways to overcome this is to get an objective assessment of your project from somebody that knows how to identify and question your basic assumptions. And the sooner the better. The more time and money you spend going in the wrong direction, the less ability you have to change directions and salvage your project.


7 Ways to kill the innovation light bulb!

Everybody pretends they want innovation in their team.  But they don’t act like they really do.  If you want to kill the light bulb in your organization, if you want to stifle creativity, slow down your project’s progress, and cripple your project team in the face of unexpected challenges, then here are seven simple steps to do so.

1.  Shoot the messenger!  Create a culture that punishes bad news and, voila, it will go away.  No more bad news!  But so will your project.  And it won’t be because you succeeded.

2.  But we’ve always done it this way!  This is a sure-fire way to shut down suggestions for new ways to do things.  Especially from new team members that might otherwise cross-pollinate your project team with new ideas and ways to improve.  Not every idea will be better than what you are already doing.  But if this is always the first answer then you will soon stop getting those ideas.  Even if your way is better, it’s NOT because you’ve always done it this way.  It’s because there are reasons why it is better.  So this answer is a cop out.

3.  Never fail!  Zero-tolerance, perfection-only, no-failure organizations ultimately fail at the big picture.  If you are never failing, then  you are not really trying to meet stretch goals.  It’s better to want to shorten your project duration by 40% and “fail” by doing it only 25% than it is to not shorten it at all.

4.  Spin everything!  Worse than a culture that shoots the messenger is a culture of lies. If you spin everything to be positive then you can never learn anything.  You also will never know how your project is really performing and whether or not any of your foundational assumptions were wrong.

5.  Always move right to the next thing!  Do not take the time to reflect and learn lessons from what you did before.  And start executing the project as soon as possible.  If you don’t spend time learning and you don’t spend time planning, then you are sure never to come up with innovative ideas and solutions.

6.  Compartmentalize information!  If nobody can see all the cards then they certainly can’t know when to bet.  So be sure to only share certain types of information with certain silos on your team.  This will ensure that there is absolutely no cross-pollination of ideas as nobody will have the ability to find common patterns between problems and point to solutions from a different silo.  Also, nobody will ask any of those pesky difficult questions that might challenge your assumptions and cause you to re-think your plan.

7.  Always make sure that you are the smartest person in the room!  And if you can’t be, then assert that you are and bully everyone to ensure nobody is willing to challenge that assertion.  Good leaders surround themselves with team players that are smarter than they are – especially in their own specialties.  So definitely do not do that if you want the innovation light bulb in your team to go dark!