Why projects fail

Projects have been here for ages and many organizations get more mature in project based work, but still projects keep on failing. I was asked to participate in a brainstorm about project failures and my input can be found below.

The Root Cause Analysis (RCA) framework was used to take a look at the different areas of which a project exists.

Please click on the image for a bigger view.

Click here for the PDF with large overview

If you would turn the negative ones into positives, you have a checklist for your next project!

A Root Cause Analysis on why projects fail

Work fascinates me, I can watch it for hours.

Werk fascineert me, ik kan er uren naar kijken

“Work fascinates me. I can watch it for hours.” During a gemba, I came across this statement at the back of a Hoegaarden beer mat which was attached to a whiteboard.

Sometimes we are so absorbed by our work that we forget to take a step back once in a while. A step back to observe the process, to observe the work delivered, to look for improvements, to adjust the strategy, …

The disadvantage of not being able to take a step back is that it’s perfectly possible to start working very efficient, doing non-effective (read: non-value contributing) work. Like they say: doing the wrong things in a very efficient way.

Toyota

The rumor is that the ability of taking a step back is one of Toyota’s criteria for acquiring people. During the job applications they leave the job applicant waiting somewhere in the production line/hall for half an hour. Afterwards they ask him what did he see during the waiting time and what could be improved.

Step back, look forward

Step back, look forward. Start, pause, stop. Evaluation. What’s in a name? It are all initiatives to taking the time (and courage) to take a step back and evaluate the current situation and progress.

The challenge is that when times get hard, it’s extra difficult to take the time for this review moment. Nobody has time for a step back moment when shit hits the fan. However, it could help that to build in review moments into your calendar and into the process.

Let’s take a look how Agile did this.

Agile and retrospectives

Agile is an iterative and incremental method used to develop software. (More about Agile in “GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management”)

In contrast with the familiar waterfall approach, Agile works in bursts. Short sprints of 4 to 5 weeks after which a working piece of software is delivered.

Agile has it’s step back moments build into the process in the name of retrospectives.

After each sprint, the team and customer get together to evaluate their last team effort. What went well? What could go better? It doesn’t matter which technique they use: brainstorming, root cause analysis, … The principle of taking a pause to observe the current efforts and see how the team can improve will positive effects on results, commitment and team mood.

Plan – Do – Check – Act

There’s no use for a step back moment when you’re not taking action. So design a method for assign and follow-up on actions and progress. Use the action list in your next retrospective. See if you made any progress (see also blog entry “A daily sense of measurable accomplishment”) and act upon it when it’s not working.

So, when are you planning your next step back moment?

Smart people have smart problems

SMART

This week I was asked to help with a problem solving (RCA – Root Cause Analysis) workshop. From my experience with RCA workshops I know that the workshop will succeed or fail from step 1: the problem definition.

When I got the actual problem(s), I was overwhelmed. It was not clear to me what the exact problem was and how I would get it to fit into the head of the fish bone (Ishikawa diagram).

Even when I applied my task force of six honest serving-men (What, Who, Where, When and How), I couldn’t get the problem sharp.

After talking with the participants, other lean coaches and searching on the Internet I got the problem sharp.

Let’s share some tips and look at the advantages!

Tips

Make your problem SMART: Specific – Measurable – Acceptable – Realistic – Time bound.

Workshop participants cannot disagree with a SMART problem because you have a measurable specific facts.

Try to formulate your problem in an elevator pitch.

If you cannot formulate the problem case in 1 to 2 sentences, it’s probably too complex, too blanket or too vague.

Check in advance with workshop participants if they agree with your problem statement and if not, what they propose.

This way you can avoid (expensive) discussion time during the workshop.

Don’t try to capture root causes hidden as effects in the problem definition.

Use only five of your six honest serving-men (What, Who, Where, When and How) for your problem definition, the sixth (Why) is covered in the RCA workshop.

Focus on the problem and not already on the root causes. These root causes will surface during the workshop.

Agree on the problem with the group before you start looking for the root causes.

Make sure everybody is focused and on the same page.

Hang the problem (formulated in the elevator pitch) on a visible spot during the workshop.

