How to Know When Project Management Has "Arrived"

Has project management arrived as an accepted practice?  How will we know when it has arrived?  I learned the answer to that question recently.  The answer is:

We will know when project management has arrived as an accepted practice when jokes are told about the practioners.

Pilots have their own jokes that have been tossed around for years such as:

Any landing you walk away from is a good landing.

Or the PA announcement after a particularly hard landing: "Ladies and Gentlemen, welcome to Anchorage, Alaska. Please remain in your seats with your seatbelts fastened while the Captain taxis what's left of our airplane to the gate."

So lighten up a little bit and start some jokes about project management such as:

Man walks into a...

The project manager walks into his boss' office and says, "Here is the bottom line budget needed for the success of the project."
The boss says, "What can you do for half the money?"
The project manager says, "Fail."
The boss says, "When can you get started?"
The project manager says, "I think I just did."
-- from Jokester.com

The Genie

Three men: a project manager, a software engineer, and a hardware engineer are helping out on a project. About midweek they decide to walk up and down the beach during their lunch hour. Halfway up the beach, they stumbled upon a lamp. As they rub the lamp a genie appears and says "Normally I would grant you three wishes, but since there are three of you, I will grant you each one wish." 

The hardware engineer went first. "I would like to spend the rest of my life living in a huge house in St. Thomas with no money worries." The genie granted him his wish and sent him on off to St. Thomas.

The software engineer went next. "I would like to spend the rest of my life living on a huge yacht cruising the Mediterranean with no money worries." The genie granted him his wish and sent him off to the Mediterranean.

Last, but not least, it was the project manager's turn. "And what would your wish be?" asked the genie. "I want them both back after lunch" replied the project manager.

 -- http://www.workjoke.comm

And...

To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the project manager, the glass is twice as big as it needs to be.

http://www.businessballs.com

You can read more at http://www.cvr-it.com/PM_Jokes.htm.

Happy project piloting...

Become a student of how things work

Did you see the movie Flight by Denzel Washington?  [Spoiler alert] The pilot (played by Washington) saved a plane from crashing by flipping it upside down to stop it from diving to the ground.  There is some level of truth in the principle there - a plane's wings can theoretically can fly upside down.  The point here is that the pilot understood how things worked - why a plane flies, how the controls work, how the aircraft systems work.

Do we?  Do we understand how things work in our project management arena in order to make effective decisions in the pressure situations?  Have we taken the time to understand how the organization makes decisions?  And who really has what power?  Do you know the organization's products and services and how the customer uses them?  Do you understand the management software and tools your organization uses to manage work?  Have you taken the time to understand the personality types of the people around you on your direct and indirect teams?

Just like a pilot needs to understand how things work to make the right decision when needed, a project manager needs to understand how things work in the organization and culture around them.  You cannot fly by the seat of your pants, and you cannot put your head down and focus exclusively on your project.  You have to put forth the effort to improve your understanding...if you want to become a real value-add to your organization.

Happy project piloting...

Should Project Management Be Boring?

I was flying back to Nashville yesterday and was thinking about how we take flying for granted.  Does anyone appreciate the fact that we are hurtling in an aluminum tube at 400+ miles an hour 5 miles in the air?  And it is safe and relatively reliable.  It is downright boring and we take it for granted.  We expect it.

Our projects are usually exciting.  They tend to be filled with challenges, impossible deadlines, late deliveries, politics, resource conflicts, poor team dynamics, changing requirements, clients that change their minds, and a rush to the finish line (only to start all over again).

What if our projects were boring?  What if our processes and culture was such that the clients of our project management practices could rely on the project getting to the finish line reliably without a lot of drama and excitement?  What would that look like?

Some problems I see:

• Do some of us like the drama?  After all, if there was no drama, there would be less need for a top-level project manager.
• Is it possible to not have such a high level of drama or is it something we just have to accept?
  
• Clients and stakeholders can sometimes be sources of the drama.
• Does there need to be an underlying focus on changing the culture?

What are your thoughts?

A Big Barrier to Project Management Team Improvements

I read an interesting paper that discusses culture and its impact on aviation safety.  At least it was interesting to me.  I suppose if you are not interested in that sort of thing, it can be some dry reading.  It was written by Robert L. Helmreich, a Ph. D. who is considered by many to be the godfather of crew resource management discipline which has been credited with changing the whole safety culture in aviation.

