When Then Feedback: Be Objective to be Effective

Wise Monkey: Hear No EvilAn effective project manager needs to constantly provide feedback to the project team on the good, the bad and the ugly to successfully manage a project. Effective feedback gives the effects of past behaviour to affect future behaviour.

Feedback also affirms good behaviour. Positive feedback shows appreciation for the contributions and recognizes the efforts of team members. When someone feels their work is unrecognized, they stop trying. When they get affirming feedback, they will continue to deliver their best. The best way a project manager can avoid having to deliver feedback on the bad and the ugly is to remember to appreciate the good.

When Then Feedback. When you do this, then this happens.

The first step is to describe the specific behaviour that led to the feedback.

When you raise your voice…
When you thank a colleague for helping you…
When you don’t respond to emails…
When you are five minutes early for meetings…
When you are late delivering…

The second step is to describe the effect of the behaviour.

…people think you are angry and not in control.
…it shows you are team player and recognize the efforts of others.
…it makes people feel you are ignoring their problems.
…it shows you respect everyone’s time.
…it makes people think you do not know how to manage your time.

Behaviours are observable. Behaviours are what we say, how we say them, our facial expressions, our body language and the results of our work. Attitudes, state of mind, motives are explanations we give for behaviours and we make many mistakes interpreting peoples behaviours.

Telling someone they have bad attitude, that they are acting angrily or that they are selfish are interpretations of intentions. Attributing intent makes the feedback subjective, probably inaccurate, more likely to be disputed, less likely to be heard and ineffective.

For feedback to be effective it needs to be accepted and for feedback to be accepted it has to be objective. Starting with actions you see or hear and describing the consequences of that behaviour makes the feedback objective.

Ranked Agenda

A sample agendaHave you thought about how to schedule the meeting agenda? Or are you listing the items in random order? Are you assigning the same amount of time for each item on the agenda? How should the items scheduled?

Start the meeting with the most important item first on the agenda and continue with next most important item. Allocate time to each item in proportion. Using low priority items to warm-up and working up in difficulty (priority), even if more comfortable, is an ineffective strategy.

The bigger the relative importance, the more important it is to have it first. Most valuable, most front of mind. If all seem equally important, which do you feel you want addressed first? It is the most (relatively) important to you. It is the item which is most likely to need extra time, the most dangerous to run out of time for.

Three more reasons for placing the most important item first are:

  1. People are most effective on the first agenda items. They are fresher.
  2. The attendees are not thinking (ruminating) about the high priority item while working through the other agenda items.
  3. It allows for more time, if needed, to complete the discussion without having the meeting run over.

After having ranked the Agenda items, the next step is to assign time for each item. The highest ranking items should be given more time. This reflects their importance and the time they will need to get through.

For example, a one hour meeting starting at 9:00AM with five agenda items would look like:

9:00 – Opening (5 minutes)
9:05 – Highest priority item (15 minutes)
9:20 – Priority two item (10 minutes)
9:30 – Priority three item (10 minutes)
9:40 – Priority four item (5 minutes)
9:45 – Priority five item (5 minutes)
9:50 – Parking lot

Beware of the set agenda; Review and reorder if necessary. Dealing with the important is more important than sticking to habit.

An agenda should be prepared with the items in decreasing order of importance. The time assigned to them should decrease along with their rank. A meeting that has an agenda organized according to priorities is a meeting that is likely to finish on time with the important items addressed.

Your Project’s Elevator Pitch

Vehicle elevators in the Old Elbe Tunnel in Hamburg-Steinwerder, Germany

Can you tell me about your project in one minute or less?

Having a concise description will help you at all stages of the project.

  • It clarifies what the project is about.
  • It is a reference for making sure you do not go off track.
  • You will know how to describe your accomplishment.

The elevator pitch answers four questions:

  1. What is the problem being solved?
  2. How are you solving it?
  3. What does it look like when you are finished?
  4. What is the theme?

Build your summary by answering the questions in reverse order.

What is theme of your project? Automation, improved customer service? A theme is not a thesis. Automation is a theme; Creating an interface with the bank is a solution. Improved customer service instead of creating a shopping cart for the web site. It’s the strategic objective of the project.

