Whether you are a project manager working in a large corporation with a PMO, or a PM-inclined individual in a smaller company thrown into the PM role, or a skilled consultant recruited by any sized organization to lead critical initiatives, you’re going to run into customers who drive you absolutely crazy.
I’ve discussed in previous articles some negative things about customers. These aren’t surprises to the experienced IT veteran. Usually the customer does not have the necessary expertise or knowledge that is needed – otherwise they wouldn’t be customer and they wouldn’t be coming to us for their project. Whatever it is – there is some need and they’ve come to you specifically, or your company in general, to fill that need.
If you come from a software development background then you know the attitude I’m talking about. It’s easy to put yourself above the customer and talk down to them. You need to both avoid coming across as knowing more than they do while at the same time resisting the urge to throttle them when they can’t seem to get a grip on what it is they really need and what you’re trying to do for them.
Customer Service
While customer service may not really be in the job description of most software developers and other key members of your project delivery team, it is a key responsibility of the project manager. The PM is the face of the company to the customer and the first point of contact for issue resolution during the project engagement process…and sometimes for a period of time following deployment. How you respond to that customer may mean the difference between ongoing revenue from them in the form of add-on business and change orders and a work stoppage on a project if they feel like they’re being treated like second-class citizens.
An Example of Bad Customer Service
I had one customer where my team was performing an enterprise software application configuration and rollout. It was, of course, one of five or six projects I was running at the time and one of three or four projects that most of my team members were involved with also. I had a junior business analyst on the project and a senior business analyst – supposedly the junior was being mentored by the senior. What actually was happening, though, was all the work being performed by the junior and no oversight by the senior.
What resulted was a functional design document that was full of errors – even easy typos – and it took four or five iterations to get it cleared up. At that time, peer reviews of documents like that were performed by position peers – meaning the senior BA was supposedly reviewing the document…but that never happened. Policy changes following this fiasco meant that peer reviews were performed by the whole team (something I personally should have required anyway as the PM…lesson learned, definitely).
What the customer saw, however, was a bad document being delivered to them repeatedly and they then realized that the senior BA was too busy with other critical work to be involved in the project. They actually had to state that they felt like they were being treated as a second-class project. Wow…I ended up with a lot of damage control on my hands.
The Lesson
The lesson here is to be proactive when these situations arise and correct the problem before the customer feels that they’re not high on your priority list. They know you have other work to do, just don’t make them feel like they’re at the end of your list. Your customer came to you out of need and because they lack the skills, resources and probably time to perform what you and your team can perform for them. Understand their need, work with their weaknesses and help them to fully understand the solution. You’ll end up with a very satisfied customer and likely a long-term customer.