Gunnar Harde

Agility and Obligation

Part 1: Why Fixed Price Projects Fail

Developing software is a complex task. Especially the interaction between client and contractor is very challenging because de facto the client cannot completely describe his requirements for the system to be developed due to the complexity. This must be considered when arranging the contract of the cooperation.

Fixed price agreements require a precise description of requirements to achieve a high level of certainty for the pricing. Because it is impossible to define precisely all requirements in advance, this kind of agreement is often conflict-laden. The planning certainty for the client suggested by fixed price agreements is usually not given. Furthermore, the contractor is tempted by fixed prices to produce software lacking the necessary quality. Therefore, the sustainable maintenance and further development of the software is endangered.

The first part of this paper examines the pitfalls of fixed price agreements and their impact on requirements engineering, project management and software quality. The second part “The Art of Assigning Software Development” will describe alternative agreements between client and contractor that lead to better quality and results.

As project manager and consultant I have worked in software industries for 18 years. I have seen many clients who believe that assigning software development is like ordering a table. These clients consider traditional assigning of “things” as the only way to control software development and its costs: You describe what you want; you arrange a fixed price agreement with the contractor; and you wait for the result you might accept or not. I have seen many of those projects fail.

It should be so simple, but it isn’t.

A client wants a software producer to develop software for him. The client describes what the software should achieve; the producer thinks about how he can realize these requirements; then he makes an offer and develops the software. Several software-engineer models, like the waterfall or the V-model, are based on this basic idea.

This approach “I tell you what I want, and you tell me what you want to get for it, and then you realize it” seems to be attractive especially for the client: The client knows at the very beginning what the project will cost and what deliverable he will get for this price – but only apparently.

The problem: This approach doesn’t work.

It doesn’t work because software is not like a piece of furniture which can be precisely described by the client and its metrics defined at the beginning. Software is more complex. The complete description of the requirements would not only be more extensive, but de facto impossible. The reasons for this are manifold:

• Even requirements that seem to be simple often turn out to be unclear. E. g., the requirement “A user can enter his phone number into the system” could mean that the user can enter something into a field and this something will be simply saved in the system. However, it could also mean that the system must make sure that this something is indeed a phone number, this number is transformed to the right format if required, the number corresponds to the location entered by the user, the user will be asked for his number again if the number is invalid, the user will be logged out in case of repeated incorrect entries, and so on. Depending on the actual requirement, the effort of its realization differs a lot.
• Many requirements are not specified at all. These are especially requirements which are fundamentally important and are taken for granted and not recognized by the client. The requirement that keyboard and display are on the same side of a mobile phone might be certainly justified, reasonable for everybody, and because of its implicitness not specified.
• Requirements are often ambiguous. So the requirement “Bring me one liter milk from the supermarket, and if they have eggs, bring me six” might lead to the result that you get six liters milk, because they have had eggs. Linguistic misunderstandings are indeed often a source of misinterpreted requirements.
• During a project the framework, like legal regulations or business processes, might change. Thus requirements change, too. Because of the dynamic nature of business, project targets are often moving targets.
• While defining the requirements concerning performance, user experience and layout more precisely, it turns out later during the project what technical consequences these requirements actually have. These consequences can be considerable.

Because of these shortcomings and incompleteness of requirements and further technical risks, the cost estimation of software is very uncertain. A cost estimation based on a specification of the subject-specific requirements typically has an uncertainty of -33% downwards and +50% upwards – even if an experienced estimator estimates the costs very conscientiously ^[McConnell]. Often the uncertainty in real projects is much larger.

Surgery was successful. Patient is dead.

One of the most important goals of professional requirements engineering is the specification of high quality requirements, and doing this as conscientiously as possible. The requirements should be complete, unambiguous, precise and worded clearly. There is nothing wrong with this aspiration since such a requirement specification forms the basis for an expeditious realization later on.

However, it is problematic if requirements engineering asserts a claim to describe all requirements completely in all details to remove all cost estimation uncertainties at the very beginning. Even if such a specification would be possible (which never happens in practice!), the effort would be enormous:

Not only all functional and non-functional requirements must be covered, but all non-functional requirements must be quantified in relation to each functional requirement. E. g., the non-functional requirement “The system must be performant” is vague, not quantified and therefore not very helpful. Even the more concrete formulation “The system must display each new screen to the user within two seconds” is not really reliable. Questions concerning constraints remain: What is the power of the computer this requirement will be tested on? How good is the network connectivity during the test? How many users are using the system at the same time? What applications are running simultaneously? What ranges do the test data have, and do they correspond to the real operations? Furthermore, two seconds would not be adequate for all screens. To be precise, performance requirements should be described for each user interaction with the system.

The problems that occur by specifying the performance are basically the same for all other non-functional requirements, such as user experience or GUI design requirements. Such a complete specification is theoretically conceivable, but the effort would be tremendous. Moreover, if the requirements should come to an agreement with different user groups and stakeholders, the effort would increase many times over.

Aside from the fact that such a specification which does not leave any questions open de facto does not exist: It has no economic value.

Assuming a project has a budget of 1 million Euros. What is the benefit if after an elaborate specification it can be said by an uncertainty of ±10 % that the software will cost 700,000 Euros, but the specification itself has already cost 500,000 Euros? Indeed the specification would be helpful during realization, but the information needed for realization could be gathered more efficiently and more favorably during project duration.

Based on a complete specification one might predict that the money is not enough – but it would have been enough if the specification had been leaner. Surgery was successful, patient is dead.

It has to be declared and accepted that software development involves a high level of uncertainty. Depending on the contractual agreement between client and contractor, this uncertainty has different consequences for the project, the product to be developed and the contracting partners, as the following paragraphs explain.