If you (like myself) want to change project management culture, read on.

There was one aspect in particular that was very intriguing to me as a project manager and team leader.  We are talking culture change here.  What is one of the biggest barriers to culture change?  Distrust.  More specifically, distrust that management (or the instigators of the desired culture change) truly believe in it and have the right motives.  In aviation, the distrust was (or is) that management was really more concerned with profits and not really committed to safety.

What is it in project organizations?  A distrust that we are more concerned with political gain?  Making ourselves look good?  Hitting the numbers? That this is just another initiative that we won't care about in x months?  Or [fill in the blank]?  Are we really sincere about creating an environment of great teams that makes customers happy and stops the firefighting....an organization that team members will be proud to participate in it?

Dr. Helmreich's paper suggests that no words can compensate for distrust.  It takes actions and proof over time.

So the question is, what message are your actions conveying to your teams?  Is there sincerity?  Do you have the right motives?  Are you in it for the long hall?

Happy project piloting...

The Slippery Slope: How Project Failures Sometimes Happen

I find that aviation accidents and their causal factors provide interesting insight into project management failures because the underlying human mistakes and conditions are similar. Sometimes an aircraft accident is the result of a sudden, critical mistake on the part of the pilot. For example, they are flying at night, fail to take into account mountains, and fly into high terrain. One big mistake with critical consequences. For those of you that all of a sudden became nervous about taking a flight at night, this would be a more common occurrence with smaller "general aviation" airplanes (generally not airliners).

The more common cause is a slower, slippery slope where there is a chain of mistakes and events which eventually lead to an accident. For example, a pilot flies for years without an incident; they start to get complacent, sloppy, and find themselves doing their checklist from memory; they break their personal rule and decide one night to fly when they are tired; they forget to check the pitot tube (a tube that provides airspeed readings); the pitot tube happens to be partially iced over that night and the weather is poor; they fly into the clouds; their airspeed shows higher than what it actually is; before they can figure it out and because of their tired condition, they lose control and crash.

It is not one particular mistake or occurence that causes the accident. It is a series of decisions, mistakes, and events: a slippery slope.

Is this not what happens when we manage projects? A project is doing well, or perhaps several projects have done well and we get just a little complacent. Or perhaps we are really busy and we "just don't have time" to do everything. We stop walking around as much to keep on top of what is going on. Instead of bothering with the change request process, one day we slip something in to make it easier. We take our engineer's word that everything is ok without asking the critical questions we know we should ask to verify. This just happens to be the time when the engineer got complacent about testing and before we know it, our project is in trouble and we wonder what happened.

While there are projects and project teams that are easier to manage and perhaps even take less time, we always need to be vigilant about following the processes and techniques that got us here. It is easy and natural to get complacent and to take shortcuts. I believe that one of the things that makes a good project manager for the long-haul is a commitment to always doing things right.

Why are People Reluctant to Admit a Problem?

I read an article recently on why pilots do not like to admit they have a problem and have dug themselves into a hole.  They are reluctant to declare an emergency and seek assistance (this was generally referring more to general aviation pilots than commercial airline pilots.  General aviation pilots are the ones that tend to fly the smaller, propeller driven, personal planes).

The point was that some pilots do not want to admit their situation and get help when they are running dangerously low and fuel, or flying into weather they are not prepared to handle.  The article listed a few possible reasons:

• People have a natural tendency not to ask for help.
• Many pilots feel there will be extensive paperwork and a big nuisance if they ask for help (i.e. being forced to fill out a lot of paperwork).
• They fear some sort of punishment or reprisal.

These are human tendencies, which is why we see them in project management teams as well (at least I have).  Why is it that we run into a problem in our project work (perhaps of our own making), but are reluctant to ask for help to admit the problem?  Does that ever end well?  Most times it does not, but simply compounds the problem the longer we wait.

I have some suggestions to help mitigate this in our project teams:

• Create a culture where there are no reprisals or punishment for coming forward with an issue (you may think this is the case now, but beware of the subtle reprisals).
• Encourage team members to come forward.
• Ask questions constantly to identify where there is a problem.  Never assume everything is fine - fight your confirmation bias and look for information that contradicts your assumption.
• "Declare an emergency" (aka raise the issue) for a team member if you find they are in trouble.  An air traffic controller can declare an emergency for a pilot if the pilot is clearly in distress but unwilling to declare an emergency for themselves.

