In the following I will distinguish between the client (company) funding a software development project and the customer role in a XP- team.
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.
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.
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:
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:
I would like to defend the following statements:
© 2001 Jürgen Ahting