We value customer collaboration over contract negotiation
Having a contract is important, but it is not a substitute for real communication between the customer and the team.
Let's assume there is a tight contract in place, detailing exactly what the customer want. The contract also contains a list of features and a deadline. Knowing all there is to know, the team now keeps the customer out of the loop as long as possible and actively avoids all contact.
Let's assume there is a tight contract in place, detailing exactly what the customer want. The contract also contains a list of features and a deadline. Knowing all there is to know, the team now keeps the customer out of the loop as long as possible and actively avoids all contact.
The team delivers according to the contract, but the client is not satisfied. The end result is a pretty nasty conflict where paragraphs is batted back and forth between client and supplier. Relations are down the drain and everyone is frustrated.
What really happened was that the client changed his mind once she got a chance to test the finished product for real. It looked good on paper, but not in reality.
The underlying problem is the fixed-price fixed-scope contract. With those iron constraints, it's not hard to understand why the team was actively resisting any feedback. All changes to scope risks delaying the fixed-price project and hurt the supplier. So the customer must be kept out of the project at all costs. The goal in this situation is to fulfill the contract, not make the customer happy!
Hear this:
By deciding requirements early, we are making decisions when we have as little information and knowledge as possible.
To avoid this mess we should constantly seek feedback from our customers: listen, understand and learn. Above all, we should consider "changing requirements" something very good. It means the customer has learned more about what she really wants.
This can only be done with trust, and trust is implicitly defined in the contract (or not, in fixed scope/price contracts).
Take away trust and all that is left is the contract and that is also the sole reason we insist on writing detailed requirements and putting down deadlines before the project even begins.
Collaborate daily with the customer. Seek feedback at every possible moment and use that feedback to change both software and process. Talk to them! The goal is to build trust on both sides.
Here are some hints to make this happen:
- An actual customer should part of the team (and on site). If the project is not important enough for the customer to be part of, then maybe the project should not have been started in the first place?
- Use an agile contract. Such contracts requires a bit of trust from both parts to work.
- Only agree on a fixed price/fixed scope contract if you can get the customer involved on a daily basis. You may be able to turn the contract around if you build enough trust with the customer later.
- Coach customers into thinking: "I know I will change my mind a lot during the project, so it is not possible to set a deadline or scope. But I trust in the team and their ability to deliver working software regularly, and I have the right to end the project when I think the system is good enough."
No comments:
Post a Comment
What are your comments? I'd love to hear 'em, so don't be shy now :-) If you want to get in touch with me directly just drop me a mail.