Workaholics need not apply

September 30, 2008

In my prior post, I related a story about how both my wife and the service company failed to be conscientious enough and thus repeated their same mistakes.  In an exchange with a reader (thanks Ben, for inspiring this post), I made the comment “As for people who have higher priorities than being great at what they’re paid to do… I hope they don’t work for me.”  To which Ben responded “As for your last point, I can only say that I routinely choose to work with people who don’t make work their top priority because many of them still outperform the more obsessive folks of average ability.”

Who are these people?!?!?  People who make work their top priority but don’t get results?  Ah, the workaholics.  Workaholic has a bad connotation, mostly from the perspective that these people give up their personal lives (friends, families, vacations) due to an addiction to working.  Nobody ever says much about the quality of their work.  It’s entirely a commentary on their quantity of work.

And Ben has an excellent point.  Putting in lots of hours (making work your top priority) does not necessarily deliver results.  In fact, the comment brings me back to a prior job where I was managing a small team of developers.  Most of the developers were not notable, except for two – Sue and Alice.  Sue was my top performer, and Alice was a good performer, but not my top performer.  Alice wasn’t my bottom performer either, by most standards.  Alice was however, a workaholic.

Sue was a forty hour a week employee (if that).  I’m not complaining, in fact Sue probably could have worked a great deal less and still gotten everything done that I had asked of her.  Alice couldn’t.  For Alice to get done what needed to be done, Alice had to work all kinds of hours.  Alice typically put in sixty or more hours a week.  Alice was in on the weekend.  By all rights, Alice should’ve been a superstar and yet she wasn’t.  She was entirely average in her work output and quality.

It’s hard to say that Alice had a productivity problem, since she delivered her work on time.  It’s just that in order to do so, Alice had to work crazy hours to get there.  Alice made false starts, Alice took a long time to debug her code.  Sue, on the other hand, breezed through her work and did it with higher quality and less effort.  In the day to day grind, I could assign something to Sue or I could assign it to Alice.  To get the same result, Sue would work an hour, Alice would work a week. 

And yet, when it came time for reviews, my short sighted manager only saw that Alice was always in the office.  Sue was, of course, at home with her family, enjoying her life.  But if I had to pick, hands down I’d pick Sue for a job over Alice any day.  Sure, Alice was dedicated to work – REALLY, REALLY dedicated.  Sue, not so much.  She’d rather be somewhere else. 

In the end, if there was an emergency, I could call Alice, because I know where she’d be (in the office).  Alice would work on it all weekend and figure it out.  Or I could call Sue, at home, and she’d be a little annoyed, but she’d log in from home and be done with it in five minutes.  I’m sure workaholics have their place somewhere – probably places where more effort gets you more results (like factories).  For thinking work, being there all the time isn’t enough.  Being there is important, if Sue had never showed up that’d be a problem too, but it doesn’t trump everything else.


The problem with not being obsessive about mistakes

September 25, 2008

I didn’t think my family would ever become a case study for how not to be process oriented.  But everyday life provides examples that translate well into stories about how not to run a process.  This morning I was feeling like I was on candid camera.  Honestly, nothing could go wrong at the same time as it has for me in the last three days.

On Tuesday it was finally cold enough for us to want to turn our heat on.  As you may or may not have read in a prior post we own a very old home, so a good week of chilly weather will make our house less than comfortable – 64 degrees inside, in this case.  Alas, there was no heat!!!  I called the company who had installed a new Tekmar Thermal Temperature Reset on my furnace.  On a side note, this is a cool device.  Basically, a forced hot water furnace is dumb to the temperature outside, so in the middle of the summer it will heat itself in preparation for the off chance that you’ll need heat.  The temperature reset will force the furnace to stay off if the temperature is above 64 degrees outside and circulate cooler than maximum temperature water unless it gets cold enough outside.  The idea is that the furnace doesn’t work as hard and you save money.  I’ll probably have a report out on the data sometime in the future, but I digress.

The company who attempted to do the repair (and who shall remain nameless) came on Tuesday to look at the problem.  The technician tells me “I think the Tekmar controller is broken, but I’m not sure.  We don’t keep the part on the truck though, so we’ll have to come back tomorrow to replace it.”  I’m thinking “OK, but you knew what work you just did to install it, so wouldn’t you come prepared?”  Anyway, a different technician came back Wednesday.  After a couple hours fiddling around in the basement he comes up and tells me he’s confirmed the problem is the controller, but he too doesn’t have the part on the truck.  This is just getting silly!

