The project plan is clear and the specifications are detailed. So why is the final product so different from what you expected? In this week's column, Nicole Auger brings a product manager's perspective on how features get changed or added during the development process. And she gives tips on how to get what you ordered, instead of a substitute.
Even restaurants have fine print these days. Have you seen a menu that gives the restaurant's policy on baked potatoes? Usually it reads: "Baked potatoes served after 5:00 p.m. are subject to availability." I have eaten in plenty of places where the supply did not meet the demand and alternatives were offered.
Recently, a waitress didn't bother to tell me they were out of baked potatoes until she brought my plate. As she set the plate down and moved a wad of pink chewing gum to one side of her mouth, she announced that they had run out of baked potatoes and had decided to give me a double order of French fries instead. She promptly left the table and headed back to the kitchen. Her lack of eye contact and rapid departure signaled that I should be grateful I got anything in the potato family. I furrowed my brow, when suddenly this sense of confused dissatisfaction seemed all too familiar to me. Aha! This is what it feels like when specific software features or functions have been requested, but the developers deliver vaguely similar features with "bells and whistles" to appease the customer. This is worse than a double order of fries to a Quality Assurance person like me.
As a strong proponent of having clear project plans and detailed specifications, it astounds me when the unveiled features and functions miss requested items in favor of "cool gizmos." An example of this might be a request for an alphabetized list, a drop-down menu, and an email link, but what is delivered is an elaborate free-form search with cross-referenced results and blinking action buttons. While not all developers are guilty of this, I have not seen a project yet that is completely immune to this phenomenon. Some items outside the expected "baked potato" deliverables are extra or harmless, like adding sour cream and chives. But a pattern of missed delivery breaks down communication, stalls projects, and costs significant amounts of time and money.
This also often leaves Quality Assurance holding the bag. I can recall many conversations with my bosses where I defended my project plan and the clarity of the expected deliverables. Adding insult to injury, when attempting to discuss the miscommunication with developers, it frequently becomes a highly technical discussion that threatens to cloud the real issue.
There is a flip side to this situation that may be even more common: developers show the latest features to a large group--perhaps upper management or customers. Not only are developers likely to show off features that are nondeliverables, they will also likely select ones guaranteed to elicit "oohs" and "ahs." This makes it challenging to get the focus back to the original set of deliverables. Either the attendees are enthralled with what they are seeing and want more of the same, or the developers take the lead and forge ahead. This may be an extreme case of an easily enchanted audience, but it happens.
Here are some simple ways to minimize the chances of getting a double order of fries instead of a baked potato.
Be Clear about Expectations Upfront
When starting any project I usually have a conversation with the developers. I let them know I'm on their side, and I'll go to bat for them if necessary. In return I expect they will program features and functions to specifications or provide me with suitable alternatives prior to implementing. That minimizes unwanted surprises.
Have QA Lead Demonstrations to Members outside the Project Team
I strongly recommend that Quality Assurance perform this role and I further advocate that the demonstrations