Don’t Kill Your Customer – It’s Bad for Business

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.

Common Challenges Faced by the Project Manager

Gary Heerkens wrote A Briefcase Book entitled simply “Project Management.”  In it he uses a fictional character, Brad (good choice!) as his subject who has been thrust into the world of project management.  Below is Mr. Heerkens section on the common challenges that he sees project managers being faced with as they lead engagements and work with both their customers and their management structure.  Read on….

Common Challenges You Can Expect to Face

As the Project Manager, can expect to face a number of challenges as you take on the responsibility of managing projects in your organization. Whatever the specifics of your particular situation, however, many of the challenges you’ll face are faced by most project managers. Let’s review a few of these common challenges.

The Responsibility vs. Authority Trap

Firmly embedded in project management folklore is this one: the responsibility you’ve been given is not commensurate with the authority (or formal power) you believe you need to accomplish the mission. The size of the gap between responsibility and authority will partially depend upon the structure of your organization. If you’re in a purely functional organization – and in many cases, a matrix organization – you should not expect to be granted very much formal authority. The gap between responsibility and authority will be quite wide. To compensate for your perceived lack of formal authority, you’ll have to rely upon expert power (respect you can garner through superior knowledge or capability) or referent power (often accessed by practicing an excellent leadership style). You’ll also need to rely heavily upon your ability to influence and persuade.

Imposition of Unrealistic Targets

Sound project management practice suggests that project goals (cost, schedule, quality, and functionality) should be determined through a systematic process of understanding customer needs, identifying the best solution, and formal planning. Throughout this process, realistic assumptions about resource availability, quality of materials, and work process (just to name a few factors) should be used. This approach yields a credible estimation of what is reasonably achievable. If this estimation does not meet business goals, then a systematic risk-vs.-return process should be pursued until it can be verified whether or not the targets can be met within a given level of elevated risk. That’s the process that should be followed.

Unfortunately, we live in a real world. Targets are far too often based on desire or a vague sense of what should be achievable, rather than driven by calculated business needs. In even more unfortunate circumstances, targets are developed before it’s even known what the project entails! In either case, the result is that impatience – rather than a rational process – drives the selection of the targets. From that point on, a desperate struggle begins, as the team tries to force the project to fit within the boundaries that have been drawn.

This practice puts project managers in a very difficult position, as it often sets them up for certain failure and severely undermines the planning process. Unfortunately, this phenomenon seems to have reached epidemic proportion: it’s one of the biggest complaints of practicing project managers today.

Perpetual Emphasis on Function

If you’re managing a project in a functionally oriented organization, one of the more difficult challenges that you’ll face is getting team members to overcome their inherent tendency to think and act in terms of optimizing their own discipline, technical field, or department. It’s important to recognize that this phenomenon is fueled by three powerful influences. First, by definition, projects are temporary, but functions live on. In other words, a person often considers his or her work group to be home; the project is just a passing state of existence. Second, unless contemplating a formal career change to project management, a person considers his or her discipline or area of expertise as the work focus. This means that her or she will likely be committed to ensuring the well-being of that area. This strong loyalty could, for example, give rise to counterproductive situations, such as team members using your project funds to advance their discipline – perhaps in excess of what customer requirements dictate. Finally, there’s the power of the paycheck. Simply stated, most people tend to pledge allegiance to the source of their paycheck. For most people in most organizations, that’s their work group or functional department, not you.

The Dual Responsibility Trap

Most project managers I encounter are asked to wear two hats. They must perform their job duties while acting as the project manager. This situation may present additional challenges for you.

At the center of this dilemma is the issue of allegiance. Imagine for a moment that you’re facing a critical decision. Unfortunately, what’s best for the project will negatively impact your work group but what benefits your work group will hurt your project. What’s the right decision? What do you do? If you make the decision that benefits your work group, you risk being viewed as a poor project manager. If you choose the course of action that benefits the project, you may incur the wrath of your peers and/or departmental management. It’s a tough spot – and you can almost bank on being in it, possibly often.

A more fundamental problem of the dual responsibility trap is figuring out how to divide your time and attention between the two roles. How much should you allocate to each? How long can you try to satisfy both before you realize you’re working most nights and weekends?

Finally, a third issue often surfaces in the form of thetwo boss syndrome. The project manager reports to his or her functional supervisor and to the person who manages the project management function in the organization. Again, this is a difficult situation for most project managers.

