Lessons from consulting gigs, project management and writing contractual agreements

Some time ago, I landed myself a consulting gig, working on the consultation of  a very popular Java IDE. Since the customer was an ex-colleague, we agreed verbally on the contractual terms.

Difficulties encountered during the project were insufficient information. And as a result of that, it was not easy to work on the consultation. After the conclusion of the project,  when it came to time for payment, the customer reneged on his verbal contract, citing issues irrelevant to the contract.

Lessons:

1. All points discussed need to be written and signed.
2. All verbal agreements need to be written as part of the contract.

On yet another consulting gig involving upgrading older Delphi components to a newer version of the IDE, I had absorbed the lessons above, and included terms absorbed from the lessons above. Unfortunately, while drafting the contract, I had neglected to include failure clauses. This turned out to bite me later on, when the customer repeatedly failed one contractual clause.

I then issued a notice of termination of the contract.

Lessons:

1. Contracts need to include failure clauses for all circumstances.
2. If circumstances cannot be foreseen, include a clause for unforeseen circumstances.

Years ago, when I took up project management courses, one of the things I learnt is to include: WHAT IS, and WHAT IS NOT. For example, in the case of the development of a product, state what the product do, and what the product doesn't do. I had successfully applied this lesson to contracts I've written, by stating what would be done, and what would not be done, so that boundaries are perfectly clear.

Since most of my consulting gigs were quite successful, I never had to learn the lessons listed above, until these two projects. Due to non-disclosure agreements, I'm unable to provide much details regarding these consulting gigs.