• Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Black Circle

© 2017 by QS2 Point

Please reload

Recent Posts

Translating Requirements to Work Packages

September 18, 2017

1/5
Please reload

Featured Posts

Good Contracts Make Good Customers

April 7, 2019

 

When I was young, my dad used to say “good fences make good neighbors”. When I first heard that as a kid I didn’t quite understand the context but obviously it means having a clear separation of space makes for a clear understanding of what’s yours and what’s not. The same principle can be applied to contracts and customers. A contract is meant to legally define what you are responsible for (ex. scope of services/products), you’re your customer is responsible for (ex. payment of invoices) but just as important – what you and your customer are not responsible for.

Think about your most recent dispute with a customer – was there an element of your contract that was at the heart of the dispute? Almost all disagreements at the engagement level revolve around come component of your contract and how each side perceives it. So what makes a good contract? I’m thrilled you asked!

 

Clear Language

I’d say this goes without saying however anyone who is ever tasked with authoring a contract should have these two words (temporarily) tattooed on the back of their hands. When putting the scope and terms of a contract together, clarity needs to be at the forefront. Using loose language is a recipe for disaster – your client will either outright reject the contract (if you’re lucky) or they’ll sign it and immediately try to get the most that they can out of the contract – and you – based on their interpretation of the language that you put together. As you put your contract together, think of all the possible scenarios that you would logically run into – what if the client runs over schedule? Do they still get to keep your fixed-price team? What about your scope definition – have you ensured that you’ve thought about what extra scope could come out of the woodwork that you need to protect against? Time spent to think of these situations (just draw on past experience as a starting point) will be worth it when you can easily solve potential client conflicts by referring back to your crystal-clear contract.

 

Specific Deliverables

Be very specific with what you intend to deliver with your contract. In the case of software development, spell out exactly what it is you are going to do for the client – not just what you’re going to build (although that is critically important too). What I see in a lot of custom-build services contract is a heavy emphasis on the scope of the solution but the contracts skimp on other areas of the project such as change management, testing support, warranty and ongoing support. You can build the perfect system, within scope and budget of your contract however your project and your customer relationship will suffer if you do not have clear terms and expectations around all the other aspects of a solution implementation. Be very clear on not only the products (your solution) but your services as well.

 

What’s Not in the Contract

One pattern that I’ve noticed in most contract disputes is the lack of language around what’s not included in the contract. Just about as important as stating what you are going to do for your customer is stating what you’re not going to do for them. A lot of contracts have a clause to the effect saying that anything not mentioned in the contract is out of scope. While this may cover you from a litigation perspective it may not clearly manage expectations and lead to some challenging situations in your project. If you sense that a customer is expecting something you are not planning to deliver – be clear about that in your contract. For example, if they are expecting your team to train all of your end users but you only have budget for a train-the-trainer approach, spell it out in the contract that you are not providing end user training. The customer may still overlook that detail and sign the contract but they will have zero reason to refute your claim that you are not scoped to perform that service.

 

Every successful project that I’ve worked on (and I’ve had my share of non-successful ones) has always started with a solid contract that both my organization and the customer were very clear on. Knowing the details intimately and ensuring that my customer knew the details just as well really helped expediting any potential disputes or conflicts over the scope of what it was we were to deliver. Good fences make good neighbors and good contracts make great customers!

 

Share on Facebook
Share on Twitter
Please reload

Please reload

Archive