Rules to Better Software Consultants - Happy Clients - 6 Rules
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 :
In fact, for every 1 hour of 'application building' coding tasks there is between 1 and 4 hours of other work which SSW will charge for. This other work includes administration, testing and bug fixing.
Here is a list of the items which SSW considers when estimating a release.
Do not wait until you have started to exceed your estimate before you notify the client that the release is running late.
Keep them informed and avoid conflict by sending an email like this:
To: Mr Northwind Cc: David (Project Manager) Subject: Northwind - Data migration
As per our conversation, the Data Migration task in Sprint 07 will take longer than expected and so looks like it won't be delivered this Sprint.
The data migration of the Coverage Data is more complicated than originally anticipated because an external database (Media Disk) also reads from the coverage table. I am revising the estimate accordingly to 3 days.
Good example - A sample of an email that informs the client that the estimate will be exceeded
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.
As soon as you realise that any of your estimates are likely to be exceeded by a material margin (about 20%), then let the customer know ASAP by phone and by email (using the 'as per our conversation' rule). This will ensure that the client is fully aware of any problems and has a chance to decide an alternative action.
Note: For Scrum projects, you should keep an eye on your burndown chart during your daily standups to see if you are on track to finish all the work in a Sprint.
"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...
The natural time for this conversation to occur is in the Daily Scrum
Always get permission for:
- Additional Items
- Investigation time for scoping out additional items
- Adding additional resources onto a project
- Exceeding estimates
- Data migration
Having said that, you need to manage two potential problems with seeking permission on work before acting:
- Increased dead time while waiting for approval
- Discouraging initiative to fix problems quickly
This rule is not generally applicable if:
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.
If you reasonably assume that the task you are working on would be approved by the customer, and it will take less than half an hour, you should go ahead with that task.
To: ScottSubject: QWI - Aqua UI Improvements from Adam
Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes.Please approve.Figure: Bad example.To: ScottSubject: QWI - Aqua UI Improvements from Adam
Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes.
I have made these small changes. Test please.Figure: Good Example.
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:
- Sprint Forecast email: "Northwind - Sprint 5 Forecast"
- See Do you send "Sprint Forecast" email to the client? for more details
Work in progress
- "Done" emails are sent asking for specific functionality to be tested
- See Rules to better Email for details
Review and Retro meetings
- The Sprint review/retro email: "Northwind - Sprint 5 Review/Retro"
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:
- Make sure you have completed all requirements
- Thank for the time and tell them the reasons why you enjoyed working on this project
- Prepare a list of future improvements you can think of that can be done
There are a number of reasons why this is important:
- It shows that you care about your client/project
- Give them something to think about. They might get you back to fix the problems you have identified
- Show that you will be supporting them after the project ends
Below is a template email you can use:
To: Bob Northwind Cc: [Account Manager] Subject: [Project Name] - Thank you
Thank you very much for your time for the last xxx weeks. I think you must be the best Product Owner I have worked with at SSW (always available for me when needed). I really enjoyed this project.
I believe I have completed all of your most important requirements. I had good look at the source code and while it's fresh in my mind, I thought I might send you the following suggestions that would make it easier for myself and other developers in future:
Improvement Area 1:
- Do this: because of this
- Do this: because of this
Improvement Area 2:
- Do this: because of this
- Do this: because of this ... ...
Please feel free to contact us if you have any questions.
Figure: Good Example - Nice 'thank you' email with a list of future improvements