Most of you have probably heard about sunk cost but being reminded about some core fallacies can be good from time to time. I’m since long well aware of the sunk cost fallacy but as you’ll see I’m still very much fallible.

A new TV series starts airing and I watch the first episode. It turns out to be so-so. Not great, but not a complete waste of time either. So I decide to give it another shot the next week. It doesn’t really get any better but I still have hope for it. The cast indicates that there should be more to it than this, so I keep watching the darn thing for a couple of more weeks. Now, it’s beginning to bother me that I’m still watching the show since it doesn’t give me anything but since I’ve already seen the first five episodes I might as well stick with it to the season finale. Then all of a sudden the network decides to cancel the show prematurely. The bastards!!! How dare they? Hey, I was watching that!

The truth is that the network did what I should have done after the very first episode, they cut their losses and decided for another future. They came to the same conclusion that I (and probably most other viewers) did; that the show was crap. But instead of loosing any more of their precious air time, they decided to cancel the show and try to make money on something else.

Time wasted

Time Wasted

The rational decision for us is to ignore the previous investment and look at what marginal gains we have from choosing an alternate path. Mine would have been to give another TV series a chance or perhaps read a book instead. The time I had wasted on the show was already spent and I won’t get more value from it by wasting more time. The network having spent big bucks on procuring a new show, have to disregard this investment when the audience fail to show up and instead look for something new to fill their schedule with. Which was exactly what they did. Pissing me off was the sound decision, for both of us. So thank you TV network for cancelling the show I was watching, I should have known better.

Have you ever experienced working in- or with “teams” that never seem to get to a state of working together as a team? I put the word teams within quotation marks since these aren’t really teams, they’re just administrative units. This has happened to me a couple of times and no matter how much we struggled with trying to get everyone on the same page through working with visualization, teambuilding, meeting formats, goal setting, work spaces etc, everyone would go back to their desks and continue to work as fractions. I’ve gone through several phases of explanations and rationalizations in my attempts to explain to myself why we had these problems. A while back Esther Derby introduced me to Glenda Eoyang’s work describing the effects of containers on systems and that really put the spotlight on some of the driving forces behind our problems.

containers

Basically a container is something that bounds one part of the system from another and constitutes a difference. Containers can be:

  • something physical such as walls, desks or cubicles that separate people or unite people.
  • of organizational nature; people reporting to different managers, belonging to different departments or being hired consultants as opposed to employees.
  • something conceptual such as purpose or rules.
  • behavioural, e.g culture or family situation.

The effects of these containers will greatly affect how people are going to work together. Some of them will work in favour of collaboration while others will drive a wedge between people. When I began to model the containers that I could identify within the troubled teams it was really easy to see how many things were pulling people apart instead of holding them together.

People may have been assigned to the “team” and in best case even be co-located. We might have a unifying goal of delivering a product or service but that’s where the positive forces ended. Then people would be experts belonging to different organizational units. They would be reporting to different managers. They could get input to their work from different sources. They would be seated together with a few people with the same kind of expertise. They belonged to different budgets. Their personal goals were set with different managers and not aligned. They belonged to different subteams. They would have to work on other projects outside of the dedicated “team”. Etc. Etc. Etc.

Seeing all these forces working against us made it clear that we had a snowball’s chance in hell of building teams that would actually work as teams. For every action we took to align the team members there would be ten other actions around us that pulled us apart. My guess is that if we would have come much further if we would have focused more of our energy on identifying and redesigning the root causes of the forces pulling people away from each other instead of performing a tug of war with these forces.

Tug-o-war

Some time ago I was asked to work with a “team” that “had problems delivering” and “the few things that did come out of the team was of poor quality” and as if that wasn’t enough, “people were generally not happy about working in the team”.

The “team” – it turned out, consisted of a handful of developers. They got their work from a couple of different business analysts in different parts of the organization and when they were done coding, assigned the work to some testers in another part of the organization. Before taking on the assignment I made one request and that was to get to work with all three disciplines as one team; requirements, development and test. We did a lot of different things together in order to overcome the challenges but the one thing that made it at all possible for us to create a high performing team was the tearing down of old containers and building a new one around the team.

