Pairing the Customer:
Software as Wanted versus Software as Needed


Position Paper for "Workshop on Customer Involvement"

Jürgen Ahting
AMECO GmbH
Lornsenstr. 72 - D-25451 Quickborn-Heide, Germany
Phone: +49 4106 761077
E-mail: ahting@acm.org

Introduction

Since 1984 I am working as a programmer, project manager, product architect and business consultant. In 1991 I took over the management of our largest project, the creation of a production planing and management system (i.e. a MIS), which is still extended today. This project was of course not done according to the XP practices but at our client they had developed some "strange" practices and even forced us to adopt some of them.

In the following I will distinguish between the client (company) funding a software development project and the customer role in a XP- team.

An interesting client

This client is a company with more than 4000 employees, which have to do hundreds of internal development projects (not software !) each year. For this purpose they have a production division which supplies the necessary facilities, materials and specialists for realizing these projects and a creative division responsible for thinking up new projects, getting a budget and delivering the result using the services of the production division. The projects are always unique but can use components from other projects and can have from one to several hundred releases. Each release usually has several iterations, one of which is reserved for severe refactoring.

The projects of this company are in some respects quite similar to software development. Due to their experience of over 50 years none of the four variables of project management (Time, Cost, Scope, Quality) is really fixed for these projects any more. Their variability in increasing order is Time, Cost, Quality and Scope.

This company has developed the following strategy for handling these projects.

The overall budget for implementing these kinds of projects is allocated on the customer side of the company (creative division) along the organizational structure, but then administered by the production division. At the bottom of this structure are those people thinking up the projects, let's call them the customers. When they have an idea, they write it down and specify how much money they want to spend on it. Their manager then decides whether the specified goal is worth the effort in money and time. In other cases the general goal, the amount of money and the number of releases are already specified in advance and they have to come up with an appropriate idea for the first releases at least.

The customer after getting the managers O.K. goes to a production manager in the production division discussing his project. Together they plan how to implement the project. They can even decide for a spike solution to get a better understanding of the first releases or the whole project. The production manager is responsible for calculating the necessary resources and additional cost, getting the resources and managing the assembled team of specialists to implement the project together with the customer, who is on site during implementation.

For the relationship between customer and production manager a pattern called the "4- eyes principle" is applied. As long as both can agree on a realization which remains within budget and time and implements the specified goal satisfying the desired quality everything is O.K. . If during calculation or any later stage of the project it becomes visible that the budget will be overrun and they cannot agree on another solution still satisfying the goal and quality, they have to ask their superiors. For them the "4- eyes principle" also applies. As long as they agree, they could change either goal or quality (manager of customer) or the amount of money or time (manager of production manager) within their own goals and budgets. In the worst case this mechanism can escalate to the head of the company, who then has to decide whether to sacrifice goal/quality or to spend additional money from his own reserve.

The same process also works in the other case. As soon as the production manager who is responsible for the economical use of resources ("Simple Design") realizes that not the whole budget will be needed, he has to inform the customer. If they can decide on a sensible use for their specified goal, they can use it, no questions asked. If not, they have to give back the budget to their managers as soon as possible. They will use it to compensate for budget overruns of other projects.

In this company it has been understood that planning is an ongoing process and that plans are not cast in stone but a valuable point of reference to measure deviation and taking decisions. It is important to get the warning of planning changes as soon as possible. For this to work it has been guaranteed that if customer and production manager go to their superiors because they see no way of realizing the goal within the given budget their decision won't be second guessed and there will be no pressure applied. Their managers just decide whether to reduce the goal or to increase the budget. This also leads to the important effect that no pair of customer and production manager is afraid of giving back budget when they think they won't need it.

The worst that can happen is a project for which the budget overrun is detected only after it was finished and the bills come still pouring in, or a project for which an budget underrun is detected too late to be used for other important projects in need. Both cases are equally bad.

Another important rule supporting this is that the production team cannot use any resources (i.e. time, specialists) which have not been authorized by customer and production manager.

Apart from "Collective Code Ownership", "Unit Tests", "Continuous Integration" and "Pair Programming" this company seems to apply all practices of XP to their own (non software) project development.

The development experience

Our client demanded that: From an XP point of view this "Pair" of persons represented the customer for the team. On the client side it was the head of an department in the production division. From our side it was a person with a good technical background which should become a domain expert during this project. In this case this person was also our project manager (i.e. me), who had to wear two hats.

This arrangement worked quite well. It was my job to act as an consultant by gathering information and learning from all stakeholders. His job was the explanation and clarification of the requirements. Together we had to reach an agreement on the business decisions by also using my technical experience as a first filter regarding estimation of effort.

Then usually I had to play the customer in the development team and the client- customer accepted the responsibility to "sell" the emerging system (i.e. our business decisions) to the clients (i.e. end users, upper level management, ...). He even trained the first users.

The success of this kind of arrangement depends on the ability of the client- customer to "sell" the system as intended by the gold owner to the end users. Otherwise (as we learned in a later part of the project) there will be a feature creep not intended by the gold owner.

Statement of position

One of the central features of XP is the clear specification of the interface between developers and clients with the developer on the technological side and the client on the business side. This puts a big burden on the customer role in the XP team.

Most clients have a business problem to be solved. They are looking for a solution which satisfies some stated business goal. They will be looking for a software developing contractor when they think that at least part of the solution can be supplied by an software system.

Thus in reaching their business goal clients have two problems:

  1. Building the right system (including organizational changes).
  2. Building the system right.
XP is an excellent concept for optimizing the economical solution of the second problem, not least by explicitly separating the responsibility for the solution of both problems between the developers and the customer. Consequently the XP approach, by favoring bottom- up design (user- stories) and local optimization (refactoring), does not much support the customer in making sure that the user stories implemented will finally ad up to the solution of the business goal.

The main support the XP practices give the customer for reaching his business goal is by reducing the cost of his learning, i.e. changing his mind and thus changing some already existing parts of the system.

Unfortunately the biggest fear of several of my clients was:

"Our software contractor will deliver a software as we want it, not as we need it !"

I would like to defend the following statements:

© 2001 Jürgen Ahting