Aiming for 'happy clients' can be an elusive game. Ultimately what makes one client happy is different from what makes another happy.
However, the first step to keeping anyone happy with a project is to manage expectations from the beginning to the end.
The following rules outline how Account Managers and Developers can handle client expectations and keep them happy...
Just like how a beautiful house is more than the bricks, a software project is more than the sum of the coding tasks.
Let's see what should be included :
We’ve all experienced that awkward silence in a Sprint Review when the boss joins the call, expecting features to be done... and they’re not. Maybe the requirements weren’t clear, maybe a "quick fix" exploded into days of debugging. Whatever the cause, the result is the same: another commitment missed, and another dent in trust.
Estimating time and complexity in software is hard. By its nature, almost all software development is attempting to solve problems no one else has done before. Industry veterans broadly agree that up to 60% of time and effort in software development is consumed by resolving unanticipated issues. Developers call these unanticipated issues "unknowns". Businesses call them "risks".
When you're scoping out a piece of work, it's important to help the business understand and manage those risks, and help shine a light on areas where risk can quickly snowball.
Do not wait until you have started to exceed your estimate before you notify the client that the release is running late.
An oversized invoice with no warning is never a good experience. A client will always prefer to be told ahead of time if a piece of functionality is going to take longer than anticipated. It gives them more control of what is going on.
Never keep the client in the dark when you exceed your estimates, it will only arouse suspicion and mistrust when they see the project deadline woosh past. It's best to tell the client as soon as the risk is identified to inform them of what's going on and ask "Do you want us to continue?".
"Sometimes it's better to ask forgiveness than permission" Tony Abbott
The trouble is that the above is predicated on the notion that you're doing something wrong and are happy spending time putting out fires that needn't have been lit.
Let's see how to live without stomach ulcers...
When you are working on a project, you need to follow the get work approved before you do it rule. However, you should assume some tasks will be approved by a client and do them anyway. This of course depends on the size of the task (e.g. half hour or less) and the obviousness of the task.
Each Sprint has a "Sprint Forecast" email that details what will be worked on during this Sprint.
At the end of the Sprint, this should be replied to with a "Sprint Review" email that shows a breakdown of what was completed.
If you're using GitHub to manage your project, create repeatable templates that can easily edited and emailed out. See GitHub Issues - Do you create a template for your Sprint Reviews, Retros and Forecasts? for more details.
Each Sprint has the following stages:
When you are about to finish a client project, it is a good idea to prepare a "thank you" email, have it checked and send it to your customer (usually the Product Owner) on the last day. In this email include:
It is really important to understand the difference between a Proof of Concept (POC) and a Minimum Viable Product (MVP). It is also important that clients understand the difference so they know what to expect.
Sometimes people get in the bad habit of reacting poorly when they receive some negative feedback, bad news or disappointing results.
These habits are not good as they lead to negative emotional responses.
To get out of this habit, you can try to separate the initial emotional urge from the actual behavior and break the connection.