I call the company to complain about the service quality.  They tell me that they’ll have someone out there Thursday afternoon.  I reject their offer, since I won’t be home Thursday afternoon and tell them this is getting ridiculous and that they need to be there Thursday morning.  They tell me that they’re fully booked on Thursday morning, to which I reply (essentially) “that’s not my problem, you’ve been here two days already and not solved it, and I’ve been more than accommodating to hang around the house while you fail to fix the problem with the work you did.”  The very nice office worker (yes, she truly was understanding and nice) says she’ll call me back.  When she calls me back, she tells me someone will be there at 10:30am.  I remind her to send the parts they’ll need for the repair.  I was half joking, half serious.

Thursday morning comes and I’m sitting in my office when the furnace guy shows up.  It’s a new technician, who introduces himself as Joe.  He tells me he’s the company’s ‘troubleshooter.’  I ponder who they sent before for a moment.  If it wasn’t the guy who could troubleshoot the problem, who exactly was it that they were sending?  Joe is down there for approximately 10 minutes when he comes up from the basement and tells me that it’s a simple wiring problem.  He doesn’t fix the problems though, so the technician from day two shows back up to actually redo the wiring they did incorrectly in the first place.

While the wiring is being redone, I get a frantic call from my wife.  She’s locked herself out of the house she nanny’s at.  Fortunately, the kids were outside with her.  This would be an honest mistake had she not done it before.  She says she’s tried to call the mother, but can’t reach her and was wondering if I could look up the phone number of the father.  Fortunately, the father runs his own business so his number is well advertised and reaching him is easy.

This, yes I know you were waiting for it, is where my two stories collide.  The furnace company and my wife had both made the mistake they made before.  The company shows up unprepared to deal with the issue they have; my wife locks herself out even though she knows that it’s a possibility it could happen.

Most people don’t obsess about their mistakes.  This is unlike me who will unmercifully flog myself over anything stupid I do.  Sure, I come off as a having a bit of an obsessive-compulsive disorder, but one thing is for sure about me, I NEVER make a mistake twice.  I’m obsessed with my own measurement of “personal quality” – not making mistakes I think are dumb.  That includes being obsessed about using Quicken to track my finances (on the more normal side of the spectrum) and having to check my alarm clock setting at least 3 times before going to sleep (on the more crazy side).

And that may be what makes me a good process person.  I’m obsessed with quality - my quality, everyone’s quality.  Obsessed I tell you, and I mean it.  When I do an analysis of a process I’ll hack away at it trying to prove myself wrong.  It’s not that I want to be wrong, but I’ve been wrong before, so I have to remove all self doubt that I might be wrong so that nobody ever catches me being wrong.  It’s also where I consider my OCD to be at a healthy level.  I still get lots done, but I reach a defensible level of confidence and can let it go.  If I couldn’t let it go I’d never deliver anything.

The furnace company and my wife are at the other end of the spectrum.  Make a mistake, that’s OK.  Make it again, that’s OK too.  For my wife, it was pure frustration that she had to suffer through.  For the furnace company, it cost them two days of labor by being unprepared.  Two unbillable days of labor – they couldn’t charge me a penny because they were under their warranty of their work.

So it’s your choice: don’t sweat the mistakes ever OR become a little obsessive about your personal quality.  I’m thinking if everyone was obsessed with getting it right, and embarrassed to be caught being wrong, a lot of the quality issue would take care of itself.  I’m encouraging you to be a little obsessive.


Multiple factors in child sleep patterns

September 19, 2008

Believe it or not, this is not a blog entry on child rearing.  This is actually a blog entry on experimenting with a process cleverly disguised as a story about raising my daughter.

My wife is trying to improve our daughter’s sleep habits.  Our little one has been having recent issues with sleeping – mostly not going down for naps without a battle.  We know of a couple tactics that work.  One, we can yell at her.  It works for some reason, but we don’t feel good about it.  If this was the only thing that made our daughter nap, we’d learn to live without her napping.  Yelling and us just don’t go together.  The other choice is we can stay in the room with her until she falls asleep.  That works really well, except then it screws up her sleeping at night.  Once she’s used to going to naps with a person in the room, she can’t go to bed at night.