What other suggestions do you have?

Happy project piloting...

Performance Metrics vs. Desired Behavior in Project Management Teams

On February 12, 2009, Colgan Air Flight 3407 crashed while approaching to land in Buffalo, NY.  There has been much discussion about this accident, and there is one interesting piece of information that provides some insight into human behavior (i.e. in project management teams).  Specifically, can a performance metric cause team members to exhibit undesired behavior in an effort to meet the performance metric?

Airline pilots routinely train to recover from a stall.  A stall is when the airplane is not going fast enough, with enough air going over the wings, for it to maintain normal flight.  If a stall is prolonged, the aircraft will crash, as with the Colgan flight (don't worry, pilots are well trained and aircraft designed to avoid this scenario).

The interesting thing is that pilots had a performance metric: they were judged by whether they lost no more than 100 feet in altitude while recovering from a stall in training.

The theory is that the Colgan pilot had the 100 feet (the performance metric) so ingrained in his head that he may have unwittingly focused on the metric to the detriment of the recovery effort itself.  Whether this is true we will never know for certain, but interestingly, the FAA has since removed that metric.

Which brings us to the human behavior aspect of a performance metric.  Most of us at one time or another have had a laser focus on a performance metric we were expected to meet (and we have seen others with the same thing).  But can this degrade the overall performance of the team member and the team itself, or produce behavior counter to the broader objective?  For example, what if a software team has a performance metric of releasing software that does not have more than x number of defects?  Might the software team be so focused on the metric of # of defects that they lose sight of the real goal of producing quality software that meets operational needs?  Could this cause a team to adjust procedures, or even leave out an important function to be sure that they meet the metric?

Do I think that performance metrics are bad?  No, of course not.  If you don't have any metrics, you can't measure anything.  The point is not that we should not have any metrics.  The point is to make sure your metrics are working to encourage desired behavior, not produce undesired behavior.

I see three further points:

1. Be careful that you have the right metrics and that you are incentivizing people towards the right behavior.  Don't assume, but monitor this over time.  Adjust your metrics if needed.
   
2. Always communicate the overall objective and mission.  Keep the big picture in mind and get people on board with it.  That will help them as they process day to day decisions and behaviors.  Make sure they are incentivized towards the broader mission and not just an obscure metric.
3. Maintain good communication.  Regularly talk with people to know what they are thinking and why they are doing certain things.

Interesting stuff since all of the individual decisions that people make each day are what make or break our projects.

Happy project piloting...

 

 

Avoiding Groupthink in Project Management Teams

I read an interesting article by Jay Hopkins at Flying Magazine on the topic of groupthink.  His focus was on pilots, but my mind went to project management teams.  According to Jay, groupthink is "a cohesive, task-oriented, problem-solving group isolated from conflicting opinions..."  The group collectively tries to rationalize or discount warnings, team members do not speak up, contrary viewpoints are discounted, and there is a false illusion of agreement because people hold back their true feelings or opinions.  Everyone simply goes along with the prevailing group "opinion."  Aviation is interested in avoiding this because there have been tragic accidents where groupthink in the cockpit was a significant contributor, but since this is a human trait I believe it applies to every team environment.

I am sure this has never happened to any project team on which you have participated.  I have certainly seen it in my experience.  As Jay articulates, there are several key points to consider in order to avoid groupthink:

• One of the roles of project manager or leader or even executive is to create a culture where the discussion can always be open and frank.
• The leader should also be careful in what he/she says in the beginning because team members are more apt to go along with the leader's opinion as opposed to voicing their own opinion.
• Take all internal and external opinions seriously.
• Be alert for anyone who is not saying anything.  Ask them directly for their opinion.

One other interesting note Jay makes is that people with similar personalities especially have to be wary.  In this case, you have to use "aggressive skepticism" to identify alternative courses of action.

Keep the risk of groupthink in mind the next time your team (or yourself) needs to come to a decision.

Using "Golden Rules" to Establish Project Management Culture

Did you know that there are golden rules that pilots follow?  Golden rules articulate the basic principles of airmanship and of interaction with automation and crew.  They are especially helpful for training pilots that are new to certain aircraft or aircraft systems.  It helps to establish a basis for good airmanship.  If you always follow the golden rules, your risk of a "mishap" or making a consequential mistake goes way down.

I suggest that you create some golden rules for your project management culture as well.  They should be the standard that you expect everyone to follow when working on projects - the basis for project management professionalism in your organization.  What should these be?  We can get some ideas from the many project management resources out there, as well as from the aviation golden rules.  Here are some examples from aviation that provide some themes*:

1.  Fly, Navigate, Communicate - in that order.  This clearly establishes a pilot's priorities.  One of your golden rules should be to articulate the priority of work.  For example, perhaps completing your critical project tasks should be treated with higher priority than constantly checking your email.

2.  One head up at all times.  To pilots, these means that someone should always be flying the plane.  There should never be a situation where everyone is focused on a task inside the cockpit.  One of your golden rules may simply be that there should never be an initiative without a designated person to manage it and maintain awareness of the project progression ("keep their head up").

3.  Use the proper level of automation for the task.  You may need to designate that certain tasks should be managed using your established "automation system" (project tracking system), or you may designate which tasks should and should not be managed with "automation."

4.  Practice task sharing and back up each other.  Pilots are not lone wolves.  They work together, share tasks, and back each other up - they work as a team.  This could be one of your golden rules as well.  This will eliminate many mistakes.

5.  Understand the situation before acting.  When a problem occurs, don't just react.  Take the time to understand the situation before formulating an action plan.

6.  Actively manage individual workload (we talked about this in a previous post).

7.  Create a shared problem model with other crew members.  When a problem occurs, one of your golden rules may be to communicate with other team members to create a shared problem model.  This ensures that everyone agrees what the problem is so that they can start from the same reference point and work towards a common objective: a solution.  This simple rule can eliminate a lot of wasted effort.

8.  Apply recommended procedures.  Don't play the cowboy.  There is a reason the recommended procedures are recommended.

These are just examples, but they provide some good themes.  If you are looking to create a project management culture, put together some golden rules that establish a pattern of professionalism and behavior that is expected in your organization.

Happy project piloting...

 

*These particular golden rules are briefing notes produced by Airbus that are used to train new pilots.  You can find more here.

 

Confirmation Bias and Its Role in Project Management

Robert Bradshaw International Airport is a simple, one runway airport on an island in the Caribbean (I believe St. Kitts).  On September 26, 2010, a British Airways Boeing 777 airliner taxied to the runway.  In this case, there was no taxiway that went to the end of the runway so it was standard procedure to takeoff from an intersection.  The airplane couldn't takeoff from the end of the runway.  In the diagram below, they intended to takeoff from the intersection marked A, still allowing for using most of the runway for takeoff.

Instead, the pilots mistakenly lined up at the B intersection, leaving only half of the runway available for takeoff.  They didn't realize their mistake and proceeded to takeoff.  Fortunately, no one was hurt, but the airliner was only 300 feet from the edge of the runway before it left the ground.

This is an example of "confirmation bias," which means that you only notice the evidence that supports your assumptions and ignore evidence to the contrary.  In this case, the Captain even remarked on how short the runway looked, and there were several communications with air traffic control that indicated some "warning signs" were seen and then discarded.  The pilots were convinced they were at the right intersection, despite clues to the contrary.

Confirmation bias is alive and well in project management.  We desperately want to believe what we believe to be true.  For example, a project manager is working on a big, important project and reports to management that all is well despite warnings from team members that there are problems with the schedule or deliverables.  Why?  Because the project manager believes that the project will be successful, and ignores or plays down the warning signs as not important or will be easily overcome.

You have to continuously and proactively overcome confirmation bias.  Pilots (and project managers) should:

• Seek evidence that disproves their assumptions whenever they are called into question.
• Create a communications culture where "confident and clear discussion" of the problem can occur.  Team members should be encouraged to raise warnings.
  
• Listen to those around you with differing opinions of reality.
• Always look for warning signs that what you think is true, isn't actually true.
• Solicit feedback on how others see reality - confirm your version of reality.

The pilots of the British Airways flight were fortunate.  You may not be so fortunate in your project if you don't guard against confirmation bias.

Happy project piloting...