Tag Archives: communication

Dealing with customers

Written Contract

Written Contract

Dealing with customers is always a hard topic. This blog post will not summarise some of my experience before working for my current company. Communication with customers require both art and discipline to make sure that nothing could possibly go wrong. Here is a quick list of errors I have been making throughout my working life. :

Not thinking through each of the small details the customers may want to add later.

For example, if the customers want his websites to work on mobile device, it would be wrong to assume that he meant iPhone. 

- Don’t have a specific, fixed requirement document.

It could go wrong if both sides did not agree on a specific set of requirement before the project starts. I think I may need to understand more about Agile development

- Agree on a verbal basic: this is one of the hard lesson that I learnt when working outsourcing. Everything needs to be at least written and agreed on the email and not just chat or voice call.

Not thinking through small details

This is what is hard with software estimation when all the devils are in the details. When customers say they want their app to work on iphone, they really think of all iphone versions, and they probably assume that it works on android as well unless you tell them. It is good to be clear upfront and think through all cases.

Another example is that customer do not understand how important security is, and they just want it to work. But while they are testing, they may find the security issue and blame us all for bad practice of coding and testing.

Don’t have a specific, fixed requirement document.

Customers may want us to change the graphics 2 to 3 times and that are lots of back and froth emails and demonstration with the client. It will also extend the deadline of the project as we may need to wait for them most of the time.

Agree on a verbal basic

Everything should be at least in a written form. This was the key lesson I learnt during the early days of doing business. Everything needs to be agreed again over email. Even if you trust someone, or have a good memory, it is important to remind both of us what we said. It could be as simple as the client wanted to change the graphics and then later on, they completely forgot. It would be troublesome if clients wanted to change the requirement, then to extend deadline and the budget but they regretted it later. A written document would be helpful, or at least an email. I am not a lawyer but I found this book (22 Legal Mistakes you don’t need to make) helpful for new people.

When you write something down and let the other side read through it once, you can confirm that both sides share the same idea and clear all the miscommunication. This proves to be effective when you work on project requirement.

What is your tip? Please share it in the comment.

 

Communication problems between distanced members

Misunderstanding

Lacking communication….

If money is your startup’s problem, you should open a branch to outsource some development work into cheaper countries, like Vietnam. Then, you would exchange 1 problem with another, probably harder than you thought.

Communication: this is a key. Effective, efficient, going into the right way. In startups, there are much less time for documentation. Things have to go really fast, features after features, products after products. It is much better for startups to go fast, try with different ideas until they get it correctly. And when they get the idea correctly, it is time to execute, as fast as possible to get the products into the market. Distance difference is a main barrier for communication, talking over Skype feels very different from talking face-to-face. Another barrier is time difference.

The time difference between Vietnam and America is huge, 10-15 hours time difference. When the Vietnamese developer wakes up, their colleague sleep, and vice versa. I have seen some approaches to this problem: scheduling out some fixed time in the day or week, to meet, or someone has to sacrifice. The first one is not normally working for startup when lots of communication needs to happen. The second one will not last for long.