So anyway, my wife called our doctor.  Side note, who knew that doctors were so useful for advice?  Not me, that’s for sure.  Our doctor proposed that we were putting her down for her nap too late and she was over tired, plus since it was after lunch she was probably all wired up from eating and then trying to nap.  The proposed process change – put her down before lunch instead.

Regardless of the root cause, it was an experiment we were willing to try.  I headed off to work, and when I came home my wife happily announces that we had success on day one.  Day two was good as well.  Then day three came – today.  And the new nap program didn’t work.  My wife was heartbroken.

Me, being a data person, saw some issues with her upset.  By the way, taking the data driven approach with your wife, not such a good idea.  But, that’s not what the blog entry is really about.

First issue, if you have 3 data points (three days of attempted naps), then one failure hardly constitutes much of an issue.  So, my immediate reaction was to dismiss it, but I decided to ask her about the napping process on the first two days and what was different about day three.

Through some more conversation I discovered that she’d employed a different process on day one and two.  Rather than just put our little one down, my wife sat in the room with her until she was almost asleep.  And here’s where we get to the point of my story.

We know from prior experience that if we stay in the room until our little one falls asleep that she’ll nap.  Does staying in the room until she’s almost asleep count?  I don’t know, but it’s different from our normal routine.  Alas, the experiment had been confounded by an additional potential factor in the experiment.  Was it the earlier nap that helped or the hanging around in the room?  Was day three a fluke that she didn’t nap or was day three a change because my wife didn’t stay in the room?

The point is this, if you’re going to make a change to the process, you can’t make many changes at once and know which change you made caused the new outcome.  Now, maybe you’re ok with not knowing which change mattered, or whether it was a combination of both, but in our case we did care.  After all, we weren’t willing to do the “stay in her room” thing because we already have experimented with that variable and know that it causes her to sleep better at nap but worse at bedtime.

The first two data points of our new nap program are garbage.  We’ll have to start anew tomorrow and see how the factor we were experimenting with really works.  Don’t make the same mistake.


Foiled by the shortcut

September 17, 2008

People don’t necessarily screw up processes because they’re evil.  Just the other day, I found a great example of people screwing it up trying to be helpful.  A few managers from a department I work with were invited to a meeting to see a new tool some of their folks had built.

The new tool allowed the user to execute test cases in an excel spreadsheet and then load the final results to our test tracking system.  On the surface, it sounded wonderful.  People were innovating, creating more efficient ways of getting their job done.  They’d taken the bull by the horns.

Of course, the problem is, they destroyed our entire measurement system by doing so.  The test tracking system we have allows us to get lots more data than just the pass/fail data about a test case.  It gives us timing information on the step by step execution of every test case.  We use that timing information to make determinations about productivity.  It allows us to see which steps fail and analyze the failure steps for patterns to see if certain types of functionality break more often than others.

But if you do all the tests in a spreadsheet and upload it, you report every test case as having run in an instant and you don’t report any data on a step by step basis, just an overall pass/fail.  The folks built a new system because they thought using the tool they had was too slow.  And yet, we had sent a team out in the past to measure the performance (with a stopwatch) and found that there were no discernible performance issues.

And yet, they insist.  So much so that they’ve threatened it will cost 30% more to use the tool the “right” way.  30%?  You’d better have some exceptional measurements to prove that.  It’s a great example why process compliance is so important – people don’t necessarily try to screw you up, sometimes they do because they think they know better.


Bad me. On using Agile to evade.

September 15, 2008

I have a confession to make.  I used Agile for evil.  If you’ve read any of my prior posts on Agile, you know that I think it’s a bunch of hooey.  Yes, that’s the technical term for it – hooey.

See, I was in this meeting where some misguided souls had come to our process team for help with their project.  They wanted assistance because (the development team insisted) the users didn’t know what they wanted and if we could help them with some use cases the users would see that they were all confused and finally figure out what they wanted.

