Agile fixed cost is real

When we talk about a project with a fixed budget, then first of all it comes to tight deadlines and detailed agreed requirements, without which it is impossible to begin development. But more often it happens that the client has a certain budget for development and there is no desire to pay separately for the pre-project analytics.
For salespeople, this is a dream client. We promise the golden mountains, subscribe to any deadlines and, finally, the cherished bonuses for the signed contract.

What happens next? If you look at the relationship between customers and outsourcers, then in 90% of cases they resemble two warring camps. Some accuse each other of the eternal failure of deadlines and overstatement of budgets, others - of unprofessionalism and “they know their own desire”.
')
After listening to the next complaints on this topic, I wanted to share my custom development experience as a project manager. It's about the history of 2009-2011. Those interested in practical matters are invited to comment.

No time to explain, just do it!

Most customers do not want to spend money on us to collect requirements, write large specs, which will be coordinated for months, and only after that they estimated the development budget.
Why? There is simply no time for this.
So in our case: the project launch dates were agreed within the company on numerous committees long before they found the contractor, i.e. us.

Finger to the sky

So, what we have is:
- a new customized project,
- a customer with whom we have not previously worked and he is not loyal to us,
- a representative of the customer - the director of one of the areas in the company, well versed in his business, but knows nothing about IT, he never heard the word agile.
- used to think and work in the classic waterfall approach.

In fact, we have nothing. We need to sign a contract for a certain amount. Having nothing, we cannot name this amount.

Usually the following happens next: at the stage of presale, high-level business requirements are written. That is, small mini-sessions are held with the customer, they are trying to get him out of what he wants, to understand his business tasks and, in general terms, the functionality that needs to be developed. Estimate, call him some amount.
Hooray! Now we have a project budget.

After that, until the start of the project, some time passes, for example, two or three months. And now the team starts to work on the project, looks and is horrified. Just the hair on the head stand on end. Who evaluated it? (Most likely one of them or even all together).
It is a horror that it says: extremely optimistic, simply unrealistic assessments.
We promised the customer that we would do such a functional, in fact, we estimated it incorrectly, and it turned out that we had already eaten our margin, and we could also go to minus. I'm not talking about the deadlines.

All this is a typical story. But the most wonderful thing we call it is the challenge. We know that, most likely, there will be huge problems, there are a lot of sleepless nights and battles with the customer ahead, but this is fun, and maybe we can even do something.

Short stages in the contract

So back to our story. The scale of the work is not clear what should work out at the output - also, the start date cannot be shifted and there is a fixed cost. Getting started. We signed an agreement in which we recorded a list of high-level requirements and broke them into stages, that is, after three months we make the first release, after another month - the second, after a month - the third release, etc. At the same time, the total budget of the project is also divided into stages; we will close each stage with an act of completed work.

Iteration 0. Analytics time

At this iteration, we still stand in the open field. Laying no more than 2 weeks. In a situation when there is no time for a detailed study of the requirements, you need to be very careful about all the information received from the client.
I call such interviews open when we come to him and try to literally pull out all the information. It is very important that this is done by a truly professional who can cost such interviews and ask questions correctly.

In fact, we formulate the requirements anew: we paint them, we prioritize them together with the customer. By the way, you can read my little note about the decomposition of the requirements and their prioritization .

All requirements are divided into many user stories (user story) - a maximum of 2-3 pages. Based on them, we offer our solution to the customer.
It is important to feel the difference here! We do not ask again: “How do you want us to implement it?”
We ourselves offer him options, because it is in our interests. The customer reads: "Yes, I like it." Fine. Agreed.

We will need all this later, when the customer suddenly wants to change something (and he will definitely want to change what has already been done) so that it goes as an additional user story, and not as a change at our expense.

Constantly changing requirements is great.

Our work is divided into iterations, at the end of each of them we show the customer the results.
And here begins ... as from a horn of plenty, changes and additions, which by all means are necessary, pour. And we rejoice and tell him: “Tell us, what do you want more?”

It would seem that we have a project with a fixed cost, and at demonstrations we again collect new information. At first glance it looks like we are crazy.

This is a very important point.

In fact, changing the requirements is really great:
- the customer never initially knows what he wants, in detail.
- we allow him to constantly offer something new,
- and we will implement this within the framework of the budget that we initially agreed on.

The main thing is to follow the rule: "If you add something, then delete something."

Project risk reduction

Why is it good for us when we collect new requirements and indeed, change the scope of the project? Because we give more accurate estimates of the new requirements, because our knowledge of the project over time develop.
If at the initial stage we could only be based on our guesses, then in the middle of the project we can make new estimates with great accuracy. How much does it take to realize the differences? We already take small pieces of the project, and we can evaluate the work to the day.

How to stay within budget

So, changing the requirements is fine, we change the work plan, assess it more accurately, reduce our risks. The question remains: who allows us to remove something from the list of requirements? Obviously no one. In fact, it is impossible to remove anything from the queue, because any customer will say that this feature is needed, as without it. It turns out that in the queue of our product wishes are only added, and it only grows.

We evaluate each wish, and the customer is left to plan releases taking into account time and the remaining amount. Remember? The cost of the contract stages. That is, we had the initial budget of the project, for example, 10 million, and we have already developed 2,000 hours, which are 4 million, and, for example, 6 million left. Now he can from the queue of unfulfilled demands, which he constantly prioritizes, to select tasks for the remaining 6 million.

In fact, with a full contract at a fixed cost, we are moving to a T & M contract, but with a limited date and budget. However, if we spend on a feature not 20 hours, but 100 hours, nobody will pay us for it. But we appreciate the little features. We say specifically: "I think we will do this in 3 days, this in 5 days, this in 10 days." Our risks are minimal.

Of course, all this is a lot of work, first of all, an account manager - a person who builds trust with the customer and involves him in the process, monitors the collection of information and coordinates user stories, after all, is responsible for ensuring that the customer is satisfied . In this way, one of the goals of agile is to be on the side of the customer.

Happy finals with a fly in the ointment

What did we have interesting? We really released after three months the first release, which went into production, which customers began to use, that is, the company had already started to profit from our product. We met the budget and deadlines.

But at the same time, the customer still has such a beautiful golden casket in his head - an ideal big product, but money is a box, limited in size. And it turns out such a psychological moment, with which our customer, unfortunately, could not cope: "I pay you money, but you didn’t do everything to me."

But nevertheless, the product continued its development, we released many more releases, and for the following projects this customer chose only us. And that means we did it all!

In one of the following stories I will write about the later projects of 2014, there will be interesting differences, there will be additional aspects of the concept and a completely new approach to outsourcing.

I also promise to publish an example of an Agile contract with a fixed price and date, but with a floating fee - from our real projects.