The value of everything, the cost of nothing

I used to work for a team who had great software quality.  I’m defining software quality as the number of bugs making it into production in this case.  Said quality came at an enormous cost, one which our business partners used to complain non-stop about.  It became a joke – “we don’t show up for less than a year and a million dollars.”

Bothered by the apparent disconnect between what the business wanted and what systems was offering, I proposed that we (I’ll paraphrase) “back off on some of the quality stuff and take the risk that something might go wrong for a significantly cheaper price.”  Sadly, I got laughed out of the room.  I know that I was not wrong.  You don’t need to have been around long to experience an arrogant system’s organization who thinks they know better than the business on what the business wants.

Would you put up with this in the real world?  I think not.  What if you came into a grocery store looking for a can of green beans and I as the cashier said “I’d like to sell you that basic can of green beans, but it wouldn’t be right for me to do so.  What you really want, but didn’t know it, was a machine that will automatically deliver you green beans right to your door before you even ask.  Sure, the can of green beans only costs $1.09, but you’re really going to like my machine for $250,000!” … “what do you mean you don’t want to spend two-hundred fifty thousand dollars?  I’m sorry, then I can’t help you.”  Sounds like hyperbole?  It isn’t in software development.  It’s part of the reason Agile is appealing to businesses – the business gets the last say in EVERYTHING.  I believe in that philosophy (I just don’t think you need to go Agile to live it).  It is the job of all good software development organizations to deliver what the business needs.  If you aren’t doing that get out of the software business.

Accept this reality (with the exception of software development companies):  YOU ARE A COST CENTER, NOT A PROFIT CENTER!  If the company could figure out how to do business without paying for your software services they would!  Most companies are NOT software companies and they need the software to a) do the job they need done and b) cost as little money as possible.  They don’t want to spend money on you; they don’t particularly like you.  They show how much they dislike you by outsourcing or off-shoring you.

This is not a bad thing.  It just is.  That’s the way the world is - maximize profit, minimize cost.  And frankly, you are and always will be a cost.  Now that you understand how I feel about software developers, and I was/am one, you can see why I might suggest that we back off on some of this quality stuff and take the risk of some defects.

I could build you an invincible car probably that would run forever.  You just wouldn’t want to afford it.  To get to that kind of quality would cost more than you’d reasonably pay for a vehicle.  The same is true of software development.  Users can and will accept a certain number of defects in exchange for a reasonable cost.  If you haven’t seen this curve before, it’s not to any particular scale, but it represents the law of diminishing returns when it comes to software quality.

 Essentially, at some point, you pay exponentially more and more to get smaller and smaller increments of quality improvement in software.  For each company, there is somewhere along this curve where the trade-off is no longer worth it.  Sure, if you’re working on the space shuttle or a medical device, very, very few defects are acceptable.  Defects on a project like that kill people.  But what about defects that could be resolved without anyone dying or losing their life savings?  I’d rather not have them, but if it is detectable and reversible I’d probably be OK as long as you eventually fixed it.  And then there are certain things which are quirky or annoying but don’t do any real damage ever.  Frankly, for most purposes, who cares?

And this is exactly where I was coming from when I said we should back off on some quality activities.  Clearly, though our quality was excellent, we were too far up the curve and it was costing too much to get that level of quality.  I know that the development process had gotten to where it was because with each mistake the team added something to the development process to assure that “it never happened again.”  Now, for a given project that “thing” might be irrelevant, but we’d be damned if it snuck in somehow.  We always had some quality activity to assure that a given mistake was never, ever repeated.  In my opinion, these are exactly the things you should back off on.  It was unclear if the mistake could even be made again, so the quality activity wasn’t necessarily adding quality.  Nobody had measured it and nobody knew for sure, but they were deathly afraid to find out that they might miss that same something again.

