The search for the so called “silver bullet” or the cure-all in software development has been there for ages. Many methodologies were developed, each claiming to be the solution. However, still there is no one universally accepted methodology that can solve all the inherent issues in software development. While all these approaches try to find an ideal development methodology for success in software projects, an important variable is usually forgotten. That is, the role of a customer in the success of a software project.
A good customer has an enormous impact on the success of a software project. A bad customer may fail a project which has the best engineering and project management skills.
The acronym CRACK 1 represents 5 qualities of a good customer (or customer representative).
- Collaborative, and willing to work with the project team toward the same goals, initially with requirements, and later with deployments and any integrations.
- Representative of the end users of the software, and is able to speak on behalf of them.
- Authorized to make decisions that have a significant impact on the project. If the customer is not authorized, there could be delays in proceedings until the necessary approvals are received.
- Committed, willing to see the project to the end, and willing to put effort to eliminate inevitable hurdles that software projects face.
- Knowledgeable about the organization and the requirements.
Here’s a comparison of two customers I have worked with in the past (Each quality is scored on a scale from 1-5, 5 being excellent)
| Customer #1 (project #1) | Customer #2 (project #2) | |
| Collaborative | 5 - Communicated the requirements clearly including the required screens. Replied to emails fast. Always clear in communication. Available over phone when needed. | 1 - Sometimes took weeks to reply to emails. Rarely available for calls. Vague requirements. Did not give timely feedback to specifications and early releases of the software. |
| Representative | 4 - He was in a position to directly answer questions about requirements based on his understanding of the end user requirements. | 1 - He had to go back to the end users and come back to us to answer questions about requirements. The answers usually were copied and pasted from answers received from end users. |
| Authorized | 4 - Had authority. | 4 - Had authority. |
| Committed | 5 - Committed to make the project a success. | 2 - Partly committed. The project was a low priority among other commitments. |
| Knowledgable | 4 - Had a good understanding of the end user needs and the needs of the company. | 2 - Did not have much understanding of the end user needs. |
Project #2 continued to be in an uncertain state with periods of inactivity and late change requests leading to indefinite delays in project completion. Although Project #1 had its share of issues, most the issues were related to engineering (e.g. performace), and with a little bit extra work, the team was able to overcome them.
It’s good to know what sort of a customer you’re dealing with before you start a software project. Although most of the time we don’t have the luxury to pick and choose customers, knowing the customer characteristics makes is possible to do the necessary precautionary process adjustments.
[1]Boehm, Barry, and Richard Turner. Balancing Agility and Discipline. Addison-Wesley, 2006.
