Special Reports

Dealing With Uninvolved Customers

One of the keys to a successful software development project is participation from the business representatives. Here are a few tactics to help developers work with them.

• By Rob Keefer
• 06/01/2006

Dealing With Uninvolved Customers
Here are a few tactics to help developers get the information they need from the project's business representatives.

According to a Forrester Research study (see Resources), a successful software development project is supported by strong business participation. There are times, though, that the business representatives for a project do not want to participate. The meetings in which developers attempt to understand what the system should do and how it should be done are viewed as a waste of time. Therefore, developers often find themselves frustrated due to a lack of direction from the business representatives.

Business representatives might not fully understand the importance of their role in the development effort. In this case, developers might need simply to educate them on the vital importance of their participation throughout the entire development process. From a developer's perspective, there are no valid reasons why business representatives cannot be involved with software development projects.

However, if a business unit does understand the importance of its representation, a few tactics have been known to enable developers to get the information they need: identifying a single representative, strategic planning, and use of personas.

Identify a Single Representative
Business representation often consists of a group of stakeholders from many different departments. It is difficult to coordinate a large group, so the development organization might suggest that the group identify one point of contact to communicate with. This individual should be empowered to represent the others, provide information, and make decisions for the project. The best person for this position is someone with the ability to understand the business needs as well as the end user's needs, and to communicate those needs effectively to the development group.

Strategic Planning
Many company cultures expect meetings to occur in a common conference room. This makes it easy for a business representative to skip the meeting. When this occurs, an astute developer will schedule meetings in the business representative's office. This might seem obvious, but by breaking cultural norms, the developer will communicate to the representative that his or her input is important for the project's success.

Use Personas
Another tool that has proven helpful in the user-centered design community is the use of a persona (see Resources). A persona, described in Alan Cooper's The Inmates are Running the Asylum, is a precise description of a pretend user and his or her goals for using the software. A persona is not a real person; rather, it represents a hypothetical user. Even though it is imaginary, it can be defined with a great amount of rigor and precision.

To create a persona, the developer community will need input from the business, but once the persona has been created the business participation can be reduced. When the developers have a question, they can now ask themselves, "What would the persona do?" and hopefully come to a reasonable answer.

Keep in mind that one of the keys to a successful software development project is business participation. If a development organization resorts to the exclusive use of either strategic planning or personas as their method of gaining input from the business, they might need to suggest that the project be canceled. The development community should be working on projects that are of interest to the stakeholders, rather than fighting to get the proper representation on a project. Too many talented software developers have wasted too much time building software that is never used. By having the development organization work toward the common goals of the stakeholders, everyone involved will be much more productive.