I’m sad to say that the reason I’m so certain about the power of the containers in this case was that as it turned out, the company structure wouldn’t allow for this organization in the long run. Soon after I left the team, group managers once again split the team into three parts; requirements, development and test, each group with their own team lead. None of the other practices we had put in place were strong enough to withstand this break-up and pretty soon everything was back to square one again.

My lesson from working with this team was that it’s not enough to learn to see these invisible structures, we also need to see the incentive systems that put them in place. But I’ll save that for a later post.

Scaffold

The Need to be Needed

January 10, 2014

“A bee is never as busy as it seems; it’s just that it can’t buzz any slower.” – Kin Hubbard

A while back I was coaching a project that was to a large extent staffed by people being experts in narrow fields of expertise that also had other commitments outside of the project preventing them from having any slack time what-so-ever. This constituted quite a big challenge because they all took turns to act as bottlenecks in the process so I decided to run a retrospective focused entirely on how we could free up more of their time in order to improve the flow of work.

The initial reaction I got was almost enough to give up on the idea entirely. Almost everyone started moaning about management and the organization being the problem.
“Tell them to not dump all this work on us.”
“As long as we have to do projects as well as maintenance this will always be a problem.”
“I have to support so many projects that I’ll never be able to set aside any slack time.”

With the support of the project manager though, I decided to run the retrospective despite the chorus of geese shaking off the water. The setup was quite simple; we divided into groups of three and I asked each group to work according to the Iroquois “Rule of Six” to come up with at least six plausible reasons for why key people in the project were constantly overloaded with work. I asked them to specifically look for reasons that were in our reach to act upon. The result was amazing. All groups managed to present at least a handful of reasons showing how we all were responsible of creating this problem.
“I say yes to almost anything.”
“I don’t trust other people to do a good job.”
“I ask other people to help me with stuff without checking if it’s prioritized.”
“I don’t prioritize the work that comes in.”
“I create work that has not been asked for.”
etc.

I was overwhelmed with the candidness and maturity in the answers. This was great; we had found so many things that we would be able to act on in order to ease up on our own as well as our peer’s workloads. With this smörgåsbord of possible actions I didn’t want to do a prioritization to select one or two to implement during the upcoming sprint. Instead I asked if we could take as homework to do a daily act of kindness to ourselves and someone else. Could we at least once a day stop to think if we were about to act according to one of the patterns that we had found and instead take another road?

This is where things started to get interesting again. Amidst the nods and yesses I detected some hesitation as well. The hesitation wasn’t spoken out loud in any way but it was in the air so I asked for a fist of five. Could everyone on the count of three please raise a hand showing their commitment to this homework by showing any number of fingers between one and five?

  • Five fingers being “YES! I’m really committed to this, count on me.”
  • One finger might as well be the middle one; “There’s no way in hell that I’m doing this.”

All people raised four or five fingers except the three persons being the most overburdened, they only held up one or two fingers.

When I asked what made them hesitant about doing this daily act of saying no to another task or not handing unprioritized work over to a fellow project member, they all fell back to the initial reaction of pointing outside their own sphere of control: “It’s not possible to say no.”
“If there’s a production problem it has to be done.”
“We have to do this even if it’s not prioritized.”
“Quality will suffer if we don’t do this.”

I’m not entirely sure if the conclusion I came to after this meeting was correct or not but I suspect that these people thrive on being busy. It could be external factors such as explicit or implicit rewards and/or threats that make people act in ways that puts them in the center of everything but having seen the same people end up in these situations time after time in different positions at different companies make me think that the problem often is self constructed. Some internal belief system or internal reward system make some people act in ways that is hazardous to not only their own health but also the productivity of the team that they work with. I don’t have a turnkey solution for this problem but I would ask everyone to consider this possibility before going about redesigning the organization or taking any other measures on the system.

The problem might not be that we force people to work too much, it could very well be that we allow them to work too much.

High-fiving the office

February 21, 2013

This morning it took me fifteen minutes to walk past my team and get to my desk…

But that was this morning, let’s back up one month. Middle of January my team had a team building activity. Now, I know that teams aren’t built during an activity but there were reasons behind us having this activity. Anyway, as a final exercise we all got to close our eyes, relax and try to visualize what it would be like if everything in the workplace was going as we wanted. We then got to draw our internal images and present them to each other.