Work out what the result will look like, e.g. Bank transactions are imported with a single click. The customer can take a shopping cart to the checkout.

Tell how you are going to get there: Create an interface with the bank. Allow the customer to select multiple items and pay for them at the end.

And describe the problem you are trying to solve, for example: Bank statements need to be entered in by hand. The customer needs to select and pay for each item separately.

As you prepare, check that you are true to your theme.

Now when you put it together, you have a story: A challenge, the journey, the happy ending and a moral. “We are spending a lot of time entering bank statements into our system. We are going to setup an interface with the bank and our users will be able to import the transactions with a single click. This aligns with our strategy to automate our SG&A tasks.”

or,

  • Manual entry of bank transactions.
  • Setup interface with bank.
  • Give user one click import.
  • Part of Automation strategy.

You are now ready to pitch, describe and celebrate your project whenever needed.

Back to the Future Risk Analysis

Back to the future risk analysis

Take advantage of twenty-twenty hindsight when it’s most needed — at the start of the project!

The way to get a retrospective view at the beginning of the project is to use Gary Klein‘s risk analysis technique, the project premortem. This is a meeting before project execution starts. The attendees of the meeting are asked to imagine the project has failed and to give the reasons why. In this exercise the participants use the same perspective that is used for events in the past to look at a future event.

The premortem is based on research published in 1989 by Deborah J. Mitchell (The Wharton School), J. Edward Russo (Cornell University), and Nancy Pennington (University of Colorado). The study looked at why moving forward in time changes the explanations given for events.

There was earlier research showing that longer descriptions, with more detail, are given for past events. This was also true when looking at future events as if they were in the past. These studies had used scenarios where a forward (future) view always had uncertain outcomes and the backward view always had sure outcomes.

Other research had shown similar effects when certainty of the outcome was the variable. People act differently when the result is a certain, even if it is unknown. For example, people will bet less on a roll of the dice if they have been thrown and the result hidden. They are more willing to make a bigger bet before they have been thrown.

The researchers wanted to know why they were getting longer and more detailed descriptions because it could help people in making better decisions. This led them to set up two experiments and they were able to show that it is the certainty of the outcome that affects the explanations.

When you are uncertain of the outcome, your mind will try to predict what will happen. When you know what will happen, like when looking at the past, you will look at reasons why things turned out as they did. “Why” explanations have context; the who, what, where and when of the event makes the descriptions longer and more detailed.

In projects we also have to deal with organizational and group dynamics. As Daniel Kahnemann points out in “Thinking, Fast and Slow“, people avoid publicly expressing doubts about a project endorsed by management because their loyalty could be questioned. Using a scenario where the project has already failed takes away the stigma of being doubter and allows more risks to be exposed.

Putting it all together, we now have the protocol to use for the premortem:

  • We change the team’s perspective by making the result certain. We get better explanations because we are not predicting possible outcomes.
  • We assume that things went wrong to find why things could go wrong. Nobody is putting themselves in the position of predicting failure because it is already assumed.
  • We ask why to find the causes of risks to the project. The reasons why things could go wrong are not hidden because no one is trying to shift blame.

One of the keys to a good risk analysis is identifying as many of the project risks as possible. The project premortem makes the team look at why things can go wrong instead of simply looking at what could go wrong. It allows the team to bring up doubts that are sometimes held back. It’s Monday morning quarterbacking on Saturday.

Related:
Performing a Project Premortem — Performing a Project Premortem by Gary Klein (hbr.org)
Pre-mortem — Wikipedia article on pre-portem (wikipedia.org)
Back to the future — Study by Deborah J. Mitchell, J. Edward Russo and Nancy Pennington (wiley.com)

A Project Management Trap to Avoid

The Year Without PantsThere are tasks that are critical to the stakeholders and there are the tasks that are critical for the Project Manager:
“Projects accumulate a pile of annoying tasks people postpone, but in order to ship the product, that pile must be emptied. Things that are less fun to do are usually harder to do, which means the pile isn’t ordinary work but a pile of unloved, unwanted, complex work… This means that at the end of any project, you’re left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them.) It should never be a surprise that progress seems to slow as the finish line approaches.” — Scott Berkun, The Year Without Pants