[codingdave]

It sounds like the author is working with contracts that are too detailed. Contracts should specify the legal obligations and structure of a relationship between two parties, but if it is getting into procedural detail, or dictating the policies of an organization, it is just asking for trouble. At that point, an internal process change could violate a contract clause. That just doesn't make sense.

[vonmoltke]

Tell that to the US Government. This is par for the course in their large contracts. Gotta reign in those spendthrift defense contractors, after all.

[dmadden]

Moving away from a fixed scope for a fixed price is a legal obligation, so the process I recommend in is simply that - keeping the contract as broad as possible to write what the legal obligations of both parties are. Instead of stating the obligations are 'X scope for $Y", I advocate "$Y", which is actually less detailed by intent.

[Argorak]

You can always amend a contract. Just write a sideletter. A contract should always contain a definition of the services and the mode they are supplied and invoiced in.

[zachrose]

I work with two types of documents: master consulting agreements and work orders. The master consulting agreement has all the "standard" stuff like IP, confidentiallity, indemnity, etc. The work orders are where I specify what we're going to do(1), how much it's going to cost, and when it will be delivered. Both are dated and signed. This works well for me and allows me to do agile-style sprints with work orders. This is usually in addition to a ballpark price range for ballpark scope.

(1) Where "what I'm going to do" can be substituted for "what I'm going to try," when the client understands why I can't guarantee something.

[Argorak]

That, I do a lot as well. Basic point being: a fitting contract doesn't have to be a hassle.