Over-engineering #1

This wouldn’t typically be something that I’d write about in my blog, but I thought it was a great everyday example of doing something totally unnecessary and over-engineered.  I numbered it #1, since I suspect it might be a fun little thing to add to my blog and I may find other silly examples.

The picture that you’re looking at is of my new raincoat.  At the bottom of my raincoat there is a string threaded through the bottom hem.  If you pull on the string, it cinches up the hem.  I assume it’s to keep the wind out.  Rain doesn’t go up, so it can’t be to keep the rain out.  In itself, the feature is silly, but I’ll let that go.

It also comes with the little clip in the picture which can be moved closer or further down the string in order to keep the cinching tight.  The crazy thing is, that little black ball on the loop will totally prevent the clip from ever falling off and getting lost.  And yet, the clip has been engineered with a little slot that someone has carefully threaded with a piece of nylon and sewn to the jacket.  Essentially, this tiny cheap little clip has its own belt and suspenders just to keep it on my jacket.

How many little feats of over engineering do you do every day?  It’s not particularly LEAN of you.  This one cost what, maybe a $0.01 for the materials and time for someone to hand sew this on?  What if you make hundreds of thousands or millions of coats?

You are offering me nothing

A turn for the worse when it comes to my post about process or process governance.  I finally heard about the first recommendation for the development process.  It was a recommendation for the system design template.  And the recommendation, never mind the template itself, was garbage!

“We’re going to provide a table of contents,” they said.  A what?!?!  I mean, I know what a table of contents is, but how does someone, much less some group of people, decide that a table of contents (a general outline of the document) would be considered a good new standard?

There is a big difference between “doing things right” and “doing the right things.” The first is tactical thinking, and the second is strategic thinking; the first is management, and the second is leadership

– Terry “Doc” Dockery, PhD

A strategy is a must have.  I’m not arguing against strategy.  A table of contents for a document is a strategy.  It covers the basics of what needs to be done.  It is the “doing the right things” part of the equation.  Alone, that is NOTHING!  It is worthless!  It is an idea that has not be executed upon.  If you are designing a process, you can’t put together a table of contents for a document and tell me to go figure out the rest.  The devil is in the details.  The other half of the equation is “doing things right.”  Where is that in a table of contents???

We already work for an organization that gave me a strategy – a suggestion, at best – of how a system design should be done.  You can tell me (that’s the royal we, referring to all developers in the company) what things I should be doing, but if you give me no direction on how to do it, don’t expect much of the results.

A good process has to have a strategy (a general idea of what the right things are) AND tactics.  You can’t leave out the process flow, the templates and tools, errorproofing, and a means to objectively inspect the work and call it a process.  Otherwise, it’s just an idea.  Not that there’s anything wrong with ideas, but how I choose to execute on an idea is going to be very different than the guy next to me.  It’s probably not what you intended.  If you are going to offer me a process, offer me the whole process.  If not, you are offering me nothing that I can use.

What’s your place in the world?

Comparatively speaking, of course, do you know where your organization stands?  How about on your software development process?

I just got out of a meeting today where someone was fretting over the fact that even if we had data that nobody ever believes it.  The data cannot be trusted, they all say.  It isn’t accurate, they say.  What they’re saying is there’s noise in the data and therefore the data is useless.

Who cares!?!?  I’ve already written about data and the presence of noise and the fact that noise is not a killer.  The takeaway from data is not always about your absolute place, but more about where you relatively stand.  If today we make decisions in the absence of data, then the presence of (relatively good) data should help us make better decisions.

It is irrelevant if the data is absolutely perfect.  If the amount of noise does not overwhelm the signal, then data can still provide us a direction and a sense of where we stand in the world relatively speaking.

Relatively speaking is what it’s all about – am I conclusively better than I was yesterday?  Am I worse than I was yesterday – should I take action?  How do I fare compared to my competitors – will I lose in this marketplace if I don’t change?  I don’t actually care if I’m the 10th or 11th best in the world based on the data.  All I want to know is if I am discernibly different from the guy who’s number 1.  If so, take action.  If you can’t tell if there’s a difference, frustrating as it may be to sit on your hands, you probably shouldn’t take action.

But it’s about relativity, not absolutes.  In the inverse, if you are the number one company out there, but you can tell your performance apart from number two, you probably want to start thinking about how to make the gap apparent.  Have you actually lost your first place ranking?  Maybe, maybe not.  Who cares!?!  When you can’t tell anymore, it’s time to make it so you can tell.

Think relatively speaking.  Think about the direction the data points you, not exactly where you are standing.

Process analysis is hard

At one point in time, one of my superiors was talking about the challenges we have in the organization with change management.  On that topic he said “we thought figuring out what the problem was would be hard, it turns out making the change is the hard part.”  He’s wrong, and the two are actually tied together.

