Agile Fixed Price Projects part 1:

“The Price Is Right”

Pascal Van Cauwenberghe
Nayima
pvc at nayima.be

Introduction always sue! Of course, if the customer really

needs the software on the given date, they
When I talk about Agile Software Development too are in trouble.
methods [Highsmith 2002] and Extreme • Customers think they take no financial
Programming [Beck 1999], the remark I get risk as the price is known beforehand.
most often is: “That will never work!” The only However, surprisingly many “fixed price”
reply I can give is: “It works for me”. The projects cost more than initially agreed
second-most often heard remark is “I can’t do upon. We’ll see later how this can happen.
that, I have to do fixed-price contracts!” My • The defined, planned and sequential
reply to that is a bit more involved. This two- project flow gives the customers a warm,
part article contains my reply, so that maybe safe feeling of control. Until near the end of
next time I will get some different remarks. the project, when these projects so often
This article describes an approach to fixed-price “suddenly” start to fail.
projects using a classical, “rigorous” process. This type of contract is almost universally hated
There are three phases in the process: and feared by software providers because of
qualifying, selling and implementing the their high financial and functional risk and their
project. This text provides some tips for each of low success rates. The contract seems to protect
the phases: the customer at the expense of the provider.
• First of all, I have to decide if a project
can reasonably be done under a fixed-price Do you have what it takes?
contract. This text contains some questions
I ask myself to (dis)qualify projects. What does it take to be successful project
manager of such a project? I and my team will
• If I decide to go for the project, I still need
enter into an FP contract if
to win the project. The sales process is
crucial to set up the right conditions for We can fully specify, estimate and plan the
implementing the project. The sales tips project.
allow me to remove some major
implementation risks before the project We can deliver the product exactly as agreed,
starts. within some small tolerance.
• When I’ve won a contract with the right Do you fail one or both of these criteria? Why
conditions, I can implement and deliver the would you enter into an FP contract? You will
project, using the implementation tips in very likely lose money and your customer.
this text. You are not alone: according to the “Standish
All of these techniques have been applied on Group Chaos report” [Johnson 2001], 72% of
succesful fixed-price projects. How do I know projects fail to deliver what was originally
they were successful? Because, given the choice, specified, in the agreed time and on budget.
everyone involved would do the next project the Read this text to get some tips to learn how to
same way. evaluate and satisfy the criteria. And don’t do FP
A fixed price contract contracts until you get the risk under control!

A fixed-price (FP) contract between a provider

and a customer defines the scope, features,
planning, timing and price of a software project.
Pretty much everything is fixed, not only the
price.
Why do customers so often demand “FP”
contracts?
• If projects are awarded after a multi-
provider bidding process, the customer
needs to know scope, timing and price to
choose between the bids.
• Customers think that they take no
functional risk: if the provider does not
deliver on time or on spec, the customer can

v4.2 Agile Fixed Price Projects part 1 p. 1

The following questions refine the conditions, freshly assembled for the project, expect to lose
which are necessary for me to make these time building a team and forget about estimating
statements. their performance accurately.
Question 1: Do I know the domain? Add newcomers to a team one by one, to teams
of experienced people.
I can’t specify, estimate and produce a software
product well enough if it’s in some domain I’ve Don’t count on them to add much to the project,
never worked in before. That would be too much at first.
to ask.
I need to know the domain well to be able to Question 4: Can I handle the
specify the project: I need to understand the estimated project size?
language and problems of the customer; I need
Am I comfortable with the length of the
to know where to get more information; I must
project? If I’m used to doing projects shorter
be able to devise solutions and explain them to
than 6 months, I will be taking a huge risk when
the customer. I must be able to help the customer
I take on projects of 1 year or longer. If the
to draw up a complete specification by asking
project is longer
questions like: “Do you need feature X? The
customers in the four previous projects in your • There are more requirements to analyze,
domain all required X”. estimate and plan.
I need to have experience in the domain to • Planning and estimation errors become
estimate correctly enough: I use actual effort larger, as the estimations of the later parts
measurements of earlier similar projects; I must of the project are based on the correctness
be able to distinguish between what’s of those of the earlier parts
comparable and different between this and • Changes in requirements become more
previous projects; I must have experience with likely and more necessary as the
the common risks of the domain. environment of the system changes.
I need to know the domain to execute the project Am I comfortable with the number of people
well: most of the project should be the on the project? Managing a team of 50 is
application of known techniques, with as few as fundamentally different from managing a team
possible original problems and solutions; I of 5. If the team is larger
expect to be able to foresee and handle most of • Communication overhead becomes larger
the risks in the project. (relative to the square of the number of
people)
Question 2: Do I know the • Misunderstandings and
technology? miscommunication become more frequent
• More effort has to be spent dividing and
I need to be familiar with the execution
synchronizing the work
environment (computer and operating systems),
• It becomes harder to find shared vision
the programming language, the tools and the
and values
development process. I don’t experiment or use
• Change becomes harder as we have to
“bleeding edge” technology on FP projects, only
boring bread-and-butter methods and tools that I convince more people
know and master perfectly. Bigger projects require more time and/or more
people. Longer projects and larger teams are less
Question 3: Can I work with my usual efficient than shorter projects and smaller teams,
team? because the effects of size are not linear.

