« Note to anyone who is wondering about this color scheme | Main | Who butters your bread? »

Where Things Break

I'm tempted to say "where they are connected" and leave it at that, but that would go against my basic principles. So here is the full story.

A few days ago I came home and found that the washing machine was no longer washing. In fact it wasn't doing much of anything except making a whirrring sound when I twisted the knob. This was a problem because it was filled with soap, clothes and water. So I pulled the clothes out and wrung them dry and bailed out all the water and set to work trying to find out what was wrong. I suspected that I would need a new belt, but it turned out I needed one of these because the little plastic fingers had broken off the old one. While I was doing this my wife was asking "shouldn't we just buy a new washing machine?".

It was actually easier to replace than I thought it would be, but I was not finished yet. I put the rest of the clothes in and ran the wash. It worked, at least until the next day. Then it turned out that water was flooding the laundry room. I seems that in working on it I must have loosened the water level sensor hose and it came off. So I opened it up again and sure enough it was no longer connected. The thing is fixed now - I hope.

So what does this mean? It means that in general things break where they connect to other things and by an extreme generality, projects and designs always are going to have trouble at interfaces, places where your team is dependent on another group to deliver something, places where your module hooks up to another, places where the roof meets the skylight flashing. Certainly stuff breaks in between, but that is usually a slow and predictable failure. The breaks at interfaces are often harder to detect until they occur and then they can occur suddenly.

There is not much you can do about this except design them better, like the part for my washing machine was redesigned. They made the fingers bigger so the thing locked together better. You can do this within your team, by making sure that interfaces and handoffs are well defined and understood - and that people on both sides communicate well. You can do this by carefully limiting the number of interfaces so that cross-site or cross-geography interfaces (where communication is difficult)are minimized. You can do this by standardizing and documenting the interfaces so there is less chance for error.

But to summarize, things break where they are connected.


Comments (1)

James Cross:

I wholeheartedly agree. I was once taught--and it stayed with me--that the job of a project manager is to watch/manage the task interfaces. With solid deliverables, the task managers handle the tasks. Don't do their job, do yours.

Post a comment

(Comments are moderated to fight SPAM and will be published after I have a chance to approve them. Thanks for waiting.)


The previous article is Note to anyone who is wondering about this color scheme.

The next article is Who butters your bread?.

Current articles are in the main index page and you can find a complete list of articles in the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.34