Saturday, October 08, 2011
When To Say No.
A lot of people that I’ve known, including clients and a previous boss, have been under the impression that we as developers (or sysadmins, or whatever else) are to do what the client (internal or external) wants. Period. They think that this is the reason why we are employed. This isn’t really true.
My old boss’s argument was that we were only a cost center and not the ones generating the revenue. This is an extremely short sighted view to take.
Our job, is to give the client what they NEED in order to do their job and for their company (and ours) to make money. There is a very large difference.
One thing we have to ask ourselves on virtually every feature of a program and even on every project is “why?”
Why are we doing this?
Does it fulfill a business need?
Does it make the company money?
Does it save the company money?
Does it make the life of people at the business easier so that they can do one of the above more effectively?
If it doesn’t fill some need, then why are we doing it? Most of the developers that I know don’t want to work on a system that nobody is really going to use, and adding features that make no sense only increases the chance of bugs in the software as well as increases the development time.
For example, say a client commissions a piece of software and one of the features, after all is said and done costs $10,000, will the value that they derive from that feature be greater than the cost? If the answer is no, then why (other than the $10,000 going into your company’s bank account) would you do it? Sure, you can keep your mouth shut and pocket the check, but chances are that the reputation may well catch up with you down the road.
Projects that come in on time and under budget tend to get you more projects. Projects that overrun on the budget and/or time don’t.
The problem is in convincing the client that they don’t need the feature (which I generally call “kitchen sink features” and a lot of people call gold plating). Sometimes the client doesn’t want to let go of a feature because they have a checklist that they want to fulfill for bragging rights/marketing material. Sometimes it’s because they don’t want to let go of *anything* and sometimes there’s some other reason.
If it turns out that you were wrong about them not needing the feature, then drop the argument and build the feature. If, however, you can deliver a better product (less bug prone, easier to maintain, etc) and do it faster without an unneeded feature, then you may want to make a business case for doing exactly that.
I’ll admit that it’s extremely difficult to make a business case against an emotional response (in this case, the desire for more more more), but it can be done.
I had a discussion with Jim Holmes on this topic at Stir Trek back in May and he had an interesting way to take care of the issue. In fact, I approve of it so wholeheartedly that it earns my Sneaky Evil Bastard Award.
He had a client that wanted far more functionality than could be delivered in the time and budget that was allocated to the project and, predictably, the client didn’t want to let go of any functionality, claiming it was all equally important.
Jim’s solution was to target one of the parts he knew they REALLY wanted as being impossible to complete given the resources since everything was equally important. Magically, the client changed their minds and decided that the unimportant functionality wasn’t vital after all, and they were able to finish the project within a reasonable time frame.
It’s funny how that works. =]
Failed projects are a bad thing. So are projects that nobody really uses. Don’t cave in to the pressure. Do the right thing when you can and work to the best of your ability. This isn’t a one-sided deal. Every piece of software involves a partnership between the craftsmen and the owners and that requires give and take from both sides. If you approach it that way, you frequently get better results.
Current Mood: thoughtful
Current Music: Jimmy Eat World – The Middle