When I meet with clients, whether new or existing, to discuss a potential .Net Development project we almost always discuss whether we can provide a fixed price. For the client, it’s simply simpler to make a go/no-go decision if they know the price. It’s easier for them to calculate ROI, it’s easier to get funding approval and it’s easier to administer. At least, it’s easier to administer when the fixed price is provided by ProActive.
Why do I say that?
We have a long history of successfully understanding, defining and estimating projects and delivering on fixed price proposals. Very importantly, we know when we can provide a fixed price and when we can’t. Our experience has taught us not to “guess-timate”, but if possible, to nail-down the specifications up-front. Understanding eliminates risk, which provides for a more accurate proposal. But you can’t eliminate all risk, and that’s where our experience helps us understand the risk inherent in each project. Some projects, by their nature, need to be done on a time-and-material basis, but we’ve found that we can often provide a fixed price. Bottom line…when ProActive provides a fixed price, we are confident we understand the scope and we are confident we can deliver on-time, on-budget and with quality.
One caveat we have learned is that Business Insight and SharePoint do not lend themselves well to being fixed price projects. Custom .Net projects are usually solving a specific problem and they can be defined, scoped and given as accurate a fixed price as possible. SharePoint and Business Insight are much more fluid and require a more iterative process for success.
We are very confident in providing fixed prices for well-defined custom .Net projects. The net result has been that, over and over again, when we provide a fixed price and scope, we are able to deliver a successful quality solution in the time frame, and for the price, quoted.
Doesn’t everyone do that?
In the past, we’ve had situations where we lost projects and the client had one of two types of experiences that allows me to say “NO, everyone does NOT do that” with great confidence.
Change Order Death: The first experience is the constant change order. I don’t know if this is caused by a deliberate attempt to keep the initial price as low as possible to get the order or whether it is simply a failure to adequately understand the scope of a project. Regardless of the reason, we’ve had clients select another development firm because the price is lower, only to find that many of the items factored into our proposal were not included in what they purchased. The result is change order hell and an always rising price. Historically, we’ve seen that the price usually ends up equal to, or greater than, our fixed price proposal.
Incomplete Solution: The second experience is that the solution doesn’t really solve the problem because the scope wasn’t understood and defined up-front. The selected development partner reaches a point where they can no longer afford to keep developing the project, so they eventually deliver an incomplete solution and walk away.
We know our clients are going to be given proposals that could result in one of these situations, so we always try, up-front, to ensure that they understand:
- the exact scope of the problem they are trying to solve to ensure that they are comparing two proposals for solving the same problem.
- that ProActive will stand by its estimate and that we will complete the solution quoted for the price quoted
- that, while a significant change in scope will result in a change order with us too, we’ve worked hard to define the right solutions up front and that will minimize the likelihood of a change. Still, if a change is needed, we will work with them to try to figure out a way to implement the change within the proposed price. Our goal is to avoid the change order.
For more than thirteen years, ProActive has consistently delivered successful fixed price solutions. We simply believe that, while situations can arise that result in a change, we have an obligation to do everything we can to get the scope and price right. I can count on one hand the number of times we’ve had to do a change order on a fixed-price .Net development project over the past thirteen years.
They key?
Understanding the scope up-front, experience and a culture based on doing the right thing.