My drawing had two parts to it. One part showing a kanban board where work was flowing smoothly, representing how we worked well together as a team. The second part pictured me high-fiving my co-workers on my way to my desk, representing us having a great time together.

High-fiving

What I saw before me was how it would take me fifteen minutes every morning to move from the entrance to my desk because I high-fived everyone along the way, stopping to ask how they were doing and generally enjoy being with awesome people.

Some background might be in place here. My desk is at the opposite end of the building from the entrance, which means that I have to walk by the entire team every morning as I walk to my place. The thing is, that I’m an MBTI introvert. I enjoy people and company like most other people but it’s exhausting for me. Having a good time with other people makes me physically and mentally tired. Because of this I’ve been taking a detour every morning in order to get to my desk without having to pass anyone I know, that way I could save my energy for “more important stuff”.

As I looked at my drawings I realized that the first part was what we’re struggling with together as a team, but that the only thing standing between me and my vision in the second drawing was myself.

The day after the exercise I stopped for a minute after entering our floor. I took three deep breaths and began the walk to my desk. Only a few team members were at their desks so I walked up to the one colleague who I knew would understand the idea. I raised my hand and immediately got a slap. It felt good and we discussed the exercise for a while. The day after I repeated the ceremony but stopped by two of my colleagues on my way to my desk.

Since then I’ve been adding people to my daily routine and this morning I walked around high-fiving everyone at their desks, stopping to chat for a while; both personal stuff as well as job-related. I timed the walk and it took me fifteen minutes to get to my desk.

What I’ve noticed is that most people’s faces light up as I walk by for the daily slap. The guy next to me was a bit upset though, he didn’t want to always be the last one to get a high five.

I believe in the idea that we are our feelings. If I act happy, then I will be happy and I will feel happy. If I start the day with a smile and a high five, I will get a better day. Fake it till you make it so to speak. The bonus is that people around have to start their mornings with a smile and a high five as well.

So as an introvert, does this procedure consume energy? You bet it does, I have to brace myself every morning before I walk into the room.
Is it worth it? You bet it is!

Disclaimer: Not everyone enjoys a high five in the morning, especially if they’re in the middle of something and that’s okay too.

That’s life … Not!

October 8, 2012

Do you remember the Smurfs? Little blue creatures with white hats. Three apples high. Very strong characters. The fact is that their personalities are so distinct that each one is named after it’s strongest character trait. We’ve got Clumsy Smurf, Happy Smurf, Angry Smurf, Grumpy Smurf and countless others.

They like to sing as well. At least here in Sweden they used to sing a song about everyone of us having an inner smurf. They were wrong. We don’t have ONE inner smurf; all of them live within all of us. Inside our heads, the entire smurf village is represented. Inside your head is a board of directors consisting of Papa Smurf, Angry Smurf, Poet Smurf and all the other smurfs.

Your board of directors

The problem is that we learn at an early age that all smurfs are not born equal. Sure, we cherish a couple of them; Pretty Smurf, Smart Smurf, Kind Smurf and a couple of others while we suppress most of them. We create rules along the road for which smurf to bring out at what occasion. One of the first things we learn as newborns is to bring out Scream Smurf when we want some attention. Then, while growing up, we create new rules that benefit us better in the new situations that we have to face. But somewhere along the way we stop evaluating our rules. The rules harden and become an integrated part of us and finally we sit there with a small number of smurfs that we only let out at very given occasions.

Not all smurfs are created equal

Clumsy Smurf, Greedy Smurf, Ugly Smurf and Crying Smurf are not let out into the open if we can stop them. Sometimes we can see them in other people, representing their bad sides and sometimes we can even hear them quietly inside our own heads but they make us feel ashamed and we shut them up as quickly as possible. We suppress Egotist Smurf until he’s no longer three apples high, but only a molding apple core sitting quietly in the corner.

When we restrain these alternative sides of ourselves, we also limit our emotional degrees of freedom. We’re stuck with only one possible emotion to bring out for each situation that we have to face. Remember that there are rules for how we should behave! The situations become governing for us and we feel cornered since we don’t have any freedom of choice on how to act. That’s also when we begin to blame our emotions on the world around us.

