I am sure many suppliers struggled at a certain point with questions. 'Can I deliver an Agile project to my customer on fixed priced?'.

In short in my honest opinion, the answer is YES.

In the shortest possible answer, I can come up with is the following. Agile is a delivery method while Fixed Price is a billing method.

So why is would collide? And in fact, it does not.

Before we discuss the rationale and practical approach on what to consider when proposing Agile projects on Fixed Price. Let's look at what is a background for the potential controversy.

For clarity of this discussion, we focus on cases where a supplier takes process responsibility about project delivery, versus a situation where a customer drives the project and just need some resources to its team

We all know the roots of agile projects and what agility means here. Agile projects were in principle brought by representatives of large digital - software companies running its in-house development and wanting to approach faster delivery and flexibility at the same time. As such if we have internal development projects Agile is quite straight forward approach to organizing it, by its origin.

But many businesses use external suppliers/integrators to deliver projects. This means the work has to be contracted and it has to be clear rules on responsibility and billing.

Traditionally contracting assumed two main models. There is a scope and price (Fixed Price) or there is a skills capacity and rate card (Time and Material).

There are of course more models like skills capacity, rate card, and deliverables.

Following above If we do not have scope defined, we not really can provide a Fixed Price offer. Time and Material seems much more appropriate as a billing method for no scope projects.

But customer's procurement departments and decision-makers use external suppliers to drive not only delivery cost under control but also minimize delivery risk by contracting Fixed Price. From their perspective, Fixed Price offers are easier to plan and manage in front of the organization.

On the other side business organizations are attracted by agile fashion and want faster results promise, but we do not necessarily want to take more risk and resign from contracting Fixed Price offers.

This is where the original requirement on Fixed Price - Agile projects starts.

One note here, there are many projects delivered as Agile by suppliers on Time and Material based (and recently we see it more and more as organizations are matured in this space). Especially when the relationship between supplier and customer is strong and there is a lot of trust.

Or simply customer runs the delivery and just adding resources from supplier to its own managed agile projects.

Coming back to main questions can we deliver Agile Projects on Fixed Price? The key role is to understand the scope factor of the projects.

Agile projects define only a very high-level scope (backlog) without initial commitment exactly what will be delivered. Commitment is there but gradually as we progress, but never on the final product. And this is a fact we have to accept.

If we take the scope out of the equation what is left is suppliers’ commitment?

Strictly capacity of skills and methodology. There is no scope of commitment anymore.

From my experience, there are some considerations on how we could approach Agile projects in Statement of Work. Below some suggestions (but not a complete list).

The first point is to understand who is in charge of an agile project. It has to be clearly discussed between parties and clearly stated in SOW.

One note here. Even supplier is in charge of driving the Agile project, there are still roles to be played by customers like product owner. This needs to be in SOW.

It is important to make sure it is clear how scope responsibility is addressed in SOW. If this is clear scope is driven by methodology, we are safe. We should be sensitive to any detailed description of scope in SOW. Of course, project goals and backlog high-level definition is fine.

As a supplier, we should focus on skills and timeframe commitment to customers.

We should have a clear definition of who plays what role.

As always there should be a risk budget planned, best between both parties Customer and Supplier.

Although change is primarily managed by the agile process – I still recommend having a change control process defined. There may be changes within the project environment that cannot be managed by the agile delivery process.