Wednesday, March 3, 2010

Dimensions of Failure

I made a slight reference to dimensions of failure in my last post. What I said there was failure to deliver was not the only dimension of failure. I would like to expand on this a bit more because I think it is extremely important from my perspective in the trenches. If this goes right, you'll probably be thinking "Jim, good job, but you missed..."

All of these are failures because they impede your ability to deliver value to the customer/stakeholder both today and in the future. Now that I've said that, I'm not going to dwell too much on that bit of terminology. I'll also say that you'll probably find much of this isn't really new thoughts of my own. There's plenty of people like Fred Brooks who've hit on at least some of these ideas themselves and Roger Pressman has covered most of these in one form or another in his software engineering textbook (it's good as a survey of ideas out there, I wouldn't recommend it as a manual on how to attack a software project).

Some Dimensions of Failure

Well, We Tried (Delivery Failure)

At the end of the day, Failure to Deliver is the most significant failure. Right? After all, you are saying that you undertook the project, but it didn't deliver. How can it be worse than that?

Well, there's a simple fallacy inherent in this thinking. Sometimes, it is perfectly ok to not deliver working software (or whatever) at the end of the project. You may embark on a project knowing that the problem you are trying to solve is extremely difficult, that others have tried it, and it hasn't succeed. Your customer may be perfectly happy to throw money at the problem on the off chance that this time a good solution presents itself. In this case, reducing the uncertainty that they could be taking advantage of something that they are missing out on has its own particular value.

Finally, Here You Go (Schedule/Resource Failure)

This is probably the most easily understood failure dimension and is certainly the most common. The project got done, was acceptable, everyone loves using it etc. However it was late even past the ideal date, the "we gotta have by" date, and three further "drop dead deadlines". It cost twice as much, and it involved, by the end, three times as many people.

The obvious cost overruns are bad enough. Far worse is the long term psychological impact on the organization as it doesn't ever want to go through that again or loses it's taste for taking on risky projects. The long term cost of not taking on good, but risky ideas is hard to measure and has led more than one organization into fatal stagnation.

We Gotta Keep The Contractors For A While Longer(Completeness/Correctness Failure)

Completeness/Correctness Failure (do not confuse this with Iterative Development!) takes a couple of forms. The easy one is that the project was 'ready' at the end of the projected time, but there were key features missing. Inevitably, there's at least some features that won't make it in that you were hoping to get in to a release. That's ok. I'm talking about key features here. Think building the next Word replacement and not being able to print. That's a key failure, because very few users are going to want to use a word processor and not be able to print. They might be ok with manual duplex features missing, but if they can't kill a tree, they're not going to touch it. This may be related to the other form of this failure mode...

More commonly, this takes the form of a project that was delivered with the majority of features, but bugs abound. There's no such thing as a significant project that releases without some bugs. However, you want to keep them down to the sort that are cosmetic, are not stop work, don't cause data loss, and don't corrupt the system they are on. It all comes down to the impact on the user. If every 40th page, your printing suddenly inverts black and white, you're gonna have annoyed users to say the least. There's a bit of wisdom about waiting for the first service pack out there, but you need to also build some credibility. If you were hoping to direct the team in to Version 2 right after releasing Version 1, but have to have 90% working on bug fixes and not the V2 features, something is drastically wrong. What's worse is if you were planning on working on that Snow Leopard port and now have to miss a whole market segment because you have to put people on bug fixing.

We Built It, They Didn't Come (Market Failure)

People will say anything at a trade show if it's going to get them a free mug, even if all they ever drink are diet cokes. Market research done in a haphazard way has caused more than one organization to blow large sums of cash on a product no one wanted as badly as they said. Other times, people are dead convinced they need an app to help trim their toenails because they hate doing it, but the reality is no matter what you build, it's either still going to be inconvenient or the reality is they are so used to doing it that they can't fathom paying money to improve the situation. This last one happens a LOT. The other way this often goes wrong is that the understanding of the problem was totally wrong. Either you don't solve enough of the problem to have a marketable product or you have something that is just missing that magic 5% that makes people want to use it.

Market Failure can be incredibly frustrating. The development team does exactly what it was supposed to. Perhaps everyone involved, not just those inside the code, does a super job. But because of some flawed understand of the need, that perfectly working, bug free code turns out to be worth zilch.

What, You Don't Need It Anymore?(Opportunity Failure)

In the 1800s, a new type of sailing vessel called a Clipper was developed. These were the fastest wooden sailing ships devised and for a period were the kings of the global trade routes. However, very shortly after they came to prominence, this new fangled thing called a steam engine started becoming popular. The opening of the Suez Canal only sped up the process of the clipper becoming obsolete as steamships could navigate it with ease, whereas a sailing vessel had a hard time in narrow waters with uncertain winds.

Many projects suffer a similar fate. They are built. They are built on time, on budget, meet the initial understanding of what was to be delivered, and by the early definition, they should have been successful. However, in the meantime, the window of opportunity has closed. Opportunity Failure occurs because of sea changes in what people want, competing products come out, new regulations come into law, etc. But overall, the theme is that there was a right time, but that right time has come and gone. This is often exacerbated by or entirely because of Schedule/Resource Failure.

In short, those Vancouver 2010 t shirts may be really great, but if you didn't have them ready until the day after the games ended, they really aren't going to make you a bunch of money.

Now Can I Get Some Sleep?(Team Sustainability Failure)

This the one I hate most. This usually comes along with one of the other dimensions of failure. In order to get done on time, weekends cease being time spent recharging with family and people end up working 60, 70, 80 hours a week (yeah, do the math on 80 hours a week). They manage to deliver something, but usually it's still a Schedule/Resource Failure, often a Completeness / Correctness Failure, and frequently features other dimensions to boot.

I call this Team Sustainability Failure because this leads to burnt out people.

"That guy who was a real hero and had all the brilliant early ideas? Well he hasn't had a good idea in months. The woman who was solving every problem encountered almost instantly? Well, she's been stuck on the same bug for three days now. And what about that one developer actually born in this country ? What happened to him. He was really the best we had, wasn't he?

"Oh yeah, citizenship plus skills meant he got an offer from someone else 3 months ago and flew out the door. He hated the hours, and was just too blasted marketable. At least he didn't steal our source code, although I'm not sure why anyone would want to."

You probably see the problem here. When the project gets on a death march like this, the team's ability to mentally regenerate begins to drop precipitously. With drops in mental regeneration comes more and more mistakes. More and more mistakes lead to falling further and further behind, and you get the rest.

Parting Shots

It's rare to see only one of these dimensions of failure manifest by itself. If it does, it's probably Opportunity Failure or Market Failure. Usually, one dimension of failure is accompanied by others. Not all failures are easily visible enough to see what's coming early. However, most failures have plenty of warning signs along the way and plugs can be pulled before too much is wasted or rocking ship can be steadied before it capsizes. Catastrophe rarely occurs because only one thing went wrong.

Technology is rarely the reason projects fail. Next time... some reasons for failure from my own personal experience (and I won't just be ripping on how having too many Business Analysts and Architects spoils the broth). What I can share now is this simple fact... most dimensions of failure can be avoided by tight feedback loops in order to make sure you are constantly driving towards value in your product. Iterative development and continuous integration are just two ways to tighten up the feedback loop. Understanding the team you have and making sure you are doing what's right to keep that team productive is the other important factor.

No comments:

Post a Comment