– Oh, you make me so mad when you talk like that!
– You make me sad when you act that way.
– You! You make me feel violated.

We can’t choose what will happen to us, but we can always choose how to handle the situations and the first step towards ownership of the situation is to take responsibility for our own feelings in it. The next time you feel anger building up inside you, try not to say that “You make me sad.“. Instead, try saying “I get sad when you talk like that.” or even better; “I’m making myself sad when you talk like that.

The rules that we have created for ourselves have at some point been useful to us but when we stop re-evaluating them, we also stop choosing rules and instead let the rules choose for us.

But what should we be doing instead? Should we throw out our old rules on how to act?

No! Don’t throw them out but start challenging them again. Evaluate them continuously and see which rules are still beneficial to you. And use them as guidelines instead of rules. There is always a choice. I can choose to get sad, I can choose to feel violated but I can also choose to ignore. I don’t have to be a victim of the circumstances because I can choose which smurf to bring out, they all belong to me.

I would like to highlight three things that we can always do to improve our possibilities for making conscious choices. These are not advanced methods and they’re not even separated from each other, they overlap quite a lot. But they do allow us to become and act as thinking creatures, capable of complex responses that match the situations we are faced with.

The first thing that often stands in our way of making a conscious choice is that we don’t take the time to consider our options.

Your kids walk up to you five minutes before dinnertime asking for ice cream.
NO!!!

You shot the answer at them in a fraction of a second as if this was a duel of life and death between you and the kid. But we don’t owe it to anyone to answer that quickly. We’re allowed to ask for time to think.

Wait a minute while I think about it.

What would happen if I let the kid have an ice cream before dinner today?
Would he get cavities? – Probably not.
Would I always have to let him have an ice cream before dinner?  -No.
Or could I let him have an ice cream just to make him happy today?
If I only take a couple of seconds to consider my options, I might realize that it could be okay for me to bring out Nice-Daddy-Smurf and let him have an ice cream today.

The second thing that has a tendency to get in the way between us and our possibilities to choose which Smurf to bring out is that we don’t listen to the person we’re interacting with. We think we recognize the situation the person is talking about quite fast and then we put it into our own context and spend the rest of the time trying to come up with a good reply for when it becomes our turn to speak. If instead, we could focus on the here and now and really listen to the person and validate that we’ve heard what she has to say, then we’d realize that the situation probably isn’t what we first thought. Once we see the complexity of the situation we are able to meet it with an equally complex response that works in the right direction, instead of just conveying our simple opinion on something we thought we had heard.

The third point I would like to suggest is to reframe the situations we face. If we can change our perspective, we will also be able find new ways to act and respond. Try to find new ways to describe what you experience and use positive or neutral terms to depict situations or actions. If your instinctive reaction to someone is that the person is irritable, see what happens to your feelings if you call the behaviour passionate instead. If someone seems fearful, try and see if your feelings change if you call him careful instead.

Assume the most generous interpretation of the world around you and you’ll definitely change your view on a lot of things. You will also learn to know a much larger portion of your inner smurf village.

Charlie Seashore – Master of reframing

This post is based on a lightning talk I recently gave (and messed up somewhat) and is heavily inspired and influenced by some awesome people that I’d like to recommend for further reading on the subject.

Beverly Patwell and Edie Seashore – Triple Impact Coaching
Barry Oshry – Seeing Systems: Unlocking the mysteries of organizational life
Virginia Satir – Your Many Faces

– It’s 42 boss.
– …
– Yes boss, that’s higher than the 5 bugs we had a couple of sprints back.
– …
– No boss, that was the sprint when we spent the majority of the effort implementing the configurable splash screen and the easter egg TicTacToe-game. The features that you predicted would triple our sales.
– …
– Yes boss, it is also lower than the 50 bugs we had last sprint.
– …
– Yes boss, last sprint. You know, the one when you hade us work overtime every second day in order to fulfill our customer’s demands of removing the configurable splash screen and the easter egg TicTacToe-game. Remember how they said that the features lowered the productivity for their employees?
– …
– No boss, it’s still 42 this sprint. However, we’re only on week three of our two week sprint that you’ve prolonged to four weeks in order to fit some extra functionality in. So I guess the number might still go up.
– …
– Boss, I think I’m actually beginning to see the value in counting bugs. These numbers seem to have a strong correlation to the decisions you’ve made. We can probably learn a lot from them.
– …
– What the hell was it you wanted to know boss?
– …

