Clients want to get control. They try to get control by making plans, defining obligatory specifications und negotiating contracts to ensure from the very beginning that they get want they want to get.
In the first part of this article “Agility and Obligation: Why Fixed Price Projects Fail”, I have described the fundamental problem and my experiences with this approach as project manager in software industries. Because de facto it is impossible that the client precisely describes all his requirements in advance, the client does not get the expected control of the project and its costs. Furthermore, there is always a conflict of interests in the case of fixed price agreements: After assigning the contract the contractor will always try to satisfy the agreed performance with little effort, whereas the client wants to get as much as possible for his money. For this reason alternative approaches are more successful.
Service agreements: The effort counts, not the result.
A physician is not paid for healing patients but for trying to heal them. This is characteristic for service agreements: it is not the achieved result but the effort for performing the service that counts. Because of this openness, a detailed specification of the requirements and a calculation of the corresponding costs at the beginning of a project are not needed. Thus, the cost estimation uncertainty and the inflexibility during the project, which lead to the problems of fixed price agreements, do not exist.
However, service agreements seem to be an endless drain on somebody’s resources. The client assigns the contractor without knowing what the project finally costs. He knows that the contractor will be interested in selling him many further services – no matter if he really needs them or not –, and he can hardly ever be sure if services he has paid for have been delivered.
Better than fixed price projects
However, the client’s loss of control regarding service agreements compared to fixed price agreements does not really exist: The client does not really have control of fixed price projects either. The first part of this article has shown this in detail.
At the beginning of a project the client does not need to specify the requirements in detail for service agreements in the way he must do for assigning fixed price projects. This does not mean that requirements engineering is obsolete for service agreements: it means that the purpose of such requirements engineering is raising business needs, not arranging contracts. Furthermore, it enables a much more flexible handling of change requests during project duration since contractual changes are not required. Requirements engineering can be much leaner and more effective from a business point of view. However, a product vision and precise description of the project goals is still necessary at the beginning of the project because an especially lightweight requirements specification needs clear target definitions for orientation during realization.
Fixed price, agile specification
The magic triangle of project management, i.e. the interplay of specification, time and costs, seems to disappear for projects based on service agreements. Whereas classical fixed price projects start with the specification and then time and costs will be derived, one might think that none of this is given in service-driven projects. Actually, the triangle should be turned upside down for service agreements: Starting with fixed budget and time, performance scope is getting more and more concrete during project duration. Whereas for fixed priced projects the specification is comprehensively documented and true costs are tainted with large uncertainty at the beginning, the budget can be preset for service agreements. Which requirements will be implemented will be decided during the project. Thus, the fear that service-driven projects could get out of control in time and budget because of a missing specification is not justified.
Service agreements are much more compatible with modern agile software development than fixed price agreements. Indeed there are requirements at the beginning of agile projects, too, but they are handled much more flexibly, as stated in the Agile Manifesto: “Responding to change over following a plan” [Agile Manifesto].
Nevertheless, for projects based on service agreements rough cost estimations should be performed. Such a rough estimation is the precondition to being able to decide if the project should be realized or not. Furthermore, the size of the provided budget should be guided by the estimation value. Since the estimation should only be rough, the client is able to carry out the estimation by himself in many cases; estimation methods like the function point method require neither comprehensive IT know-how nor a detailed analysis of requirements.
Conflicts with services
The conflicts of interests between client and contractor related to fixed price agreements are solved by service agreements. Although there is another conflict of interests: The contractor will endeavor to keep the performance scope large and even to increase the scope. The contractor will try to make new functions tempting for the client. Likewise he will try to perform conception, documentation and quality assurance with an excessively large effort. This problem won’t be avoided even if the client had fixed the budget at the beginning. The contractor might still conjecture to get a further assignment after the budget has been exhausted since essential requirements haven’t been realized. At least he won’t risk that the product is completed too early without exhausting the budget because he performed efficiently.
The situation is particularly precarious if client and contractor are located far apart from each other. The client has almost no chance of getting a sense of whether the contractor is actually working on the assignment that he has paid for. Ideally, the contractor should work on-site. If the software engineers need clarification, they can reach out and ask the client project manager (in case of a Scrum project this is the Product Owner) at any time. Questions can be easily clarified and trust can be built up.
Building trust
“Trust is good, control is better.” This oft-cited Lenin quote should not be transferred to software development projects. The problems of fixed price projects in achieving control by unambiguous specification and clear contractual agreements concerning costs and time at the beginning have been explained. Thus, one of the central statements of the Agile Manifesto is: “Customer collaboration over contract negotiation.” It is not a classical, data-driven controlling that is required, but rather developing a trustworthy cooperation between client and contractor: “Business people and developers must work together daily throughout the project.” [Agile Manifesto]
For instance, the Scrum framework, which defines a project management method based on the agile approach, provides that not only the developers and the Scrum Master take part in the daily action planning, but also the Product Owner as the representative of the client. Even other stakeholders of the client, like users or managers, are invited to this so-called Daily Scrum and can participate as passive listeners. Also, the developers present the result of a sprint (a sprint is an implementation cycle of one to four weeks) to the Product Owner and other representatives of the customer immediately at the end of a sprint.
The client can immediately test the software after each sprint. The Product Owner decides if the sprint version will be rolled out as a new release. As a result of this early testing and rollout of a first release, shortcomings of the software are discovered early; since problems concerning cooperation are often the roots of these shortcomings, they are quickly discovered too.
These agile methods can build up trust, but they require trust as well. Effective software development without trust is condemned to fail.
Finally, because of the permanent proximity of client and contractor, there is the danger that requirements are brought to the developers’ attention in an uncontrolled and ad-hoc manner. Therefore plain rules must counteract this. Agility does not mean chaos. E.g., Scrum provides that the development team explicitly commits to the sprint target and that during the sprint further requirements cannot be added, but are gathered in the requirements list (the so-called Product Backlog) by the Product Owner.
But don’t be naïve
Shifting from classical, fixed price agreements to (fixed price) service agreements without a detailed, up-front specification means that the client has no chance to claim recourse. This seems to be naïve at first glance. And it is naïve, indeed, if the client is trapped in a long-term contract which doesn’t allow for a proper separation in case of a dissatisfactory cooperation.
Agile software development frameworks like Scrum suggest defining quality criteria which must be met at each end of iteration. These Definitions of Done enable the client to define obligatory standards and artifacts that the contractor has to comply with. In this way, a client might stipulate that all known bugs must have been fixed, working deployment scripts exist and documentation is up to date. Furthermore, in the case that the client dismisses the contractor, the contract might stipulate that the dismissed contractor has to support knowledge transmission for a certain time. All these arrangements make it easier for the client to change contractors.
Certainly, every exchange is painful. But the client can reduce this pain and gain independency. This independency is the best weapon he has in case of loss of trust with the contractor. This weapon is much more effective than obligatory specifications, which are often ambiguous, and threats to claim recourse, which have an uncertain outcome.
Sharing as an alternative approach
Both fixed price agreements as well as service agreements are fundamentally based on the assumption that there is a client who engages the contractor to create a product that the client uses afterwards for his own business aims. However, if one drops this idea, a new way of cooperation opens: Client and contractor merge as partners who bring a product on the market together. The “client” assumes the business part, whereas the “contractor” assumes the technical part. A real client doesn’t exist, like there is no contractor anymore. Instead a company with business know-how and a business idea seeks an IT company which will be engaged in the profit.
This approach, which changes contract partners into real business partners, has considerable advantages: It is in the own interests of the IT company to assure the quality and thus the maintainability of the software, while avoiding the realization of unneeded functions and promoting an effective software development. Thus, the interests of the partners coincide, and the conditions are ideal for successful software development.
However, such an approach requires considerable effort to initiate the cooperation and allocate the profit. First, the initiator of such a cooperation, which is usually the partner for the business part, must develop a comprehensive and reliable business concept and present this concept to the potential IT partner. Both parties must evaluate the expected business-related, organizational, sales-related and technical efforts and negotiate how the shares of the product can be allocated. During the common cooperation the one partner must be willing to disclose all relevant business figures and allow the other partner to check them.
Nevertheless, even the necessary effort of generating a reliable business concept and checking by the partner helps shape the picture of realistically achievable aims – and might prevent unrealistic projects in an early phase.
Conclusion
The complexity of software development does not allow a precise description of all requirements at the beginning of a project. Therefore, the obligation regarding quality, time and costs suggested by classical, fixed price agreements does not really exist. Instead of facing this fact, contractors do extra, unpaid work, develop software of low quality or charge for every tiny change request and each implementation of ambiguous requirements. In my experience, these are the main reasons – next to the unavailability of professional software developers – why so many software developing projects exceed budget, lack quality and ultimately fail.
Service agreements support effective software development much better and enable an agile approach. Nevertheless, they require a transparent and trustful interaction between client and contractor during the project. In this case, the client must take care that the cooperation with the contractor is close; i.e. the contractor works on-site and consistently involves the client in the development.
Alternatively, the client and the contractor could cooperate by sharing the profit of the developed software. A client should first check if such a long-term cooperation with an IT company, in which both parties exploit the market, might be reasonable. Through this profit-sharing, the partners have basically the same interests concerning an effective realization of the software.
The success of software development beyond fixed price agreements not only depends on the contractual agreement of the parties but also on the way in which client and contractor actually live the cooperation. It depends on the cultures of the participating parties and on their willingness to establish a trustful, long-term cooperation. In my experience, this is the key.
I look forward to reading your experiences, your thoughts on project agreements and your comments on my ideas.
References
- [Agile Manifesto] agilemanifesto.org. 21/10/2012.
After studying physics in Germany and New Zealand, Gunnar Harde worked as software engineer, later as IT consultant and project manager for IT and business consultancies and research institutes. Since 2007 he is responsible for the development of several IT systems of the Group Quality Assurance at Volkswagen and shapes the cooperation between IT and business department strategically and methodically. Harde is Certified Scrum Product Owner and expert in agile management.