RCA workshop can take some time and it’s helpful to have to problem available to refer to in times of need.

Example 1 – four steps from a bad to a good problem statement

Bad problem statement:

“Our external vendor is delivering bad work”.

Why: too vague, not specific

Bad problem statement:

“Cooperation with our external vendor is going bad.”.

Why: too blanket

Bad problem statement:

“The external vender has delivered software with many defects because is not working like agreed”.

Why: has root cause in it, vague (“like agreed”?)

Bad problem statement:

“The external vendor has delivered software with many defects and the analysis was not on time”.

Why: multiple problems in one statement

Good problem statement:

“Our external vendor delivered software with 67 defects in the database layer for software release X on May 2^nd and because of it the cost rose with 10%”.

Why: specific, measurable, factual, no discussion, has effect

Example 2 – two steps from a bad to a good problem statement

Bad problem statement:

“The project documentation is unclear and not up to date, so is not used by new team members”.

Why: multiple problems in one statement

Good problem statement:

“Project documentation in the maintenance team is not sufficient for training new team members which leads to twice longer orientation times”.

Why: specific, factual, no discussion, has effect

Advantages

The advantages to put enough time in the preparation of your problem definition are:

• Everybody is on the same page. Focus.
• The problem is a (measurable) fact and no assumptions are made.
• There’s no discussion about the existence of the problem.
• Because the problem is a fact, it’s an issue that needs to be resolved.
• If your problem is defined SMART, you can measure the effectiveness of the solutions you find & apply.

“A problem well stated is a problem half solved” – Charles F. Kettering, US electrical engineer & inventor, Head of research for GM (1876 – 1958)

Get into flow

Flow is a term used for different concepts. The concept that is described here today is high performance work.

Everybody has moment when time flies by. You are working hard and for some reason, you become unaware of what is happing around you, the music you hear and the feeling of time passing by. You are working hard, you like it and things get done.

For getting into flow you need a lead time: you cannot just start right away with high performing. The lead time is estimated to be as high as 15 minutes, so switching between tasks can have a very negative effect of getting into flow and your productivity.

Here is where the problem lies in many cases at our work and even personal live. Our society is becoming more and more interconnected and next to colleagues asking questions, you now also have cell phone where people can reach you at any point in time by calling or texting. On a smart phone you even have notification for each new email, Facebook request and software update. Your email and agenda client at work (or even at home) is popping up for every new email or calendar notification.

Next to all these, you have the forums, blogs, news sites and communities you are following.

For the digital attention drawers there are some easy tips which you can apply:

• Put your messenger offline when your dedicated to one task.
• Disable email notifications on your email client and smart phone.
• Disable other notifications on your smart phone (eg. Facebook, software updates, …)
• Only enable reminders for meeting that you have to attend to. Limit the amount and time of reminders.
• …

Team work?

But what about those colleagues that ask you questions every x minutes? You cannot ignore them because the team and team goal are important, but you also can’t devote all of your time to helping them with every question.

How to detect the problem?

First of all, keep your eyes and ears open for complaints from colleagues at the work floor. If you notice there is some frustration, you study it to estimate how big the problem is.

The DILO (Day In the Life Of) technique is a very useful activity study technique for capturing problems like these. Sit next to the employee for one day and capture all actions, requests, meetings, interrupts, … of the day. When he switches tasks add a lead time of, for example, 5 minutes to it and categorize it as non-value adding (waste). At the end of the day add up all the wastes and express it in percentage of time. When the numbers speak, you have a burning platform.

How to handle the problem?

Once you’ve got buy-in, you can start with discussing the problem. Do a root cause analysis to find the real causes of the problem: why are colleagues interrupting your work so much? Or SMARTer: “why are colleagues interrupting my work so I loose 1,5 hours each day by task switching?”.

Typical improvement actions range from coaching, peer coaching, training and mentoring for junior colleagues, product usage demonstrations by business and technical demonstrations.