The Fundamental Conflict of Certainty and Uncertainty

Many misunderstandings and disconnects between project managers and organizational management can be traced to the fundamental conflict between the certainty that management requires to properly run the business and the inherent uncertainty of project work. Cost and schedule estimating provides us with an excellent example.

Suppose you’re just beginning a project. It’s likely that you have limited information on this project and there’s a significant degree of uncertainty. In a situation such as this, project management practice suggests that you would be well advised to use ranges of values when providing estimates on cost and schedule. The size of your range would reflect a level of accuracy consistent with the extent of your knowledge and the amount of uncertainty. In our example, it would be perfectly appropriate for you to estimate that the cost of your project will be somewhere in the range of $400,000 to $550,000.

Unfortunately, many project managers today would receive a very unfavorable response from their organizational management to that type of “crude” estimate. It doesn’t provide the certainty that management requires for approval.

Unfortunately, this example is not exceptional. The uncertainty associated with projects exists throughout the life of the project: it simply never goes away—nor does management’s craving for certainty.

Peer Review Everything

In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that.

Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.

Proof and Test

The same care needs to go into our project deliverables. Proof, proof, proof. Test, test, test. When you hand a deliverable over to the customer – unless it’s understood that this is an early draft – then you’re telling the customer that this is done and the best I can do. It better be correct. It better be accurate and read well. And it better be free of simple typos, for crying out loud.

Bad Example

I had a project with a major US airline where I had two business analysts working on the project. One was more experienced than the other and was really acting in a mentoring role to the other one. The less experienced one was the BA actually doing most of the work. The understanding was – for my team AND for the customer – that the less experienced BA’s work was being overseen and proofed by the expert BA.

Ok…so when we had to go through 5 iterations of the Business Requirements Document (BRD) going to the customer with typos, inaccurate table of contents items, misspellings, missing graphics, etc. you can imagine how quickly the customer satisfaction we were building started to disappear! The customer couldn’t understand – and rightly so – how a team of 5 skilled technical resources (including me as the Project Manager) couldn’t turn in an accurate BRD without typos. Customer confidence dropped like a rock.

Never Assume

I was in the wrong for assuming that between two experienced Business Analysts that they could get a document handed over to the customer that was free of typos. I was busy, everyone was busy, and I expected it to just get done and be done right. It wasn’t until we started incorporating peer reviews for EVERY SINGLE DELIVERABLE that went to the customer that we started handing over error-free documents. We conducted peer reviews on the BRD (finally), the Functional Design Document, the Test Plan, and every piece of information that went to the customer in written (or electronic) form from that point on and we got it right. I even had the full team review the status reports, weekly status meeting notes, revised project schedule, and issues/risks lists before sending them off to the customer in order to ensure that the customer did not see any more incorrect and unprofessional submissions from our team.

Summary

Never take for granted that everyone cares as much as you do about the output that they deliver. Yes, it has their name on it, but if it’s your project it also has your name on it and everything comes back to you as the Project Manager. Work hard to ensure that emails are accurate and have the proper attachments the first time, that status reports are accurate, that status notes are accurate, that your project schedule has been updated with everything that the customer is expecting to see, and definitely make sure that the documents you deliver as part of your engagement are free of the simple errors and typos that make a professional team look very unprofessional.

This won’t necessarily increase customer satisfaction because it’s really just an overall expectation they should have anyway, but at least it won’t decrease customer satisfaction and that is definitely a good thing.

We Learn from What We Screw Up

The title basically says it all. We go to school, we go to training classes, we join associations, we read books. We do everything good little IT and business people should do to better ourselves in our profession. And, at the end of the day, we’ve learned some things that help us in our jobs.

But what do we really learn the most from? Growing up, did you learn more from what you were told to do or did you learn more from what you did wrong and had to pay the consequences for? I contend that the latter wins hands-down. It’s nice to learn things…it always is. But when we screw up really good and pay some sort of price for it…I contend that those are the times that we really really LEARN.

Example #1

Case in point…. I’ve mentioned many times how budgeting issues can torpedo projects and I’ve had at least one major project of mine go south due to budget handling issues. I’ve passed blame somewhat, but overall I’m the Project Manager and that’s my responsibility. That which does not kill us makes us stronger, right? I firmly believe that. And that which does not get us fired makes us a better employee, a better server of our customer, a better business professional.

