As a new project manager it was glaringly obvious to me that my success was largely dependent upon customer satisfaction. I knew that I needed strong collaborative relationships with my customers. I needed them to respect me and trust me to get the job done. I needed them to help keep the project priority high and to provide financial support and subject matter expertise.
I loved giving them good news and I hated giving them bad news. For some reason I came up with this equation:
Announcing new requirements (or any change in direction) as a scope change = bad news
Now maybe this was because whenever I suggested to my customer that his new request was in fact a new request; he said things like “No, this is what I always wanted.” Or “I thought this was already in scope.” Not wanting to provide poor customer service I would go back to the team and have them incorporate the changes.
And this is when I learned that my wonderful customer with whom I had amazing rapport and respect had no clue why the project was late or why it cost more money. Let me be more accurate about this point. My customer was able to pretend he did not know why we took longer to complete the project because there was no proof that we incorporated any changes. Why should he sit in a meeting and admit that he added time to the project by adding additional requests? He was not a bad guy; he was just being politically savvy. Why, it was as-if all of those conversations and agreements about adding five more days to development for more in-depth error messages had never occurred. How could this be?
Sure my customer was happy; the end result was exactly what he intended all along.
No changes occurred; everything was in-scope from day one. This was simply another case of Information Technology taking too long.
And I had learned a new equation:
Skipping change management = Undocumented overages plus poor customer perception
I moved on, determined to be a better project manager and to continue to enjoy a great working relationship with my customer.
You can bet that on my next project there was change management. I documented it in the project plan and I reviewed it with the entire team. And when the first change surfaced my customer refused to fill out a change request. I explained that without the documentation there would be no change. I decided to be helpful by completing the change request for him. All he had to do was sign it.
As you may have guessed, this did not make it easy. Now the perception was this was a form that had to be filled out by Information Technology for Information Technology in order to keep the project moving. I was still missing customer buy-in. And so I learned:
Change management without customer participation = Documented overages plus poor customer perception
I did not give up on change management; instead I learned that I needed my customer to be my partner in the change management process. They needed to understand and support the process. They needed to see the value of tracking changes and I needed to understand that expecting their support and participation was good customer service.
Well when the second project ended I was able to show which part of our schedule and budget variances were due to project changes. My customer could not dispute this; he had signed the change requests. Guess what happened in our next project together? My customer was onboard with change management. He worked with his team to do a more complete job of defining the scope and he worked to discourage unnecessary changes and he reviewed and discussed the changes that made sense.
As you can see I had a few ‘Aha’ moments as I found my way as a new project manager. I think these four points capture the essence of my ‘Aha experience’:
- Best practices exist for a reason, to help us not to hinder us. If you choose to disregard a best practice like I initially did by not having a scope change management process and you have a bad experience, you really need to revisit that best practice. If you disregard the best practice again and you still have a bad experience, shame on you!
- You teach people how to treat you. At first I taught my customer that all he had to do was hint that he was upset about a change being treated like a change and I would back down and incorporate that change without any documentation.
- People will do what is easiest for them. In hindsight I truly believe that my customer knew that a scope management process was the right thing to do, but it was easier for him to have no process. If I was not going to follow recommended project management practices and that worked for him, he was not going to say a word.
- Skipping scope change management was actually poor customer service. It prevented me from providing my customer with an accurate accounting of what we really provided him for the time and money invested in the project.