Don’t Break Out the Champagne Just Yet!!!
Many executives evaluate software development projects with one criterion; whether or not it meets its ship date. Agreed, missing your project milestones could be devastating, especially if there are some legal implications tied to a release schedule. However, the ship date is not the only decisive factor you should pay attention to. Ever heard of customer satisfaction?
At the end of the day, if your customers don't like what you've shipped, they're not going to pay for it. And if they don't pay for it, then meeting that so important ship date is meaningless.
Unfortunately, too many managers learn this lesson the hard way. They declare the product generally available as soon as it comes out of the validation phase, and immediately break out the champagne. “Congratulations everyone! We've met our ship date! Let's celebrate.”
Wait a minute! Meeting the ship date is like studying for an important exam. Sure, perhaps you think you are ready, but don't you think you should wait until after the exam to celebrate? The true test to determine whether or not you've succeeded is not exiting the validation phase; it's successfully completing the customer acceptance phase.
I remember a case where the R&D team was celebrating their success just as the product was being packaged and shipped to the customer. One executive in particular was going on and on about how he played an instrumental role in meeting the ship date. Without him, this project wouldn't be a success – or so he claimed.
When the customer did receive the application, the installation manuals and user guides weren't even in the box. They “weren't quite ready” replied the executive “because they needed some last minute updates due to a change request implemented at the last minute”. Regardless, the customer proceeded to install the application. He failed miserably! “Not to worry.” answered the executive. “We're going to send someone over to help you out.” Finally, after modifying a few (read most ) configuration files and tweaking some of the code, the system seemed to work.
A week in the Acceptance Test phase, the customer reported that 5 of the most important use cases weren't met, and that their testers had raised over 50 software defects. They decided to not accept your product – nor pay for it – until they reached a 98% success rate on the ATP.
Do you consider this project a success? Was meeting the ship date a good enough reason to break out the champagne?
If you're that executive, you're probably trying to put the blame on other departments. “Product Management didn't identify the right set of requirements”, and “Quality Assurance should have consulted with the customer to better understand their acceptance criteria.” It's their problem, right? Wrong!
Listening to your customers is not an activity that only applies to other teams. It's an activity that needs to be practiced by every department in your organization. Involving the customer should be part of your corporate culture. It should occur at every stage of the development process, including the planning, definition, construction and validation phases.
Granted, customers are not always easy to deal with. They can make your work life miserable, and if not managed properly, can actually do more harm than good. Customers…
- Don't always know what they want, and those who do have a hard time explaining it.
- Won't commit to a set of features. They'll describe something different every time you ask.
- Agree (after the fact) that the initial set of features don't meet all of their requirements, yet they're not willing to pay extra for the additional features they are now requesting.
- Won't read your specifications or answer your questions in a timely manner, but are very quick to complain once the product is in their hands and doesn't meet their expectations.
- Aren't technical enough to describe their real needs.
- Don't understand your software development process and that you can't rewrite the system two weeks before its ship date.
However, regardless of how tough your customers are, you cannot develop your system in a silo and then hope they're going to accept and pay for the product. The solution is not to ignore the customer. The solution is to develop a better relationship with them, and to involve them even more!
By further involving your customer, you build a better relationship with them. One where you're not afraid to remind them that you need feedback in a timely manner, or otherwise jeopardize the delivery date. One where you can say no to change requests late in the development cycle.
Building a strong relationship with your customer doesn't just make the experience more enjoyable. It increases your likelihood of meeting their acceptance criteria. It allows you to manage their expectations, and therefore their satisfaction. After all, isn't customer satisfaction just the customer's perception of your solution in comparison to his expectations?
Involving the customer isn't just a start of project and end of project activity. Here are some ideas to involve the customer at every phase of the development lifecycle.
Planning phase: Inquire about your customer's internal milestones. Try to line up your deliverables and determine a release schedule that meets both your needs. If you can both agree to some of the larger milestones, there is a stronger likelihood that your schedule will remain the same. Furthermore, your designers will treat those deadlines more seriously and will put in extra effort to meet them.
Definition phase: Get your customer to describe, or better yet, write down use cases and other requirements that will eventually be included in the acceptance test plan. Get him to review your prototypes and functional specifications and welcome their feedback. The earlier you work on the acceptance criteria, the better your chances of meeting them – and getting paid.
Construction phase: Keep your customer up-to-date on your progress. Do regular product demos and show them you're on track. Demonstrating progress is great for nurturing your customer's trust. Furthermore, it helps them understand that they can't submit significant change requests when you're so close to project completion.
Validation phase: Ask your customer to Beta test your application. Let them install your application, execute system tests, integrate it with their other systems, and even get a sneak peak at your manuals and user guides. Many of them will gladly do it – for free – and will be more than happy to point out some defects and/or recommendations that you can fix before the ship date. This is especially useful when you don't have enough capacity to test your system as thoroughly as you'd like.
Product launch: Train your customer. Show them how the product is meant to be used. Teach them how to not make errors. Many defects raised during an acceptance phase are not bugs with the system itself but rather problems related to how the tester uses the system. Educate them on how to properly configure your system and use your graphical user interfaces.
Involving the customer won't guarantee they'll commit to a set of features, control feature creep, or magically increase their technical knowledge. It won't get ride of the 6 problems highlighted earlier in this article. But it will build a stronger relationship, it will allow you to better understand their acceptance criteria, and it will make it easier for you to manage their expectations. Without your customers, you'd be out of business, so don't learn to ignore them, learn how to deal with them. Involve your customers throughout the software development process, and ship a product that meets their expectations – and then break out the champagne!
This article was originally published on www.gantthead.com.