My Photo


« 9 Reasons You Don't Make the Sale | Main | Attracting Your Ideal Clients - Pt 2 »

September 14, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.

Raj Menon

Change request is one of the challenges of any project. Version control is very important for all to be on the same page. This process has to be defined before the start of the project. In spite of this we had problems due to lack of clarity of the client

Christine Baker


When reading your case study I found myself nodding in reminiscence. I had a client a couple of years ago who used to ring me at all hours of the night, (literally) agree to my ideas initially, but then unpick everything I did. Result? The organization has lost some great people who wanted to do things my way but found their boss (my client) was going in the opposite direction. It was so sad to observe. Oh, and I should have charged her far more for the hassle!
I now check, at the outset, for the client's emotional commitment to the changes in management practices I propose. It's up to them, not me, to implement and sustain changes and that's been an important learning point for me.

Not long ago, I had an experience pretty similar to your example #2. Unfortunately, it ended unsuccessfully.

The assignment was to compile a coherent instructive publication from disparate pieces of information. The problem for me was the flood of bits and pieces that needed to be inserted into the flow of the publication but were changed while I was busy working with the previous versions. The client also insisted on frequent follow-up meetings, during which I often had no progress to show because of the impossibility of organizing the information within the available time frame.

I finally called a time-out to be able to put together one master document for keeping tabs on the changes -- in principle, telling the client that 1) I needed a little time to sort out the mess, 2) we should work on one single master document instead of dozens of files whose versions nobody could track, and 3) based on point 1, we needed to reschedule the follow-up meetings.

I was declared uncooperative and my performance below par. I tried to explain my reasoning in a couple of emails, but they were never responded to.

In hindsight, it was probably better that the project didn't go ahead, although it felt really bad at the time.

Lesson learned: whenever there's the slightest possibility that a client or project may turn difficult, try to level the playing field immediately. When you're deep inside the project, the client will interpret any change from his expected process as a threat to the project or himself.

The comments to this entry are closed.