In extreme cases, you can apply concepts like the cockpit and quarantine. The “cockpit principle” for example is used in the flying industry: during take off and landing the pilots need to be very focussed on achieving success and putting the plain up/down in a safe way. To ensure this the agreement is made not to speak during these critical moments with the only exception when safety is at risk.

In the Agile literature I’ve come across of some application of the cockpit principle where IT workers use flags, mascots and other indicators that they cannot be interrupt for a while, unless for really urgent problems.

But first, let’s look at the root causes before putting on your captain’s hat.

The ideal moment for a Root Cause Analysis (RCA)

A Root Cause Analysis (RCA, Ishikawa diagram or fish bone) is a problem solving technique that gets to the root causes of problems. The workshop has an action plan as output to deal with the real (root) causes and make sure the problem doesn’t occur  again.

You can do the root cause analysis on different moments in time: during right after the incidents or even later.

During the incident

When an incident takes place, there will be no time to do a root cause analysis. The focus is to get up & running as soon as possible. Afterwards the problem can be studied with a root cause analysis to solve the root causes and make sure it doesn’t happen again.

Right after the incident

The ideal situation for doing a Root Cause Analysis is immediately when the incident is solved.

The reason for this is that the incident is still fresh in people’s mind. Everybody is thinking of the same and there is no (better: less) room for interpretation and assumptions.

To make sure everybody is on the same track, some best practices are to prepare the problem statement in advance and to agree to it in group when the workshop starts. This approach will save you lots of group effort (time) because the discussion is held up front with the necessary contributors, and the focus is clear and set when the group effort is needed.

It is also easier to agree to the problem to investigate with a smaller group.

When the workshop starts you can recapitulate the problem you are about to investigate and see if everyone present agrees that his is this problem to make sure there is no room for interpretation and assumptions.

After some time

Due to time and other restrictions it is not always possible to facilitate a Root Cause Analysis workshop right after the facts and more time is needed.

An example of this could be a postponed workshop for a software release evaluation X that is held after release X+1 went to production.

The challenge for this workshop is to get everyone looking in the same direction. We want to evaluate software release X, but in the meanwhile another software version (X+1) is already released. The risk here is that during the evaluation of X, participants are confused and will discuss or mix-up incident details with the evaluation of release X+1.

How can you deal with this?

• Think carefully about the added value of doing the workshop for release X after release X+1.
• Address the issue to the participants. You know it’s rather late to make the evaluation, but the added value is high enough to put in the effort (and take the risk).
• Tell the story again: what happened? What were the conditions? Who was involved? If needed, create a time line.
• On workshop start, make an in and out of scope board. Put topics on Post-Its to set them explicitly in or out of scope. When in doubt during the workshop, you can refer back to this board. “In scope is the release X and out of scope is release X+1, some more?”
• Don’t make assumptions: when in doubt, don’t assign root causes.

RCA: there’s more meat to this fish

The Root Cause Analysis (RCA) problem solving technique is typically used for studying a specific problem to get to its root causes and to find solutions that solves the real causes and not only the symptoms.

The RCA technique makes use of the Ishikawa or fish bone diagram and this fish bone makes it possible to use as framework for other workshops.

Positive RCA

As said before, the RCA starts from a SMART problem, but you can also use it to brainstorm solutions. Put the wanted result in the head of the fish and use the bones to capture ideas.

I often refer to this technique as the positive analysis.

Brainstorm

We can take the brainstorming one step further: the fish bone is also handy when brainstorming solutions, issues and risks. For example when creating a project charter and you want to identify all possible risks of your project.

Other categories

Why limit yourself to the default categories of process, people, organization, equipment, measurement and procedure? (I actually had to look up the default categories again)

Just use what fits the purpose. If you’re discussing an IT failure in the production environment you can apply for categories like database, front end, infrastructure, network, catalogue and so forth.

Voice Of the Customer survey

You can use the RCA framework even for a VOC survey. At the head of the fish you  put the area you want to evaluate and together with the customer you capture positive and negative remarks for each bone to evaluate.

The advantage of this technique is that you can receive feedback you would never have heard when providing a fixed list of questions. The disadvantage is that the survey (workshop) requires more energy and participation of your customer, and not all customers are willing to participate in such a workshop.

