Advertise with us Contact Us

The Fixed-Price Project Delusion and the Benefits of a Continuous Delivery Model

By Leonardo Mattiazzi

Agile has been largely regarded as an ideal fit for today’s business challenges (for a reference, check the Forrester Research Feb. 2012 report, “Determine The Business And IT Impact Of Agile Development”).

And, from our experience, the business benefit of using Agile is magnified when it is coupled with the application of Lean principles, such as establishing a continuous flow of constant throughput. This principle, known as heijunka in the Lean vernacular, when applied to software development means creating a continuous delivery model, with a fixed-size team that undertakes several different projects one after another (of course, using Agile methods in each one of them). By doing so, we are able to eliminate several different sources of waste, and significantly decrease the actual cost of these projects (in our estimates, by at least 25% in the long run), as well as the total project timeframe from “Hello” to the application go-live.

Moreover, the ability to adapt during the course of a project (as well as in real life) is a critical part of success. Lean/Agile methods not only accept, but also embrace change. On the other hand, in a fixed-price engagement, the only way to fix price is to also fix the scope, so change becomes an evil enemy. That’s why Agile and fixed-price are intrinsically incompatible.

Still, even when companies are trying to adopt Agile, often times we are faced with an established procurement process that requires a fixed-price, project-by-project model – a model that is directly counter to the flexibility of Agile development and the benefits of a high-performance team working in accord to Lean principles. The irony is that the fixed-price model was designed to generate cost savings (through competition) and predictability, when in reality it only destroys value by creating several sources of waste. If you have been through this situation (or may face it in the future), and feel you need some help on clarifying why your company should break with the status quo and abandon those practices, you may find the following compilation of sources of waste quite useful:

Ramp-ups and ramp-downs

There’s always a learning curve at the beginning of any project. The development team needs to learn about and setup the technical environment, learn the basics of the business and get acquainted with the client’s team. In our experience, the third sprint of a new project has approximately 20 percent higher productivity rate than that of the first sprint. By going through this process every time a new project starts (as opposed to keeping the same team for a flow of projects), the only guarantee is that everything that was learned is thrown in the garbage – making the project more expensive and lengthier.

In addition, during the final phases of a “traditional” or waterfall project, there is a ramp-down, as not all members of the team are needed until the end. And with that ramp-down, resources are assigned to other engagements, so accessibility to valuable knowledge becomes limited. Of course, the remaining team members will eventually figure it out, but only after valuable time and budget have been drained.

Fixed-price embedded risk

In a fixed-price engagement, any provider that wants to maintain a profitable business will embed risk into the project plan. Rather than share goals and risks, the client pushes the financial risk to the provider by requesting a fixed-price, and provider pushes risk back to the client by embedding it into the budget. In these types of engagements, we are already off to a bad start, and the relationship then focuses on risk management rather than driving towards business goals, resulting in mediocre results at a much higher cost.

Management overhead

Due to this risk management behavior, too much time and energy is spent on project management. A project’s price can only be fixed if the scope of work is also fixed. So it then becomes the job of the project manager on the provider’s side to make sure the scope doesn’t change, or if it does, to justify a price alteration by proving that the scope was not clear in the beginning. The client-side project manager is then tasked with making sure the scope is very clear, so the provider cannot later claim otherwise. Time and energy are wasted detailing the scope and formalizing agreements, turning the project into a bureaucratic nightmare. Dollars are, of course, added to the project cost without generating any value.

Sign up for our Nearshore Americas newsletter:

So with one project manager defending the cost, and the other defending the scope, often they are at odds with one another. If there is a change, no matter how legitimate the business need is, it will create a stressful situation, a negotiation that may distract them from the overall project goal and often times drain their energy to the point of burn-out.

Defensive attitudes

As client and provider project managers have opposite goals, naturally, they become defensive. Instead of moving aggressively toward shared goals, every decision is made from a cost perspective, ignoring value generation. Agility is lost when every decision must be analyzed and then approved. With this defensive attitude, it is virtually impossible to complete a fixed-price project on time and on budget.

Sales and account management overheads

When every project is negotiated on a case-by-case basis, more work is created for the account management team as well. Proposals are lengthened to appear well thought-out and sales reps and account managers are ingrained to look for every opportunity to up-sell. These may not be direct costs to the client or provider, but you can bet they are often returned to the client in the form of higher prices. The time required to start a project also increases dramatically, as a lot of formalization is required. By contrast, in the continuous flow mode, a quick intake is needed for project estimates, which are either approved or not approved by the client, and the project may start just a couple of weeks after the first intake meeting, as the team is already in place.

Legal paperwork

As if commercial paperwork was not enough, there’s also the legal paperwork. Due to the defensive attitude previously described, lawyers from both sides tend to have a more prevalent role than is truly necessary. If nothing else, the timing of the project will be impacted by the multiple rounds of legal changes and approvals required before the project can begin. One can only hope that this doesn’t happen in the middle of the project too!

Of course, no development project will be perfect, but by utilizing Agile methodologies and a Lean, continuous delivery model, we understand how to avoid the waste associated with fixed-price projects. As more clients learn to identify areas of waste that lead to higher prices and lengthier projects, we predict that the continuous delivery model will become the preferred method for contracting and running projects.

 

About phaller

5 comments

  1. Great article!
    I would mention two extra reasons, of why fixed-price projects, also lead to a bad end!

    One is related to Projects over a year of duration. At some point, the business might run old, and what was a must-have 6, 7, 8 months ago, is now considered as second priority. How you re-negociate it? How you get things out of the scope, if you already committed to a contract and to an amount of money?

    And two, is that I never saw a Change Request negotiation go down smoothly for both sides. Always one part will end up feeling that the deal was not good for them. And partnerships can be damaged, when the Supplier starts to throw Change-Requests bills, on the client's face.

    There is no doubts, that High Performance Teams, bring way more benefits to any client-supplier relationship.

    Janos Hovac

  2. Mauro Oliveira

    Great Article.
    Congrats!

  3. Very nice! Worthy reading.

    Agile approaches also reduce the "scope" paperwork. Agile teams do not need to generate lots of documents in order to create the "ilusion" of fixed requirements (that do not exist in real real).

  4. Márcio Cyrillo

    in this new digital world where tech start-ups with limited resources can show to big companies how things should be done, it is amazing that so many companies still insist on carrying projects using the waterfall model.

    some metrics can be good like "average discount procurement gets", but no one is really collecting the actual costs of those engagements to come back and say that overall it's been good business for the company to buy from o roaster of different vendors without leveraging the best they can offer: people.

    well, start-ups secret sauce is quite simple: agility, low turn-ober, learning.

    scope is defined along the way, what really matters is that you have a team that performs and adapts quickly building the right solutions for your current context.

  5. Great article and well written.
    A couple points… first, agile is also used for projects that cannot call for continuous delivery, especially pilot projects. So some of the waste you mention above will also occur for ramp up and down scenarios even with Agile. Second, clients also like Fixed Price programs because they have to secure funding and appropriate budgets with some measure of predictability for the CFO. It is not always because they want things competitive or because they want the illusion of control. Unosquare overcomes this by providing a not-to-exceed "estimate" that allows the CFO to appropriate funds. But you are 100% correct – we build in the cost for risk and weak scope documentation.

    In the end, the clients always pay more for fixed pricing and most of them either don't care or don't know. Or they use companies that guarantee pricing while doing Agile and eventually go out of business.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll To Top