Dean,
I spent a number of years implementing software in a fixed price fixed time scenario when I was at Cambridge Technology Partners.  And the Fixed price fixed time scenario was innovative and a differentiator for awhile.

So, now to the specifics of your question. 
Assumptions are the main area of emphasis to ensure that the customer is aware of the turn around time for input and participation.  Also, making it very clear about any roles or contribution that the client team will need to make.

If you know the specific areas of complexity or customization, make an explicit listing of the number of reports, or the number of parts or the number of whatever you assumed when you made your estimates and note that if they are different that they will then require a change order.

The key to be able to comfortably expand the size of the implementation is being constant in your communication and alert the client very often as to whether or not the assumptions you made on the fixed price and time still hold.

As to the specific language, you have the basics already there.  It is more important for the client to understand that you are very confident about managing to the budget of time and fee but that it is a “team sport”.

Hope this helps.  If need be, contact me and I can pull specific language from software implementations done on a fixed price and time from multi-million dollar deals or couple hundred thousand.

Cameran H.

Dean,

We face similar challenges. We do our best to manage the risk through traditional consulting techniques but we’re also plagued by fear of a customization far exceeding the estimated effort. When forced to go the Fixed Fee route, we typically use the following language. We’ve never had to invoke this language so I can’t vouch for it’s effectiveness.

Completion
Each of the phases included in this SOW, as described in Section 2: Project Scope and Assumptions, will be deemed complete when Supplier has provided the deliverables specified below associated with each phase, as limited by the assumptions described in the same section and Customer’s performance of responsibilities pursuant to the Customer’s Responsibilities section below.

Upon submission of deliverables included in each phase, Customer will evaluate the deliverables provided, and within five (5) business days, either: a) accept the deliverables as complete, or b) reject the deliverables, and provide reasonable written justification for such rejection. Customer must either accept or reject each phase in total prior to Supplier commencing work on subsequent phases.
Should Customer reject the deliverables of a phase, Supplier may, at its sole discretion, either: a) remedy the non-conformant deliverables, and resubmit the deliverables for Customer review and acceptance, or b) terminate the engagement. Should Supplier successfully remediate the non-conformant deliverables, Customer shall pay Supplier for the agreed upon fees for the rejected phase.

Should Supplier reasonably determine that a phase cannot be completed in the allotted timeframe, Supplier will provide written notice to Customer.  Customer may, at its sole discretion either:  a) negotiate in good faith with Supplier a mutually agreeable fee for completion of the phase, or b) prioritize Supplier’s remaining efforts and terminate the phase when funds have been expended in accordance with the Time & Materials rate agreed upon in Section 5.

Hope this helps,

Israel F.
Director, PS

I totally agree with Cameran

A couple of times in my career I have assisted in moving T&M based organizations to a Fixed Price basis (and back again when it made sense).

The key is in scope definition and assumptions.

Often scope is difficult because the semantics can be vague � but stick to high level goals and include a list of items that are specifically out of scope.

Assumptions are the heart of the matter. Be specific on the things that your price is based on and if any change or prove false alert the client immediately. I have gone as far as “assuming” levels of effort and duration. For example, it is assumed that this project will last for 6 weeks and will require a Sr consultant and 2 consultants full time.

Also be sure and define acceptance criteria - and set default for review time frames and iterations. “Client will have 5 business days to review any deliverable after which it is deemed accepted. At that point any further revisions to that deliverable must be completed under a separate change order.”

I would not assume that selling a Discovery phase will slow down any deals (but your situation may be different then my experience.)

I hope this helps a bit

Good luck

Gary G

Director Business Development

Hello Dean,

I think as Cameron and Israel have alluded to, there is much to consider when moving from T&M deals to Fixed Price. Aside from the wording to trigger when a change request to the SOW is required, your general approach will be influenced by the complexity of your product and the underlying purpose of your PS/Services organization in support of product sales.

My company develops and sells software which discovers the IT cost and IT risk in an organization by indexing what is in the data centre and mapping all of the dependencies, patterns and relationships between every IT item.

For our Fixed Price SOW we do 3 things, again as suggested by Cameron and Israel:

1) Declare the scope and boundary parameters. In our case our scope is governed by the number of operating system instances a client has, the number of application dependency maps they would like us to create, and the number of product integrations we need to complete. We spell out the boundaries and make it crystal clear what the tolerance levels are, and what happens if they are exceeded.

2) Detail all assumptions. We have a long list of these. The key thing for us here is that our assumptions spell out exactly what we expect our clients to do in order to make the engagement a success.

3) Detail the change request procedure in the SOW, together with providing a blank boilerplate/template for Change Requests. The template clearly shows that we will be recording the justification of each change together with estimate cost (increase or reduction), and impact on time-lines, etc).

With regards to your point about a requirements gathering phase, we offer our clients a pilot opportunity. This facilitates capturing a number of data points and intangible factors which will impact a Fixed Price engagement, and forms part of our “land & expand” sales strategy. Our pilot engagements, governed by a SOW as described above, allow our clients to quickly see the benefit and value our product provides without going through a full deployment, while providing us with a view of how mature the client organization is, how receptive they will be to a larger deployment of our product and what internal behavioral issues we may encounter, and therefore need to qualify in the SOW for the larger engagement. Our sales team can offer the pilot to clients for a small fee covering our costs, or provide it free-of-charge as a cost of sale.

Hence, the wording in the SOW referred to below forms only part of a strategy for reducing the risk of Fixed Price engagement.

