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.
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.
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.
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.
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.