Avoid this Margin-Crushing Mistake

Margin. It’s the fuel of your business. It’s the payoff for all your hard work. Like oxygen, you can’t survive very long without it. Why, then, do so many projects have so little margin when completed? The answer involves mystery, but is not mysterious.

Analysts often know that they are not salesmen. They understand that the optimism, duck-feathers, and high-touch people skills are just not in their arsenal. Salesmen, on the other hand, may not recognize that they are not good analysts. That is, they don’t see the need for a patient, linear, detailed approach to scoping a project that comes built into a Requirements Analyst.

Analysts are wired to hunt down the dirty details — to find the hidden gotchas in a complex project — to eliminate mystery. Salesmen are just the opposite. Getting mired in the nitty-gritty spoils the happy customer relationship that they are trying to build. It doesn’t come off as a “can-do” attitude so necessary to winning the bid. Base your cost estimate on this optimistic view of life and you set the stage for a low (or no) margin project.

The two basic variables here are the price you charge and your cost of delivery. Once you deliver the price to the customer, that price doesn’t move. Even on a time & materials job, they get very attached to the early number and your team catches heat if that number starts to rise. If your price was based on your cost plus your target margin, then everything is riding on your delivery cost.

Without a written plan for your project — a blueprint — the last half will not be nearly as much fun as the first. You can face a margin-crushing series of surprises.

Barcode support? Why didn’t you mention that in the sales interview? Integration with the new accounting package? Why would you need that for a customer service web site? Migrate the old data? Are you kidding? It’s a mess!

Don’t think of blueprint preparation as a delay or extra cost — it’s insurance. A blueprint will safeguard your margin as well as your reputation. Build it into your process and protect the profit that you work so hard for.

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.