Fail your dev project so your client can love you!
In more then 10 years in project business I was fighting for project delivery, timeliness and quality. My one and only goal was always to make clients happy.
And I failed most of the time.
What happened? Our goal was to deliver on time, on budget with a moderate bug rate and an application which was well crafted. And we did that. Accomplished that. But when we checked for the customer feedback — there was most of the time: SILENCE. Nothing. void. They were busy with the next project, task, mission. No “Thanks”, no “well done”, just a paid invoice and the request for the next feature set. Yes, a paid invoice is truely a strong indication about our success, but what should I tell to my teams? The client paid and ordered a new project? Wow, what a useless motivation for hard-working, talented and skilled people. What I needed was a good feedback, someone really providing some words about the things we did (besides making money) — something to keep our heads up and to know why we’re working so hard.
But it never happened.
But if there was a single bug, a small feature misunderstood, a pixel not in the right place — We had hours of phone calls, 2 page long emails, documents, screenshot…
We had to change this!
And we did. I started with one of my most experienced project managers and a project with low risk. We decided to have the client participate in our pains, overtime, challenges, technical risk (we we’re shielding all of this before to provide superior service) and let him feel the pain we felt while working for him.
Means, on the 3rd day of the project the PM sends a message to the client, that we had technical issues and we might need another 5 days to get this fixed. And the journey of our client started. In the next days we made small incidents bigger in communication to the client — with the target that he got really worried about the project and the delivery. We basically shaped a story of our work and our challenges and made him join our own emotions and worries. And yes, we leveraged this a little bit.
At about 50% of the project, the we started sending “this feature works now” and days later “ we finally solved the other issue”-messages to the client step by step. We eased the perceived bad state of the project to the client.
And finally: Surprise! The project was delivered on time and budget.
And you know what? The client called and congratulated us for the excellent delivery, the great project management, the good work we did.
Does it really have to be this way? I couldn’t and still can’t believe it! But this pattern still works and I still train it to advanced project managers…
