The Duck Hunters

Duck hunters shoot ideas as soon as they hear of them.  This is a recipe to become a mediocre team.

Imagine yourself in one of your project meetings.  This particular meeting proceeds just like any other meeting.  You look around checking everyone’s faces. You can plainly see on everyone that unmistakable look that they’d rather be elsewhere.  Everyone knows this meeting is a waste of time.  The meeting conveys nothing that can’t be broadcasted by more efficiently and effectively by email.  But it is a long held ritual and apparently must be perpetuated.

All the ingredients that make up dull meetings are here: meaningless status updates,  the obligatory round-the-table ‘what are you working' on’ exercise, and finally, the question: ‘Is there anything else?’

The more experienced members of the team keep silent.  However, Jack, a new and young member of the team, nervously, tentatively, makes a suggestion:  “Uhm… I was just thinking… uhm… you know how we are implementing the database for this system… I was just thinking, have we determined all the end users who will be using this system?  I was just thinking, they might have different needs and I’m not sure the database as currently designed will be able to handle all their needs. I was just thinking we should maybe make a list of the different kinds of stakeholders and what their needs are”

Jim, the project manager replies dismissively:  “We’ll just be making extra work for us that way. I think you’ll find that even the stakeholders don’t know what they want.”

Bang! A Duck Just Got Shot Down

The project manager’s dismissal of Jack’s suggestion, apparently without even giving it its deserved consideration, is equivalent to shooting down ducks as soon they get spotted. 

Duck? An idea duck.  People who shoot down ideas as soon as they get raised are what I call duck hunters. The moment they hear an idea, they take aim and fire: Bang! Another idea shot down.

Some people are so good at shooting down ducks, almost as soon as they take flight, they are the equivalent of professional duck hunters.  Maybe they find pleasure in shooting down ideas – maybe an ego boost.  Maybe they’re trying to act decisively, but what’s the broader impact to the project?

Let’s take a broader view.

How would Jack feel?  He has put forward what he obviously thought was a good idea, something that he thinks will benefit the team.  But his idea just got shot down, almost not taken seriously.  You can be sure he is anything but more motivated. Next time, he might try again, and when his duck get shot down again, his attempts will come less and less often, until it finally stops.  When people notice their ducks being shot, soon they will stop introducing new ducks. 

How would other project team members feel?  Maybe some of them agree with the project manager.  Maybe some of them agree with Jack?  All of them will notice – at different degrees – how Jack’s idea was shot down.  They will think twice about raising their own ideas.

An environment not conducive to inviting ideas has just been established.  Whether this negative environment continues and reinforces itself to the detriment of the team, or gets weaker allowing more ideas to come up, depends on the next meetings.  If the same thing happens, it will reinforce the negative dynamics. 

When the Ducks Go, the Team Goes

A project team that raises no new ideas, soon becomes a mediocre team, unable to produce anything but the dullest, plainest possible product.

High quality people don’t want to be part of mediocre teams.  A mediocre team will soon experience an exodus of its brightest and most passionate members.  First the exodus will happen intellectually and emotionally.  People will start to tune out.  The team members will still be physically part of the project, but their minds and their passions have long gone.  It is only a matter of time when they also leave physically.

Avoiding Duck Hunting

How does one avoid this problem?  The solution comes from the top.  It must establish a management system where ideas a actively solicited, and rigorously considered. 

I would suggest putting up an idea log, where ideas can be put forward, and discussed and considered, and then rejected, accepted, put on hold, modified, or otherwise acted upon is.  Having a history of ideas generated is a terrific tool for documenting lessons learned.  (Of course, depending on the organisation’s culture, this could be a terrible witch-hunting tool as well).

Save the Ducks

Next time you’re in a meeting, watch for ducks, and for one day -- just one day --  make a note to leave your gun behind and don’t bring it to the meeting.

Risk Versus Risk

One of the most critical processes in managing projects are those addressing project risks.  Some writers go so far as to call risk managent 'project management for adults'.  The implication being that if you’re not doing risk management in your project, then you’re just a kid, you haven’t grown up yet, and have no place among grown-ups (I agree with this view, by the way).

When asked what risk is, quite a few will give an answer that goes something like: 'a risk anything that can go wrong.'  In this view, a risk is something that can go wrong, and therefore risk management is about addressing those things that can go wrong.

But there is another, less commonly known, view of risk.   In this view, risk is something uncertain that may affect the project.  Not something necessarily bad, but something uncertain. 

Let's suppose you are planning a picnic for tomorrow.  Being an adult, you have prepared a risk management plan (your picnics may be boring, but they are predictable).  You have an entry for weather in your risk plan.  In the first view of risk, you look at the weather and look for something that could 'go wrong' that could negatively affect your picnic.  Is it going to rain tomorrow?  If there's a chance of rain, what can we do to mitigate the effects of this rain on the picnic? Perhaps bring an umbrella.  Perhaps plan to hold the picnic nearby an accessible shelter, to make escaping from the rain easier.

In the second view, we look at the weather not as something that is the harbinger of something that can go wrong, but simply something uncertain.  So there's a 50% chance of rain.  Let's prepare for that eventuality.  But there's also a 50% chance of no rain. Let's also prepare for that happy eventuality as well -- perhaps plan to go to a place with a nicer view if the weather clears up.

With this second view, risk is not simply viewed as about bad circumstances that can happen, but simply about all uncertain circumstances. Circumstances which can indeed turn out bad (and whose effects we should be ready to address), but which can also turn out good (which we should be ready to take advantage of).

In the first view, we simply prepared ourselves for the worst.  But in the second view, we also prepared ourselves for the best.

Assumptions

Until we develop the ability to see the future, projects and programmes will have to be run in the face of uncertainty.

In the absence of complete information, assumptions will have to be made. Otherwise decisions cannot be made and activities will stall. At least some of these assumptions are documented in the projects. In the more badly run projects, the assumptions are there uncritically reviewed. Because a project is proceeding as if these assumptions are valid, it is critically important to review the assumptions.

You are trying to cross a bridge and making the assumption that the floor is sound. You have several choices: make the assumption, and proceed to walk normally as if the assumption is correct. You can also make the assumption, keeping in mind that you could be wrong, and proceed with caution, testing every step to see if the assumption holds. You can also, before, proceeding, inspect the bridge, and gather more information about the assumption. How likely is the assumption to be correct? How likely is it wrong? Apart from
physical inspection you can observe the environment. Are locals crossing the bridge? Are there local experts who know if the bridge is sound?

Because the assumptions are the 'floor' on which the programme will be proceeding, it is critical to review these assumptions to see how sound they are. These assumptions should be looked at with the following filters:

• Are they complete? Are these the only critical assumptions?
• Are they valid? Are we making assumptions about things that are not already known to be false?
• Do we have a plan for reviewing the assumptions at a later date, when we may have more information and able to verify or reject the assumptions.
• Have we identified the risks that will arise if the assumptions on which we are proceeding are proven false?