Hardwired to Fail

One of the best statements of need for proper Requirements Analysis is given in this course description by the University of Management and Technology in Arlington, VA:

“All projects arise in response to needs. In theory, the whole project effort should be geared toward addressing these needs. Unfortunately, needs are often incorrectly identified, poorly articulated, or simply ignored.

Requirements, in turn, are the physical embodiment of the needs. If needs are poorly defined, then the requirements that address them will be off-target, no matter how brilliantly formulated.

Ultimately, many project failures are rooted in the poor development of needs and requirements at the project outset. In this case, project work has not even begun when failure is hardwired into the project.”

~ Introduction to professional development course PM013

Projects don’t fail

Projects don’t fail. People kill them.

A bad project is put down like a vicious animal that threatens the children. Ok, actually stakeholders cancel them to relieve the pain. But what makes a project bad? More importantly, how can you keep your project from becoming rabid? This is not about blinding charts or brain-numbing statistics. We avoid tasks that are critical to our success for very simple, gut-level reasons.

Have you ever climbed a ladder to work on something like a light fixture, only to realize that you need another tool? I have. Why? Could I not take 30 seconds to think through the tools I might need up there? Am I not clever enough to use a bucket or canvas bag to put them in for a single trip?Let’s be honest. I didn’t make just one trip down and back up the ladder – I made several. Why do I do that?!

The answer is amazingly simple… I’m impatient. I want the instant gratification of “making progress” on this task and any semblance of planning won’t give me that. It feels like a delay. So up the ladder I go with a phillips screwdriver. Flat screws? Who uses flat screws any more? Oh yeah, my house is 25 years old.

When was the last time you rushed out the door and forgot the papers for that important meeting? Your umbrella on a rainy day? Your car keys?! It happens. We’re so focused on the destination that we forget about the process that will get us there.

Good software, like so many other things, requires planning. A little clarity of thought — and we all know this — prevents huge problems later in the game. We don’t do it because we can’t wait and we mentally skip ahead to the desired result.

What happens? The project runs off the rails. The project is full of rework. Users are angry about the project taking so long. The project becomes an anxiety-ridden, evil thing that needs to be put out of everyone’s misery. Eventually a new consultant comes along who says “Where is your blueprint for this project?” and everyone goes “Duh!”.  And the project starts over – this time with delayed gratification (planning) built in.

Why Software Estimates Stink

When a builder prices a custom home, he looks at all the pieces. He considers the concrete, lumber, plumbing, HVAC equipment, wiring, etc. — all the way down to the bathroom fixtures.

Why don’t software builders have the same level of accuracy in their build estimates?

Well, we could talk about how houses are assembled from well-known components available from multiple vendors. Or we could examine the amount of time and discipline that the housing industry enjoys, which dwarfs the software industry.

A major issue for software buyers is that they cannot easily describe the size, features and quality of the “house” they want. They offer desires like “fast” and “easy to use” and talk in vague terms about “order entry” and “shipping” functions. Likewise, the builder can rarely walk them through a software “model home” to demonstrate the ammenities available and their cost.

The benefit that a home builder has in approaching estimation with confidence a proven instrument of clarity and decision-making: a blueprint.

The heart of a software blueprint is the Features List — the list of what is to be built. If this list is broken down into estimatable units, the builder has a fair chance to give a price that is meaningful.

What is an estimatable unit? Think in verb-noun pairs like this:

  • Add Customer
  • Delete Order
  • Find Vendor
  • Update Order Status

When a complex subsystem like “Order Entry” is broken into smaller parts like this, both the buyer and the builder can see what is being estimated. Clarity like this produces confidence that the estimate has value — and the buyer can budget for success.