This article was originally authored by me for the Projects@Work website and published there on 10/8/09.  Go here to view the original article.

PM Customer Service

The first thing I would like to discuss deals with the concept of the project manager in the role of customer service.  There are a lot of things we do as project managers when we’re leading our high-visibility engagements.  We can be prudent project budget managers, great leaders of skilled resources, organized reporters of project status, well-versed speakers during weekly customer status calls, and confident managers of our own personal project portfolio as we report status updates to our PMO and company leadership.  This is all well and good, but if the customer is not happy, we’re not successful.

Read that carefully before you disagree.  We may have done everything right.  But if our company’s mission includes making money, being profitable, and retaining and growing the customer base, then we must make our customers happy.  Referenceable, returning customers is what distinguishes a growing successful company from a short-term fad.

How Do We Keep Them Happy?

So, how do we make and keep our customers happy?  Usually, if we do our jobs right, it should be easy.  The key is to keep them informed – even bad news is good for the customer (and I’ll address that in another article).  Here are the basics of what we need to do for our customers on delivery projects as the project manager:

  • Kickoff the project in person, formally and with confidence
  • Deliver weekly – at a minimum – revised project plans that accurately depict current project status and task assignments
  • Keep detailed project budget and forecast information and deliver it to the customer as jointly defined during the kickoff session
  • Deliver timely, concise and informative weekly status reports
  • Lead regular, formal weekly status meetings reviewing the status report, all issues and risks, budget status and include your entire delivery team
  • Closely manage scope and keep the customer informed in advance – as much as possible – of any potential change orders necessitated by issues or requirements changes
Of course, as a PM we do a lot more than this list, but this is a pretty good start on what our customer expects from us.  If we do all of these things well, then the customer will be satisfied right?  Wrong.

If we do all of these things well and deliver on-time and on-budget (relatively speaking, of course), then the customer will be satisfied, right?  Wrong.  They may be, but there’s no guarantee.  What are we missing?  What else can the customer possibly want?

Accuracy of the End Solution

The customer may be unhappy with you personally for reasons that don’t seem to make sense…that can always happen because customers can be very needy and quirky and you simply may not be properly feeding that need in them.  If that’s the case and you’ve done your job well, then don’t worry too much – there’s not much else you can do.  But, thankfully, those instances are relatively rare.

A far bigger concern is whether or not you deliver a workable solution to the customer.  You can be the most informative PM, deliver the project on-time and on-budget and do so without any change orders, but if the solution that is delivered is not what the customer’s end user base needs, then you won’t have a happy customer.  Period.  Unfortunately, I’ve seen this happen on other projects with other project managers and even more unfortunately I’ve had this happen to me.

How Did we Get Here?

What could have been done differently to prevent such a predicament?  Let’s look back to what I call the Exploration phase - where business processes and requirements are defined in detail and the Functional Design Document (FDD) is created.  This is a make-or-break phase for many projects as the issue of poorly defined requirements will become a bigger issue in the next phase – Design – in the form of a poorly designed solution.  The problem is only exacerbated from there in the next phase – Development – in the form of a poorly developed solution. 

At this point, the likelihood of being quite a ways off base from where the customer subject matter experts (SMEs) envisioned the solution to be is quite high.  Now fast forward to deployment and what do you think happens when those end users start to use the system you’ve just implemented only to find that it’s functionality strays from what their needs are for the solution?  Two words…customer dissatisfaction.

Requirements are Key

The key is to spend as much time as is absolutely necessary to properly define requirements before ever moving forward with a design session.  Forget what the schedule demands.  Forget – to some degree – what the budget demands (because in the long-run you’ll save it back with well-defined requirements).  Spend as much time as you need to on the Exploration phase and ensure that your customer has provided you with well-documented and well-defined business processes and requirements before ever signing off on the FDD. 

Only two things can happen with poorly defined requirements and they are both bad – either you come back to define the requirements in more detail later when you realize the problem thus costing the project extra time and dollars or you deploy a system that doesn’t give the customer what they want. 

It doesn’t matter who is to blame for the poor requirements, in the end it will be the customer who is unhappy and they’ll be unhappy with you…and your customer leadership will likely not be too happy either.  The customer may not want to hear it early on in the project, but if it’s necessary to halt the project and go back to further define requirements, just do it.  Both you and the customer will realize great benefits from the extra work.

 


Comments




Leave a Reply