« The dangers of DHMO | Main | So this "Atlas" thing you mention... »

June 19, 2006

Broken Windows Theory, and how it's supposed to work

Philip Su's ethereal "Broken Windows Theory" post is back up.  It's a good read, and reminds me of life inside a Fortune 500 software company that I once worked for.  Except that the Microsoft environment is much, much nicer.  Take this quote, for instance:

I once sat in a schedule review meeting with at least six VPs and ten general managers.  When that many people have a say, things get confusing.  Not to mention, since so many bosses are in the room, there are often negotiations between project managers prior to such meetings to make sure that no one ends up looking bad.  "Bob, I'm giving you a heads-up that I'm going to say that your team's component, which we depend on, was late."  "That's fine, Sandy, but please be clear that the unforeseen delays were caused by a third party, not my team."

That's not the way it's supposed to work.  For your company to really be disfunctional, it has to work like this:

  1. Your boss goes to a meeting where edicts come down about what will be developed, and when it needs to be developed by.  Everyone below senior management knows it's completely unrealistic.  No on calls bullshit.  It might be in the interest of the company to know that it won't work, but it's not in the interest of any individual manager to bear that news.  Any manager that does so will be singled out for criticism.  Everyone nods their head to the scope and schedule, snaps out a salute and a "Yes sir.", and leaves the room with body language that fully indicates that they're going to charge the hill.
  2. Your boss comes and meets with you, his faithful team.  The meeting goes something like this.  "Get this, they want X by Y.  (Chuckles fill the room)  Ok, when this slips/fails, we need to be able to prove that it wasn't our fault."  There's never, for one second, any planning about actually meeting the unrealistic schedule.
  3. The team works in earnest, on not being the reason for the slip.  This is not the same as actually working towards the success of the project.  Not being at fault ranges from bluffs of, "No, our stuff is ready.  We're just waiting on (something that no one could possibly expect us to have control over.)"  To actively sabotaging other teams.  "I'll teach Bill over in spider plasma tools to f' with me.  He totally backstabbed me in that meeting 6 months ago, and now I've got my chance.  Check the component in that they're dependent on, but don't tell anyone.  In a couple days he'll start screaming for it.  We'll say, 'What?  It's been checked in for days."  Let's see him hit his deadlines with that."  The most effective way to not getting blamed for a slip is having someone else who you can blame, and make it stick.
  4. Eventually, it becomes obvious that it's going to slip.  Now it's time to "Figure out how we got here, and how to keep it from happening again."  Everyone opens their suitcase of evidence about how some other group is responsible for the slip and the blamestorm ensues.

I remember reading an article in Scientific American about a researcher at HP.  They had a problem where sales people wouldn't give accurate estimates to their bosses about how much they thought they would sell in the next quarter. Everyone would sandbag.  So instead of asking how much they would sell, they were given the choice of being paid a high base, or more commission.  It became instantly obvious how much everyone really thought they would sell.

There's also research into using markets as more accurate predictors than official estimates.  Something about the markets being able to predict complex events better than estimates.

Posted on June 19, 2006 at 04:01 PM | Permalink


The comments to this entry are closed.