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.
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.
- [McConnell] McConnell, Steve: Software Estimation. Demystifying the Black Art. Redmond, Washington 2006.
Fixed price offer Projects/Work packages can really be a bottleneck
Recently we are doing a fixed offer project with our North american counterparts.
Even though we are from the the same company within the departments we have the fixed offer project/work package.
It started with a initial estimation and we all agreed with the budgeted engineering hours. Things started to run after the Purchase Order.
Problem started when after 4-6 months we did a monitoring on the eng. effort spent on the work package. To our surprise we almost spent 3x the budgeted hours!! a jolt on our team. We also burnt the Risk Hours which were part of the initial budget.
Its really beneficial to be clear upfront that that during the execution of the project there could be budget overrun and this has to be clearly agreed upon during the beginning regarding who should absorb which overrun and should never left for the end. (when the damage is done and people are more in the 'blame game').
We asked for a Variation order quite late in the project but it could not be catered due to skew engineering effort at their end as well.
There is one another point of view of the problem our counterparts off load the tasks to us to have some cost benefits due to lesser Eng. hourly rate but in the end it could be case they end up spending the same amount of price which they may spend back in there home country.
I would say a double edged sword to handle with. Atleast some margin for excess hours has to be agreed upfront so as to avoid last moment surprises and panic attacks.
Dear Arjun, many thanks for sharing your experiences with fixed price projects. Exceeding a budget by a factor of three is certainly a very unpleasant situation. I think you are absolutely right: If you see that the budget will be exceeded, it's important to inform the management as soon as possible. And I think as well that in general the management should be sensitized for the uncertainty of software development projects. But I have two questions:
Years to do requirements? Obviously not a good practice... If something. Is that big, you need business and information architecture, break the beast into cohesive and decoupled pieces, and start delivering as soon as possible. With a good architecture and plenty of resources, you can even do multiple pieces in parallel. Requirements "up front" does not automatically mean big or lengthy. It frustrates me to hear about your experiences and know it is still common across a lot of organizations and projects. It reflects negatively on my profession, and i fully understand why agile arose when it did; developers were tired of getting terrible, out-of-date requirements. Not from me, though...
Need a little separation
Two things going on here, sloppy requirements and unprofessional contractors. My experience is on the requirements side, driven by the reality that detailed requirements can definitely be defined up front, and does not take forever. The example of the telephone number is not one of detail level but of incomplete requirements elicitation. Not specifying the domain and validity rules of any data entered into a system is just lazy, they ain't called information systems for nothing. From my own article writing I know it is tough to provide good examples , but I can't accept this one. I would offer that totally missing required data is a bigger problem, like the client not realizing they need an email address too, and the analyst not having the techniques to expose that need.
As to the issue of bad behavior of contractors, either in getting the contract or while doing the work, I do not offer anything unique, except maybe this question: what would be the impact on everyone's behaviors of actually have correct and detailed requirements up front without taking months to do it? You may not believe that is possible, perhaps a different article will be needed, but do consider it and offer your thoughts for further discussion.
Dear David, it's interesting for me to see how different your experiences are compared to my ones. The phone number example is a good one for this: I have seen a lot of requirements of this kind. In most cases they don't lead to any serious problems, but some do. You are right: Experienced analysts should detect the missing qualitiv requirements of this functional requirement. But: 1. Such a detailed specification up front can extend the up-front-phase of a project to several years (I have seen such long requirements-elication-phases); at the meantime, many requirements are often obsolete. 2. A heavy-weight up-front-phase instead of a more agile-iterative approach encourages the stakeholders to overload the specification with nice-to-have requirements they don't really need at the end.
Good article, lots of nodding heads from this side......but.....a contract is a contract, a customer has to protect themselves somehow and fixed price contracts provide protection in law if things go pear shaped. It seems the compromise is that a contract needs to be part fixed price and part time & materials but that's tricky. So what are the value propsitions that can be put to customers to encourage their buy in to a more time & materials type cost structure and contract? Will this just be offset by more punitive damages being included in the terms and conditions?
Dear Paul, thanks for your feedback. You are right: If things go pear-shaped and there is no contract that describes the committed requirements, a costumer has basically no protection in law. But in my experience the protection is very limited, too, if the contract is a fixed price agreement containing detailed requirements. Too many requirements, especially nonfunctional ones, are still too vague to guarantee a positive outcome in court. A combination of both fixed price and time and material agreement seems to be complicated. It even might combine the disadvantages of these two worlds, not their advantages. I think that the best protection is a trustful cooperation between customer und contractor with continuous delivery of results and the right for both parties to cancel the cooperation. There are pitfalls, too. But these are described in the second part of this article, which will be published in the next issue.