How do you educate your customers?

Question

Customers need some education because they think different. Customers think:

• changes are not a problem in any time of the project

• details are not important (exceptions even less)

• time does not cost money (they have a fix price agreed)

• one sentence in the specification can be extended/read freely to fit the actual needs - and this does not affect the contract. (here we see often the "common sense" discussion - example: "Of course we need a invoice management screen when we talk about accounting managment - this is common sense!")

• the list goes on...

The main problem is that customer (no matter if external or internal/department) do not want or can not understand. It took me many years to understand software creation process and I am still learning, so how can they in just a few months.

What is your experience, what is the best approach to educate customers?

Answer 1

This last summer, I have had a very similar conversation with a customer.

The customer wanted me to provide a competitive price for the defined work, and then when their needs change, or their understanding of their needs change, they wanted to change the spec without allowing me to change the cost to reflect the change in work.

I asked my customer if they had any suggestions for how I could cost for unknown changes as part of the quote. The solution we worked out was for me to quote including an itemised contingency allowance of 15%, which we would then work with the customer to prioritise their changes to utilise that allowance. In the end the contingency was not completely used I only invoiced for the work done.

The end result was that I was happy I'd been paid for the work done, the customer delivered internally under budget, and because I'd raised the issue in a professional way with them up front they chose me over a competitor to actually do the work.

I just wish all the potential customers out there are this professional and actually value quality workmanship.

Answer 2

Educate the customer. I wish I'm not one of your customer ;)

Seriously, I understand your are in trouble, and you think the problem is the customer. Maybe it is, but it doesn't matter. Changing your customers is really hard, while changing the way your work with them is lot more easier.

The problem is that most customers are not aware of all implications of software development and you are not aware of their business in details.

Just one little thing:

changes are not a problem in any time of the project

"No matter how far you have gone on a wrong road, turn back." Turkish Proverb

I love that proverb, so when I can use it, I'm happy. Thanks for the opportunity ;)

Here are a couple of solutions:

You must provide the customer with the possibility to change his mind, because this will help him getting the right software that really fits its needs. He will eventually get more ideas while you are developing it.

Your are in a fixed price contract, so I guess you had to gather requirements, estimate them and put a price on each?

If you have to build a new thing, use the same process: you amend the fixed price contract with the extra requirements. Accept to remove requirements that will be useless (of you have not built them already of course).

Another approach would be to finish what has been negociated (less useless and not developed requirements) as version 1, and negociate a version 2 with its new ideas.

The second solution would be to create iteration in the development like in Scrum. I've no experience with this yet in fixed price project (because I don't do fixed projects anymore), so I don't know if it works or not. I seriously have lot of doubts Scrum (or Agile) is the solution to all software development projects, but maybe some of the practices described will help you.

Answer 3

If you have a fixed price contract you need to make it clear that every scope change will cost money, and they you will evaluate the change and present a costed quotation for implementing the change.

This is widely accepted practice in most industries but some customers will get very upset by this.

If sounds like you have a bigger problem though if you have "common sense" being argued.

A little like a customer many years ago where I worked who read the specification and said things like "There is an IMPLICIT REQUIREMENT that you do XXX"). To which the answer was: There are no implied requirements. The only requirements are the ones in the written specification. If you want to add or change requirements, please submit a specification change request and we will quote the scope change.

The message eventually got through but it took a long time.

Answer 4

One solution is to put more work into defining what you are agreeing to do before you start working. As you said, one sentence in the contract can easily be read differently by you and the customers. The more detailed the project plan is the easier it is for you to say that the extra they want you to do is not part of the original deal.

It's also important to be consistent. The customer doesn't know how much work there is involved for any given new feature. If you agree to add quickly implementable features for free, it's very hard to later explain to the customer why you can't do this other feature for free as well when the customer's common sense says it shouldn't be any more work.

One trick with fixed price contracts is that even if you do the job with a fixed price put in an estimate on how many hours the job takes. Even though you don't bill by the hour this takes away the illusion that fixed price equals infinite work hours.