Do not be afraid to test the limits and find where the right trade off for the customer’s needs are.  There is a certain quality they need, but there also is a cost they aren’t willing to pay.  In terms of a Kano analysis, over optimizing for cost suggests you believe that quality is a primary satisfier of your customers, and it is likely to be a must be.  You have to have a certain amount of quality, but more of it isn’t going to make your customers that much happier.

Caught between a rock and a hard place

Yesterday was just another day in the office and another bombardment with Agile as the silver bullet to all our problems.  Usually I just sit quietly and zone out when someone gets on the “Agile is going to solve all our problems” soapbox.  Unfortunately, after being subjected to a highly contrived team exercise to show how waterfall development was bad and Agile development is good and then being forced to listen as not one, but three, of my otherwise highly respectable peers sang the praises of Agile I could take it no more.

“This is ridiculous!”  I blurted out.  Yes, seriously.  So, in another article I shall talk about what would be considered career suicide, but I could take it no more.  One thing I have insisted upon (probably to my detriment) is that I walk out of work with my integrity intact.

First off, my comments went to something along the lines of “you are treating Agile like it’s some sort of new religion that you’ve all just found” and “I haven’t heard one bit of critical analysis about Agile’s potential weaknesses” and finally “everything you have said that is great about Agile can be accomplished in a waterfall-like methodology.”  In all fairness, pretty much everyone who compares Agile to waterfall insists on looking at the far end of the spectrum.

This is my proposed software development spectrum.  On one end of the spectrum we have what most people compare against when they refer to “waterfall”.  I’d say the company I work for and the US Government falls into this school of thought – documentation for the sake of documentation.  On the other side of the spectrum, which people pretty much universally dismissed, is “cowboy coding” wherein each developer simply does what s/he thinks is right.

So, let’s talk about what’s out there on the far left:

1. An insane amount of documentation, so maintaining the documents rather than the software becomes the job
2. Crazy project schedules that are totally predictable but completely unreasonable due to all the overhead
3. So much rigidity that change results in predictable pain as you are wrung through the change control process

Out on the far right we have:

1. A complete lack of any documentation, so software maintenance is a nightmare
2. Crazy project schedules that are totally unpredictable yet appear at first to be completely reasonable due to a lack of any learning from past experience
3. So little rigidity that change results in suprise pain inflicted by unexpected consequences

At either end, the same problems manifest themselves in a very different way.  I’m sure the list could go on and on. 

So what’s in the middle?  Agile?  Yes.  Waterfall?  Also yes.  How can this be?  What really is in the middle is common sense.  I realize that if common sense were so common you wouldn’t be reading this, but I lack a better name for it.  I’d propose that “good” Agile exists somewhere just to the right of center (a little more towards “people are smart and make good decisions”) and waterfall exists somewhere just to the left of center (a little more towards Ronald Regan and “trust but verify”).

Here is why I believe this is true.  For every Agile “benefit” that I’ve heard I can find you a reasonable waterfall equivalent advantage / disadvantage.  I’ll go through a few (just to make my point) in the format: Agile “advantage” -> Waterfall equivalent.

1. Regular delivery of business value -> phased development.  AKA multi-stream waterfall OR simply put “do smaller projects.”
2. Just in time requirements -> again, phased development.  Only ask for what you need.  This is a problem with requirements elicitation and prioritization, not waterfall.
3. “Right” documentation -> “reasonable” analysis and design documents.  It is imperative you recognize that documentation is not written just to produce documentation.  It only serves the purpose to prove the design correct before coding.
4. Group decision making, pair programming, etc. -> peer review.  Two heads are better than one, I’ll agree.  I’ve already ranted about decision by committee before.  Compromise is not always a good thing.
5. Team defines the development process -> a smart person defines the development process.  Don’t get a moron to define your development process; you end up on the far left of the spectrum.  Plus one process means you can make comparative measures.  Note, you should read my prior rant against broad standardization to understand when it is appropriate and when it isn’t.

