https://t.

me/PrMaB
 www.data-solutions.ch

https://t.me/PrMaB
Content

1. What is this book about?

2. Why agile budgets and contracts?
3. Agile budgeting
3.1 Why do we need a budget?
3.2 Why are budgets a problem?
3.3 Who is creating and managing the budget?
3.4 Cost per iteration, per team?
3.5 How many iterations per team?
3.6 Are there any additional costs?
3.7 How about contingency?
3.8 How reliable is the budget?
3.9 Possible reactions to a budget overrun
4. Agile contracting
4.1 Why do we need a contract?
4.2 What kind of a relationship are you looking for?
4.3 What is an iteration?
4.4 How about scope changes?
4.5 When can I get out of the contract?
4.6 Is it finished?
4.7 What about deliverables?
5. Agile contract models
5.1 Fixed price with fixed scope
5.2 Time and materials with variable scope

https://t.me/PrMaB
 5.3 Capped time and materials with variable scope
5.4 Capped time and materials with fixed scope
5.5 Incremental delivery
5.6 Bonus and penalty
5.7 Fixed profit
5.8 Target cost
6. Conclusion
7. About the author

https://t.me/PrMaB
1. What is this book about?

This book will help you understand why budgets and contracts are crucial
success factors of your agile project. It includes clear budget examples and
contract models to make your life easier when facing the task of creating a
budget or contract for your own agile project.
Whether you are on the client or supplier side, when you are involved in
creating a budgetor contract for an agile project and want to prevent
undesirable outcomes by design, then this book is for you. This book is
particularly useful if you are a:
product owner
project manager
program manager
portfolio manager
contract lawyer
As a warning, this guide is a short crash-course. I don’t explore millions of
different contract models and options. I also don’t focus heavily on the
nuts-and-bolts of budgeting you can find that stuff out from other sources.
This book is not about creating the perfect budget in Excel or drafting the
ideal contract. It’s about creating budgets and contracts that support agile
project management instead of hindering it; it is about contract models that
support collaboration and mutually beneficial relationships, about
understanding where risk is present in agile project management. I focus on
the few things that really matter.
Don’t get distracted by all the people offering agile certifications, agile
coaching, agile books, or agile games when it comes to budgets and
contracts. They may be helpful to improve your Scrum process, your
delivery speed, your team building, your product quality, but most won’t
overcome your failure to fix the common errors that many organizations
make in their budget process and contract writing.

https://t.me/PrMaB
On big projects, none of your agile process details matter if you haven’t
established the economic basics first.

https://t.me/PrMaB
2. Why agile budgets and contracts?

“Plans are worthless. Planning is essential.” ~ Dwight D.

Eisenhower

Most agile project management books focus on quick delivery, team

dynamics, and quality. There’s no need to repeat what they are writing.
There are many great books out there. I am just of the opinion that these
address only a part of the problem with project management.
Many projects are setup to fail from the beginning because of budgeting
and contracting, no matter how good you are at delivering. This is because
many projects pretend at the beginning of the project to be able to look into
the future. What is even worse, people and companies are committing
themselves to such predictions. Fixed scope, fixed price, and fixed time
sound familiar? We should accept that this is just crap and adjust our
budgeting and contracting processes accordingly, on both the client and
supplier side.
This is especially relevant for agile projects, since commonly used budget
processes and contracts actually hinder agile delivery. I know the agile
manifesto says client collaboration over contracts, but it does not say you
do not need contracts at all. And anybody who has worked on larger IT
projects knows that they are a necessary part of the game.
Yes, even when you are not using any external suppliers, you still have
contracts. Your own employee contract, your project charter that you just
presented at your steering committee, and your guaranteed bonus/promotion
when you deliver this project for your manager.
Some numbers can help us understand the size of the problem with project
management, and why many end in lawsuits:
One out of six IT projects has an average cost overrun of 200
percent and a schedule overrun of 70 percent. Around 45 percent of

https://t.me/PrMaB
companies admit that they are unclear about the business objectives
of their IT projects. (Harvard Business Review)
A study of 5,400 large-scale IT projects (projects with initial
budgets greater than $15M) finds that 17 percent of large IT
projects go so badly that they can threaten the very existence of the
company. On average, large IT projects run 45 percent over budget
and 7 percent over time, while delivering 56 percent less value than
predicted. (McKinsey Study)
As per an IBM study, only about 40 percent projects meet budget,
schedule, and quality goals. (Harvard Business Review). We are not
even talking about promised scope!
About 75 percent of IT executives expect their software projects to
fail. (Geneca)
The US economy loses $50-$150 billion because of failed IT
projects every year. (Gallup Business Review)
Around 60 percent of companies do not measure ROI on their
projects. (KPMG New Zealand: Project Management Survey 2010)