The most important variable is the development Sales tip 1: Don’t just respond to
team. What’s the use in knowing that last time RFPs
we implemented some feature in 20 days with
team X, if team Y implements this project? How Customers often look for a provider for a fixed-
quickly and how well will team Y implement price project by sending out a “Request For
this same feature? I have no idea, unless I’ve Proposal” document. The RFP contains a
worked with them on similar projects. description of a problem to be solved. Providers
Team performance depends for a part on the who wish to implement a solution, have to
respond with a written proposal containing a
talent and experience of its members.
Performance depends a lot more on how well specification, timing, planning and price. The
these people work together. If a team works well customer then chooses the provider with the best
together, has a “rhythm” and knows its “pace”, proposal, according to their own criteria.
you can predict with some accuracy how they This customer has, most likely, been helped to
will perform. If the “team” is a bunch of people write this document by one of your competitors.

v4.2 Agile Fixed Price Projects part 1 p. 2

As a result, RFPs, which should be open-ended, project will take, how much it will cost. Thus, I
typically have a concrete solution in mind: your can compute a price that allows me to recoup my
competitor’s solution. And, in any case, these costs and make some decent profit.
RFPs are always incomplete. If you’re in competition to get the project, it will
Just responding with a proposal document is not be tempting to lower your price, planning to go
very likely to win you the deal. Even worse: you over budget anyway. This extra billing might
might win the deal, but if you base your compensate for the loss you make on the initial
specification, planning and estimate upon this bid.
biased and incomplete RFP, your project will I don’t enter into a contract that is unfair to me
most likely fail. and I don’t try to correct this unfairness by not
I go and talk to the customer, ask questions, get giving the customer what was agreed. That
some more information, get the answers that are would a great way to start a business
not in the document, establish a rapport, try to relationship…
steer them away from the solutions already Do I tell my team that their target is not feasible?
envisioned with my competitor during the Do I tell them that I expect them to fail? That
drafting of the RFP. would be a great way to motivate them…
If they won’t talk to me, answer my questions or And it doesn’t work anyway, because
clarify their wishes now, I don’t make a “Implementation tip 1: Don’t allow change
proposal. I don’t have enough information to requests” doesn’t allow me to increase the
work on. Even if I could win the project, how budget. It’s a fixed price contract, remember?
likely is it that I will communicate better during
the project? Sales tip 4: Add some slack to cover
the risks
Sales tip 2: It works both ways
I have to admit it: I can’t specify, estimate,
A fixed-price contract is a contract between two plan and execute a project perfectly. It’s a
parties for their mutual benefit. Both parties useful and reassuring simplification, but I’m
have rights and responsibilities and these must hardly perfect. For projects in a known domain
be divided fairly between the two parties. If and environment, with a known team and of the
either of the parties does not feel treated fairly, I usual size I can get close. But I know I will
don’t enter into the contract. The contract should make mistakes before and during the project.
clearly state the responsibilities of both parties. There are factors related to the customer that
E.g. the customer should deliver some can’t be controlled: how well will they respect
information by a certain date, provide testing their commitments, how well have they specified
feedback within a certain timeframe… The what they needed, how high are the odds that the
provider should deliver some functionality by a requirements will have to change…?
certain date, make the product comply with Then there are the “forces of nature” that I have
certain quality criteria…. no control over: people will get sick, computers
More important than the contract is the working will throw tantrums, and other jobs will need to
relationship of the customer and the provider: be done urgently….
• Is there a good level of communication? All of these foreseen events and many more
• Do both parties trust each other? unforeseen ones are the “risks” of the project. I
• Are both parties willing to perform their try to enumerate and quantify the risks, the odds
part of the job? of their happening, and the cost of avoiding or
• Does everyone realize the commitment mitigating them. And then I add some more for
they are making? Do both parties have the unforeseen risks. I add a few percent “slack” to
necessary time, knowledge and authority to the estimates (and thus the planning, timing and
do their job well? budget) to cope with all these risks.
• Is there a willingness to solve the How much slack do you need to add? I’ve added
problems that will inevitably arise? between 10% (for predictable, short projects for
• Is everyone committed to making a known, professional customers) and 30% of the
success of this project? original estimates. If I feel I need more slack
One of the most important tasks during the sales than that, this project is probably too risky to do
process is to set up this working relationship. If under a standard fixed-price contract.
you fail to do that, you’ve just added a huge risk I don’t cut slack to underbid a competitor,
to your project. because I will need it during the project, if I’m
paid for it or not.
Sales tip 3: Don’t underbid
I can estimate a project perfectly (for some
definition of “perfect”): I know how long the