So there’s more to this fish than just getting to the root causes! Why not try it next time?

Dealing with root causes, not symptoms

Today the Belgian government proved that even for highly educated people it’s difficult to really get to the root cause of problems instead of dealing with the symptoms of the problem.

Last week in a tragic case of traffic aggression a Belgian assistant for bus drivers of the MIVB (a Belgian public transportation company) got killed with a blow to the head. The reason why the aggressor gave the punch is not clear. The same is valid for the increasing number in violence on Belgian public transportation.

The government reacts today by adding 400 new police forces to support the MIVB bus drivers in the capital Brussels and hopes to decrease the number of violent incidents. By adding more blue to the streets, the problem of traffic aggression is still not solved: we are only dealing with the symptoms of the real problem, and the symptoms here are the excessive violence.

The assault on Iliaz Tahiraj is no stand alone case: there are more and more incidents reported with violent acts against public transportation representatives. During interviews on the local radio, reporters are asking questions about the root causes to random people and they are only guessing: the offender came from a different layer of society, public transportation is not for the rich, bad education, and so forth.

So we have a recurring problem with a devastating effect (loss of lives) and still we are only focusing on the symptoms and temporary solutions?

On one hand, these temporary solutions are needed to temporary deblock the public transportation strike and provide some security for the drivers, but i sincerely hope they are also investing time for getting to the root cause.

This ain’t going to be an easy one, but we can do better than this.

Time never stops

Last night i saw a scientific documentary “Wonders of the Universe” where they discussed the concept of time. We notice time because things are changing. Things are changing because they get energy from the sun and other stars. At the last hours of the universe, all stars (suns) will be dead and all material used. There is no more energy. Since there is no more energy, nothing is changing. When nothing ever changes, the concept of time stops.

So if the sun is still shining and there’s plenty of energy available, why does time stop at so many visual management stations and even whole departments? We can’t see anything moving: the KPIs look frozen, the steering board is not updated, old fish bones from RCA workshops decorate the walls, visual material is outdated, … Only the team plan boards seem to move because work is taking place.

If this sounds familiar to you: what are you waiting for?

• If your KPIs were only suited for a specific time period, replace them by relevant ones.
• Find better KPIs if the current ones are not suited at all. There is no need to hang on to measurements that are not working.
• Plan a 5S action at your department and clean up all old material from RCA, VSM and other workshops.
• If you team steering board or plan board or dashboard is not working, start from scratch and invite your team to design a new one.
• Clean up success stories and customer feedback to make place for new one.
• Put a reminder in your agenda to do this each month.
• etc

Keep in mind: outdated information is wrong information.

Time is ticking…

Hunting crows and chasing rats

The fable

Since a few days, the farmer had some problems at his ranch. Crows were circling around all the time and they were bothering his chickens. He took up the challenge and set a scarecrow next to the chicken yard. This worked for a few weeks, but then the crows were back. So he bought a small air rifle to shoot some of the crows. Shooting the crows seemed to solve the problem. On the meanwhile he found another problem. All over the place there were little holes in the ground and it didn’t took long before the farmer saw a rat. He was used dealing with rats so he spread the poison where the chickens couldn’t reach it. He thought his problems would be solved by now. He couldn’t be more wrong… The rat problem was getting out of control and the crows kept on coming.

With hands in his hair, he called out to his nephew for help. His nephew was raised in the city and knew nothing of farming, but was eager to help his uncle with the problems.

“So,” he asked, “what is actually the problem?”
“I can’t get rid of these filthy rats,” he said.
“So the rats are the only problem?”
“No,” the farmer said, “we also have problems with crows. They just keep coming back here and i can’t figure out why”. 
“So what did you already do?”, the nephew asked and the farmer explained the whole story, starting from a few weeks earlier.
“Hmm,”, the nephew said, “it looks like you are dealing with the symptoms, not the problem”. On the wooden door of the barn, his nephew drew a fish bone diagram to get to the root cause. After a short session, they came to the conclusion that the problems was the vast amount of available food (grains etc) that was available for the chickens, but also attracted other species.

