Various studies – and common sense – indicate that involving customers increases the likelihood that your product will meet customer requirements (I hope these studies weren't funded with my tax dollars!)

Although the above statement sounds exceedingly obvious, the fact of the matter is many software projects lack customer input. Consider the following example:

Week 0: Red, our friendly project mangler, is in charge of the next release of his organization's flagship product. For the past 3 months, Product Management has been meeting with existing and potential customers to determine which incremental features should be added to the existing release. After gathering those requirements, the one and only Product Manager wrote an SRS (Software Requirements Specification) that has now been handed over to Red.

Week 1: After reviewing the SRS, Product Development's first cut of the project estimates it will take between 30 to 34 person-months to meet all of the requirements. Red's budget only accounts for 25 person-months.

Week 2: Red's top priority is to scrub the requirements. Unfortunately, the Product Manager, who just ramped up a hard 3 months, took a well-deserved vacation. He'll be back in 1 week. To get his team going, Red decides to prioritize the requirements himself and cut a few features that he doesn't feel are necessary.

Week 3: Another week has gone by and the Product Manager is back from his vacation, well rested. After spending most of the day going through his inbox, he stumbles across an email from Red informing him that the I18N feature will not make it in this release given the budget constraints. The Product Manager is fuming. “This feature has been committed to a customer and MUST be in the product!” On this note, he leaves for Europe to meet with a huge potential customer.

Week 4: Red is still over budget, and needs to add I18N back in the product. The Product Manager made it very clear that I18N was expected by a customer, but didn't explain which other features were of lesser priority. Red hopes that he can settle everything when the Product Manager comes back from Europe early next week.

Week 5: Our Product Manager was scheduled to come back from Europe this week, but a major sales opportunity presented itself in Brazil, so he's off once more. Since the project has already used up 16 person-months, Red desperately needs to determine which features are not going to make it in the product. He asks around for feedback, and everyone has a different opinion. Red therefore decides to loosen some of the requirements related to performance. “The system might not respond quickly, but at least all of the features will work.”

Week 6: The Product Manager comes back from Brazil. He finally gets to meet with Red and the rest of the R&D team. He informs them that it's critical the system meets the performance requirements. However, the Reporting and the SSO features, which were respectively sized at 2 and 3 person-months each, are not required in this release of the product and can be rescheduled for the next release. The lead developers working on these features inform them they were both were completed a week ago.

I don't think I need to describe the rest of this project. But in case you haven't guessed, it was late and over budget.

If you were to ask this Product Manager whether or not he involved the customer in the project, his answer would be “Absolutely! I spent 3 months gathering requirements and writing an SRS.” But where was the customer feedback when the SRS needed to be scrubbed? And where was the Product Manager when Red and the R&D team needed questions answered regarding the list of features?

In a Hundred Words or Less

Gathering feedback to write your SRS is a great start to involving the customer in your project, but you can't stop there. If your user input stops when Product Management prints out the SRS, you're in trouble!

Involving the customer means having the customer or his proxy (e.g. the Product Manager) available at all times. If you truly believe that involving customers increases the likelihood that your product will meet customer requirements, make sure they are involved throughout the project, not just in the Definition phase.

Luc Richard is professional speaker and author with over 10 years of experience managing the development of software applications. He can be reached via The Project Mangler (http://www.projectmangler.com).

Article Source: http://EzineArticles.com/?expert=Luc_Richard