From our perspective we regard each engagement as a partnership and we want to show our clients that we are very comfortable doing what we do and that we have the expertise to make our clients successful.

--

Regards,

Charles R.

Director, PS

Dean,

Not an answer to your precise question but:

We’ve been doing all of our implementation engagements as pure T&M for many years. We’re seeing increasing pressure to offer fixed-fee
as an option for some new customers/deals.

We also occasionally experience the same pressure. One thing I like to do in those cases is to point out to the client that what they are
really asking for is that I sell them an insurance policy on top of our basic service. That is what fixed fee effectively is - insurance
against slip or increased scope.

And, I point out, the economics of insurance are such that the majority of insured items (car, boat, professional services project)
have a higher overall cost than the inherent cost of the (uninsured) thing itself. How much higher is a function of the magnitude of
risk. In our case, that magnitude is unavoidably large (because of the nature of the work we do). So the premium for fixed cost is between
50% and 100% of the T&M price.

In almost all cases, the client - who is usually a lot bigger than we are - realize that they don’t really want to buy insurance after all -
or certainly not from their small, specialized consulting vendor - and they revert back to T&M.

The bottom line is, if the client thinks that fixed price will cost them the same or even less than T&M, they are - for the majority of
projects - wrong.

Tommy

Tommy,

Very good points. The fact that your ‘insurance’ is at a 50% to 100% premium really sends the message. Our uplift is no where near that high,
but there is a premium to fix the fee.

As has been stated by other colleagues, whenever we fix the bid, we add a significant number of additional assumptions to mitigate our risks. These
include participation expectations from the client, turnaround times for reviews, definition of ‘acceptance’, and a host of other specifics to box
our exposure.

Like many, our clients ask us to fix our bids, which we do when pressed. The thing I would caution is not to go T&M with a cap. This is the worst
combination for the PS firm.

Great dialogue.

Joe G.

I completely agree with Tommy. After we have presented the T&M proposal and they then ask for fixed price proposal, the price is
almost 40-60% higher. When asked to defend that practice I usually have a conversation about how they are asking me to assume all the
risk and I am prepared to talk about the unknowns that can cause changes in scope. I also discuss the administrative aspect of having
to manage a fixed price project. It is not that you don’t have to aggressively manage scope, and expectations with T&M, but you have to
be much more vigilant with a fixed price.

This is also a great time to position the value of Steering Committee Meetings and the type of reporting you will be providing so there are
no surprises. I am usually able to convince them that the T&M is a more economical option for them in the long run - at least lets start
with T&M for the Discovery phase and we would be happy to revisit the option of Fixed Price during one of the Steering Committees.

Barbara T.
VP PS

Thanks to everyone for the great information!

I’m on board with stating all of our assumptions, especially in the areas where we know that complexity can hide.  The comments about clearly stating what is required of the customer rings true, as our projects have a large data integration component.  We expect the client to provide expertise (and sample data) so that we can effectively map their data into our system.  If they don’t provide ready access to their data experts (or if they don’t have them!) then our costs go up accordingly.

Tommy (and others), your insurance analogy is a very good one.  When customers demand “fixed fee” and “Not to Exceed” language, I believe you’re right - what they are looking for is “overage” insurance.  In my experience, most of the overages that we encounter are driven primarily by the customers’ inability to control their own “requirements”.  Of course, sometimes we underestimate the effort for a given scope, but we always participate in paying the overage in those cases.  So, the customers demanding fixed bid typically do so because they know they’re going to ask for more than they can pay for!  That’s what makes me nervous about taking on the fixed bid arrangements.

Thanks again for all of the good insight and advice.  I’ll let you know how the negotiations and the project turn out.

Cheers,

Dean

I have been following this discussion with great interest. Many of my customers desire a Fixed Fee or Not to Exceed contract these
days. The uplift to these contracts are not 50% but they are not insignificant either, usually in the 15% range although it can go
higher. But on a $1m plus project 15% can hurt.

I think in the ERP space so many customers got burned early on with T&M projects that simply ran over by 50% or more that now they want
to control their risk. Passing that risk to the service provider is the only contractual way they know how to do this. Where they risk
premium is exposed they choke and want to negotiate the premium on our “insurance policy”, most of us don’t have the luxury of this
particular negotiation. We also have been burned by customers who don’t quite come to the table with what is needful.

One thing I have not seen discussed are risk sharing models. I have worked with these models with some of my customers and it worked
well. When both customer and partner understand the value of the “risk” they can make good decisions. The risk share model I
worked most successfully with was where both my organization and the customer agreed on the Risk value of the project and each of
us “banked” 50% of that value. There was a process to draw from that budget that both parties had to agree to. At the end of the project
there was a reward based upon the quality, scope, budget, and customer acceptance criteria established at the beginning of the
project and ultimately the value of the banked risk budget.

I think that where the customer is fully engaged in managing risk and there are real dollars involved they become more involved in the
overall process.

Just my two cents.

One thing I have not seen discussed are risk sharing models.

An approach we proposed (but never implemented) on that front was a gradual rate decrease if the project went on after a given date.

The rate would start to decrease each week (say) after the agreed finish date. How low it could go would be open to negotation, but in
our case it never fell below cost. The point though was that regardless of what the rate fell to, it would be *below what we could
get elsewhere*. So the client knew we were effectively losing money if we stayed too long and so we were incentived to stay on track.

In the end, the client again reverted to T&M because they realized that they were the main source of slip (we work in a form of software
test, and it’s almost always *their* stuff that slips). So they themselves couldn’t commit to a credible end date.

Tommy