There’s an old saying that a lazy programmer is a good programmer. I’ve never heard an old saying about a lazy manager being a good manager but yet there are all too many of them out there.  Not the good kind of lazy manager who is willing to delegate work and to let people do what they’re good at without micromanagement. No, we get the other kind of lazy manager – the Panacea Manager – who is constantly looking for a shortcut.

The Panacea Manager will measure the organization on what he can count on his fingers and toes because words bore him, unless of course they’re his own. The Panacea Manager will ask for bug count, lines of code, number of test cases etc.

What do you think the Panacea Manager will receive when asking for these numbers?
Is it hard for a developer to produce a lot of code if that is what she is being measured on?
Is it hard for a tester to produce a lot of test cases if that is what he is being measured on?
Will the number of bugs found tell you anything about the quality of the software after they’ve been corrected?

Do our customers care about the bug count or LOC or number of test cases? I don’t think so. Bug count and most other numbers that we collect are just proxy variables for quality as we think our customers perceive it. Measuring quality and productivity via proxy variables might very well result in quite the opposite of what we’re trying to achieve.

How about if the Panacea Manager took a long look at the system he has built or inherited and started making deliberate decisions based on how he actually wanted the system to work? What if he stopped measuring bug count and lines of code and began asking the customers for what really matters to them? Would it make his job harder if he tried to compare customer satisfaction over time instead of employee hours spent in the work place? It probably would to some degree but it would also mean that he actually began doing his job.

So what should we measure then? I’ve learnt that many people itch to ask that question after listening to my arguments. Please don’t! That means I’ve failed at getting my point across and I’ll loose even more hair on my head. Begin with asking yourself; what decision do I want to make and what do I need to know in order to make that a good decision? THAT is what you should measure.

As a leader – or team member as well for that matter, you are faced with a big problem every time you try to implement some sort of a change in your organization.
No, that’s not true. You face a lot of big problems, but one of the bigger ones is … you.

You are trying to interfere with a system without being able to see the entire system. You need to get a helicopter view of the landscape while at the same time being grounded as an important part of the very same landscape.

Most of us don’t understand how much we affect a system that we are a part of, and more importantly; we don’t understand in what ways we affect that system.
Our presence in a meeting can set the entire tone of it without us doing anything in particular. Likewise, we can also affect the outcome of a meeting just by being absent from it.

How do we interact with our systems? What messages do we send to them? Do you have a total coherence between your thoughts, your words and your actions? If not, what parts of your intentions and your communication are getting across? Vice versa; what parts of your coworkers’ true intentions get across to you.
How can we possibly know how a system will react to a particular change if we can’t see the entire system?

Being a lean/agile coach, I’d like to suggest that you get yourself a new set of eyes and ears. As a leader or team member, it’s your duty to be a part of the landscape. You must be the intricate part of the machinery that you are. I, as a coach on the other hand can reserve the right to stay outside your particular system. I can put my stethoscope to the heart of your organization and listen without the distorting filters of preconceptions and interfering echoes of my own actions.
(… at least for a while. Sooner or later we all get biased.)

There are also tools like the left hand column exercise and Virginia Satir’s interaction model that can help us learn to see how our own behaviors affect those around us. If we accept the help and take the time to study ourselves, we can begin to move out of our own blind spots and get our helicopters in the air.

Rotting Estimates

June 20, 2011

Have you ever been part of a late project where you constantly update your estimates and plans but they continuously get worse instead of improving? Where you finally get to the point where your estimates get out of synch during the time you fetch a cup of coffee?

No? Then I congratulate you because it’s an extremely demoralizing and costly situation.

Yes? Then this post might be able to provide some insights to the dynamics at play.

The model

A colleague of mine just recently presented me with the generic project model built on the work of Pugh Roberts in the early 70’s.

