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 not be done in the presence of developers or programmers. Keep the demonstration running smoothly by providing an outline to the attendees. Be sure to notify the developers or programmers when this demonstration is taking place so a testing area is available. Finally, never blame a developer or programmer in front of a group when a feature or function does not work or look as expected. Comments like "I guess Harry forgot to fix this" do nothing but harm. Always offer to take issues to appropriate persons and report back on the progress. Don't be tempted to sacrifice integrity for short-term payoff.

Communication before Delivery
Quality Assurance should clear the path so that developers and programmers can openly discuss snags in the project and offer alternatives. It is important to realize the best window of opportunity is after the request has been made and before the delivery is complete. Delivering without a feature or function or with a questionable alternative is a symptom of poor planning and communication.

A final note: Holding to the requested features is not about inhibiting innovation. Users are best equipped to tell you what they need. It will be a test of understanding their needs, and of communication skills, to implement real innovations.