Stunned, the farmer asked: “Regardless of how many crows I would have shot and regardless of how many grams of rat poison i distributed, the problem would not be solved?”
“Correct,” his nephew confirmed, “you were only dealing with the symptoms, almost like firefighting. While all the time the root cause was right in front of you, but you never saw it”.

The technique

While we’re in the heat of the battle, we sometimes lose sight of the battlefield. Setting a step back to check for root causes instead of firefighting will help you really solve the problems. But just using the fish bone (or Ishikwa) diagram is not sufficient: you also will have to apply the “5 why” technique. “5 why” is a method for asking questions and not stopping at the first answer. When keeping asking “why?” you get closer to the root cause of problems. The closer you get to the root cause, the easier it is to find solutions for your problem. Using the “5 why” method can also lead to multiple answers which need separate solutions.

Remark: the 5 in “5 why’ is only indicative: after a certain number of why-questions the answers get too trivial or you could get back in a loop to the first question.

An example

When we were looking at a problem of knowledge sharing and transfer, we found a root cause that describes an experienced employee leaving.

The experienced employee is leaving and that’s why we fail at knowledge sharing and transfer.

If you apply the “5 why” technique here, there are two possible routes.

The experienced employee is leaving and that’s why we fail at knowledge sharing and transfer.
Why? Because he got a better job offer.

You could go deeper with this one, but then you’ll follow the HR road and this deviates too much from our problem: knowledge sharing and transfer not going great.

Let’s give it another attempt.

The experienced employee is leaving and that’s why we fail at knowledge sharing and transfer.
Why? Because he had a lot of experience and you cannot replace that with a new employee.

This is a correct answer, but does not lead us to the root cause of the problem. If after five years the next (experienced) employee leaves, you would have the same problem!

Why is it a problem that he is leaving? Because he was the only one with the knowledge of system X.
Why is the only one with this knowledge? Because there was no employee intake program, because there is no documentation set up during the years, because the knowledge transfer period was too short, because …

And now you finally got to the root causes! For each of these root causes we can find a solution that is suited. Without the “5 why” technique, we would have stopped asking questions after the first root cause and only came to the conclusion that a lot of knowledge was with the former employee. So if we would train a new employee and he would leave after x years, we would have the exact same problem again. After applying “5 why’ and solving the root causes, the departure of the newly trained employed shouldn’t have that big of an impact anymore.

Best practices for a Root Cause Analysis – perspective of the coach

We do problem solving workshops all the time, but what can we learn from it?

In two posts I will share some best practice from a different angle. The first post discussed the perspective of the facililator of the event (or also the coachee). This post will handle the perspective of the coach.

Defaults like “start on time”, “training”, etc. are omitted, unless it’s considered critical.
I am sure there are many more best practices ready to be shared, so please do!

Preparation of the workshop

	What was learned?	Why is it critical?
1	Prepare the problem to be SMART and unique.	Set focus/goal. Avoid ambiguity.
2	Check if the workshop can end with success.	Avoid damage of the program.
3	Check roles, responsibilities and involvement for the facilitator, participants and lean coach (i do, we do, you do).	Clear understanding of their and your contribution.
4	Help with calculating the cost of the problem.	Make the added value clear for the coachees.
5	Repeat the techniques: 7 step A3, 5 why, role facilitator, …	Process skills of facilitator are important for results.
6	Logistics: book preparation and follow-up meetings in advance. Reserve an extra timeslot in case of problems.	Don’t attack the coachees agenda’s on short notice.
7	Manage expectations of stakeholders: when is the workshop a success or a failure?	Check the timing needed for the workshop. Prepare results of workshop.
8	Check if an introduction from the manager is needed	Engagement of participants. Handling of sensitive issues.

During the workshop

9	Observe. Write down what you see and how the group reacts.	Give objective and constructive feedback to your coachee.
10	Be a safety net (if agreed).	Help the facilitator when things are going hard.

After the workshop

11	Make the balance: time invested vs spent	Make sure coachees see the added value of the workshop.
12	Give feedback to your coachee about your observation.	I do, we do, you do