Problem was, as far as I could tell, the users knew EXACTLY what they wanted and had asked for it pretty much in no uncertain terms.  If you’ve ever read Tom DeMarco’s “The Deadline” you’ll immediately recognize this.  The users asked for a product they had already seen, but at a much lower price point.  Use cases are lots of fun, but here was an example where they weren’t needed.  You could simply pick up the user manual of the other product and it was all there for you to read.  The users knew what they wanted and they wanted to know if it could be done on the cheap.

Anyway, the development team was insistent that use cases were needed, so we tried to help.  By the way, I’m in the process design business, not the requirements elicitation business, so this was a silly request of our team in the first place.  But we tried, really, we did.  We created a first set of use cases based on the product the users had already seen.  After all, WE (the process design people) already knew what the users wanted, so we had a great guide.

The development team said “no, that’s not what we need.  We need product-level use cases.”  So, we went and got one of the folks from product, who along with us said “what the heck is a ‘product-level’ use case?”  We wrote a different set of use cases, same processes, slightly differently organized to see if that’d make the dev team happy.  Nope.

Finally, we got into another meeting with the development team.  I said “why don’t you go Agile?  Clearly you think the business folks can’t give you requirements, so the best solution would be to start with a handful of stories, figure out what the minimum marketable feature set is, and build the product iteratively.”  Of course, this was BS.  The business people could give very detailed requirements, if only systems would let them.  Me, I just wanted off the project.  These systems people were nuts, and probably subconsciously trying to avoid the project and so were throwing up roadblocks.

Whatever the reason, I finally found a good use for Agile… “requirements are hard, so let’s just not do them.”  But really, it’s an excellent way to evade a hard conversation.  Of course, the conversation will come up later, but at least I can put it off and hopefully they won’t remember me when it comes up again.


The receiving end of bad change management

September 10, 2008

There’s nothing better (sarcasm alert) than being on the receiving end of bad change management, especially from the people who are supposed to know how to do it well.  Part of it that drives me crazy is being aware of why I am unhappy with a change and yet being unable to control how I feel about it.  On the other hand, if I was unable to empathize with people, change management skills might be completely absent for me.  So, let me take you through the situation, why it made me mad and what the better alternatives would have been.

It’s a standard affair of the corporate shuffle.  People come and go all the time, but this time it was my immediate manager.  My manager is off to a new role in the company, and while I am happy for my old manager, the process of change was still not well handled.  We’ll call my ‘old’ manager Bob (because I like the generic name) and my ‘new’ manager Joe (also another good generic name).

Let’s begin at the beginning.  Odds were good, and somewhere in the back of my mind I was aware, that Bob would be leaving.  But for some reason I just assumed Bob was just, what’s a good word for it, speculating when he said things like ‘there’s this new role out there’ and ‘this new initiative is coming.’  I don’t think I’m dumb, but you probably weigh friendly conversation with the likely occurrence of something really happening and dismiss it.  So, lesson one:  people dismiss things you try and say in a subtle manner.  If you want to tell your employees something, don’t be subtle.  This is a good time to prepare them for change if it might really happen – BEFORE THE CHANGE IS UPON US!

At some point between those ‘friendly conversations’ and now, Bob did take a job with the new team.  And then Bob set up the ‘vague’ meeting.  You know how those things go.  If EVER (and I mean ever) a meeting shows up on your calendar with a vague topic like ‘team updates’ and the body of the message says something like ‘I’d like to share with you some updates on goings-on’ you immediately know that someone is leaving.  Nobody sets up a meeting on short notice, with a vague subject and no real content.  I accepted the meeting invite and emailed Bob “are you leaving?”.  Bob didn’t respond, so the answer was clear.  By the way “pleading the fifth” in court, in my mind, is basically an admission of guilt.  So is “no comment”, and of course so is not responding.  Lesson two:  you can’t set up a vague meeting on people’s calendars and not start a rumor mill.  This is not the way to tell your team you are leaving.  No scheduled meetings are going to be acceptable.  You’re giving people time to stew.  Sit down with them one on one and tell them.

So anyway, Bob held his meeting with us.  Of course, the walk to the meeting room with him was like The Green Mile.  Can you say “awkward”?  We ended up in the cafeteria because the first - and second – conference room that Bob booked were occupied.  It was like watching the executioner fumble with the lever to the trap door.  Painful.  Lesson 2b:  If you’re going to schedule such a meeting, don’t drag the start of it out.