We are heroes.

A typical scenario: The requirements have been reasonably specified, the fixed price offer has been issued and signed, and realization has started. Then matters of detail concerning the requirements occur. The contractor clarifies these questions with the client and notices that the realization cannot be done with the originally assumed expense.

The contractor could now get in contact with the client and explain to him that during preparation of the offer information was missed and that further expense must be expected. However, the idea of negotiating contract changes with the client, maybe interrupting the project and annoying the client led the contractor to back off from such a step. If the additional effort is rather small, the contractor might accept the extra costs. However, this can happen during the project again and again so that his calculation at least gets out of control.

And so overtime is done, efforts are not invoiced, and the contractor plays the ‘we-are-heroes-and-make-everything-possible’ game. Especially young companies with less experience in project business can easily run into economic trouble. In this way a long-term and trustworthy cooperation between client and contractor cannot be built up. Whereas quite a few contractors will try to offset the economic damage by reducing software quality:

It works – somehow.

It is one matter to make software somehow runnable and to implement the requirements more or less successfully, but it is another matter to write software of high quality. Good software does not only function, but it can be sustainably and efficiently developed further. Thus, a software architecture and a design are needed which not only have been conceived at the beginning, but which are also actually implemented, reconsidered and appropriately adjusted during realization. Furthermore, a consistent programming style, a logical naming of classes, methods and variables as well as an adequate annotation of the source code are part of high quality software.

Developing software of a high standard initially means an increased effort, but it reduces the effort during the further programming and is therefore a prerequisite for a sustainable product development. In contrast, software of low standard satisfies quickly the requirements of the client at the beginning, but the longer the further development lasts the more cumbersome the realization of new requirements becomes. Finally further development is not possible any more. Then, only the complete reimplementation remains as the last resort.

Especially if projects are under time and cost pressure, the contractor might be seduced to realize requirements as cheaply as possible at the expense of quality. First, the client gets the impression that his pressure is successful: The software does what it is supposed to do. The layout might not be that pretty and the user experience might not be really brilliant, but it does not seem to be worth explaining these complaints to the contractor or even investing additional money to fix them. What the client doesn’t see are the qualitative deficiencies ‘under the bonnet’. And what the client doesn’t know yet: Each further development will be more and more expensive, and he is imprisoned in a project in which the contractor can hardly be replaced since the contractor is the only one who understands the source code. Finally, even the contractor gives up in face of the chaos.

Good software has its price. Not being willing to pay this price can be very expensive at the end.

Therefore, the client might try to control the quality of the developed software. But how?

The patrols of the code police

Assuring the quality of the functions and the usability is relatively simple, but only superficial as we have seen above. Whereas assuring the quality of software design and source code is costly and can only be tested randomly. Only experts can do this. Few clients have the required expertise to this.

It might be problematic to assign another IT company for this checking, too. The effort and the corresponding expense would be untenable for a thorough validation. Furthermore, conflicts between the developing and checking contractors would be inevitable since many design decisions can only be judged subjectively, and plain design policies do not exist for every case. A contractual determination of the architecture and the design ahead of the project would be a limitation of the contractor’s business; moreover, the design must be changeable during the project’s duration. A rigid adherence to original considerations can be disastrous for a project.

In essence, the client has no chance to control the software under the bonnet in a powerful, comprehensive and efficient way. Here, the fundamental problem is the cooperation on basis of a fixed price agreement: The contractor is interested in a realization of the requirements with as little effort as possible. If the cooperation is not considered as a long-term one, the contractor is invited to stint on the quality.

Bricks cost extra.

While contractors with low business experience tend to play the “we-are-heroes-game”, many other contractors love to play another popular game in case of fixed price agreements: We sell a house to you! (However, the bricks cost extra.)

The contractor makes the most favorable offer possible for getting the assignment. After getting the acceptance he tries to sell the features which are not precisely described in the specification or have been specified ambiguously as expensive extra performances. And thus, performance improvements cost extra because the statement of the specification that the system must be powerful is not really unambiguous; likewise the validation of user inputs cost extra since the specification describes what the user can enter, but not what he is not allowed to enter; etc.

The client, who has hoped to get what he wanted for the offered price, actually gets what he has said he wants to get. And this is something different. So it turns out that such types of fixed price agreements are much less fixed priced than the client assumed.

However, it is getting even worse for the client:

The insurance policy by the software producer

If the cooperation continues on basis of fixed prices, the contractor could change his strategy: Since the contractor cannot be easily replaced and is in full control, but at the same time does not want to exploit the extra-bricks game too much, he takes all project uncertainties into account when calculating further offers. For this calculation the contractor assumes the expected efforts in the very worst case rather than the realistically expected ones. So the client does not buy only software, but also an insurance policy which should guarantee the compliance of the assessed costs.

Especially inexperienced clients, who haven’t arranged milestones with defined states of documentation, test coverage and code guideline, are locked in: They have to accept almost every price because swapping the contractor during runtime could be even more expensive. And so the client does not only pay for the software development itself, but also for an expensive insurance policy by the contractor.

Conclusion

Fixed price projects suggest that the client controls the project. Because of the uncertainty regarding the requirements and their descriptions, the contractor can de facto easily take control of the project. The problem presented in the first part of this article can be summarized as follows. There is always a fundamental conflict of interests in 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.

I have experienced projects that have followed different and more successful approaches. These alternative approaches are described in the second part of this article “The Art of Assigning Software Development”.

In the meantime, I invite you to share your thoughts and experiences with fixed price projects in the feedback part of this article.

References

• [McConnell] McConnell, Steve: Software Estimation. Demystifying the Black Art. Redmond, Washington 2006.