https://t.me/PrMaB
3. Agile budgeting

There is a ton of literature and training material about agile estimating and
planning. My personal recommendation would be the book and online
course by Mike Cohn on this topic. But even after this training, it is still
unclear for many how to make the leap from estimations and planning to a
sound budget. This chapter will create the bridge between estimations and
planning and a sound budget. Although my focus is on budgeting for larger
companies, because that is where I have my experiences, I am sure that it
can be useful for smaller companies as well.

3.1 Why do we need a budget?

“Don't tell me what you value, show me your budget, and I'll tell
you what you value.” —Joe Biden

Before starting to work on creating a budget, we have to know why we need

a budget. This sounds logical, but I have seen many cases where this simple
question could not be answered. Why are we actually doing this project?
That is why I use a set of eleven questions that together will help you
answer the big one:
1. Exactly what problem will this project solve? (value proposition)
2. For whom do we solve that problem? (target market, target users,
legal and compliance reasons)
3. How big is the opportunity? (market size, potential savings or
penalties when not done)
4. What alternatives are out there? (competitive landscape, alternative
solutions/products/suppliers, costs of doing nothing)
5. Why are we best suited to pursue this? (our differentiator as a
company or project team)
6. Why now? (market window and urgency)

https://t.me/PrMaB
 7. How will we get this project to go live? (implementation strategy)
8. How will we measure success/make money from this product?
(metrics/revenue strategy)
9. What factors are critical to success? (solution requirements, skill
requirements, budget)
10. What are the main cost drivers? (people, licenses, hardware)
11. Given the above, what’s the recommendation? (go or no-go,
continue or stop)
The answers to the questions above will guide you in creating a budget that
makes sense. It also gives you guidance on scope and timelines. Instead of
setting all these things arbitrarily, use your answers above to define these
parameters. It is like the old service law. Service can be good, fast and
cheap. Pick any two. When your deadline and scope are fixed, you need a
lot of money. When time and budget are fixed, then you can only play with
your scope.

3.2 Why are budgets a problem?

“A budget tells us what we can't afford, but it doesn't keep us from

buying it.” ―William Feather

Did I not just say that we need budgets? We do, but not all budgets are
created equal. The typical large company is organized into cost centers;
each cost center must contribute project spending or people (the primary
cost element) to the new effort. This creates a number of problems,
including:
1. The project budget process is slow and complicated; it takes many
individual budgets (one per cost center) to create the project budget.
2. It drives teams to make detailed decisions far too early in the
project. Teams are forced to come up with plans that are just
guesses; if they can’t identify all the tasks, how can they estimate
how many people are needed, and for how long?

https://t.me/PrMaB
 3. The assignment of project team members is a temporary thing; the
organization assumes people will come back into the cost center for
future assignments. If they don’t, other planned projects will suffer.
4. The model drives cost center managers to make sure everyone is
fully allocated. However, running projects at hundred percent
utilization is an economic disaster. Any small amount of unplanned
work will cause delays, which will be even worse because of time
spent on re-planning.
5. The model prevents individuals and teams from working together
for longer than the duration of just the one project. This has a
negative effect on knowledge acquisition, team performance, and
employee engagement.
Once the project is initiated, the challenges continue. The actual needs of
the business change quickly, and the reality has not much to do anymore
with the assumptions that the project made. However, the projects cannot
adapt to the changing priorities, because their budgets and people are fixed
for the project term.
The result is that the organization is unable to adapt to the changing
business needs without the overhead of re-budgeting and reallocating
personnel. Overhead kicks in; economics suffer. The cost of delay (the cost
of not doing the thing you should be doing) increases.
But we are not done. Software development cannot happen without takings
risks. By its very nature, development is extremely difficult to estimate
because it contains a large degree of technical uncertainty. And everyone
knows that most things take longer than planned. Moreover, even when
things go really well, stakeholders may want more of a specific feature.
That takes longer, too. Again, project-based funding hinders forward
progress, culture, and transparency.
When a schedule overruns for any reason, it is necessary to analyze the
variances, re-budget, and re-plan. Resources are scrambled, and
reassignments of personnel occur. Other projects are negatively impacted.
The “blame game” sets in, pitting project manager against project manager
and financial analysts against the teams. Any project overrun has a

