“Of course software development is not dry cleaning!”, you might be saying. However, it’s apparently a not-so-obvious idea. As a services-oriented software company, what’s your role? Is it to deliver “satisfaction guaranteed” ? It it to do whatever it takes to get things done on time, and if there are delays, to do what it takes to get back on schedule? If the delivered is somehow unacceptable is it your job to fix the situation, because what you delivered wasn’t perfect? Is the customer’s singluar role to evaluate if what they brought you turns out right? Really, that sounds a lot like a dry cleaning business. The “Dry cleaning” approach is a classic services-industry scenario.
Dry cleaners, restaurants and florists who follow this model are generally going to be successful, it’s a tried-and-true approach. It’s really understandable that in approaching the services-side of software, that people might think the “dry cleaning” model would once again lead to success. However in software, this model leads to unsuccessful projects.
Picking apart the scenario, the main problem is the client relationship. Software services are very different from traditional services in that the client’s requirements can be incredibly complex and individualized. Developers need to understand the client’s business and the problem that nees to be solved. Communicating this information is not a one-time thing, but a task that generally runs thoughout the process of development. The client can’t just “drop off” what they need and pick it up later with software. In contrast, their busness and specific needs are so central that the client needs to be considered part of the development team to create the product together-the development team develops, the client communicates and is the investor, the designers manipulate graphics, these are all parts of a working whole with the same goal.
It might seem “scary” to let the client inside the team, but the fact is, doing so will help clients to understand that they and their requirements are important and valued by the software company. In addition, clients will understand that since they are important and equal members, they have to live up to their role in the team or the project is hurt. Since it’s no longer and us-vs-them situation, if the client IS late on something, they will have an easier time understanding that their actions have consequences, i.e. the whole team is delayed, and they’re are either causing someone to work overtime, or maybe they’ve created a situation in which the team cannot possibly deliver on time. If you leave the clients on the outside and leave the development process a black box, it’s understandable that they would be intolerant to delay or bugs. Bring them into the decision process… “well, things did end up getting a little more complex than we anticipated, so if we cut time for testing, there are going to be more bugs. or we can add time and deliver with fewer bugs. What’s best for the project?” If the client understands what led to bugs and their own role in that, they will be more willing to see followup as part of the process and not a “freebie” they are owed for the software company “messing up”. More followup was just a tradeoff choice.