Buying and Selling Agile Projects

When talking about agile projects many books seems to be written under the assumption that you work with the whole life cycle, from its initial conception to maintenance and support of the system. But quite often, parts of the project are done by another supplier. This other supplier may have a different underlying motivation and his business may not be the same. The most common price unit in knowledge-based work is probably price per hour, direct or indirect. The buyer’s income model is probably different; it may be based on cost savings, or on either revenue from or new opportunities emerging from the product (or transaction), or interval based, such as price per month. Therefore, a built-in conflict may exist between the revenue model for the buyer and that of the supplier.

 

Who should take the commercial risk?

The buyer can handle the project on their own and just hire or contract some consultants that will work on a per-hour basis, in which case the full risk remains with the buyer.  Or the buyer can outsource a part of the project to a supplier, who also takes an agreed-upon portion of the risk as part of the deal.

 

This is often handled with a requirement phase that produces a requirement document that one or more suppliers use to develop a bid for winning the contract from the buyer. The contracts often include the total cost, some options (often add-ons) and a time when the delivery shall be done.

 

The problem with this is that it doesn’t facilitate changes and the flexibility to apply knowledge that you gain during the project very easily. When the project starts, keeping to the original plan becomes more important for both parties instead of maximizing the business value. This prevents either party from incurring cost or schedule overruns that could turn their side of the contract into a losing proposition.

This inflexibility negates the benefits of agile development projects, which are adaptive so as to maximize business value. But there are alternatives to fixed-scope/fix-price types of contracts. I will talk about different kinds of contracts soon but first I would like to explain maximal value focused.

Maximal Business Value

Maximizing business valueIf we only have an idea of what might create the benefit we expect from a specific software solution, it’s hard to create an accurate detailed plan of how to reach that goal. Complex projects have multiple solutions; there is no one BEST way to run a software project. We can’t predict the best solutions. But, if we conduct the project like an exploratory journey looking for the best opportunities that appear to us along the way, we stand a better chance to maximize the business value. This is because whoever undertakes the project is likely to never have done this kind of work before. This kind of work must focus on knowledge acquisition and making the best out of the current situation. At the same time, the project must remain on target toward the long-term grand vision of what is going to give the customer the competitive advantage he is seeking.

 

The Pareto Principle