https://t.me/PrMaB
budgetary impact. The casualties are transparency, productivity, and morale.
So ideally you would fund initiatives or larger programs, not single
projects. But the reality in most companies is that funding is on a project
level, so let’s have a look at how this can be done for agile projects, and
start with the first question you will have to ask yourself.

3.3 Who is creating and managing the budget?

Projects are funded in company-specific ways. Usually, a project sponsor

gets funding from a steering committee or the CFO. In other cases, a project
may be funded out of a specific department's budget. In all cases, there is
ultimately a budgetary authority that authorizes predefined or ongoing
spend for a project. Any well-run company has a budget process. This
process includes the delegation of formal authority to someone in the
organization to manage that budget.
On projects that use the Scrum framework, that person should be the
product owner. In Scrum, the product owner is responsible for prioritizing
the deliverables. By extension, this makes the product owner responsible
for the allocation of resources for the project and for creating the initial
budget. Sounds easy, but this alone already poses a challenge for many
companies because the person who gets the role of product owner is
typically somebody who is not allowed to handle a budget. Besides this
challenge there are all the processes around changes in scope tied to a
budget that can only be approved by big groups of people like a steering
committee, making any change very slow and troublesome. Maybe even
dangerous…

“The more people you have to ask for permission, the more
dangerous a project gets.” ―Alain de Botton

3.4 Cost per iteration, per team?

The two fundamental features of Scrum projects are that they will have a
stable team setup and iterations with a fixed duration—for example, two-
week iterations. When you have these two pieces of information, you can

https://t.me/PrMaB
compute the costs per iteration. Sounds simple, but the approach has a few
challenges.
Let’s start with the team composition. We will assume what is typical for
projects in larger companies, which is a mix of internal employees and
external contractors and consultants. For each team member, we will need a
few pieces of information.
Role: Product Owner, ScrumMaster, team member (business analyst,
software engineer, tester).
Daily rate: Most companies will have a fixed daily rate for internal
employees. Based on their level, they will sometimes be different, but
typically there is one rate for all employees that includes all costs. External
employees will have a daily rate specified in their contract and, when
relevant, you should add VAT to this rate to get the real cash-out costs.
When you have not yet fixed the rates of the external employees, you will
have to estimate them. I prefer to take a range and create a low-cost and a
high-cost projection of one iteration.
Allocated time on project: In an ideal world, the team members are
working full time on this project, but this is often not the case. We will have
to determine the percentage of their time that they will be working on this
project.
Burn rate per iteration: This is the cost that this team member will incur
per iteration, under the assumption that he or she will work the agreed
allocated time on the project. I always assume twenty working days per
month for budgeting. In this example, it's ten days per two-week iteration. I
know that people who are allocated 100 percent on the project will not work
260 days a year. Typically this will be around 220 days a year (Switzerland
and other countries will have fewer or more days off).
Internal/External: For computing the cash-out in your budget, you will
need to identify which costs are internal and which are external.
An example of internal and external costs for a team:

https://t.me/PrMaB
When you are budgeting a larger project with multiple Scrum teams, you
just do this exercise for each team. I budget them separately, which means I
will have a line in my budget for each team and do not have a total cost per
iteration. This is because not every team will have the same number of
iterations.
When your project includes project management office (PMO) resources,
such as a chief product owner or a program manager, you can do two
things: create a separate team for them and do exactly the same exercise as
above, or add each one of those resources for a certain percentage to an
existing Scrum team. I have seen both, but I prefer the first one and call the
team "Program Management." This way, it is very clear that they are
managing and not building, and you prevent long discussions regarding
team percentages.
One other team that I have added to some budgets is the Initiation team.
Before everything is in place for a larger project (including a final budget
approval), a small team starts the initiation and elicitation of the project.
And yes, I let this team work in iterations as well. Why?
1. Management is not willing to commit to starting the project without
having a view of the total scope and cost.
2. A business case is required to make a decision whether to go ahead
with the project at all.
3. Multiple stakeholders must agree on the scope of the deliverables
for the project before it is sanctioned.
An example of internal and external costs for multiple teams:

https://t.me/PrMaB
After I have the cost per iteration, per team (including the overhead team, as
shown in the example), I can start the next step.

3.5 How many iterations per team?

