- Enforce Deadlines - Every week (usually Tuesday) the developer has a meeting with the client to discuss the status of project.
Note: If you can't have a meeting, a phone call must make do.
Note #2: A weekly status update report (if the release is not yet complete).
- Have a project release plan - ideally a signed copy of the Release Plan in their diary.
Note: A printed copy of the email with "Approved" is fine.
- A debrief when the release is done.
- A mark /10 - from the client.
In respect of the debrief, when thing have gone off the rails, it is easy to speak your mind and say what you believe went wrong. However often when things are going right, the tendency is to skip the debrief thing, with a comment 'all is good'.
A better idea is to figure out 'why are things are going right?', and work out how you can repeat it. For example, if your client calls and says,
"We think Dan has shown very professional conduct and has delivered a high-quality solution"
you should look at how the project was run. Was the solution high-quality because your developer is a faster coder, or good at following your coding standards? Or was his professional conduct due to lots of customer interaction and polite and clear communication?
Of course, if in your release debriefing, if you find that the client is unhappy due to bad conduct, scope creep, or poor quality code, you need to check that your standards are being followed to ensure a positive experience in the next debriefing.