Bob put on a smile and told us he was leaving.  There was silence at first, and then Bob tried to fill the silence with a message about how good it was going to be.  Bob was taking some of his responsibilities with him, and isn’t it good for the company that those ideas would get new exposure at a new team?  Um, I could care less.  Lesson three:  Helloooooo…. the mantra of change management is ”what’s in it for me”, not “what’s in it for the company” for a reason.  You told me bad news and attempted to offset it with good news for the company?  I don’t care and you aren’t softening the blow.  Lesson four:  Following on the heels of lesson three, silence is not a bad thing.  Filling the silence is not helping.  This is a loss situation, so people need to go through the stages of grief – denial, anger, bargaining, sadness and eventually acceptance.  It isn’t a “big” loss, relatively speaking, but it is a loss.  If you spend your time talking instead of listening, you are keeping all of us from starting the process.  Lesson five:  (man, this was a bad meeting).  Don’t hold a half hour meeting to tell people you are leaving.  No coping is going to occur in the 10 minutes left after you’re done announcing.  If you’re going to hold a meeting (and I already said you shouldn’t do that in the first place), provide ample time. 

By the way, we all know the corporate game for change.  It doesn’t matter how happy or not happy we are about the change, the game is that we all feign that we’re OK with it.  It is ‘unprofessional’ to vent.  This is, of course, totally wrongheaded.  Venting is natural and should be encouraged (within limits).  At any rate, Bob tells us that our new boss will be Joe.  Time’s up!  I have another meeting to attend (see lesson five).

So at this point I’m mostly angry.  Denial?  That’s pretty easy to get over.  I’m not really angry at my old boss.  In fact, I really liked my old boss.  Personally, I can get paid decent money to work anywhere I want, which means that job satisfaction is a big part how I choose where to work.  A big part of that is choosing a boss who I’d like to work for.  I don’t know Joe.  I don’t know if I want to work for Joe.  I’m not pleased because I don’t like uncertainty.  Guess what, I’m not alone in feeling that way.

The work day ends.  I tell my wife the story because I want to vent.  I love my wife, but for some reason I often dread telling her about things that make me unhappy.  I think it’s because she attempts to sympathize.  It’s not her fault, but her communication style doesn’t work for me when I’m unhappy.  But I digress, my wife is not part of the change management strategy (or lack thereof) that was employed in this situation.

The next work day begins.  I’m still in the same state, since I haven’t got any outlet for my anger.  Bob ‘decides’ to not cancel our team’s weekly meeting.  Clearly, Bob wants out and by holding this now otherwise pointless meeting Bob can introduce Joe to the team.  I’m irritated again.  I still haven’t gone through the coping process and Bob is pushing Joe.  I’m still ambivalent about Joe.  I haven’t even had twenty four hours to consider the situation on my own.  Lesson six:  Don’t push your agenda.  Now that you’ve made the change, there has to be some lull for people to work through it.

Bob introduces Joe at the meeting.  I’m working from home so I call in.  Immediately irritated, I put the phone on mute and open up CNN.com.  Instant detachment.  I’m only half listening, but enough to get more frustrated.  Bob asks Joe for his vision.  Joe starts in on how wonderful it is that Bob is leaving and taking his responsibilities to the new team.  Lesson seven:  Joe’s vision!?!?  This is not the time for Joe’s vision.  You’ve already introduced one change.  How about another?  Don’t add insult to injury.  Lesson 7b:  Guess what, I’m still concerned about what’s in it for me, and don’t care about what’s in it for the company.  Joe’s vision is pretty irrelevant to me.

Bob attempts to praise a couple of us about past accomplishments and how that might lead to new roles.  Lesson seven continued:  Still talking about more change.  I’ve had enough change for one day.

I stop listening and start actively reading news stories on CNN.  Good thing I’m on the phone.  Lesson eight: don’t give people change news over the phone if you can at all avoid it.  You’re not seeing my body language so you can’t react to it.

The meeting ends.  I open up careerbuilder.com to see what else is out there.  I don’t really want a new job, but bad change management does that to people.

