BradEgeland.com #PMP #PPM #project #Agile #cybersecurity #planning #ai #SAFe #coronavirus #virtual #mindmap #remote #COVID19 #scaledagile #fintech #webdesign
  • Welcome
  • Contact
  • Mentoring Contact Form
  • Expertise
  • Blog
  • Find Local PM Jobs
  • Books / White Papers
  • Software / Service Reviews
  • This Week in PM
  • PM Video Series
  • Awards/Recognition
  • Templates & Downloads
  • Clients
  • Professional Services
  • Past Survey Results

You're Only as Successful as Your Last Customer Thinks You Are

3/6/2010

0 Comments

 
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.

0 Comments



Leave a Reply.

    Author:

    Picture

    Brad Egeland


    Named the "#1 Provider of Project Management Content in the World," Brad Egeland has over 25 years of professional IT experience as a developer, manager, project manager, consultant and author.  He has written more than 7,000 expert online articles, eBooks, white papers and video articles for clients worldwide.  If you want Brad to write for your site, contact him. Want your content on this blog and promoted? Contact him. Looking for advice/menoring? Contact him.

    RSS Feed

    Picture
    Picture
    Picture
    Picture

    Archives

    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    June 2020
    May 2020
    April 2020
    March 2020
    February 2020
    January 2020
    December 2019
    November 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    March 2011
    January 2011
    December 2010
    November 2010
    October 2010
    September 2010
    August 2010
    June 2010
    May 2010
    April 2010
    March 2010
    November 2009

    RSS Feed

Powered by Create your own unique website with customizable templates.