There are thousands of articles and videos on agile estimating and planning,
so I will not address how you can do this here. What we will need from
each team for our budget is the number of iterations that are planned. This
can be done by estimating the product backlog and dividing it by the team's
(estimated) velocity. You will not even have to do this for some projects
because the time is fixed, and you know the maximum number of iterations
up front. The overhead team always has the same number of iterations as
the team with the largest number of iterations.
When we have this information, we can compute the total project budget for
each team. When the project runs over multiple calendar years, you will
have to split the numbers by year. This means that you count the iterations
per calendar year for each team.
An example of total project budget for each team:

3.6 Are there any additional costs?

This answer will be "yes" for almost every project. Additional costs are
incurred through local hardware and software for the software engineers
and testers as well as the infrastructure for the final project. Development

https://t.me/PrMaB
environment, test environment, user acceptance testing environment, and
production environment will cost money to buy, set up, and maintain. I do
not allocate these costs to a team when it is not forced by accounting. I will
add a line for hardware, a line for software, and a line for setup costs
(typically an external IT provider or internal IT costs). Other possible costs
are travel (for example, one team is at a different location), workshops, and
training. Again, these are project costs and not team costs.

3.7 How about contingency?

Most companies I have worked for have an obligated percentage of

contingency on top of the total budget, or parts of the budget, that typically
range from 10 percent to 15 percent. Be careful here, because although you
have more money, it is hard to add members to an existing Scrum team.
Therefore, this is only usable for running an additional number of iterations.
So you’d better make sure you do not have a fixed scope / fixed time
contract when working with agile teams.

3.8 How reliable is the budget?

Unfortunately, serious, realistic planning is impossible at the start of a

software project. This is true for conventional and Scrum projects and does
not reflect the team or service provider’s capabilities. It is due to the nature
of complex IT projects.
But unlike in waterfall projects with detailed requirements specifications,
Scrum embraces this impossibility, so the initial estimates in Scrum are not
fixed. They become more realistic over time. As soon as the project starts,
the requirements and general conditions become clearer with every passing
iteration. And by using proven estimation methods and gained experience,
the team becomes better at determining how much a desired feature will
affect the budget. After just a few iterations (which is very early in the
course of a bigger project) the project sponsor has reliable and valid
information about the required budget.

https://t.me/PrMaB
Besides creating a more reliable budget by design as part of the Scrum
process, Scrum projects guarantee transparent budget control on the way.
Cost explosions, which might need to be accepted in a Waterfall project if
you want to actually see your software in the end, can be avoided with
Scrum. The project sponsor will still receive a high-quality software
product, albeit with fewer features than initially planned.

3.9 Possible reactions to a budget overrun

What happens if, after a few iterations, the estimates are much higher than
the initial estimates? Does the project sponsor lose all control over the
budget in Scrum projects? The opposite is actually true. The project sponsor
always has options due to the new, incoming information about the total
budget. This is one of the main advantages of Scrum. Early on in the
project, the project sponsor has functional software containing the most
prioritized functions and offering the greatest benefit. In this case, the
project sponsor has four options:
1. If meeting all requirements is expected to cost more than budgeted,
the project sponsor can abort the project at an early stage. A basic
version of the project is generally released after just a few
iterations.
2. The project sponsor can let the project run until the planned budget
is consumed and then suspend or terminate the project. In any case,
they will have functional software that contains the most important
functions.
3. The project sponsor has the option of changing the project scope by
postponing or omitting less important functions.
4. The project sponsor can increase the budget.
Scrum allows the project sponsor full budget control and thus full flexibility
while reducing the risk of cost explosions because of big-bang
implementations.

https://t.me/PrMaB
4. Agile contracting

“Contract law is essentially a defensive scorched-earth

battleground where the constant question is, “if my business partner
was possessed by a brain-eating monster from beyond space-time
tomorrow, what is the worst thing they could do to me?” —Charles
Stross

4.1 Why do we need a contract?

A contract is a voluntary arrangement between two or more parties that is

enforceable by law as a binding legal agreement. So as soon as there is
more than one party involved in a project, you will need a contract of some
kind. The most rudimentary forms are just a piece of paper with a signature
or an email. In the kind of projects I am typically involved in, there are
usually multiple companies working on the same project: external
consultants, external developers, outsourced infrastructure, third party
software, component suppliers, and so on. This will lead most certainly to a
larger number of different contracts within one project.
As a client or supplier of services at the beginning of a project, you know
better than to work with just a verbal agreement. There is just too much at
stake for both parties. Although the Agile Manifesto values client
collaboration above contracts, contracts are necessary when working with
external suppliers. A contract is just a set of written rules. The right rules
increase the chance of success for both parties. The wrong rules make
working together successfully more difficult.
When working with large companies, there are often standard conditions
that must be accepted to do business with them. These conditions are
seldom fair, so a reasonable project outcome depends heavily on a good
relationship between client and supplier and avoiding recourse to the
contract of law. Because when you have to, typically both parties do not get
what they want.