The Pareto principle (also known as the 80-20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. It is a common rule of thumb in business; e.g., “80% of your sales come from 20% of your clients”.

Pareto's Principle

In order to be able to correctly analyze a project as the buyer, an effective approach may be for the supplier to first show how they have estimated the work, followed by a dialog between the buyer and supplier. When doing upfront design of a large scale project, it’s quite common that requirements are finalized and prioritized before the supplier has estimated them. But how can you know whether it costs more than it tastes before the estimate? Showing how estimation is done is therefore something that creates trust between both parties. Then the buyer gets a second chance to prioritize, having learned from the supplier dialog that some things might create more value than others. The suppliers don’t want to reveal their estimates to their competitors, but that issue can be addressed with a confidentiality agreement. Remember the “feature used on failed projects” from chapter 2 which indicates that 45% of the features were never used; they must have cost more than how they tasted!

 

What are fixed price contacts?

Fixed priced contracts are employed when a contractor takes a commercial risk in order to complete a predefined amount of work. This risk is worth something so therefore a risk premium is added to the original estimation. It could be 20% higher price than the estimation in order to cover the financial risk if estimations turn out to be wrong, such as if bugs are found and for handling “the unknowns” that no one could even think about before the project.

 

Why not just use Fixed Price Contracts all the time?

The answer is estimation, estimation and estimation! If estimating was easy and always turned out correctly, buyers could easily do high confidence cost analysis by themselves. But in complex situations where things depend on many variables, accurate upfront estimations are almost impossible. You will need to really understand on which level you should put your effort. Any solution can be developed in many different ways, and there is no universal “best-practices” approach; it all depends on the problem context. Therefore, you as a supplier need to really understand the problem context and on which level of quality this buyer expects the solutions to end up on.

 

What is the Purpose of a Contract?

Contracts should set the basic parameters for a project to create optimal conditions for successfully completing the project – for both the buyer and supplier. But in practice, contracts are often seen as competitive and not collaborative, in which the objective is to place the other party at a disadvantage, especially if things don’t go according to plans. Contracts handle the upside (the motivation to do something) and the risk that obstacles will arise during the journey that will involve additional cost and time to overcome.

 

Usually when people say fixed price, they mean fixed price, time and scope. This requires detailed, stable and accurate documented requirements, and the technology to be used is well known. The advantage of the agile approach is to handle development when requirements are fuzzier, and do not adequately reflect the underlying reality of business.  Many companies like the idea of writing a contract that fixes the scope and price because they believe it lowers their risk. But as we start developing the software, inevitably things change. In reality, fixed scope, fixed cost and fixed time is very risky for both suppliers and buyers; it almost guarantees delivery of software that the business doesn’t want. I have delivered systems with all requirements implemented, on time and within budget, only to see that the users aren’t satisfied. That time it turned out that it wasn’t just us “the supplier” that learned more about the customer during the project; the users realized what they really needed during the project. At the end of the project they didn’t want what they originally had demanded, but instead a system that reflected their new depiction of the system as of the end of the project.

 

If buyers want to lower their risk and get more value for their money, projects should become iterative, and then the contract will need to reflect that. What buyers often need is a fixed price contract or a price ceiling so that they can make an investment decision. Time and scope are often not important to fix; allowing flexibility with a more business value driven approach often allows customers to reflect on what they might want to gain. What may appear to be a looser contract might in reality yield two benefits: help raise business value, and lower risk. Neither you nor your mechanic would agree to an all inclusive fixed price to service your car before he looked under the hood. So why put a strait jacket on something that is far more complex, more costly and takes far longer time, such as a software development project? Here are some ideas for how you can create different types of contracts, based on the situation.

 

Different Kinds of Contracts

The most common kind of contracts used when an outside supplier is to deliver one part of the process is to put a specific set of requirements out for bid. The winning bidder becomes the supplier, whose work is then governed by a fixed price contract.

 

Fixed price & fixed scope projects

The usual fixed price contract is a plan-driven arrangement, covering a fixed scope for a fixed price. Penalties are built into the terms of the contract, to be levied against the supplier if the work isn’t delivered per the strict terms of the contract. The penalties are usually financial in nature and can be pretty steep. When the buyer publishes the Request for Proposal (RFP), the penalty terms are spelled out in detail so that bidders know what they are getting into before they bid.

This type of contract is good for budgeting and return of investment decision, and works best when the technology is well known and the stakeholders agree on both the requirements and where the project’s business value comes from. With a fixed price & fixed scope (FP&FS) approach, it can be difficult to adapt a full agile view, because you will not embrace change; you are compelled, to stick to the original plan. A quite common add-on is a delta list, on which you log extra work that is needed but wasn’t included in the original plan. But you need to renegotiate the scope with the customer before putting something up on the delta-list. Often, projects adapt some agile principles (for example frequent delivery, automated tests, continuous integration) but not a fully agile methodology when working with FP&FS projects.

 

“Fixed Price and Changes for Free” option clause

Fixed Price and Changes for Free is not about selling or delivering the (B) + (Something new) – it’s actually to deliver (B) + (Something new) – (Something else). The supplier can use a standard FP&FS contract, but add a Changes for Free option clause in the contract.

The Changes for free options have some conditions:

  • The customer must execute this option by working with the team on every sprint.
  • Failure to do this voids the clause and the contract reverts back to a fixed price & fixed scope contract.
  • The product owner re-prioritizes the Product Backlog at the end of each Sprint.
  • Changes are included, with these rules:
    • Changes in priorities are free if total contract work is not changed.
    • New features may be added for free at Sprint boundaries if lower priority items of equal work are removed from contract.
    • All features are prioritized by business value and implemented in order of maximum value.
    • Users follow the project closely and work with the Product Owner responsible for producing a high quality Product Backlog.

Changes for free

Here is a description about the process:

When planning the project you start with some requirement, either as a user story, scenario, or as a use case. Then you make a rough estimate of what it will cost to deliver that requirement. And then, you sequence them all in a product backlog. All requirements have a unique priority; two requirements can never be prioritized the same. One of them is always more important. Then you look on all the requirements and their estimates, and summarize the cost. That gives you a rough budget of what it will cost to implement all requirements. When you start the first iteration (called sprint in Scrum), you look at how many resources you have, for example, 4 people working on this project for 40 hours a week and the iteration will last 3 weeks. This means that you sum up the estimates for the top requirements until you reach 360 (4 x 40 x 3) hours of planned work. These requirements cannot be changed from now, but all other requirements in the backlog can be changed and re-prioritized, or you can remove or add new requirements. At the end of each sprint, everything that has been completed is demonstrated, or better yet, delivered for use. When you demonstrate and users use the software, new requirements will evolve. They might say, “When I see this you will need to do this also, otherwise this has no value!” Now the backlog grows, and the value of all implemented requirements plus all the new ones are higher than what you budgeted for the project from the start. But at the same time, what goes down in the backlog is the requirement that wasn’t prioritized. The total planned work effort is the same, so it means that the requirements that have the lowest business value are deferred or dropped.

 The Scrum Process

 

Money for Nothing clause

The Money for Nothing clause is about focusing on business value, as in Pareto’s principle about focusing on being as productive as possible while costing less than it taste. With this clause, both parties will have an underlying motivation to reach the greatest possible business value as productively as possible.

 

The Changes for Free options have some conditions:

  • It’s only effective if you use an incremental and iterative process that both parties understand. If this condition is not fulfilled, the contract reverts to time and materials contract.
  • Estimates are mutually agreed upon. If this condition is not fulfilled, the contract reverts to time and material contract.
  • The buyer and supplier have to agree on the same standard of the level of quality, i.e. what is minimally acceptable. In order to make this possible, the buyer must be available on a day to day basis so progress can be followed.
  • The buyer has to analyze the ROI cut-off, where implementation of the next feature costs more than the value of the feature.
  • The supplier allows termination of the contract at the end of every iteration and shall receive XX% (for example 20%) of remaining contracts.
  • The supplier assumes the risk of late delivery.

 

money for nothing

 

Fixed Price & Fixed Date with Money for Nothing and Changes for Free clauses

It’s also possible to combine the “Money for Nothing” and “Changes for Free” clause. This enables the buyer to tune the system to the latest known business value. Any requirements that haven’t already been worked on can be swapped out for others of equal value, and the customer can re-prioritize any requirement. And in adhering to Pareto’s Principle, the customer may terminate the contract early if its value has been fully satisfied, for 20% of the remaining unbilled contract value.

 

 Some other advice on Contracts

Communicate win-win

Both parties have rights and responsibilities, and these must be divided fairly between the two parties. If either of the parties doesn’t feel that the agreement will treat them fairly, they shall not enter the agreement. And if they feel it to be a zero sum game, they will start acting very defensively as soon as something is not going as planned. Both parties need to feel that they will benefit from this contract without harming the other party – i.e. a win-win proposition.

 

Underbids

Some supplier might underbid a proposal with the expectation that the inevitable change orders from the customers will allow them to recover the profit margin they are losing in order to get the business. Beware of bids that seem too good to be true. If the sales team is not presenting a competitive yet fair bid, it may mean that the supplier doesn’t understand the requirement, and when they finally do become aware, they might want to renegotiate.

 

Dependencies to the 3rd parties

A software development project often has interdependencies with other systems that need to involve work on the part of other departments or suppliers. They are not always as happy as you are when a new project needs their attention, as they might have been bidding on the same project or may not have available resources to help you when the schedule requires them. Sometimes they even want to see you fail. The situations where your success is highly dependent on a 3rd party must be identified early, and preferably before the contract is written, in order to cover all legal aspects and ensure continued progress toward the project goal.

 

Complex sales take time because they build on trust

Selling a complex project takes longer then selling a more simple solution. I think this has to do with the nature of complexity, that stakeholders are far from agreement on both what they want to accomplish and how they are going to accomplish that. What a sales person is doing initially is to help the customer and the stakeholders to be more aligned with their demand. First, sales will suggest different options as to how the system could work, and the stakeholders then talk to each other and arrive at a more aligned view of what they are trying to accomplish. Second, it builds trust; when stakeholders feel that you bring some clarity to their accomplishment, they feel that you understand them and are working on their behalf. It takes time to help the customer gain clarity and become more aligned toward the requirements, and to build trust.

 

For further reading I recommend:

 

What risks should each party assume, in a fixed price contract?

I think it’s important to examine different aspects of the project between supplier and buyer, for when things don’t turn out as planned. Exactly how the contract should be written and how the risk should be shared or divided between you and your customer is not easy to recommend. But here is my personal point of view, if you work with fixed price and with one or both of the clauses “Changes for free” or “Money for nothing”.

  • If the customer changes his mind about a priority and the feature isn’t included in a sprint, it’s okay to re-prioritize.
  • If the customer changes his definition about a function, the customer shall bear any increase in cost.
  • If a requirement has been misunderstood, the supplier shall take the cost. This places the burden on the supplier to break down all requirements in small enough pieces to simplify their estimation of them, and make it easier to verify the requirement with the customer.  (That is why you have a risk premium added to the estimate).
  • If development takes longer due to underestimation, the supplier has to take the cost. (That is also why you have a risk premium added to the estimate).

 

Conclusions of Contracts

Development during complex software development projects is like making an exploratory journey – it’s difficult to give hard guarantees of what shall be done, instead the agile view in which we shall be prepared to follow the best possible journey. Fixed Price, fixed time and fixed scope contracts don’t offer any guarantees to either the customer or the supplier, despite the appearance. This is especially true if you lock all three aspects, because then the only remaining variable, Quality, gets compromised in order to achieve the three fixed components. This often leads to one or more of the three fixed aspects being compromised too, in an unconscious way.

 

But if you prefer more flexibility for adaptive behavior in your contracts, the “Money for nothing” and “Changes for free” clauses are good complements to normal fixed price projects.  The “Money for nothing” and “Changes for free” clauses might also be valuable when working with organizations that have professional buyers that only focus on the price. The company’s Purchasing Department may maintain a frozen requirement specification that they will find the best (the cheapest) supplier for.  A supplier can then offer the purchasing department a fixed price contract with the “Money for nothing” and “Changes for free” clauses so that the internal department can have the flexibility to adapt during the project or to stick with the original plan.

purchase departments and agile