The point is this.  If you’re doing process work you’re going to have lots of situations like this where you are the bearer of bad news.  In my case, it was my boss leaving, but you might be changing their job responsibilities or even just the way they get things done.  Get it right, and people will have ample time to internalize the change without it being forced upon them.  They’ll have time to go through the coping process and be ready to take on the change.

But, if you do it wrong, you’ll have employees opening up careerbuilder.com looking for a new opportunity.  For some people it’ll pass, but there’s a chance that someone you really wanted to keep on the team will find something and take it.  At least if that happens you’ll be on the receiving end of bad change management for a change.  Maybe you’ll learn from it.


The problem with single points of failure

September 9, 2008

Besides Six Sigma, one of the process thinkers out there was Dr. Michael Hammer.  I didn’t know him, or attend any of his training, or read his books.  But he ran an entire company that did nothing but discuss business process re-engineering.  He died recently, and very unexpectedly, in fact.

While I feel bad for those he leaves behind, as a process oriented person, it makes me wonder how you run a company knowing that you are a single point of failure.  The company bears his name, and as I understand it, for the most part, people paid to see him teach and have him come to their companies and take his advice.

When I applied for my first job at the company I’m at now, I had a very interesting interview with the vice president for the department.  We were talking about all the process design I had done for the old team, and he said to me “and how’s the team going to be without you around?”

My answer was “They’ll be just fine.  Everything I put in place has controls to assure it keeps happening, and people who are passionate about process to keep improving it.”  Indeed, it was true, when I went back to visit some friends at the old company, I found the team, even with a bunch of new members, following the process I had laid out nearly two years prior, with some enhancements based on their experiences.

Companies can’t rely on people like me, or Dr. Hammer, to be their single point of failure.  A great process or great ideas must be capable of going on without you.  If not, they die with you.


Meetings need the rules of the Senate

September 3, 2008

Crazy idea.  What if we had some sort of, I don’t know, organized set of accepted rules on how meetings or conversations were to proceed.  I think we might get an issue resolved before we got off on another topic.  We’d actually talk about the topic until people agreed the topic was complete and then move on in an organized fashion.  I wonder if anyone’s ever come up with such a loony idea on how to maintain order…

Oh yeah, we have the US Senate, and pretty much any other organized group to look to.  Yet we allow meetings to proceed in pretty much total chaos.  Most of the time I don’t even get an agenda, just a meeting invite!  If the meeting goes off track, nobody brings it back on track.

Side conversations.  Meeting organizers who try to bring order by proposing their own set of rules of order.  Nice attempt, but too confusing to remember.  Forget it!

Organizations much bigger and older than ours have figured out how to structure conversation and debate so it proceeds.  Sure, we’d probably want to leave out filibustering.  Or maybe not, because I could see a bunch of us filibustering a meeting being held by someone who called a meeting that had no point in the first place.

I was watching a debate from the British House of Commons on CSPAN (I think it was CSPAN) not that long ago.  And it was so simple.  The PM (I think that’s who it was), stood near the center and made some statement.  Then, anyone who wanted to speak would stand.  The PM would recognize one of those people and everyone else would sit down and shut up.  They’d speak, the PM would respond to the question asked and anyone who wanted to speak would stand again.  And so it went.  It was orderly, though not very clear to me how the PM decided who got to talk next.

Instead, I get into meetings where some egomaniac who likes to hear himself or herself speak monopolizes the bulk of the meeting and everyone else spends time posturing.  Honestly!  It’s like going to a gym where everyone is standing around flexing.  You can practically hear the grunting.  And it’s totally unnecessary – we get it, we all know you’re a senior vice president and are supposedly important.  Stick a cork in it already!

Regardless of the duration of the meeting, at the end, if the meeting had a point, a decision is made.  If the meeting had no point, no decision is made.  Duration is irrelevant, because it’s not about getting all the debate on the table, it’s about running out of time.

I suppose you could just hold shorter meetings, which I am always a fan of given no other solution, but then people would just hold more of them.  So my proposal is instead this, the company institutes effectively the rules of the Senate (or some lightweight version) for every meeting.

If you can’t get a quorum, no meeting.  Don’t sit around and chat and waste time, just skip it.  Plus it’d probably put a stop to unnecessary invites to meetings.  If you invited too many people, who had no real reason to show up, they wouldn’t and then you just couldn’t hold the meeting.  You’d stop inviting people just for the sake of inviting them.