The model is very simple but it gives a good starting point for discussing the recurring dynamics in projects. We pull work from our “Work to Do” box and implement it, either correctly or incorrectly. Work done correctly goes into our “Work Done” box while work done incorrectly goes into our box of “Undiscovered Rework”. Note that this has nothing to do with our physical deliveries, both work done correctly and work done incorrectly will move along the same physical path since we haven’t been able to distinguish the two from each other yet. When we do discover the need for rework we will assess the problems and move them back into our backlog of “Work to Do” again.

What is “Undiscovered Rework”?

In this post I will mainly focus on the “Undiscovered Rework” box. This is our backlog of work that we think we have completed but that will not be accepted as it is. Some of the rework will be discovered when we implement new functionality, some will be found during testing and yet some will be discovered by our end users in production. Anything we produce where the quality is unknown carries the potential to end up in this box.

The sources of “Undiscovered Rework”

The amount of work in  “Undiscovered Rework” tends to grow quite fast as a project goes along. A couple of factors that speed this growth up are:

  • Not having a good definition of done
  • Postponing testing until the end of the project

Both of these factors hide the true quality of our product and allow for different kinds of errors to pile without us knowing it. If our feedback loops for determining the quality of our product are too long or if they are missing entirely, there is really no limit to how much waste we can add to this future todo-list.

The implications

The big problem with “Undiscovered Rework” is that it hides the true progress of our project. It hides our status because we do not know how much work is actually done and we do not know how much work is actually left to do. It also corrupts our view of the rate at which we make progress.

Normally when working in an agile project where we use our velocity to predict future deliveries, our estimates narrow in and get better and better as we gather data over the sprints but this only holds true if we don’t let our hidden backlog grow. If we do not know the true quality of our product, the only thing our velocity tells us is at what rate we can produce crap. If we allow the amount of “Undiscovered Rework” to grow, our estimates will keep deteriorating over time.

An example

Let’s imagine we’re in a project where a serious amount of the testing is done at the end of the project. We begin this project with 15 user stories in our backlog and find that according to our velocity we can implement three user stories each sprint.

The thing is that one third of this work ends up in the “Undiscovered Rework” box. We move into our next sprint believing that we have finished requirements A, B and C and that we will be able to do requirements E, F and G during the next couple of weeks. The problem is that stories C and G will need to be redone completely later on (I’ve simplified the example by gathering all errors in one user story here).

After going for four iterations believing that we have a velocity of three, we look at the last three remaining items in our backlog and think that we are one iteration away from our goal. But testing will show that we actually have four more stories to complete from our previous sprints. So we actually have seven (!) stories to implement.

We are not talking about one more sprint anymore. That is more like two and half sprints. But wait a minute, our true velocity was not three stories per sprint, we actually only managed to produce two stories of good enough quality per sprint so that means that our seven remaining stories actually will take three and a half sprints to complete. Now we’ve gone from being almost done, to being halfway done.

The insights about the remaining work in the previous example will not happen all at once. They will usually dawn on us one at a time and without us being able to see the connections. The symptoms that management and we will see are that work suddenly begins to slow down. So we begin to re-estimate our work when the first bug reports come in. During our first re-estimates we probably still believe that our velocity is three stories per sprint and we will just add some time for the bugs that have been found so far. Then as we move closer to testing and get faster response on our fixes our true velocity will begin to show and we will need to re-estimate again. What often happens at this point is that pressure from management will force people to take shortcuts so the rework becomes fixes and the fixes becomes workarounds and these workarounds will create new problems for us. Stress generally forces people to make bad decisions that will put the project even more in a pickle. If we are totally out of luck, management will fall back into old command and control ways of thinking at this point and force the project to go from pull to push while beginning to micro-manage people and thus slowing down progress even more. Now there is really no saying how long this project will take anymore.

Conclusion

Good estimation is about always being correct but adding precision as we learn more.

Most projects start out with a well-defined status (i.e. nothing has been done) and they stand a fair chance of making a somewhat decent initial estimate. Nurturing this estimate by collecting data while at the same time assuring quality will help bring precision to it. But if we allow for quality to be an unknown and still fool ourselves into believing that our data gathering will add precision to our estimates, then we are heading for a crash. The false sense of knowing where we stand will only make further estimates more and more off for every new data point gathered.

Turning this knowledge around though, you can use it as a canary in our project. If you experience that your estimates begin to get worse over time instead of improving, it might be a sign that your project has some serious quality issues.