https://t.me/PrMaB
This is the case with waterfall projects, but even more so for agile projects.
This is because most existing contract types within large companies are not
suitable for agile projects. They do not incentive the supplier to do its
best/fastest work (time & material) or try to put all risk on the supplier
(fixed cost).
The structural and legal aspects of agile project contracts are the same as for
contracts of more traditional development styles. The key difference is the
approach to, and understanding of operational process and delivery and how
this is included in the contract.
An understanding of agile and lean principles is necessary for procurement.
Applying iterative development leads to less risk and exposure, and that
needs to be expressed in the contract. An agile approach enables rapid
incrementally deployable deliverables and collaborative decision-making
between the parties, and so relieves pressure on liability, warranty, and
similar issues.
Do not assume that contract negotiations are less complex for procurement
departments who understand agile principles. It is important to recognize
that contracting is a complicated process, especially in a domain of high
complexity and uncertainty such as software development.
Lawyers must continue to pay close attention to the legal framework that is
necessary to deal with a breakdown of trust and collaboration between
parties.

4.2 What kind of a relationship are you looking for?

Contracts reflect people’s goals and, especially, fears. Successful projects

are not delivered by contracts, but from relationships based on
collaboration, transparency, and trust.
Successful contracts contain rules that support the building of collaboration,
transparency, and trust. As trust develops between the client and supplier,
the contract model should relax and support a better client collaboration
over contract negotiations.
Relationships can be categorized in four different attitudes:

https://t.me/PrMaB
 1. competitive (my win is your loss)
2. cooperative (win - win)
3. indifferent (I do not care - you lose)
4. dependent (heads I win - tails you lose)
These relationships are typically driven by the party who is carrying the risk
of failure. We will discuss this in the next chapter at the hand of our
discussed contract models.

4.3 What is an iteration?

For procurement departments that are new to agile delivery models, it is

important to understand the concept of iteration and what it means in the
context of delivering that which is part of the contract. An iteration can be
summarized as following:
At the end of each two-week (or up to four-week) time boxed iteration,
deliver a deployable system with useful features. It may have insufficient
functionality to be a candidate to deploy, but with each iteration, it is
getting closer to be a deployment candidate.
Incremental delivery is not a new concept in contracts; many identify
intermediate milestones, either fixed by date or by goals with associated
acceptance criteria or a statement of work. The noteworthy differences for
procurement departments regarding iterations and milestones in agile
delivery are doneness and timeboxing. Each iteration delivery is done,
programmed, tested, and so on, and is in theory deployable. Each iteration
is of fixed time but with variable scope.

4.4 How about scope changes?

“It does not take much strength to do things, but it requires a great
deal of strength to decide what to do.” ―Elbert Hubbard

The issue of change is addressed within the overall philosophy of an agile

delivery approach because of a prioritized backlog and adaptive iterative

https://t.me/PrMaB
planning. So no special change-management process, board, or request
mechanism is needed. It is critical for procurement departments to remove
old change-management language from contracts because such language
typically blocks working agile.
Change in project scope requires the most attention in an agile contract in
order to make change easy and frequent in the collaboration between client
and supplier. Avoid mandating change-management boards, change
requests, or special change processes.
But, as with project scope, there are variations in change-management
flexibility, ranging from high flexibility without penalty when using flexible
scope contracts, to medium flexibility with shared gain/pain when using
target-cost models.

4.5 When can I get out of the contract?

The concept of termination is an important one in an agile project. It should

be possible to change the direction of the project (scope, supplier,
technology) to the point of actually stopping further effort at the end of any
iteration. In contrast to conventional project thinking, procurement
departments need to understand that early termination should be viewed as
a positive, desirable event in an agile project, because early termination
does not automatically mean failure. It can mean that success was achieved
quickly. Learning fast that the path taken is the wrong one is also a success.
Sunk costs are minimized.
Arguably the ideal termination model in an agile contract is to allow the
client to stop, without penalty, at the end of any iteration. Naturally, if the
supplier has dedicated hundred people for an anticipated two years, and
termination is unexpectedly much earlier, they likely have an expensive
problem on their hands. Hence possible contract rules include a sliding
scale of penalty to the client that reduces over time (and iterations).
Termination can be one of the most difficult areas to negotiate in any
contract. The key mitigating differences in an agile approach are that (1) the
client has a working system at the end of each iteration, and (2) both parties