All processes, I’m convinced, have just a handful of key things that either make them work really well or not.  It’s the good old 80/20 rule.  Hearkening back to my “Unintentionally Fixed Price Development” post, there really was only one thing wrong with the estimate process – the use of staffing models.  No major changes are needed to the estimate process, simply estimate the entire project rather than just the development work.

But we don’t tackle most of our problems that way.  Instead, we look at the root causes of each defect created and drop them into a pareto chart.  When one or two things don’t create 80% of the problem, we propose fixes for all the causes – maybe 10 or 20.  Suddenly, we’ve gone from an elegant tweak of the process to a massive redesign.

And guess what, asking people to make a massive change to the way they do work is significantly more challenging than a simple little tweak.  Worse yet, all the dozens of changes are unproven, so one can see how lots of changes would be met with resistance.

Going back to the estimation challenge, I could speculate on hundreds of little problems with the process: who we had involved, when they showed up, how we delivered the estimate back to the team, even the way the documents aren’t all in the same format.  The reality is, only one thing was causing us to produce estimates that the business was unhappy with.  And it was no small task to prove it in the end.  Though I speculated in my last post that it was caused by the staffing models, I had lots of additional research ahead of me.

In the end, I looked at (literally) hundreds of sample projects, searched for patterns in the data that would prove it was happening (and found them), and built monte carlo simulations to show how the methodology would cause estimates to be produced in a very narrow range.

Analysis is hard work – well, real analysis is anyway – but it makes change easy.  When you figure out what is going wrong, it is a minor tweak to make it significantly better.  And little changes are easier than big changes to make.

If you find yourself facing an uphill battle on a change, maybe you should be asking yourself if you need all that change or if just one or two little things can make all the difference in the world.

Communities without silos

I’m not much a fan of the new Knowledge Management trend I’ve seen going on.  The gist of the idea is that within and across the silos of a company’s functional organization these spontaneous communities pop up to share information that is otherwise blocked from flowing by the corporate structure.

They are not ideal to the company for a couple reasons.  One, management can’t control the communities that occur without management intervention.  Management likes to control things, so it’s very frustrating to them to have these little communities exist without their approval.  Two, knowledge that is shared through the community has value to the business but isn’t being recorded anywhere.  If the community breaks down the knowledge it collectively had is lost.

Where I am, we’re struggling with creating new communities, even though we’ve hired in a very knowledgeable and talented individual to help build them.  I started to wonder what the issue was exactly.  In theory, these communities for knowledge sharing already existed here, they were just informal.  If we created the structure for them to formalize, shouldn’t people flock to the new corporate-supported structure?

One possibility would be that no communities really existed to be made into something formal.  But why would no communities exist?  Could the company have acted in a manner to squash the informal communities deliberately?  Not deliberately?

Deliberate supression seems unlikely.  First, you’d have to recognize communities to squash and informal communties wouldn’t be easily recognized.  It’d just be people talking to other people.  No websites, no blogs, no meetings, no shared data in any written form at all.  No proof that anything was going on.

So what kind of non-deliberate action could the company have taken to destroy the seeds of community?  What if it is the way the company is structured?  Typically, companies have silos that are relatively stable and encourage up and down communication of information.   Crossing silo boundaries occurs at a management level where necessary to coordinate projects.  But what if the silos weren’t stable, what if the organization was matrix staffed?  If that happened, perhaps an important seed of community is missing – people never stay together long enough to build the trusting relationships needed to form the foundation of a community. 

To have a formal community and informal one must exist first.  With the odds being good that you would not work with the same person or team again for a year or more, when would you ever build up the informal network to share ideas?

It’s a stretch I know, but I haven’t yet figured out why people didn’t flock to a place to share knowledge they were already sharing.  I’m a believer that there’s a simple force at work here – that the 80/20 rule applies and single cause is keeping most people away.

Given the sheer number of people at the company I find it hard to believe some of the more cynical reasons like “we’re a culture that doesn’t share” (it goes against human nature, if you can believe Mark Buchanan’s ‘The Social Atom’), “everyone’s too busy” (always too busy to make their own life easier?), and “there’s no management support for it.” (isn’t that the point, it’s a community, there’s no formal management at all)

I think we’re looking at something more subtle at play here.

51% Bad Decisions

I’ve been kicking around this idea about exactly how good do you need to be in order to be successful as an individual or an organization.  I believe the answer is just 51%.  That is, you only need to make good decisions 51% of the time in order to be very likely to beat out someone who makes just 49% good decisions.

