Who is NOT Happy

  1. Posted on February 24, 2010 2:23:PM by Earl Beede to Practicing Earl
  2. Technique, humor, requirements

That should be the real question that any project should ask. Far too often the purpose of project work is to make lot of different customers happy. We get requirements from every Tom, ***, and Harry, from the business, from marketing, from sales, from the technology gurus, from the people who will have to maintain the product (OK, we DON’T get requirements from them), and all these requirements get mashed together into a big fat requirements document.

Then we go to build the product and someplace in the middle-to-late development cycle we are shocked, shocked I tell you! that for some reason we don’t have the time and the budget to build all those requirements. So we start de-scoping, deferring, and deleting things that, up to a moment ago, were “required”.

As an aside, when did “require” become optional? Obviously if we choose to release without having all the requirements present, then those requirements are not “required” by any sense of the word as I understand it.

Where were we? Oh yes, despondent at the deluge of delisting requirements (I think I am running out of “de-“ words). The biggest issue in all this is trying to decide (ah, one more) which requirements weren’t really requirements in the first place but pseudo-requirements; wishes in requirements clothing. We hold meeting after meeting prioritizing and re-prioritizing the requirements to try to find some “low” ones to chop off. Only, everybody knows that if they even mention that the requirement source could somehow live and the company survive another quarter without their requirement, onto the chopping block it goes. So of course everybody claims the fulfillment of their requirements are the sole reason people on this planet exist.

Meanwhile the individual contributor at the bottom of the corporate hierarchy is asked to sort all this out. From all of us who have been there before: Good Luck.

This problem is so common but it really is a form of corporate malfeasance. The people at the top have not decided who this project will NOT make happy. That is just as important as who it WILL make happy. The sad truth is that we can not make everybody happy. If do not make decision early, we will waste time and money throughout the project and we will release something that will please no one.

To be clear: any given release of a product can make one customer class happy, the rest you try not to make angry.

If there were a way to make just one product that made everybody happy, the car makers, the shirt makers, heck, the toothbrush makers would have figured this out and there would be just one perfect toothbrush. But there isn’t because you can’t.

So at your next product definition meeting, instead of saying all the cool features your product will have and how people will feel their life is complete just because they had an opportunity to touch it, how about picking one customer class who this product is for and then listing all the customer class “likely suspects” who will not be happy but who we will try not to piss off.

Then sit back and see how much easier the entire development effort becomes.

Post a Comment:

 
 

Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).

 

Contact Earl