https://t.me/PrMaB
will have clear and up-to-date views on the state of the deliverable. These
are crucial points for procurement departments to grasp.

4.6 Is it finished?

“Is it finished?”- “What to do if not finished?” - “We have now decided to

change our minds and reject the iteration delivery from three iterations ago.
Do you mind?”
These are vital questions in outsourced project work, and unclarity around
such issues is a possible source of conflict and litigation. Clarity regarding
finished, acceptance, and correction both in the minds of the parties and the
contract language is an important issue to address for procurement
departments. They can help considerably in negotiating a contractual
framework for acceptance that encourages collaboration.
Acceptance still exists, but is much simplified because of iterative delivery
and acceptance, and because acceptance is incremental and adaptively
agreed upon for each iteration. Further, agile practices usually include
highly automated acceptance testing so that little or no manual (human)
effort is required for validation.
Acceptance builds upon itself such that the final acceptance is the
culmination of a number of acceptances that have occurred throughout the
life cycle of the project, ideally most being repeatedly verified with
automated acceptance tests. In terms of contract work, this means that
acceptance definition and negotiation does not have to be a massive
comprehensive exercise; only the framework for acceptance must be
contractually clear.
Broadly, for each iteration, acceptance is based on conformance to a prior
agreed-on acceptance-test set, and in the case of Scrum, in conformance
with the “definition of done.”
Another element of acceptance in agile development worth considering in
the contract framework is to include candidate users of the new system in
the definition of acceptance and acceptance testing. Procurement
departments concerned with a successful project should ask, “Are the right

https://t.me/PrMaB
people, i.e. the hands-on users, involved in acceptance, and at each iteration
are they collaborating with the supplier?”

4.7 What about deliverables?

Traditional project contracts often include a detailed, prescriptive list of

what should be delivered. Typically a lot of different documents. These
details are sometimes embodied in a statement-of-work or “quality plan”
appendix. You should avoid such detailed deliverables list in the contract.
This only leads to an increase in waste activities rather than a focus on
working software, and there is a presumption, possibly untrue, of knowing
what artifacts are valuable. Besides that, it makes the assumption that a
fully defined system can be predictably ordered and delivered as though it
was a burger in a fast food restaurant rather than creative discovery work.
Discovery of valuable deliverables can be more simply achieved through
frequent incremental delivery and deployment, rather than through a
contract deliverables list.
What you should never forget, however, is the source code of custom
software. I have been on multiple projects where this has become an issue.
Especially when all development is done at the location of the supplier, and
not the client. Your procurement department should also think about the
source code of products you buy in the case the supplier goes bust. Escrow
is your savior.
On occasion, technical documentation to support maintenance is valuable,
usually as a learning aid for people new to the system, and its delivery is
often specified in a traditional project contract. Yet, maintenance of a
recently deployed system is frequently outsourced to the same people that
created the system and so they have less need for such documentation.
Therefore, it could be wasteful to require it as an early deliverable. If, at
some future time, there is a demonstrated need for documentation for the
client (for instance, if the client takes over the maintenance work), then it
can be created by the supplier, perhaps in a joint agile documentation
workshop with the client after the system is finished.

https://t.me/PrMaB
5. Agile contract models

“A valid contract requires voluntary offer, acceptance, and

consideration.” —Robert Higgs

This chapter will discuss a number of different contract models by using

hands-on examples. The eight contract models we discuss are:
1. Fixed price with fixed scope
2. Time and materials with variable scope
3. Capped time and materials with variable scope
4. Capped time and materials with fixed scope
5. Incremental delivery
6. Bonus and penalty
7. Fixed profit
8. Target cost
For each model, we discuss scope changes, risk, termination and
client/supplier relationship. I can really advise you to have a look at the
different forms and think about this before you structure or sign your next
contract. You can combine many elements of them into the model that is
most suitable for your specific situation.
Before we discuss the different contract models, I would like to talk about
the concept of an iteration contract. This concept is helpful in understanding
the relationship between product owner and implementation team. This is
not really a commercial contract, but simply the agreement between the
product owner and the team for one iteration.
The implementation team agrees to do its best to deliver an agreed set of
features (scope) to a defined quality standard by the end of the iteration.
Ideally, they deliver what was promised, or even a bit more. The product
owner agrees not to change his instructions before the end of the iteration.

