Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail if it doesn't meet user needs or expectations.
Software Magazine, Feb. 2001, Collaborating on Project Success
Based on the Extreme CHAOS 2001 Report from The Standish Group.
Agile development teams deal with the issue of customer involvement by having a person who is empowered to specify the User Stories, set their priority and to answer questions about them in order to clarify the real requirements. Ideally, this Customer is co-located with the development team, although an even better approach is to locate the team with the Customer.
The effect of having the Customer working so closely with the developers is twofold:
Because of its importance in ensuring the success of a project, the Customer role requires certain traits in the person who fills it. They must be able to make informed decisions quickly and not waffle on their answers. If they don't know the answer to a question, they need to be able to say so and then follow through with getting the answer as quickly as possible. They need to know the business that will be supported by the system quite well. They also need vision.
For a small system with a focused group of users, having an end-user as the Customer is fine. When a system is larger, for example it consolidates several lines of business, the Customer needs to have an overall strategic vision of how the system is going to be used to support all of its users. This requires someone at perhaps a management level, or they have a reporting relationship with C-level management. This is required because the issues faced by this Customer increase considerably with the number of lines of business in the system. Often, these issues require resolution from a higher level of management, and having a Customer either at that level or with a direct reporting relationship to that level will speed the resolution process.
Issues
More than One Customer
What happens when a system has multiple Customers or Stakeholders? Getting multiple Customers to agree on the time of day let alone User Story priorities is very difficult task. In situations such as that, there needs to be a higher level of leadership from whole organization, not just the Customer or IT groups. One strategy is to have one person appointed as the single Customer who can make the vast majority of decisions about the system on the spot. Another is to have a comptroller or similar person from the financial part of the organization to assist in determining the true cost and benefit of requested features.
A strategy that simply does not work is to have a Customer Committee (read Change Control Board) to determine the requirements and set priorities. In almost all cases, such committees are too slow to respond, and impede the team's progress. What can work, however, is to have a steering committee comprised of executive-level members (CxO, VP's etc.) to provide oversight for the project and a consistent means of escalation of issues from the Customer level. There still needs to be a Customer who will be the single voice for the project in order to provide consistency for the developers, but that Customer can rely on being able to obtain quick resolution of issues by having the ear of senior management.
Customer "Balkanization"
Different people have different priorities, they work differently and see the world differently. Some people may want reports to show the data with all its warts, while others may want to massage it so that it appears more consistent. Some people want a very spartan interface so that they aren't distracted by reams of data, while others want as much as can possibly be crammed onto a page in order to avoid scrolling. Also, although we're all supposed to be adults, personality conflicts can enter into the equation. I personally have witnessed situations where if person A said the sky was blue, person B would disagree as a matter of principle.
Resolving issues such as these is critical to the success of any project, but again it's even more important on agile projects.
Even when there a single Customer has been appointed, sometimes other people work behind the scenes (e.g. talking to developers directly) in order to have the features that they see as important moved up in priority. The best solution that I can see is to ensure that the leadership of the Customer's organization is aware of the issues, and that the development team needs the Customer to speak with a single voice.
To provide resolution, the Customer needs to either be or report to a sufficiently high level of management to be able to impose a certain level of order. There are times when a decision simply has to be made, and the Customer must be in a position to make it themselves or to escalate to their management to have the decision made.
Summary
The Customer role is the single most important and difficult on any type of project. It is especially important for an agile project due to the hands-on approach required. They need to be located with the development team (or the team with them) in order to facilitate communication.
The Customer must have an overall vision for the project, and how it fits into the business that it will be supporting. They must have the authority to make decisions required to allow the team to keep moving forward.
By having a dedicated person located with the development team and able to make decisions quickly, the chances for success increase tremendously.
Software Magazine, Feb. 2001, Collaborating on Project Success
Based on the Extreme CHAOS 2001 Report from The Standish Group.
Agile development teams deal with the issue of customer involvement by having a person who is empowered to specify the User Stories, set their priority and to answer questions about them in order to clarify the real requirements. Ideally, this Customer is co-located with the development team, although an even better approach is to locate the team with the Customer.
The effect of having the Customer working so closely with the developers is twofold:
- Communication improves dramatically. Verbal discussions provide much more valuable information than e-mail or hard-copy documents, and thus costs and the time taken to make decisions are reduced. This isn't to say that no documentation is produced, but rather that the documentation should be the result of a conversation first, and not vice versa.
- Decisions are made more quickly. Because the Customer is readily accessible, questions can be answered and decisions made in very short order. This allows the team to keep moving forward, rather than waiting for answers or performing speculative work.
Because of its importance in ensuring the success of a project, the Customer role requires certain traits in the person who fills it. They must be able to make informed decisions quickly and not waffle on their answers. If they don't know the answer to a question, they need to be able to say so and then follow through with getting the answer as quickly as possible. They need to know the business that will be supported by the system quite well. They also need vision.
For a small system with a focused group of users, having an end-user as the Customer is fine. When a system is larger, for example it consolidates several lines of business, the Customer needs to have an overall strategic vision of how the system is going to be used to support all of its users. This requires someone at perhaps a management level, or they have a reporting relationship with C-level management. This is required because the issues faced by this Customer increase considerably with the number of lines of business in the system. Often, these issues require resolution from a higher level of management, and having a Customer either at that level or with a direct reporting relationship to that level will speed the resolution process.
Issues
More than One Customer
What happens when a system has multiple Customers or Stakeholders? Getting multiple Customers to agree on the time of day let alone User Story priorities is very difficult task. In situations such as that, there needs to be a higher level of leadership from whole organization, not just the Customer or IT groups. One strategy is to have one person appointed as the single Customer who can make the vast majority of decisions about the system on the spot. Another is to have a comptroller or similar person from the financial part of the organization to assist in determining the true cost and benefit of requested features.
A strategy that simply does not work is to have a Customer Committee (read Change Control Board) to determine the requirements and set priorities. In almost all cases, such committees are too slow to respond, and impede the team's progress. What can work, however, is to have a steering committee comprised of executive-level members (CxO, VP's etc.) to provide oversight for the project and a consistent means of escalation of issues from the Customer level. There still needs to be a Customer who will be the single voice for the project in order to provide consistency for the developers, but that Customer can rely on being able to obtain quick resolution of issues by having the ear of senior management.
Customer "Balkanization"
Different people have different priorities, they work differently and see the world differently. Some people may want reports to show the data with all its warts, while others may want to massage it so that it appears more consistent. Some people want a very spartan interface so that they aren't distracted by reams of data, while others want as much as can possibly be crammed onto a page in order to avoid scrolling. Also, although we're all supposed to be adults, personality conflicts can enter into the equation. I personally have witnessed situations where if person A said the sky was blue, person B would disagree as a matter of principle.
Resolving issues such as these is critical to the success of any project, but again it's even more important on agile projects.
Even when there a single Customer has been appointed, sometimes other people work behind the scenes (e.g. talking to developers directly) in order to have the features that they see as important moved up in priority. The best solution that I can see is to ensure that the leadership of the Customer's organization is aware of the issues, and that the development team needs the Customer to speak with a single voice.
To provide resolution, the Customer needs to either be or report to a sufficiently high level of management to be able to impose a certain level of order. There are times when a decision simply has to be made, and the Customer must be in a position to make it themselves or to escalate to their management to have the decision made.
Summary
The Customer role is the single most important and difficult on any type of project. It is especially important for an agile project due to the hands-on approach required. They need to be located with the development team (or the team with them) in order to facilitate communication.
The Customer must have an overall vision for the project, and how it fits into the business that it will be supporting. They must have the authority to make decisions required to allow the team to keep moving forward.
By having a dedicated person located with the development team and able to make decisions quickly, the chances for success increase tremendously.