Also, we should talk about equivalent costs of Agile vs. waterfall.  This time, in the format: waterfall “cost” -> equivalent or replaced Agile cost.

1. Time spent designing/documenting -> refactoring.  Guess what folks, no client is paying you to rewrite code you screwed up.  It’s not a feature, it’s a fault.

I think Barry Boehm got it right when he laid out rules for determining Agile vs. waterfall.  I’m writing a blog and not a secondary research paper, so I’m going to reference wikipedia because I can’t be bothered to look up the original/credible source.  Fortunately for me, the wikipedia article does, so if someone quoted him improperly, take some time and update wikipedia for all our sakes.

Based on all I’ve learned to-date, I’d say the decision on which way to go comes down to one thing: do you believe that people inherently are smart and motivated or average and lazy?  Everything I know says that people tend towards the second.  Reality check, IQ is known to be normally distributed and only 3.3 percent of people have an IQ of 130-132 (depending on the test) or above.  The odds of you running into a truly smart person aren’t good and even worse if you want a smart and motivated person.  Leaning towards document nuts (don’t go to far mind you) is the cynical view of the world.  It doesn’t mean that great things can’t happen all the way out on the right in cowboy coding land, but the odds are against you.  On the upside, if you are cynical the “worst” thing that ever happens is you are pleasantly surprised.

Maybe someday soon I’ll post the basic waterfall model that I observed work really well because it used an enormous amount of common sense in the process creation and yet I insisted that each phase be finished before moving on to the next phase.  Don’t go claiming that I had stumbled upon Agile development and have simply misidentified it if I ever do post it; you’d be wrong.  My core nature tends towards “document nuts.”  It wasn’t until I got to the company I’m at now that I realized someone could take it too far.

Sometimes showing up is all that matters

So you know how you’ve heard from your boss and peers alike that “showing up for work isn’t the job.”  I think this is a pretty fair assesment of the laziness people put into their work efforts.  That said, I just had an experience at my job that made me think that showing up (or something close to it) is pretty much all that matters.

I’ve been working on a number of projects, all involving major change management efforts.  It’s not that the work is so hard so much as people don’t like change.  I’ve written about that before, so it should come as no surprise.  But that said, I’ve had some of the worst experiences with people just “showing up.”  Whether I like it or not, I’m not in the position where I get to dictate to others what will and won’t be.  It makes me long for the days where my word was the final word.  Alas, I gave that power up in a small development group to hopefully find it again in a much larger arena.  For the time being, I have nothing but influence.

So, on a couple of these projects I’ve had to get agreement about prioritizing a list of items.  In one case it was a set of requirements and in the other case it was a list of KPIs.  Now, on each list was probably about 20 items, and all people had to do was rank order them.  It’s the kind of work you can do in your sleep.  It certainly doesn’t require a lot of time, energy or thought to get done.  And since their answers were going to be merged in with everyone else’s answers and the average rank used to order the items, not having the items in “perfect” order was not going to matter all that much.  As long as other people thought the item was important as well, it would rise to the top and be dealt with first.

I will say that this kind of multi-voting, in my opinion, is worlds better than getting into a room and arguing out relative priority.  Everyone gets a say, all their votes are equal so nobody is railroaded by a more senior team member and it’s quick – find 5 minutes and do it in your own time.  Alas, that’s only in theory.  In practice, if you ask someone (at least where I work) to take 5 minutes out of their day to do something for you, you might as well have asked them to give up their first born child. 

What’s wrong with people!?!?  I considered that maybe they didn’t like the voting system, but nobody objected when I asked.  I considered they were too busy, but again, I openly asked if the timeline was OK and nobody said it was not.  Then again, nobody said anything at all in response to my emailed request.  But that’s the issue, isn’t it?  Everyone knew it was coming.  They sat in the prior status meeting and discussed that I’d be sending it out for review and voting.  There were tons of opportunities to object or discuss the strategy.