v4.2 Agile Fixed Price Projects part 1 p. 3

Sales tip 5: Real business • The provider gets to bill more than
requirements budgeted, which makes the provider’s CEO
and CFO happy.
I write the specification together with the But there are many drawbacks:
customer. If they don’t have enough time to • The changes disrupt the orderly flow of
discuss, review and improve the specification, I the project, making the development team
don’t bid for the project: if the project is not less efficient. Team members get
important enough to specify and plan well, it’s demoralized when feature lists and planning
not important enough to implement it. are in a state of flux and completion dates
Each item of the specification, each feature (or slip.
use case or user story) must comply with the • It’s more difficult to schedule and
following criteria: synchronize with other projects, as there’s
• The description of the feature must be no way to predict when this job will be
fully understood by the customer and by the finished.
development team. The description uses a • The disputes preceding the change request
vocabulary that is familiar to the customer, (“It’s in the spec! No, it’s not! Yes, it is…”)
no technical mumbo-jumbo! and the haggling over estimates and extra
• The feature must add some business cost poison the relation of the provider with
value. The customers must understand why the customer. All of this nasty commercial
this feature is included, what value it will negotiation stuff should have been finished
provide. before the project started.
• The feature must be verifiable by the • Change requests invariably lead to
customer. At some point I have to ask the dissatisfaction of the customer as the
customer “Is this requirement met? Yes or budget and timing creep. How does a
no?” If we’ve defined the acceptance project get to be late and over budget? One
criteria beforehand, I can be confident that I change request at a time. Welcome to the
will get a “Yes”. “challenged projects” category!
I leave the technical details out of the customer’s The problem with change requests is that their
specification; they’re only used within the negative effects only show up after a delay.
development team. The specification should be Responsibility for the project at the customer is
as brief as possible, so that we don’t need to typically shared between a project manager
spend an inordinate amount of work writing it. (with authority over functional matters) and the
The specification should describe the finance manager (with authority over budgets).
requirements with “enough” precision: just The project manager agrees with every small
enough to be able to understand, estimate, change request and is happy to see more
implement the requirement and to evaluate if the functionality added. The finance manager only
implementation meets the requirement. sees a large budget overrun at the end of the
billing period. The end users only see that the
Implementation tip 1: Don’t allow product is not delivered on time. By the time the
change requests negative effects appear, it’s too late to do
Change Requests are a well-known tool used by anything about it. And so, a lot of yelling and
most project managers. If a customer wants recriminations ensue… Which makes everybody
something that’s not in the original specification, unhappy.
their project manager can fill in a “Change Don’t use Change Requests because their
Request” form, which describes the change. drawbacks heavily outweigh any initial
Based on this information, the provider’s project advantages they bring.
manager can estimate the extra work and cost
required. If the customer agrees with the When I explain this rule, older, wiser, more
estimate, the extra work is performed. The cost experienced and more cynical people invariably
of this work is added to the final bill, the extra point out to me: “You’ll never get rich this way!”
time is added to the planning. Change Requests seem to be a standard
Change requests have the following advantages: technique to make customers pay more than
• They allow the customer to steer the agreed.
scope of the project, use the knowledge I’m not rich, so I guess they are right. But is a
they have gained during the project and project manager who brings in twice the amount
correct any mistakes made during the initial budgeted, by delivering late, a success or a
specification phase. failure? The use of “Exchange Requests”,
explained in the follow-up article, can deliver
the flexibility of change requests, without the
negative effects upon schedule and budget.