https://t.me/PrMaB
So a Scrum project is simply a series of mini projects with fixed
parameters:
Time: iteration length
Scope: iteration backlog
Quality: definition of done
Cost: team size * iteration length
Without exception, you can apply this concept within any of the following
contract models.
All contract models will be explained at the hand of one simple example. A
project with around 110 person days of work, the daily rate is $ 1500, and
the profit margin of the supplier on this rate is 20 percent, i.e. they earn $
300 on every person day sold for $ 1500.

5.1 Fixed price with fixed scope

Agree on the deliverables, and deliver it. Send a bill. Clients like fixed price
projects because it gives them a sense of security (or at least they think so).

https://t.me/PrMaB
Scope changes would lead to a change of contract and new negotiations.
Very inflexible. Termination is typically at delivery of full scope, or after
the client has paid the penalty to get out early.
Obvious risk is on the side of the supplier. If the estimates are wrong, the
project will lose money. Less obvious risks are the change request game,
through which the supplier negotiates additional revenue through scope
changes. If the supplier had badly underestimated the effort or quoted an
unrealistically low price, the losses could threaten the existence of the
supplier, which also represents a problem to the client.
The relationship between client and supplier is competitive to indifferent.
The client generally wants to have more, and the supplier wants to do less.
The supplier wants the client to be happy, so usually the supplier yields.
The word “et cetera” is very dangerous in a specification to a fixed price.
All project managers should be familiar with this kind of type, because
every one of them basically “signs” one when they present their project
charter document to their Steering Committee. Boom, scope, time and
budget fixed…When you are forced to do this, make it a Waterfall project,
because it has nothing to do with agile project management.

5.2 Time and materials with variable scope

Work for a month, then send the client an invoice. Suppliers like it because
the client carries the risk of changing his mind.

https://t.me/PrMaB
Scope changes are not an issue. The client can decide what the supplier
should work on. Every person day is paid.
Termination is as soon as the clients say so, it ends. Typically, with a month
or so upfront.
The risk is carried one hundred percent by the client. The supplier has little
incentive to keep costs down. Effort to ensure that only legitimate effort and
expenses are invoiced can be substantial.
The relationship is indifferent. The supplier is happy when more work
comes because more work means more money.
Recommended for projects where the client can better manage the risk than
the supplier. This is often combined with a cost ceiling, although this can
degenerate into a “heads I win, tails you lose contract” if too much pressure
is applied on the price.

5.3 Capped time and materials with variable scope

https://t.me/PrMaB
Capped time and material contracts work in the sense of traditional time
and material contracts. However, there is an upper limit to how much
customers will have to pay. In this way, suppliers benefit with early time-
frame changes while clients only have to pay up until the capped cost limit
is reached.

Scope changes are not an issue. The client can decide what the supplier
should work on. Every person day is paid.
Termination is as soon as the clients say it ends. Typically with a month or
so upfront.
The biggest risk is that the budget will expire without achieving the
necessary business value for the client. The client won’t get everything he
asks for.
The relationship will be cooperative. The combination of limited budget
and variable scope focuses both client and vendor on achieving the desired
business value within the available budget.
Smart way of handling such contracts is confirming an iteration contract in
writing (e-mail) at the beginning of every iteration.

https://t.me/PrMaB
5.4 Capped time and materials with fixed scope

Capped time and material contracts work the same as traditional fixed price,
fixed scope contracts, except if the vendor gets finished early, the project
costs less, because only actual effort is invoiced.

By a change management process as with fixed scope / fixed price

contracts.
Termination is upon completion, after paying the penalty, or after agreement
of both parties.
This appears to represent the ‘best of both worlds’ from the client’s point of
view. If it requires less effort than expected, it costs less. But once the cost
ceiling has been achieved, it behaves like a fixed price project.
The relationship is a dependent one. From the supplier’s point of view, the
goal is to hit the cost ceiling exactly. There is no incentive for the supplier
to deliver below the maximum budgeted cost. The client has probably
treated the project internally as a fixed price project, and so has no incentive
to renounce scope to save money.

https://t.me/PrMaB
5.5 Incremental delivery

Incremental delivery contracts allow customers to review contracts at

designated points in the contract life cycle. These points are negotiated into
contracts and allow customers to make changes, continue, or terminate the
project. For example, fund quarterly releases and approve additional funds
after each successful release.

New business goal for each release, compatible with a product backlog
prioritized by the product owner.
Both sides can decide to end the collaboration after each phase.
Client’s risk is limited to one-quarter’s worth of development costs.