Tack on all the other formalities, and despite the potential for points of order and whatnot, I think you might actually get something done and stay on task.  Clearly being ‘well facilitated’ is beyond the grasp of most meeting organizers, so I’m thinking a process improvement is in order.  Why reinvent the wheel?


Assume not

September 2, 2008

Need I say more than the title?

Two days, two instances of disastrous plans being laid upon shaky foundations.  The assumption is the bane of every business case in the world. 

For example:  We’d like to build this new system.  It’ll cost ten million dollars.  No worries though, we’ve discovered that we do 1 million transactions a year, and each costs ten dollars.  We assume the new system will reduce transaction cost by twenty five percent to $7.50 a transaction.  Therefore, saving $2.50 per transaction, we have an ROI of four years!  Hooray!  Let’s invest!

Hello!?!?  What’s wrong with this math?  Well, nothing is actually wrong with the math.  What’s wrong is the assumption.  A 25% reduction in cost per transaction?  How’d you figure that out?  For a good ROI, you’d have studied it, but oh no, not these two case studies. 

Both had very similar logic.  “We do X amount of work per year costing Y per unit, therefore if we reduce the cost per unit by Z percent, we’ll save money.”  Simple enough, and easy to believe.  The problem is, they didn’t bother to get any proof that Z percent would actually happen.  No data, just a guess.

Warning sign number 1:  The data is collected via interviewing people on how much easier their job will be.  What!?!?  Interviewing people on how much time they saved?  No stopwatch, no time study, just ask them.  Sure, people are really good at giving you that data accurately.

Warning sign number 2:  The assumption has no basis in reality at all.  No study behind it, just a number.  Big hint, if someone gives you a savings that is rounded to a whole percent particularly 10%, 20%, 25%, 50%, and other likely off-the-top-of-your-head numbers, you know something is wrong.

One real study on process improvement we did about process variation, we went from a 7.37% standard deviation to a 1.77% standard deviation.  That’s a 5.60% improvement.  Not a 5%, not 6%, 5.60%.  A real number, based on real data, from real experiments conducted on real projects.  Not made up data that sounds good.  Not data that satisfies the cost benefit analysis in a time period people will be happy with. 

Real data!  Get the hint?  Assumptions ruin otherwise valid CBAs.  The only exception I can think of where it’d be acceptable is if any different reality about the assumption would improve the situation.  But if the benefit part of your cost-benefit depends on assumptions to be right, replace the assumption with real data.


John or Mr. Smith?

September 1, 2008

On a not so much process as people related note, I was chatting with a peer of mine on our way back from a Labor Day event.  Apparently, the folks in his office had taken to calling each other Mr/Mrs So-And-So as opposed to first names.

Historically, we have always associated being on a first name basis to mean you were close to someone.  For example, I used to visit the local chocolate store so often that I was on a first name basis with the store owner.  Most people don’t have that relationship with the owner, so it afforded me some special treatment.  The first name basis suggests a certain closeness of your relationship.

And so it had gone on at companies for many many years.  You always referred to your superiors as Mr. Smith or Ms. Johnson or so on.  And then, I’m not exactly sure when, companies decided to change all that.  Suddenly, the new norm was to call people by their first name.  Mr. Smith became John.  Ms.  Johnson became Margaret.

And life was chaos!  The old formality of Mr. and Ms. served a purpose beyond showing respect.  In fact, because it was the norm, it didn’t really impart any respect at all beyond an artificial one.  Respect doesn’t come from a name, or so I thought.  That is, until I realized that I too had taken to calling a handful of my peers Mr./Ms. So-And-So.

When the norm is that you are on a first name basis with everyone, right up to the top dog, then being on a last name basis becomes the alternative.  People I now have a close relationship with are greeted warmly with a “Good morning, Mr. Smith” even though it’s a complete reversal of the way things were.

As long as you understand the norm for the company, then you’ll see the alternative form of greeting, the greeting that imparts true respect upon another individual.  In a company which attempts to remove formality by going on a first name basis, people reintroduce it to establish the close relationships they were robbed of by the change in how people are addressed.  Pay attention to it, because it can help you discern who really respects who.