Be Careful What You Ask For: Contract Considerations for New Projects | TechWell

Be Careful What You Ask For: Contract Considerations for New Projects

A software professional about to sign a contract

A consulting friend was involved in a project implementing software as a service. The system had to be in place by a specific date to meet regulatory requirements. As in many procurements, there were challenges and delays, so development of the support requirements and service-level agreements in the contract were rushed.

The firm providing the service was a mom-and-pop shop, and they weren’t experts in service-level agreements. They have a model that is working for their other clients, but this client wanted a custom support model different from what they standardly offer.

The resulting contract was unclear about who was to do what. No one much cared about the service terms when the contract was signed; a bunch of analysis, configuration, and customization were necessary to prepare for the rapidly approaching go-live target. But as it came time to focus on support issues, the ambiguity of the contract became apparent. Some of the roles and responsibilities for providing ongoing user support were unclear and going to be difficult to measure and administer.

I’m not making excuses for the poor contract or procurement process that got everyone into this mess. Both the vendor and the client signed the contract, and courts exist to sort out ambiguous terms when there are different interpretations. That said, how client staff wanted to respond is interesting:

  • Hard line: One manager who has experience as a contract administrator wanted to waive the contract and say, “I’ll see you in court!” His feeling was, if you didn’t like the terms, you shouldn’t have signed the contract.
  • Giveaway: One of the analysts on the project believed the vendor was doing great work and operating in good faith. She suggested the contract be modified to clarify expectations and pay the vendor for tasks the vendor claimed were out of scope.
  • Compromise: Lastly, one of the executives suggested finding a way to split the difference between what was desired and what was captured in the contract.

In my opinion, none of these approaches is correct. But some are more appropriate in some contexts than others.

Bankrupting your service provider isn’t something to undertake lightly. You have to be prepared to fight (and willing to win). However, when there’s blame to go around, beware trying to avoid your share by destroying your partner. If your partner goes out of business, you lose, too.

On the other hand, giving away the store is not fulfilling your obligation to the organization that employs you. How would a reasonable person interpret the contractual language? Were there any contemporaneous emails or presentations that might shed light on what people were thinking at the time? It might be a fifty-fifty proposition, and it might not.

Lastly, compromise isn’t a bad thing, but it isn’t always the best course. Do you believe both sides were acting in good faith? Are there alternative solutions to the problem that relieve both parties’ pain?

Do your homework and go into the conversation prepared to negotiate. Understand what you want, determine what you have to give or trade, and get an idea about what the other party needs, too. There is no “correct” answer apart from the context.

Up Next

About the Author

TechWell Insights To Go

(* Required fields)

Get the latest stories delivered to your inbox every week.