https://t.me/PrMaB
The relationship will be cooperative. Both the client and the supplier have
an incentive that each release be successful, so that additional funding will
be approved.
This mixes well with capped time and materials with variable scope. You
can specify the release goal, daily rate and cost ceiling in the contract. The
client provided the product owner. Everything else is determined in the
iteration contracts.

5.6 Bonus and penalty

The supplier receives a bonus if the project completes early and pays the
penalty if it arrives late. The amount of bonus or penalty is a function of the
delay. Often applied for construction projects, e.g., roads, tunnels, and
runways, for which it works well. Scope changes are not an issue, and
genuine economic costs drive the client to achieve the deadline as well.
With IT projects, this is a sure setup for lawsuits.

Changes: difficult to accept because changes potentially impact the delivery

date, which is surely not allowed.

https://t.me/PrMaB
Does the client have an incentive for early completion? The ROI arguments
must be compelling and transparent. Otherwise, the client gets a cheaper
solution the longer it takes.
Could be cooperative, but might degenerate into indifferent if the client
does not truly need the software by the date agreed.

5.7 Fixed profit

Any project budget consists of effective costs and profit. The parties agree
on the profit margin in advance, e.g., 20 percent. The client can back out
after “any iteration” by paying a cancellation fee of the profit part of the
remaining effort.

Can be variable - it is possible to finish early. This only works with agile
development, because only agile methods deliver software incrementally.
Risk is shared. If project finishes early, the client pays less, but the supplier
still has his profit. If the project exceeds budget, the client pays more, but
the supplier does not earn additional profit. After the target delivery date,
the supplier may not invoice any more profit, just cover his costs.

https://t.me/PrMaB
Cooperative - both have a clear incentive to finish early. The client saves
money, and the supplier has a higher profit margin.

5.8 Target cost

In target cost contracts, parties involved with the contracts agree on a final
price during negotiation. These contracts allow cost savings for both parties
if contracts run below budget, but also allows both parties to be faced with
additional costs if contracts run above budget. This is a combination of
several approaches. Work is basically on a time and materials basis with a
cost target. However, the intention is that the project will not use up the
entire project budget. After a certain amount of functionality has been
delivered, the client should realize that enough business value has been
realized that further development is not necessary and can, therefore, cancel
the project. A cancellation fee equal to the remaining profit is due.

Can be changed. Planned but unimplemented features can be replaced with

other stories of the same size. Additional features cost extra.

https://t.me/PrMaB
Risk is shared. Both parties have an interest in completing the project early.
Client has lower costs; supplier has a higher margin.
Cooperative - both have a clear incentive to finish early. The client saves
money, and the supplier has a higher profit margin.
If the budget is exceeded, the rules of the fixed profit or cost ceiling
contracts can be applied. The fixed profit approach is more consistent with
the goal of fostering a cooperative relationship.

https://t.me/PrMaB
6. Conclusion

In order to run your project in an agile way, you have to make sure your
budget and your contracts support the way you want to run it. There is no
one size fits all, but in general, you can say that reserving a budget, but
releasing it to the team on a sprint to sprint or quarterly basis works very
well for bigger projects.
For very large projects, the first thing I would advise to do is split it up into
smaller projects. Large projects have the tendency to fail, no matter how
you run them, and it is impossible to focus efforts when the project has fifty
plus parallel deliverables planned. In almost all cases, it is unnecessary to
run one very large project. Keep your efforts manageable and focused.
For new technology projects and products, make sure you run a proof of
concept/prototype project first. Sunk costs in the case of failure are far
much lower, and cost of delay are much lower in the case of success.
Regarding contracts, I am a big fan of the target cost and incremental
delivery models. Of course other models can work well depending on the
situation. But no matter what you do, I would advise using iteration
contracts when you work in an agile way. They can be informal short
emails, but it sets expectations for all parties involved, and this is never a
bad thing.

https://t.me/PrMaB
7. About the author

Henrico Dolfing has been a project rescue consultant for almost a decade.
His company Data Solutions advises companies in the financial sector on
large IT projects.
His expertise in software development and experience with agile processes
and techniques allows him to rescue projects that are in critical phases on
the verge of failure and lead them back to success.
Born in the Netherlands, one of the flattest countries in the world, Henrico
spends all his spare time in the Swiss mountains enjoying alpine marathons,
climbing, downhill mountain biking, river rafting or leisurely hikes with his
wife.
Connect with Henrico on LinkedIn or Email
LinkedIn: http://ch.linkedin.com/in/henricodolfing
Email: henrico.dolfing@data-solutions.ch

https://t.me/PrMaB