Problem – the perceived difference between a current state and a desired state.

In my last post I discussed assumptions as a good starting point when looking for initial causes in a root cause analysis. Today, I will look at one more practical way of finding these hidden assumptions. I will make an assumption myself here and that is that you are already familiar with basic root cause analysis and know what an Ishikawa (or fishbone) diagram is. If my assumption is wrong you can find some good basics at Wikipedia before continuing.

I find that using brainstorming techniques such as working with Ishikawa diagrams in order to find starting points for causes, have a hard time bringing out unspoken assumptions and prerequisites. Usually the brainstorming is done first and then the results are mapped to the categories in the fishbone diagram or the brainstorming is done with respect to each category, but if we instead start by asking questions that combine the different categories in our Ishikawa diagram, we can find several of the failed assumptions. This can be done as a complement to what is normally done and should not be seen as an either or.

Let’s say we’re working with the 4, 6 or 8 M’s (Machine, Method, Material, Man Power, Measurement, Management etc). Try to combine the categories in questions that are relevant to your situation, e.g.:

  • What training will our Man Power need in order to understand our Method?
  • What limitations do we have on our Material considering the Machines we’re using?
  • What support will Management need in order to make good Measurements?
  • When will we need our Material if we’re going to follow the new Method?
  • What is required from Management for our Man Power to get the Machines or tools they need?

Doing this we might come up with a list of prerequisites or assumptions that were never made explicit at the outset:

  • If we assumed that everyone on the project was familiar with some basic technology, compare this assumption to reality.
  • If we assumed that our target audience belonged to a certain demographic group, compare this to our true audience.
  • If we assumed that people in adjoining departments would communicate with each other, check if this actually happened.
  • If we assumed that our instructions would be read by everyone, check if everyone actually read the instructions.
  • If we assumed that everyone knew where to find the background documents, see if everyone actually knows how to find them.
  • If we assumed that a new hire would be brought up to speed by the team within two months, check if that was the case.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there.

As I mentioned in my previous post; validating assumptions is something that should be done all the time and preferably at the beginning of a new project or endeavor of some kind. Using the technique described above does not have to be limited to root cause analysis when the problem is already a fact. Perform this exercise or whatever works for you at the outset  of any new project, change program or other activity where you’ll be working according to a new process.

Problemthe perceived difference between the current state and a desired state.

At times when we find ourselves in the need of performing a root cause analysis (RCA) we have usually ended up at a current state that differs significantly from our desired state. When we embarked on the endeavor of trying to reach our desired state, we probably had a plan or process that we expected would help us get there. Now, most of us design our processes very carefully but we also often implement them on top of a number of loosely made assumptions that are more error prone than anything else in our process.

Depending on our selection of method for RCA we might or might not have the tools for looking at our new process in order to find flaws in it. My suggestion is that you select a method that will help you analyze your process, but that is not what this post is supposed to be about. What I find most methods for root cause analysis seem to lack, is a way to look at the assumptions that we base our process on.

Every problem solving approach that I’ve come across so far has followed a similar pattern of:

  1. Identify problem
  2. Find cause
  3. Find and implement solution
  4. Check result

There are methods for problem solving and RCA that are a lot more refined and give the user good help on how to move between the different steps but the “find cause”-step is often left to more ad hoc techniques such as brainstorming. I think most methods miss out on one good starting point when looking for the causes; our assumptions.

The old saying that assumption is the mother of all f…ups holds true quite often. Validating assumptions should always be done, but if you missed doing this validation earlier, at least do it during the root cause analysis. You will stand a good chance of finding some problem causes in this group.

I want to suggest an approach where our assumptions are made explicit and are compared to history and facts as a first step to identify possible causes. After a problem statement has been properly identified and expressed, try to list any key assumptions or prerequisites that would have been necessary to hold true in order for your process to be valid and for you to reach your desired state. These assumptions might have looked more or less obvious at the outset and thus taken for granted, but that is not the same as them being true. Compare these assumptions to history for fulfillment to see if we actually had everything in place in order for our process to work.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there. Remember that these are probably only immediate causes and not our system causes.

In part 2, we’ll look at one way of bringing these assumptions out into the light.

%d bloggers like this: