The N Dysfunctions of a Team

A friend of mine passed along “5 Dysfunctions of a Team”, which I haven’t yet opened. In fact, before I opened it, I treated it much like a book that I was considering buying. I went to Amazon.com and I read the reviews to see if it was even worth me opening the book in the first place.

At a glance from the reviews, the book seemed very much like the school of management which believes teamwork will solve everything. It’s the same school of management which believes that hanging ‘Successories’ (you know exactly what I’m talking about if you’ve ever seen one) on office walls. So, I’m pretty skeptical about the book.

But it did get me to thinking. We (that’s the Royal we) believe that having great processes and not so great people is the secret to success. We have accepted that people are fallible and therefore that there must be an alternative solution which addresses the issue. We believe that solution is process.

But as I sat there and thought about it, I realized that making better processes to compensate for not-so-great people is avoiding the root cause of the issue. If you could just get really good people, who really cared about what they were doing, then they’d be great all on their own. They wouldn’t need great processes. Processes, in some respect, are an avoidance of the true root cause – people who don’t do the right thing.

And so I wonder, is learning to select, educate/train/mentor/whatever, and retain the right people the only secret there really is. If you could do that, why would you bother doing anything with process? Sure, if you can’t do the above, then maybe process is the second best solution.

Or is this a case of testing with software? Sure, we all know that it isn’t value added, but we know of no way to avoid it. Maybe that’s the case with process; that we do it because we know of no other way to successfully get the right people in the right jobs doing the right thing all the time. We can’t solve the first problem, so we solve the second one. It’s easier, presumably, to find one bright process designer than it is to find a large (or even a small) team of really good people.

It doesn’t change the fact that, in theory anyway, that good process is in itself a treatment of the symptom and not the root cause.

Please refrain from poking the jellyfish

I feel like I’ve written this entry before, but I can’t find it when I look through my posts.  I guess that says two things – one, I don’t tag my posts adequately enough and two, I’ve written enough posts that it’s now hard to remember what I have and haven’t written about. 

About a month ago my boss asked me if I could do a review of all the root cause analysis we had done to date to determine if it was adequate.  It’s sort of an odd question in that I wasn’t sure if he wanted to know if we’d done ‘root cause analysis’, which to me means the measure and analyze phases of DMAIC or if he wanted to know if we’d done enough to address the root cause of issues.  The first is “did we do our homework” and the second is “if we did our homework, did we actually do anything with the information.”

My first, and I admit failed, attempt at this problem was to look at what work was going on in the entire development space.  I asked around, pulled from what I knew and essentially built up a map of our development process and overlaid it with all the initiatives to identify and fix the reasons that part of the process map was having problems.  For requirements, for example, I found a project which redesigned that phase.  There were similar projects for design, coding and testing.  I found evidence of ongoing management of bugs.  We have a process in place to locate where the most bugs are coming from.

In short, I concluded that we were indeed doing enough, but it was hard to tell if what we were doing was going to be effective or not.  After all, most of these initiatives didn’t follow any sort of structured thought process.  They simply popped forth from someone’s head like Athena from Zeus (I think I recall that myth correctly).  And most of them were currently in-flight.

My boss didn’t really like that, since my conclusion was basically “do nothing, we’re doing enough.”  So after some more discussion, he asked if we shouldn’t have some review of a sample of defects every month to see what the root cause is of each of those.  To which I said, “no, we shouldn’t, because your fire-fighting rather than solving why you get bugs in the first place.  If you get the process under control and at a level you can live with, then there’s no need to understand the root cause of every defect anymore.”

Essentially, my point was if you’ve fixed the process, and you have tons of initiatives to try and fix it, then why are you still looking for problems?  Again, that didn’t go over well, so I backed off and said I’d do some additional research.  Hey, I know how to play the game, even if I am stubborn sometimes.  I can’t just fold like a house of cards; I do want to go home with my integrity intact.

I pulled defects for the last two years and sliced them every which way to look for special cause variation in the number of defects over time.  Hooray C charts!  I also looked at defects per unit of work (very coarsely) by using defects per person month of effort.  All in all, I concluded that I could find no evidence that anything in the process had changed for the better or worse.  The story was a mixed bag.  Good news was we weren’t getting worse and the bad news is we weren’t getting any better either.  But, there’s something to be said for stability.  At least you know where you stand.

Anyway.  As I was driving home tonight a thought popped into my head about all this.  You can’t take an iterative approach, at least not like my boss was proposing, to fixing the process.  Now don’t get me wrong.  You absolutely, positively CAN make some fixes to the process, measure the process again, look for new data and continually improve it.  However, if you have, say, 40 things in flight to change the process and none have been given time to work, I don’t think it’s appropriate to be doing a root cause analysis of a sample of bugs coming in and making more changes.  And, as an alternative, if you’re not going to act on all this root cause work, what’s the point?  I can measure improvement simply with a control chart of defects per unit of work per month.  If we get special cause variation for the better there, then gosh darn it all, our changes are working.  I don’t need all that extra detail to tell me that.

If in-flight fix A hasn’t completed and would solve the problem you just reviewed, then you simply wait for A to go into effect and you’re done.  If instead, you simply make another change to react to what you are seeing now, then you’ll never know if A made the difference or if the thing you just did made the difference.  And while it’s great that the problem got fixed, your only focus cannot be on quality.

I can get you quality.  It’ll cost you limitless amounts of money, but you can have it.  We’ll do all kinds of quality activities, many of which that don’t pay dividends.  But it doesn’t make sense!

If you have measured the process and you know it is stable then you can feel confident that a good random sample of the problems you are seeing today WILL be representative of the problems you will see in the future.  THIS IS THE BIG SECRET OF GOOD SAMPLING!  You CAN learn about what will happen in the future by studying the past if the process is stable.  And if you bothered to get a good random sample, then when you make fixes to the process based on your analysis, you will be preventing the problems that actually are likely to occur again.  On the other hand, if you just react to the bugs you have today, and today’s the day that some idiot new developer introduced a whole bunch of NULL pointer exceptions, you’re going to pay for a process change that isn’t likely to happen again.

Combine that with an in-flux process and as Steve McConnell said in Code Complete “As popular as this practice is, it isn’t effective.  Making changes to code randomly is like poking a jellyfish with a stick to see if it moves.  You’re not learning anything; you’re just goofing around.”  The same applies to process work.  STOP POKING THE JELLYFISH!

Finding the right unit of work

Size matters.  No I’m not making an off-color joke, but I did get your attention.  One thing that seems to get lost on people is the idea of opportunity for a defect.  For example, my computer crashed today.  My wife’s computer did not.  Is my computer unreliable?  Not necessarily.  Yes, my computer did crash once, but due to my job, I also use my computer almost 12 hours a day (let’s ignore the fact that I probably work too much).  My wife, by comparison, just checks her email for a few minutes, let’s say 30 minutes at most.

In any given day, I use my computer 720 minutes, my wife uses hers 30 minutes.  Because I use my computer more than she does there is a lot more chance that my computer will crash.  If your computer is off, you can’t crash it.

When we talk about improving processes, we discuss the problems in terms of defects per million opportunities (DPMO).  DPMO is useful because it allows you to compare disparate volumes.  If I make a million widgets and have 2 defects and you make 100 widgets have have 2 defects, who’s worse?  We both had 2 defects.  By having common denominator, you can tell.  One could assume that if you had made a million instead of a hundred widgets that you’d have about 20,000 defects.  Now we’re talking apples to apples.  My 2 defects per million or your 20,000 defects per million.

In most types of process work, the unit of opportunity is obvious.  It might be defects per order filled, or defects per transaction processed.  Software, well, that isn’t so pretty.  What exactly is an opportunity to create a defect when it comes to code?

In fact, I had an experience over the past few days that brought up this exact issue.  I was asked “are we getting better at delivering this software?”  In other words, are we getting fewer defects in production?

First off, in terms of pure defect counts we seemed to be getting worse.  There were simply more defects over the past few months than we had ever had before.  Oh, the sky was falling, I tell you!  More defects!?!?  The world was ending!  Ah, not so fast, I argued.  What if there were more opportunities to have a defect recently?   Maybe things were getting better, or at least not getting worse.

Of course, if you’re the person who is on the receiving end of being told that your software development process is a problem, you’re pretty ready to listen to someone who tells you that it might not be as bad as it seems.  So, they said, let’s look at defects per transaction.  We ended up with a control chart that looked something like this:

To me, looking at this chart, there are two populations.  There’s a population hovering around the lower control limit (LCL) and then a second population around the upper control limit (UCL).  Between observation 8 and 9, something appears to have changed, even though nothing is different about the process we thought.  What it seems to me is that defects per transaction caused the data to be segregated into two populations.  Since the process was believed to be stable, this seemed odd.

I decided perhaps a different denominator would be appropriate.  Maybe a transaction wasn’t the right measure of an opportunity for a defect.  This seems to make sense, since software is one of the most repeatable processes we have.  It’s digital, after all.  Given the same inputs, absent any funny memory leaks, the same input to code should generate the exact same output.  Therefore running more transactions is unlikely to yield more code defects.

Instead, I proposed we look at defects per hour of coding effort.  Yes, like lines of code, function points and any other measure you can think of, there are problems with “hour of coding effort” as a measure of opportunity.  Fear not, I’m just using it to illustrate a point.  When I created the control chart using that denominator, I got this:

Ah ha!  A process that appears to be in statistical control if I look at defects per hour of effort.  Now, for my unhappy manager who was being yelled at about the code quality, this wasn’t the best story in the world.  I saw no evidence of “good” special cause variation.  They didn’t appear to be getting better at delivering software, but they didn’t appear to be getting worse either.  Crisis averted!

Here’s my proposal.  If you don’t know what the correct unit of work is for the denominator, simply throw out a few ideas.  Then, create control charts using each as the denominator.  If using that denominator doesn’t bring what is supposed to be a stable process under control, it’s probably the wrong choice.  In my example above, we discarded defects per transaction because it seemed to create two populations we didn’t expect.  And instead, we went with defects per hour of coding because it did stabilize the process.  Now, I’m not suggesting you should allow your own bias to find some complicated way of showing there is or isn’t variation, make your denominator something simple to count.  And it’s likely that more than one denominator would probably work.  In my case, not only would hours of effort worked, but number of lines of code changed, function points created or even requirements filled would probably have had the same effect.  The point is to find a good, not necessarily perfect, denominator to normalize for the amount of work being done.

Now, when we go to change the process, you’ll have some way of knowing whether we’re getting better or not, even if we do more or less work.

Agile, day, uh… well…

Not that long ago I wrote “Agile, Day 1” which was my personal introduction to what being on an Agile software team might be like.  I wasn’t impressed, and I get this funny impression that nobody else, including the boss was either. 

Why do I say that?  Well, other than a brief hour long exercise a couple days later to try and finally get our stories prioritized, nothing has happened on the topic since then.  I, of course, hesitate to bring it up since I really was not a fan of it in the first place.

I’d like to say I wonder what happened, but I have some inkling.  See, not long after Day 1, Bob went to an offsite to hear all about Agile at big companies.  The presenters, Bob tells me in a later phone conversation, explain that as a professional services company they have discovered that Agile doesn’t actually work all that well.  In fact, they themselves have given up on it and use a hybrid approach, something that’s neither really Agile nor strict waterfall.  Having not seen it, but liking to claim victory for my position all along, I’d call it LEAN software development.

In fact, this company went on to say that they’ve had clients who like more documentation or more rigid process.  As the vendor, this company provided services that met their client’s view of how projects should be run.  So, I’m wondering, if they could do pretty much whatever process the client liked and still found the project to be profitable, I’m guessing their original adherence to Agile wasn’t the key difference in their company’s success.

Anyway, I think this all disheartened Bob, who was so convinced that Agile would be the future (by the way, Barry Boehm has long since presented that the Agile fad is over and companies should move to a hybrid approach) that he just couldn’t bear returning to the team and having to share this news with us.  Ok, an unlikely story. 

The sadder, and probably closer to true, story is that Bob probably doesn’t actually care all that much about the process.  OK, listen to what I’m saying… Bob, my boss, the boss of a group of process people, the person who is responsible for an entire organization’s process work, doesn’t have the time to figure out his own team’s process for getting work done!  Hello?  To quote the movie Zoolander, “I feel like I’m taking crazy pills!”

I hate to say it, but Six Sigma or any other process discipline you may like cannot be above the law so to speak.  We are not special!  We are not different than any other disciplined, scientific approach to dealing with a problem.  And yet, if your boss can’t be bothered to enforce a process just mere days ago he believed (for right or wrong, let’s just assume Bob had good reason to believe Agile was worthwhile) would have a significant impact on our productivity, I think that might pretty much sum up the problem.  Of all people who should be striving and obsessed with continuous, measurable improvement, we should be.

Standards for the sake of standards

I’ve been forced to rewrite a large section of this post, since my original optimism about the value of controlling process variation has been dashed to the rocks by a healthy dose of reality.  I have no idea what I was thinking when I first wrote this.

Just the other day I was in a meeting with a bunch of business folks and some people from our team.  Some time back we set out to standardize the requirements gathering process.  Over the course of a few weeks we researched the industry standards and built a model for requirements gathering centered around some very basic ideas like JAR sessions and clear, concise requirements.  Certainly there was nothing that was brain surgery about it.

As we neared the end of our pilots, which people seemed very happy with, we realized we needed to plan for ongoing support for the process.  One of the key features, right or wrong, was that every project would have a trained facilitator for the JAR sessions.  For the sheer volume of projects we do every year, we’re talking about a significant resource expense to have these people on every project.

When we went back to the sponsors and said “hey, we need X millions of dollars to pay for resources over the next 5 years” to support our standard process, it didn’t go over that well.  Their response was, logically, “and what’s the benefit of paying for these people?”

Ah, how much I love it when the rules of the game change.  We’d now gone from standardize to improve.  At least in as much as the improvement had to pay for the resources we were asking for.  What to do, what to do?

I think panic set in at this point.  Standardized was OK with our sponsor as long as it was free.  Since we were asking for resources to support the standard, it suddenly wasn’t appealing to just have a standard.  And now we were being asked to prove that it was worth making the investment.  We’d never planned on it being worth anything, but just that it’d become the basis for future improvements.

The problem is, controlling variation doesn’t add a lot of value when the cost of one project can be offset by the value of another.  In the old process, we used to spend an average of 11.28% of our project money on requirements.  It had a standard deviation of about 7.3%.  In the new process, we’d spend an average of 11.3% of our project money on requirements and it has a 1.7% standard deviation.

Of course, having told you all this, the standard deviation is not meaningful in this case.  Recall from a prior post that the average describes what you’ll encounter over the long run.  When it comes to money, something funny happens.  If you overspend on one project and then underspend on another, it can all come out in the wash.  It’s different from say, building widgets, where if you build it too large or too small that it’s defective.  Money is a different animal and it’s likely that your CTQs will be around average cost, not variation in the process.

Think about it, let’s say you’re offering some service to your customers.  On average it’s costing you $100 to deliver the service.  If it sometimes costs you $10 and other times costs you $190, that’s fine.  As long as it averages out to a profitable number, you’re good.  You can charge every customer something over $100 and even though you’ll lose some money some of the time, you’ll still be turning a profit in the long run.  And if you can’t make money at an average cost of $100, then controlling the variation of the process isn’t going to make the situation better.  You HAVE to move the average.

Anyway, back to the problem.  Since the new process had a slightly (0.02%) higher (read: worse) average cost, in the long run we’d lose money.  Standardizing for the sake of standardizing hurt us.  And even though we settled on what we thought was a good standard, it was not good enough to be worth doing.  We’d actually lose more money by controlling the process than by letting it run wild.

So there you have it, standards for the sake of standards is not a universally good idea.  Sometimes chaos turns out a better result than controlling it.

Operational definition = stupider people

Some how Green Belt training has made our employees dumber.  No, this isn’t an example of Flowers for Algernon (it was a short story I remember from my childhood, go look it up), but something has gone awry.  Maybe ‘dumber’ isn’t a fair term, but the basic assessment is this: individuals who have not taken GB training are exposed to it and suddenly they forget what words mean.

In my specific example today, someone asked me what the operational definition of “unambiguous” is.  Occasionally, someone springs a twenty-five cent word on me, but unambiguous isn’t even a five cent word.  It has common use in our language.

So let’s get back to basics people and help you all out by defining “operational definition” in my own words.  An operational definition is an unambiguous (go look it up, if you’re confused about that word) description of how something will be measured.

For example, how do they measure “on time departure” for an airline?  Take a guess.  The minute the plane leaves the ground?  Nope.  The minute the plane taxis to the runway?  Nope.  The minute the doors close?  Nope.  It is considered “On time departure” when the emergency brake is released on or before the scheduled departure time.  Going to be running late by any rational person’s definition?  No problem, just release the parking brake and set it again.  You’ve departed “on time!” 

Operational definitions differ from dictionary definitions.  “Good” or “Bad” has a place in the dictionary, but neither word has a place in an operational definition because the words have multiple meanings.  Instead, regardless of whether the definition is perfect, an operational definition’s focus is on setting something up to be consistently measured regardless of who does the measuring.

Operational definitions assume you know what the words mean, for example “departure” in “on time departure” means to leave.  The issue isn’t that we don’t agree that departing means to leave, it’s how we measure exactly when someone is considered to have departed.

So, I’m convinced that Green Belt training has made people stupider.  Suddenly they’re not only misusing a concept from training, but they’re using it to ask questions about words they already know the meaning of.

Let’s try it my way

I’m not exactly sure what to file this under other than “just plain frustrating.”  Dr. Deming would have called changing a process without understanding it tampering.  This rant might apply to my green belts, to my sponsors, to almost anyone who doesn’t understand the value of understanding.

How sick am I of hearing about solutions to problems when the cause of the problem is not understood.  “It’s a training issue”, “it’s a resource experience issue”, “let’s standardize that process.”  I’ve reached the end of my rope.

Myth 1:  We have hired particularly intelligent or skilled workers and therefore the fault with the vendors we work with is that they have not.

Reality:  Nonsense.  Every company wants to believe that they’ve hired the top talent.  Define top talent?  The top .03% of the population?  Hellooooo… all companies can’t have employed the top .03%.  There aren’t that many people to go around.  Odds are really good you’ve employed pretty average people; THE STATISTICS ARE AGAINST YOU!  Think the Toyota philosophy: really great processes + mediocre people = good results.

Myth 2:  When in doubt, training will solve everything.

Reality:  Training solves very little.  People quit.  People forget.  People ignore you!  People subvert the process because they can.  Training implies people are well intentioned.  Forget training, just make it easier to do the right thing than the wrong thing – errorproof!

Myth 3:  Standarized process will solve the problem.

Reality:  What standard?  Any standard?  Is a bad standard better than no standard at all?  Could you replace good judgment which produces variable results around an acceptable mean with no judgement that produces a very tight spread around an unacceptable mean.  You bet you can!  At least you’ll fail in a standard way!

And yet, we march forward relying on the same time-tested bad advice.  Why?  In the absence of any data or the thought to get any data, people learned to go on their guts.  Now that they get data, they look at the output and say “oh, that’s no good.” and go back to their gut for the solution to the problem.  Well guess what, if you had made more good decisions than bad decisions, you never would have hired a six sigma person in the first place.  Things would be working out for you instead of where they are today.

Let’s try it my way and think “my gut is wrong, I will believe the data” instead.

I don’t believe the data

What do you do when the data you gather doesn’t meet the expectations of the audience you have to tell?  One of the Green Belts (GBs) that I’m mentoring just gave a presentation on the first go-round of a measure phase.

My poor GB was forced into doing a baseline measurement because, while people felt there was a problem, we had no idea how big or small the problem really was.  I want to give my GB credit for doing her homework the right way.  She got statistically significant sample sizes.  She properly randomly (not just haphazardly) selected samples from the population.  She conducted careful time studies with the resources who actually do the work in question.

And when we presented the data to the sponsor, he concluded that the data was suspect.  Why?  Because he had a different expectation than the data showed!  My GB was collecting data regarding the effort that goes into testing.  While trying to figure out what the financial opportunity might be, we needed to know how much effort went into writing a test case.  How would you time it?  We got a stopwatch and had the test case writer record the start and stop times for each test case written.  We didn’t even tell him what the data was for, so he had no clue whether a higher or lower test case writing time was preferred.  Hopefully that at least eliminated deliberate bias, though I suppose the writer may have assumed one way or the other was better, but I doubt it.

What’d we find?  The 95% confidence interval for median test case writing time was between 201 and 261 seconds.  Note I said median time, so you know that my GB did the right thing and checked to see which statistic (median or mean) was more descriptive for the data collected. 

What’d the sponsor say?  “The data is suspect, test case writing should take at least 10 minutes per case, I’d expect.”  WHAT!?!?!  Where’d he get that number from?  Gathering data isn’t about matching someone’s expectations; data is about confirming reality.  Whether the sponsor liked it or not, the data showed that’s how long it took to write a test case by these resources.

So I found myself saying to my GB after the meeting, “just ignore them and trust the data.”

One might conclude that taking so little time to write a test case is the problem, but it’s not like you can just say to your resource “take longer to write a test case.”  Well, you can, but you can be sure that the resource will still take somewhere between 201-261 seconds to write the median test case and spend the remainder of the time twiddling his/her thumbs.  The time taken to write a test case is dependent upon the effort put into it.  Change the nature of the effort, change the time it takes.  But you can’t change the time directly.  All other things being equal, at a speedy 201-261 seconds per test case, why would you want it to take 10 minutes per case instead?  If you said “that’s too long” I could see a complaint, but “that’s too short”?  Baffling!

Your everyday, “average” disaster

Here’s an interesting real life example of not getting the basics right.  There was a project that I was looking at the data for just the other day.  It was a LEAN project, so the black belt assigned was hoping to reduce the cost of resolving defects (our “Y” in this story).  The BB, let’s call him Bob, did a nice XY Matrix to brainstorm the things he should measure.  Bob even did a nice job collecting the data; he carefully conducted a study to produce a value stream map.

And then Bob promptly screwed up his entire project!  Bob had a few potential X’s for his project.  He made the same mistake with all of them, so I’ll just focus on one of them.  The X in question was the number of rejections per ticket.  Now, I can’t say that Bob did a correlation test between this potential X and Y – which may have been his first mistake.

His second mistake was not running a normality test on the data.  How someone forgets to do something so basic, I’ll never understand!  If you don’t think normality matters all that much, let me tell you how the story played out as a result of this decision.

So, Bob assumes the data is normal and calculates the average rejections per ticket.  The number comes in at around 5 rejections per ticket.  “Five rejections per ticket?, ” he thinks, ” this is clearly a problem and we can fix this.”  Bob implements some improvements to help assure that good information gets into the ticket in the first place.  He re-measures after the improvement is in, and wouldn’t you know it, the average number of rejections drops to 2.5.  “Success!, ” Bob declares, ” now that the average rejection rate is down the cost of resolving defects will be greatly reduced.”  I’m making up Bob’s dialogue because I wasn’t there with him when he made this errant claim and I imagine him saying silly, badly-scripted things with a false sense of confidence.  Kind of like the Bob from those enzyte commercials…

Except that he’s wrong… see, the data wasn’t normal.  The high average number of ticket rejections is due to a handful of tickets each month that are so sloppily entered that they get rejected dozens of times before they are correct.  For most tickets, the number of rejections is between zero and one, but those very few disaster tickets skew the average to be high above the more descriptive statistic – the median!

Bob’s improves did improve something.  The improvement eliminated some of the worst offenders in ticket rejection, but since the vast majority of tickets didn’t have this kind of rejection rate, changing the X failed to have any effect on the Y.  Congratulations on failing, Bob!  Next time pay attention in Black Belt class.

I think after someone claiming to have expertise makes this kind of amateur screwup that we should be allowed to send him or her to remedial statistics.  I can almost understand why someone might not review the residual plots for a linear regression, but not running a normality test?  Foolish, at best.

A disturbing lack of integrity

Of all the skills that a Six Sigma person needs to be successful, I’d say two things stand out.  The first is the ability to analyze data for statistically (and practically) significant patterns.  The other skill is change management.

So, when I observed a person using the first skill to manipulate the data to enable the second skill I saw a person treading a very dangerous line.  A healthy foundation of change management is the trust that you have built with the folks you are trying to influence.  You use data to make your case, build trust in your analysis and show that you are not being manipulative.  And sadly, as I’ve just observed, sometimes (mis)use that trust to hide the data that doesn’t fit your case.

Where I work, Six Sigma is still a fairly new concept.  If an individual in the Six Sigma organization misuses the trust we’ve built up, s/he can do more damage to that trust in a single act of subterfuge than we can hope to rebuild with months or years of honest, forthcoming behavior. Lack of integrity on the part of even one individual in your organization has consequences that reach far beyond the individual.

Here’s what I saw today.  As a team, we were working towards a presentation to a group of senior managers.  Each project manager was going to have to present his/her project, goals and results on a one-page slide and then speak to it for just a few minutes.  This was purely information sharing.

One of the charts showed a stunning rise in First Pass Yield of a given type of transaction.  It looked kind of like this:

What a great story!  First Pass Yield from the 30-40% range to 70%!  Who wouldn’t be excited?  Well, who wouldn’t be excited except that this chart is truncated.  Here’s what the data looked like a few months after May…

In June through September, the numbers were better than they were in January through April, but only marginally so.  I haven’t calculated control limits, I doubt excepting for May that it’d even show special cause variation.  It wasn’t nearly the great success story.  Now, one might chalk this oversight up to optimism.  We could have simply claimed success too soon in May.  But we weren’t preparing this presentation in May of 2007.  We were preparing it today, nearly one year later!  We knew that the gains in May didn’t hold; we had the data in our hands which showed it.  And yet, one of my peers was prepared to show a slide which conveniently cut off the data before it went south.

What’s worse, is that we make all our data, including this disastrous collapse in first pass yield, available online.  It wouldn’t take much for one marginally smart individual to connect the two and say “hey, that isn’t what you showed us in that presentation!”  And, if that realization gets back to the right (or wrong, as it were) person(s) then our entire group’s credibility is damaged.

It may be convenient to lie now because it gets you your Black Belt certification, but these kinds of actions serve only to undermine the longevity of not just your, but all our careers.  Change Management, and the required trust to accomplish it, cannot be sacrificed for short term gains or personal reward.  Once the trust is undone, you can be sure that nothing else you try will ever make a difference because nobody will allow you to implement a change again.

It takes an enormous amount of integrity to do the right thing, but it is better to admit that more has to be done to meet your customer’s CTQ than to sweep it under the rug.  Your lack of integrity will catch up with you.