One major project completely shutdown for budget issues that could have been avoided – or least the blow could have been softened – with the appropriate action. I learned from that mistake and budget information is key to weekly discussions and project status reports that I have with and share with the customer now. It’s formally documented – both current budget and forecasted budget – and discussed formally every week. I’ve taken away the question marks and made it a joint effort with the customer. And believe me, the customer always appreciates the knowledge and would rather know the bad things and work through them with you then to waste money and cancel an engagement. I’m certain of that.

Example #2

I also worked on a major $50 million program for the US Department of Education. It was much more of a program than a project – it had a five-year run followed by an RFP process and our proposal and another contract win. The company I worked for always won it because the program had grown to such a large size, it was so complex and had so many add-ons that no potential bidder could knock us – the incumbent – out of contention for the next proposal. We had become fat and overconfident.

Then one day a funny thing happened. We missed a major milestone deliverable. Then we missed another. Then we improperly tested a change order resulting in delays and re-work. Suddenly, the government was not so enamored with our performance and certainly had lost confidence in our ability to deliver. We desperately needed to learn from this mistake, act aggressively and right the ship before it was too late – because at this point the project was within one year of coming up for re-bid.

I had responsibility on this program for all financials and budgeting, all change management, all change orders, disaster recovery, and status reporting. Production was not in my scope, but I pulled my direct reports together and we resurrected the project schedule that I had put together 3 years prior in order to win the current contract and we updated it to what was happening today. What my team and I turned out was a project schedule encompassing nearly 4,000 tasks and a my peer managers on the program were ready, willing and equipped to manage their specific portions of this mammoth project schedule.

My responsibility was to bring that all together and take over leading the weekly status meetings with the government managing everything to that schedule and producing meaningful alert reports from it both for internal purposes and for the customer to hold us accountable to. What resulted was a project that quickly got back on track, a customer whose satisfaction was raised beyond the level it had been previously and another huge contract win down the road. It wasn’t my doing – my entire team and I took the initial action – but everyone pulled together and made it work. We learned from our overconfidence and mistakes before it was too late. And in this case too late could have meant losing our jobs in a year if the contract was lost.

Summary

We’re human…we’re told what to do from the time we’re born till the time we die from someone or another. It doesn’t matter if we’re John Doe or Donald Trump…someone somewhere is instructing us off and on. We learn from those instructions. But I believe we also learn very fast – maybe faster – when we screw up and suffer the consequences. Sometimes we have to fail to perform better.

PMXPO 2009

PMXPO 2009 occurs on Thursday, May 14 beginning at 9am EDT – Register here.

Keynote: Fourth and Goal: Making the Tough Calls that Make Leaders Successful – Bill Cowher, Head Coach, Pittsburgh Steelers, 1992-2007; NFL Analyst, CBS Sports

Here are the details:

gantthead is once again excited to be bringing you our annual virtual conference and exhibition on Thursday, May 14th, 2009. It’s your opportunity to learn, network, earn PDUs and gain valuable knowledge all from the comfort of your home, office-or home office.

With today’s tight budgets, PMXPO 2009 is a fantastic way to get the trade show experience without all the trade show expense. You’ll have the same interaction with experts, peers and solution providers, the same educational opportunities and the same professional networking capability, all within typical work hours, and all completely free.

This conference addresses the specific needs of project executives and aspiring executives, charged with managing project offices, program offices and project portfolios of organizations big and small.

In five sessions-plus an exciting keynote presentation-we’ll offer overviews of common PPM and PMO issues with valuable take-away materials, including templates, checklists, project plans and presentations that you can modify and use in your own practice. Session topics include:

• Agile Project Management for Extreme Projects: Getting a grip on chaos
• Rethinking Project Priorities During a Recession
• Making Successful Decisions: A PM’s Path to Success
• Mind Mapping for Efficient PM
• Managing Projects to Deliver Maximum Business Value
  

Get all of this, without the hassles of travel, wardrobe and sore feet that come with the typical trade show experience. You won’t be getting the pens, squishy stress balls and keychains that you pick up at a live conference, but you will get hand-outs that you can use, like product demonstrations and other special offers from vendors at their virtual booths.

Registration is free, so take a minute now and make sure you don’t miss out on what promises to be one of the highest-value conference experiences in project management this year.