Do fixed-price ERP projects protect against expensive cost overruns?

Having worked in the Public Sector, I have done a lot of fixed priced ERP projects.

As Jeff pointed out, fixed price contracts provide a tool for managing project scope and when used as part of a well defined and executed project can provide protection against cost overruns. The key to this is making sure that the scope of the fixed priced work is accurate, expectations about deliverables are clear and that there is a process and potentially a contingency budget for change orders as all projects will have them at some point in time. (The logic same holds true for managing time and materials projects).

On the positive side, fixed price contracts force customers and vendors to be engaged in an on-going discussion about project scope. On the negative side, if scope and expectations are not clear this can lead to a combative relationship as clients and vendors may argue what is in versus out of scope.

I completely agree with Jeff's assessment. A sad side effect of "fixed cost" projects are that the real project cost gets hidden in the mountain of change orders. There are a few firms who specialize in this shell game too. Pure time and materials is also a problem most of the time too because it creates the wrong incentives.

I'm a proponent of both risk and gainsharing projects with firm budgets and timelines. Notice I didn't say rigid budgets an timelines but very firm. Over the years I've seen lots of companies miss out on tremendous efficiency and automation opportunities that were at their doorstep but they had no ability to move the ball a little on budget or time. However a balance risk and gainsharing arrangement helps mitigate that fixation while still helpin a company not get taken to the cleaners.

I agree with Jeff and Bill. A fixed price is based upon some known set of requirements. IF, and that is intentionally a big IF, the requirements differ then the change orders start flying and the fixed price increases. Our experience is that by reducing the scope and complexity of a project you can better manage not only the cost aspect but also the schedule. Eating an elephant is a lot more digestible when you take small bites...bites that ideally are one to two weeks in duration. This way the results are aligned with the investment and the project can continue to be funded, adjusted or terminated. If a software vendor walks in the door with a fixed price offer and a project schedule of months the best advice is to run.

I don't think there's anything inherent in a fixed-price project that protects from additional costs being levied later. In general, some clients feel more comfortable beginning a project from that standpoint, perhaps in the believe that they've achieved protection. But once the ball starts rolling, costs have to be balanced with outcomes. And once the first deliverable is on the table, the client has a much better feeling for the process and quality of the vendor.

If the result is 90% of what I hoped it would be, I'm likely to cough up the cost for the remaining 10%. If, however, the result falls woefully short, then I may determine the vendor-client relationship isn't what it needs to be in order to ultimately succeed.

From a vendor's perspective, I think it's quite risky to bid fixed-price projects unless they are for clients with whom you've worked successfully before, know their business, industry, and environment well, or if the project is quite narrow and clear in scope.

As Jeff pointed out, Fixed-Price ERP projects often end up with cost overruns., due to scope creep and assumptions. The bidder expects to provide standard features for most of the requirements, and the mismatches get discovered later in the project.

In my experience with Fixed-Price projects, a change order sign-off process can help the sponsors to decide on incurring the cost based on the presented impact and ROI analysis.

The work of a project needs to be completed, regardless of whether it is performed on a fixed price or hourly basis. However, if the vendor and customer can nail down requirements, scope, and schedule up front, then a fixed price can work well.

In my view, fixed price forces all parties to prioritize the work and plan carefully up front. This creates a planning burden that many people are not willing to undertake. In fact, this planning should really be done regardless of how the project is billed. Resistance to careful upfront planing is a primary reason many projects run over-budget or are late.

At the same time, successful fixed price relationships require real collaboration between customer and vendor. If either party tries to take undue advantage of the other, the relationship will eventually break down and the project will suffer.

In summary, I am fan of fixed price projects when the parties have a collaborative relationship, scope and schedule can be clearly defined, and the work is highly specified up front.

Can you say "Out of Scope"? I agree with a great number of the replies here but for perhaps a slightly different reason. The hardest part about a fixed price implementation is trying to help the customer understand what you, the vendor understand about the solution being implemented; before you start.

Most companies think in terms of a budget for implementation that they can afford on top of the solution cost. They then ask the solution provider to "back into" the Scope of Work for implementation based on that budget. The job is then for the solution provider to prioritize the Scope of Work and minimize those areas not deemed critical to the needs of the company and to maximize those areas that are critical.

The problem here is that the Scope of Work becomes a moving target and the "Change Orders" start flying. The user's priorities change as they understand the solution more fully and the result is a revised implementation plan. In the end you either change the Scope of Work subordinating some areas of concentration to others, or you start writing change orders to add the new ones that are out of scope.

The only way to do a fixed-price implementation properly is to start with a very clear and realistic Scope of Work that is not just a function of budget alone, but the job at hand and the areas of focus that are needed for the company in question to bring the implementation fully home. If agreement here is based on the true reality of what needs to happen based on the solution, the company's needs, and a very specific SOW, then things will go well. If you have to shoe-horn into an arbitrary budget constraint, things will not go as well and the client will feel they have been short changed on the implementation. Clarity and reality are key here for all parties involved. Implementation without these mandatory components will be difficult at best and very painful at it's worst.