As a result, I finally figured out who really should get rewarded by the organization.  More importantly than anything else, is that they “show up” and at least respond to requests in a timely manner.  I don’t care if the response is “here’s your answer” or “I can’t answer that right now, but I’ll have it for you by X date” or “I refuse to answer that question.”  I don’t care if the answer is all that “good”, at least it’s something I can work with and gives me a direction to continue my research.  But for god’s sake, at least answer me!  When did it become acceptable for people to just ignore you in the office?  But, that’s what it’s come down to – showing up is the job and a job far better done than what most people give.  I can’t believe we pay these people most days…

K.I.S.S. Off

I hate KISS (Keep It Simple, Stupid)!  It’s possibly the world’s WORST advice ever given about software design and development.  First of all, I take exception at being called stupid.  I am not a moron, and most of the people I have worked with (whether they are good at their jobs or not aside) are not idiots.  Who the heck gives advice by first verbally abusing the person that you gave the advice to?  Oh, sure, I want to take advice from a person who has resorted to name calling.

Secondly, I take exception with the world “simple.”  Define simple.  Let me help.  Here’s a snippet from dictionary.com:

1.	easy to understand, deal with, use, etc.: a simple matter; simple tools.

2.	not elaborate or artificial; plain: a simple style.

3.	not ornate or luxurious; unadorned: a simple gown.

4.	unaffected; unassuming; modest: a simple manner.

5.	not complicated: a simple design.

6.	not complex or compound; single.

7.	occurring or considered alone; mere; bare: the simple truth; a simple fact.

8.	free of deceit or guile; sincere; unconditional: a frank, simple answer.

9.	common or ordinary: a simple soldier.

10.	not grand or sophisticated; unpretentious: a simple way of life.

11.	humble or lowly: simple folk.

12.	inconsequential or rudimentary.

Which one of these terms works for you to describe your code?  “Common or ordinary,” perhaps?  Or do you prefer “inconsequential or rudimentary?”  Of course, you’d probably pick “easy to understand, deal with, use, etc.”  Ok, here’s a handsaw, go cut me some boards to build a house.  It’s simple after all, so by the K.I.S.S. philosophy this is what you ought to be using to get the job done.  Forget a saw mill – it’s too complicated!

The problem with simple is that it means too many things to too many people.  Simple is subjective.  Simple isn’t simple to define or pick out.  Definition is in the eye of the beholder.

How about a practical example?  I worked on a team at the start of my career that developed software for the Ortho Autovue (check it out here if you’re curious: Ortho Autovue).  It was my first job out of college, and my mentor was the most senior member of the team.  He is a great guy; I haven’t talked to him in years but I loved working with him.  He was the epitome of the grumpy old (I’m sure he won’t take offense) programmer.  He was eccentric.  We worked in a small building, and he loved to play his music loud enough in his office that I could hear it in mine.  Yes, I had a real office with a door I could close and a window I could open!  How I miss those days when I’m sitting in my cost-saving crappy cube.  He loved to curse at the code, a habit that I picked up and took years to train myself out of once I didn’t have the privacy of an office anymore.  And for all his coding ability, the only shortcoming I can think of was that he was a fan of KISS.  He told it to me first, and it’s the one thing that I learned to disagree with him about.

His idea of KISS was code readability.  Could the average idiot pick it up and understand what he was doing?  That was KISS to him.  And so when he had to deal with translating multiple values into a single value, his choice was a giant if..then..else statement or nested if..then..elses.  It might go on for pages and pages.  Why?  Well, to him it followed the KISS philosophy.  My solution to the same problem was an N-dimensional array.  Simply reference the cell you want using the inputs as indices into the array and ta-da!

His code might be:

int TranslateValue(int X1, int X2) {
        if (X1 == 1) {
              if (X2 == 1) {return 1;}
             else if (X2 == 2) {return 3;}
            else if  (X2 == 3) {return 1;}
       } else {
             if (X2 == 1) {return 6;} ...

Easy to read, sure.  Simple?  I think you’d have to agree that it is by some definition.  Good?  Not so much.  How about my solution?

int TranslateValue(int X1, int X2, int LookupTable[][10]) {
    return (LookupTable[X1][X2]));
 }

Better?  I think so.  Simple?  There’s that eye of the beholder thing again.  In my opinion, this is a much better solution.  It’s a data driven approach.  You can’t tell from the code what the any combination of X1, X2 will return, but it’s easy to expand the function to return new values, can work for any array passed in (provided it’s second dimension is 10 elements in this really basic example), and allows for the lookup table to be read from a file or modified on the fly.  It isn’t all hard coded.  This still isn’t exactly what you’d call difficult code.  It works (I didn’t compile it and haven’t coded C in a long time so it might not compile), it’s easy to understand (even if you might have to look in a different place to understand the values in the lookup table), and above all it’s a more elegant solution.  It does everything that the giant if..then..else chain does and then some!

So, what if he was doing more than returning the value based upon examining two other values?  What if he was executing a bunch of code that had side-effects?  Then my solution no longer works, right?  WRONG!  Instead I can make the table a two dimensional array of function pointers.  Sure, function pointers scare the heck out of most people, but they are extremely powerful (compare handsaw vs. saw mill).  In his giant if-then-else he’d either be forced to copy and paste code or write functions to be called.  I still have to write functions, but I maintain the ability to read from a file (say I was using functions by name in a DLL) or change the lookup table on the fly.

Now, I will admit there are non-simple things people do in code.  I think they’re best described as anti-patterns (http://en.wikipedia.org/wiki/Anti-pattern).  Things that you do because you think they’ll be super-cool and end up handcuffing you rather than freeing you like you imagined they would.

But simple… simple is a terrible word that encourages people to write code that needs lots of maintenance every time something changes in order to provide readability or some other perceived benefit instead of doing something elegant, something so “simple” that nobody would believe it’d work. 

Another great example of the right kind of simple is Ethernet.  Prior to Ethernet you had managed networks like token-ring where each computer got a turn on the network.  It required token passing and resulted in a sluggish network whenever the size of the network grew because the token had to be passed around in case any computer wanted to do something.  Ethernet was a kick in the teeth to token-ring.  Instead of coordinating traffic, Ethernet did the most beautifully simple thing possible.  It’s was called Aloha or CSMA/CD (carrier select multiple access/collision detect). Basically:

1. Listen.  If no one is talking on the network at the immediate moment, go!  If they are, wait a short random amount of time and then listen again.
2. Send your data and listen at the same time.
3. If what you hear doesn’t sound like what you sent, your data collided with someone else’s.  Wait a short random amount of time and start over.

It’s fantastic!  It’s brilliant!  It’s unbelievably super-simple.  No coordination, no need to manage the network.  Pure “chaos” with just 3 simple steps works really well!

So the next time someone else tells you to K.I.S.S., I think you should tell them to K.I.S.S-off.  Do the right thing and build the beautiful, elegant solution that’s so simple nobody can believe it works and is adaptable to change.  Don’t succumb to mediocrity.

Work is a monopoly

I didn’t study economics in college, but years later I found myself curious about the concepts.  It was probably for the same reason that I’m geeky enough to ponder all these process and human behavior issues in a blog.

Anyway, I picked up a really basic economics primer just to get the main concepts down.  I seriously doubt that’d I’d ever read anything more substantial on the topic, but it was enough to make me dangerous.  I was particularly interested by the concepts of monopolistic oligopolies and perfectly competitive situations.  But, of course, that led me to thinking about monopolies and that’s when I realized that I worked for one.

No, the company I work for does not have a monopoly on the industry it is in.  Far from it.  However, the office I’m in does.  Each department in the company is the sole provider of some service to the corporate economy.  There are examples where competitive situations have arose internally, but largely there is one provider for anything.

For example, while one department has a reporting team whose job it is to create various reports for the clients, they’re overwhelmed and take a really long time to produce a report.  So, another team was built (probably secretly at first) to do all the reports that the designated team couldn’t do.  It has created quite a few problems, since people who assumed their role in the company was safe and sound have discovered that they have competition for the work they do.  One would assume that either the original department will get smart and figure out how to compete or die off. 

It was then that I realized we had not approached some change management situations properly.  In a competitive economy,  if you don’t like the service you are getting from, say, the phone company, you switch companies.  The fact that you have choices forces companies to drive up efficiency and drive down costs.  They have to offer you more for less than their competitor.  But the office, for the most part, is not a competitive economy, it’s a collection of monopolies.  Each department is the only department that can service your particular need.

In a competitive environment, I can berate my supplier about poor services or products because the threat exists that I’ll take my business elsewhere.  Try that in the office and you will likely get worse service, not better.  If the department is the only game in town it takes away all incentive for them to improve because they are secure in their role.  Regardless of how much or how little you like or use the group, they all get paid.

My ideal model for process improvement is to be in charge of the organization I want to change.  Barring that, my second choice would be for the head of the organization that needs to change to be the one who initiates change.  And finally, the most common situation I get is like having an intervention with your alcoholic uncle.  Somebody else wants the dysfunctional department to change and you’ve been tasked to make it happen.  It’s just going to be an unpleasant conversation for all involved.

If you’ve read my “Me! Me! Me!” entry, then Bob will sound like a familiar fellow when dealing with almost every one of these situations.  They department head will say “sure, set up a meeting, let’s talk” and then after you’ve done all the research and so forth you get “Fred, we like the process we have, it works for us and we don’t want to change.”  Why does it make me think of Scooby-Doo?  “And if it wasn’t for you meddling kids I would have gotten away with it too!”  Except the villain does get away with it, and the meddling kids get a swift kick in the backside.

I hate interventions, but it is clear that we cannot approach them like we have in the past.  There’s little value in providing overwhelming voice of the customer to them, they don’t care.  At one point I was thinking I’d provide practical advice to appeal to their egos and this would be the same story that I wrote before.  Then I thought to myself, “this is a blog and I can dream up any crazy solution I want because I don’t have to pitch it to my boss!”

Here’s my idea.  Rather than trying to convince the organization that they need to change, you tell them they should change.  Of course, they will do nothing, but you’ve warned them.  Next, have someone (not you directly) begin visibly working on a plan to create organizational competition for them.  Think outsourcing or just hiring a new team to do the same job.  The organization may or may not have to hire anyone, but I think you have to be prepared to play a serious game of chicken if they call the bluff.  Even if you can’t necessarily create competition, you can create the threat of competition.  All of the sudden you have a powerful motivator for change.  Then, once the threat of change is well established, show back up and see if there’s anything “you can do to help out the department.”  I’d bet they’d be a lot more willing to talk.  If not, you keep ratcheting up the competition pressure.  In the worst possible case, the ineffective team will be replaced by a more effective team (since your cohort hired them) and the problem will be solved.

The constant threat of competition should be enough to keep people moving.  This definitely ties in with my “People are selfish” philosophy.  You’ve discovered that getting a paycheck has enormous utility to most people and that’s why they show up for work in the first place.  If doing the same thing will no longer result in continuing to get a paycheck, they will change.

The Prisoner’s Dilemma

First off, I’ll explain my title and then why I chose the title.  The Prisoner’s Dilemma is a part of game theory.  Here’s the idea:  you and a friend go commit a crime.  The police catch you both and arrest you, but they only have circumstantial evidence.  Without a witness, they need one of you to sing like a canary to put the other away.

So, the police separate the two of you and give each of you the same offer.  “Turn your friend in and he gets 10 years in prison and you go free.  If, however, he tells on you as well, you’ll split the ten year sentence and do five years each.”

“What if we both stay silent?” you ask.

“Well, then we’ve got little on you and you’ll both serve just 6 months.”

The answer seems easy, right?  It’s best, collectively, for both of you to stay silent.  You’ll serve 6 months each.  However, what will your friend do?  If he tells on you he may win his freedom if you stay silent and the same in the inverse.  You have to betray your friend and tell on him.  If you don’t, you risk a ten year punishment while your “friend” gets to go free.  And believe me, let’s see how good of a friend you have if it’s the difference between freedom and ten years in jail.

Sadly, the choice of both of you is lose-lose.  The “best” choice is to not tattle on each other, but it carries the risk of a very heavy punishment if your friend doesn’t to the same.  And that brings me to my topic…

How we get the wrong behavior from every employee at work.  We’ve set up a “prisoner’s dilemma” to do the right thing in many cases.  My personal favorite is time keeping reports.  As a system’s organization we need two things: deliver projects on time and on budget AND to have accurate timekeeping in order to optimize our business. 

As an employee, what do you do?  On one side, you are told “report your time accurately” and on the other “don’t go over budget.”  I know what I’d do – lie!  There is so much disincentive to report my time accurately that we hamstring the organization’s ability to do better.  I have on my own job responsibilities the requirement “to report time accurately” and also “to keep projects on budget.”  Now, I don’t measure my project budget for reporting purposes.  Someone else does that reporting for senior management. 

I do, however, input my timecard.  Other than putting a tracking bracelet around my leg, the company is hard pressed to know when I’m working and when I’m not.  Even if I’m in the office for ten hours, I could be spending eight goofing off and two working.  There’s simply no way to validate that my timecard is correct, so as long as it’s submitted they have to more or less take it as truth.  Sure, if I did something totally dumb on my timecard maybe someone would notice, but if I stay within reasonable parameters nobody will ever know. 

So, I can satisfy both my goals without doing much of anything.  The optimal path for me is to lie on my timecard because it solves both problems without creating issues for me.  Long term, it shafts the company because they are trying to make staffing decisions based upon my reported effort.

In fact, the behavior is even encouraged by managers to their directs.  I had pulled a bunch of budgeted hours and actuals for about 200 projects at my company.  By definition a project is considered out of control where I work if the actuals vary from the budgeted effort by +/- 10%.  200 projects is a lot of data.  If I were estimating projects, one would think that variance from actuals would be normally distributed.  Most of the time I’d be pretty close, but some of the time I’d guess wrong.  The funny thing is, the data didn’t look like that at all.  The data is, in fact, non-normal.  There is a precipitous drop-off for projects that are 110% or more over budget.  Although there are a few projects out past that point, it is few and far between.  Usually when they are out there, they are ridiculously over budget.  It’s so suspicious that one can only conclude some tinkering with the data is going on.

I’ve found other examples in our software release process.  The release team asks for lots of data about the work you are installing, but if you give accurate answers it encourages them to ask questions which creates more work for you.  It’s best to lay low and pretend you aren’t installing anything major even though the company would be better able to plan if you gave accurate answers.

So, here’s the new dilemma – do I rat myself out for the betterment of the company long term?  Alas, the answer is no, I am not paid or given a bonus based on how much I support the future capability of the company to improve.  I’m paid to do today’s work and so is everyone up the chain.

With that in mind, as a process owner, you can’t put the fox in the hen-house and manage your process effectively.  You must arrive at a means to measure your processes without allowing the influence of people.  People are very strongly rewarded by manipulating the data. 

By that rule, it is better to measure the date of a deliverable which you can independently verify than the effort to get there which you cannot.  It is better to derive the scope of changes to a release by examining the files changed rather than asking the developer.  It is better to count defects reporting in the bug tracking system than to ask the teams to summarize it for you.  So, while it is true that a good process could be done in the absence of technology, it is the technology which is going to enable you to measure the process unless you have a means to independently verify the employees’ behavior – a corporate NARC if you will.