v4.2 Agile Fixed Price Projects part 1 p. 4

Implementation tip 2: Spend your not. The team and the customer only need to
slack wisely know two things:
• Will we be able to deliver as promised?
Thanks to “Sales tip 4: Add some slack to cover • If not, what can we do to get back on
the risk”, the project has been allotted more days track?
than strictly necessary. I use this extra time
sparingly. I try to resist the temptation to “slack
off” because there’s ample time left. When do I
spend slack?
• Something goes wrong: a team member
get sick, a tool doesn’t work as advertised,
the database crashes, the computers refuse
to work, some risk materializes…
Accidents happen, some of the slack must
be spent to handle the problem.
• An estimate is too low. If a job takes 2
days more than estimated, I take 2 days out
of the “slack piggy bank”.
A simple and effective method is to have a
• The specification was wrong or can be “burndown chart” or “backlog chart” [Schwaber
improved. I spend a small amount of slack 2002]. This essentially plots the amount of
to do the extra work required, so that we
effort left versus time. Each time a feature is
can avoid “change requests” or other
finished, we reduce the “amount of effort left”
actions that increase timing and budget. The
by the effort estimated for that feature. Any child
customer appreciates it if I spend my
can see how we’re doing. This chart is easily
precious time on improving his system.
updated and should be visible to all project
• Something unforeseen happens. I can try participants, as an “information radiator”
to foresee and avoid all possible risks and [Cockburn 2002]. If anyone wants to know “Are
still some unforeseen ones crop up. I’m we there yet?” they just have to look at the chart.
constantly on the lookout for these events It’s important to only count fully completed,
and use some of my slack time to nip them tested and “ready for acceptance” features. This
in the bud. keeps me from deluding myself with statements
Sometimes things turn out better than expected, like “the feature is 80% finished”. A feature is
jobs get finished faster than estimated. Put the either done (and acceptable for the customer) or
time you gained back into your “slack piggy not done. This guarantees that the tracking
bank”. represents real progress.
The plan is just a plan; the only important thing
Imagine a 19th century engineer keeping a steam is the delivery of the project. I don’t care about
engine running. The project is like a beautiful deviations, as long as the goal of delivering is
machine, lovingly built, gleaming clean and in not jeopardized. For example: if I have two
perfect working order; slack is like a small can features, each estimated at 5 days, I don’t worry
of lubricating oil. A few drops of oil here and if one takes 4 days and the other takes 6 days.
there do wonders to keep the machine running Sure, I didn’t follow the plan, but I’m still on
smoothly. At his best, the engineer is completely target to deliver as planned. The plan gets
attuned to the machine and seems almost modified to reflect reality, but always with the
prescient, lubricating the parts before they start same goal: to deliver the project as promised.
creaking. On the other hand, no amount of We can also record how long each feature took
lubrication is going to keep a badly maintained, to implement. This allows us to calibrate the
sloppily built and over-stressed machine doing team’s speed and to improve the estimates for
useful work. the following project.
Implementation tip 3: Simple, honest Implementation tip 4: Manage your
and correct tracking project
During the course of the project, I need to track If the requirements have been established, the
my team’s progress. Are we behind or ahead of effort has been estimated and the project has
schedule? Will we be able to deliver as been planned the hardest part is over, right? The
promised? Do we need to take some corrective rest is just implementation: following the plan.
action? It all sounds very complicated and time- No. A project manager’s job is to manage the
consuming. There are all of these wonderful, project. What does that entail?
expensive and complicated tools I can use. Do I
really spend a lot of time tracking? Of course