Here’s the simulation I devised.  You start at a score of 100.  For each good decision you make you are rewarded by gaining 1% of your current score.  If you make a bad decisions you are punished by losing 1% of your current score.  In my little model, all decisions are equal, though it’d be easy enough to add in a percentage of help/damage each decision would make to the overall.  For each round, the simulation makes 1000 decisions (arbitrary, I know).  At the end, it spits out your final score.  A good decision vs a bad decision is determined randomly.  I simply generate a number between 1-100 and either 49% of decisions are bad decisions (thus, 51% are good decisions) or 51% of decisions are bad decisions.  I then repeated the simulation 100 times for 51% good and 51% bad decisions each.  Here’s the results:

It might be a little hard to tell from the images, but the green histogram represents the range of results you get from making 51% good decisions and the red from 51% bad decisions.  The bulk of the data for the green is around a final score of 111.  For the red, it’s around 83!  In either case, there’s overlap in the two populations, 51% good decisions does not mean you’d beat out another random set who randomly made more good decisions than bad or had a great ending streak.  But the location of the data is markedly different.

What’s interesting to me is this very simple model shows you two very important things.  One, a company can succeed or fail in spite of itself.  Even making 51% bad decisions, there was at least one example that ended with a final score of 177.  And making 51% good decisions, there was at least one example that scored a 53.

The other important thing is that just 1% can make a huge difference.  It doesn’t take a vastly superior organization to be successful, it takes one that makes more good decisions than bad decisions.  If you can take intelligent risks that work out just 51% of the time, just slightly better than 50/50, your odds are good of coming out on top.

The question is, of course, how do you make better decisions?  My common theme has been, get the data, understand it, and trust what it is telling you.  And, more importantly, if going on gut has generated 51% bad decisions for your organization, you are in more trouble than you know.  In the long run, you are going to end up in a world of hurt.

Career Suicide

This will probably be a short post, since I don’t want to even write down the gruesome details.  I’m going to say this falls into the category of bad change management.  If you want something from someone, it is bad form to call them out on unrelated bad behavior. 

I had this illusion, foolish I know, that my superiors lived up to their description and were indeed superior to me.  I expected that they would be brilliant, ask really tough questions and otherwise wow me – thus justifying their lofty positions.  What I found out in this meeting that I was in was this simply was not the case.  I’m not suggesting by any stretch of the imagination that these people were dumb, but the magic is gone.  They are just people.  The issue is, I thought this, one of my peers said it.

While discovering that they had short attention spans and not particularly enlightening questions to ask was disappointing, that doesn’t make it a good choice for someone subordinate to them to call them out on not paying attention in the meeting.  In the realm of influencing people to do what you want (while I question the ability of influencing to create action in the first place), I can’t think of a case where embarrassing anyone, especially a superior is a good idea.

In a prior post I had written about how sacrificing one’s integrity hurts not only yourself but your entire group by association.  The same applies here.  It’s career suicide for those of us who have to go back to that same person later and ask for something.

Process or Process Governance First?

This might be an issue of which came first, the chicken or the egg, but I’ve been wondering about it for a couple weeks now.  If you are building up a new process (or set of processes) for an organization, should you focus first on defining the processes or on the governance of a yet to be defined process?

I wonder this because I was sitting in a meeting the other day with a group of IT professionals who were trying to put together a new set of development practices.  On the to-do list were processes for all kinds of things, including a few governance items.  Prior to the meeting, we had been asked to rank all the items in order of preference.

Most people’s lists were similar, except mine.  Almost everyone wanted to put into place a set of practices on how to do the development, while very high on my list were the measurement system and governance components to watch over the process.

Of course, some part of me thought that I might be totally out of touch with the real world.  Of course, it makes sense to define the processes for actually doing the work, I thought.  But then I wondered if this was just a fundamental difference between how I think about things and how most people think about things.  Most people are not, in my opinion, particularly analytical.  Most people like to act, so it makes sense that they’d want to define processes closest to the work getting done.  After all, if you can’t actually take action, at least you could work on something that would enable taking action.  Me, on the other hand, I prefer to ponder things, so setting up the governance and metrics so that I could collect data about whatever we did decide on doing would be important to me.

If you had to choose, and couldn’t do both, which would be better?  Define a process that you lack complete ability to govern and measure or be able to enforce and measure a process or set of processes which is only partially defined?  The easy answer is to do both, but I’ve taken that option off the table.  Clearly there is no value to governance of nothing.  But what about governance over a small something?  If you are deliberative like I am, then wouldn’t you rather be able to manage what you have and then use what you find out to add to the process? 

On the flip side, what’s a defined process with no compliance to it and no ability to figure out how it is working?  If the results aren’t what you like, you can’t do anything about it.  In fact, you can’t even be sure the process is or isn’t at fault since you’d have no clue as to whether someone was using it.

Me, I’d rather be able to correct and improve the situation that I’m in rather than just imagine it is being followed in earnest.  Maybe that’s just me, but I often wonder when I find myself in the vast minority if I might be on to something.