I was driving in to work this morning trying to think of how to help a particular company that I working with, who just can’t seem to nail down the design for their software. Every day the developers would come up with some new, neat idea and whammo, months are added to the development cycle, the whole software requirements and functional specs require major revisions, and feature creep starts reaings its ugly head.
With the clinical trials deadline moving alarmingly closer for this customer, any change in plans right now could really jeopardize their success.
OK, “Neat Things” are cool. I get that. It is sometimes no fun to build a dull boring program. But, software not delivered on time can really ruin your whole day, not to mention deep six your whole company!
Most developers are not mechanical drones. They tend to be very creative people and want their work to be fun, leading edge, and therefore interesting. Because of that they can easily fall prey to what I call: “Software Shiny Object” syndrome. They want their software to be cool! But software is also a tool and as such just needs to perform a task. Yes, it should be attractive and easy to use but it does not always have to resemble the latest high tech video game.
“Shiny Object” syndrome is a close cousin to something everyone knows…”buyers remorse.” Let me explain. You know how you spent months and months deciding on what big screen TV to buy. You research all of the different companies that make them, look at all of the different models they make, and decide on the biggest one that you can afford. You take a deep breath, get out your credit card, hand it to the guy, and Voila! you are the proud owner of a brand new beautiful big screen TV. You can’t wait to get it home, set it up, and sit down in your comfy chair with a beer and some potato chips and watch the big game right before you in almost life size splendor.
The problem happens when you sit down at the computer after you have bought the thing that you find out that the company has just come out with a bigger, better, smarter version of your TV and your model is not only obsolete, but it is now hundreds cheaper. Thats when the head banging begins and the self doubt starts to creep in. I must have been so stupid to have decided to buy this TV…
The reason for this is that we have just too many choices. You pick one and then there will always be something else that comes along that appears to be better But, I ask you, are you really that unhappy with what you have. After all, you can almost remember the CRT type TV you had as a kid that was so small it fit in a bookshelf.
Well designing software can be the same way. You’ve done your marketing homework and think you know what your customer needs. Then half way through designing your product you start thinking of all these things that you can put into your program that will give your customer the ultimate experience.
On top of that your sales department is starting to heap loads of whip cream features on top when they talk to their customers. I can sell “X” number more…read in giant number…if you add this widget. Pretty soon you find yourself so mired in trying to satisfy everyone you can’t see how you are ever going to deliver the product. Brain freeze…!
But, your customer will never have any experience if you go out of business because you fail to deliver the software for your product. So, how do you prevent feature creep?
1. Start with the end in mind and stick with it. Have your Requirements Spec defining what problems you need to solve with the software for the first release…no more…no less. What are you willing to spend company money on delivering because you know it will get the job done for your customer.
2. Make sure all interested parties have read the spec. With that I mean Marketing, Sales, and any other interested party. Tell them that at a certain time the bar is closing on features and they need to make sure that they are happy with the list.
3. After the bar has closed on the feature set have a process where all interested parties have to assess each new feature that is requested to get added for cost benefit analysis. Have all parties understand and agree to the consequences of making the change. Ask questions like is it so necessary that the schedule should be moved to a later date to accommodate it?
4. Have clear dates for releases ahead of time and stick to the dates. If you can put in an new feature and still make the date, sure. But, if the date slips because of the new feature, look at the feature and assess whether it is a deal breaker or another “Shiny Object” and can be postponed.
5. If you customer is insistent, have a clear release date that will immediately follow after the initial release where you will be adding their requested feature.
No customers wants to hear “No.” But if they know that you will accommodate them and give them the date for their release, they just might appreciate your attention to quality and accept this. After all, if you don’t deliver anything, that will not make them happy at all.
The key to avoiding “Shiny Object Syndrome” is to understand that the real way to deliver on time is to master the requirements list. Be ruthless in removing them, if you find you are falling behind.
Getting your software out there is the key. Many times you really don’t know what your customers need until you deploy something. Then you can see how your customers use the software and what they really need rather than guessing. There will always be time to add some shiny new “chrome” that will attract their eye and their dollars the next release you have.
