Top Five Problems with Fixed Price Contracting

I've spent a number of years doing IT consulting, and I've been on both sides of fixed price bidding and contracts.
Below I put together five problems I've seen, and I describe anecdotes that really happened from the point of view of the
consulting / solution provider (I'm just hiding identifying details).
Please note that these problems are more likely to occur the larger the project is (at least \$100,000).
And before you protest: some projects don't have these problems, but most do!

Everything is Grey

No matter how detailed and specific your contract and agreed requirements are, there are always multiple ways
of interpreting human language. Unless the requirements can be evaluated by a computer, there's going to be
a human deciding whether the requirements have been met.

Once I was a developer on a project to translate a large code base from VAX Pascal to DEC Unix C++.
My boss, not a standard IT saleman, negotiated the contract, and he was a real stickler for details.
He actually got the client (a defense contractor) to agree that we were finished development
once a set of agreed-upon unit tests passed. I think that's pretty impressive -- there could have been a million
other details needing to be translated but not covered in the unit tests (since the unit tests had to be
agreed to in advance, there was not enough time for either side to confirm that they covered sufficient ground).

Above, I was just being cheeky and showing the exception that proves the rule -- almost all other projects just
have Word docs and rough prototypes as their specs.

There's Always Contention

It's just human nature -- whenever you have people with different motivations working together, you're
bound to get contention.

Once I was working as the technical lead on a J2EE project, and after it went live, there were performance problems.
The app ran fine under a light load,
but once a certain threshold was reached (less than 10 people!), performance dropped off a cliff. The whole team
was working really hard to figure out the problem, and I was getting pressure to go to the client's site
to make them feel better (they were freaking out since the system was essentially worthless when it ground to a halt).
I didn't want to fly to the client, especially since I knew that I could not figure out the solution in an airplane
or in a face-to-face meeting with an angry client trying to tell them everything was OK. We figured out the problem
(it turned out a former coworker did not know that Oracle does not automatically
create indices for you ;-). By that time my boss's boss was sitting on the airplane runway to fly up to the client.
Well, at least I avoided the client's insistence to visit!

There's Always Change

For any project that takes more than a week to complete, there will be changes, either to the specs, or to the
members of the team. Maybe the client or solution provider's company will be bought. There can be
changes to the project's standing in the company (maybe more important, maybe cancelled), or the project team can have greater insights while
trying to implement the project. Or the client just forgets some details. Any way you slice it, you're going
to get change.

Once I was the technical lead on a smallish project (around 3 months with 4 people) for a pharmaceutical company,
and it was the first project by my department, so my management wanted to make sure it went well. Halfway through implementation,
the client started asking questions. How do I add new users? (Uh oh, no one spec'ed out an admin section.)
Why aren't you following our manufacturing calendar? (Uh, no one told me about it, too bad we had tons of date-related calculations
that needed to be redone.) Where is such-and-such data? (I didn't even know, but it turned out we needed to setup
and use a daily feed from another system.) Why isn't your webapp following our password policies? (That's how I learned
that we needed to integrate authentication with their Windows domain.)

Salespeople Can't Say No

As soon as the people making the sale are different from the people doing the work, you've got a problem.
And the problem is that these two sets of people have different motivations. Salespeople really want
to get their commission, but they only get paid if the client is happy enough to pay the bills.
Saying no to client requests runs the risk that the client won't pay, or will underpay, and that would hit
the salespeople's commission. On the other hand, the actual project team
just wants to put in the minimal work necessary that they don't get in trouble (the exception is if they get paid
for doing overtime).

Once I was stuck on a long drawn-out project, which was running late and been rescoped a couple times already.
We were doing a "final" review of the technical specs, before we were to finish implementation. In this meeting
were several representatives from the client, our developers, and representatives for upper management
from my company. At this point in the project, my management was worried that the client would bail out and not
pay. So as we went through the specs, the client was free to add any features they wanted. And did they add them!
I tried to protest, since we were supposed to be clarifying requirements and not adding them, but without any support
from my side (here my management was acting like salespeople) there was nothing I could do.

At the End, Nobody Gets What They Originally Expected

Due to all the changes that take place as a project progresses, the client loses some features they wanted, but hopefully gets
some features they needed. And the project team has to put in some overtime to get things done by deadline.

Once I was a developer on a small intranet project for a pharmaceutical, and the project team was working directly
with the business folks since the project was being run in-house. It was kind of amusing to me that the business folks
had never worked on an IT project before. Boy, did they get a surprise! They thought their project was going to be
simple and easy to implement -- it was just to track salespeople's territories. They didn't expect that:

• The project would be considered "validated", thus requiring extra paperwork and slowing things down.
• IT folks won't do anything unless it's been agreed to in the tiniest detail. And when the detail is not there, then you just go in feedback circles making minor tweaks.
• Cross-system integration is painful and always takes longer than you expected -- even if you already took that into account!
• The poor business folk had to do testing because they hadn't budgeted for external QA. How annoying!

Conclusion

Even though some things above might sound negative, all the projects completed successfully!