v4.2 Agile Fixed Price Projects part 1 p. 5

 • I’m aware of a lot of risks that the team parameters as possible constant from one project
runs. I’ve prepared ways to avoid the risks, to the other.
devised contingency plans and stored some It all sounds very boring: “been there, done
amount of “slack” to deal with them. that!” It’s not boring at all, because each
• I’m constantly on the lookout for new, customer, each problem and each project is in
unforeseen problems. Whenever one rears some way unique and will bring some
it’s ugly little head, we nip it in the bud. unexpected events to tax my project
• If the tracking shows we are getting into management skills.
trouble, the team and the customer know it This type of project is what Jim Highsmith calls
and we find and solve the problem. an “Optimization” project [Highsmith 2002]:
performing a well-known activity as efficiently
The job is not about specifying, estimating and as possible by reducing the risks. This type of
planning perfectly. project works best with a “Rigorous Software
The job is to deliver what the customer needs. Methodology”: a method whose main method of
dealing with risk is to reduce or eliminate it.
If we extend the rugby metaphor of the From the description, this looks like a relatively
“SCRUM” method [Schwaber 2002], the team’s narrow category of projects. The further we
goal is to score the touchdown. We’re always on deviate from the low risk ideal, the more
the lookout for adversaries threatening our dangerous a fixed-price contract becomes for the
progress. Everything that gets in the way of the provider and the customer. The next article will
team gets tackled. We don’t care who scores the describe some techniques that are more suited to
touchdown, as long as the team scores. The “Exploratory” projects, where risks are higher.
project manager (or “scrum master”) is I use these techniques to extend the range of
responsible to get all obstacles out of the way. projects that can be handled with fixed-price
contracts.
Attack your risks or they will attack you
Conclusion
Some people think the project manager should
shield the team from every outside influence that Fixed-price contracts fix scope, timing, planning
might impede their progress. For example: and price of a software project. They represent a
“developers should not talk to the customer, lest high risk for the software provider and for the
they get confused”. On the contrary, involve the customer, even though they seem to shield the
team in discussions with the customer about customer from all risks.
functionality and let them avoid and mitigate These contracts can only safely be entered into
risks and solve problems. The job of the project for low-risk “Optimization”-type projects.
manager is not to solve all problems and shield We’ve seen a few selection criteria that allow
the team, but to ensure that the problems get me to (dis)qualify a project for implementation
solved. under a fixed-price contract. If the project
qualifies, we can apply the sales and
Don’t shield the team. implementation tips, which allow us to reduce
Help them to avoid and solve problems. certain project risks.
If the project does not fit the Optimization
With all of these tasks, the job of a project model, it should not be executed under a fixed-
manager looks quite hectic. It isn’t, unless it’s price contract with the process described in this
done badly. A good project manager is proactive text. The next article describes some techniques
and solves most problems before they become to handle projects with higher risks under a
apparent; which still leaves enough problems to fixed-price contract.
fill a full working day. If problems grow and
fester, the job becomes a lot harder. References
Good project managers don’t seem to do a lot [Beck 1999] “Extreme Programming
and lead pretty uneventful lives. Explained”, Kent Beck – Addison Wesley 1999
[Cockburn 2002] “Agile Software
What kind of project is this? Development”, Alistair Cockburn – Addison
Wesley
If we review all the tips what are the recurring [Highsmith 2002] “Agile Software Development
themes? I’ve done this type of project, in this Ecosystems”, Jim Highsmith – Addison Wesley
type of environment, with my team a thousand 2002
times before. I can look back on several similar [Johnson 2002] “Collaborating on Project
projects for experience, domain knowledge and Success”, Jim Johnson, Karen D. Boucher, Kyle
actual performance measurements. I do my best Connors, and James Robinson – Software
to minimize the risks and to keep as many Magazine February/March 2001. Online at

v4.2 Agile Fixed Price Projects part 1 p. 6

http://www.softwaremag.com/archive/2001feb/C
ollaborativeMgt.html
[Schwaber 2002] “Agile Software Development
with SCRUM”, Ken Schwaber and Mike Beedle
- Prentice Hall 2002

v4.2 Agile Fixed Price Projects part 1 p. 7