What Happens When the Customer Wants too Much Say?

This is a tough one…what happens when your customer wants too much ‘voice’ in the project? It is ‘their’ project, after all. But they’re not the experts. They’re the experts at ‘as-is.’ They’re the experts at ‘what’s wrong now.’ Otherwise, they wouldn’t be coming to you for this solution.

The Customer is Not the Expert

They may think they’re the experts at ‘to-be.’ And with subject matter experts (SMEs) at hand to help guide where their business processes and ultimately their solution requirements are going, then yes, they do have some ‘to-be’ expertise. But they’re looking to you and the delivery team for the solution so the true experts are the delivery team members. And the experts in the ‘to-be’ solution…well that’s somewhere in between, I guess. The key is to keep in mind that even though the customer pays the invoice, requested the project, and signs off on the solution, they are not the experts and you can’t ever just go with what the customer says.

Maintain Control

I’ve already covered this some in a couple of past articles, but the point I’m trying to drive home is that you have listen carefully to the customer and also be careful when listening to the customer. Never quickly agree with them. I’ve run into a lot of customers – internal and external – who were certain they had the entire project mapped out in their minds before we started…the right technology, the implementation date, all the milestones, etc. You know how God laughs at us when we think we’re in total control? Ok…so don’t laugh at your customer – at least not to their face – but try hard to listen and reset expectations as necessary.

The happy customer in the end is the one that is led down the right path by the experienced project manager and delivery team on the right solution that is implemented as painlessly as possible and as on-time and on-budget as possible…but WORKABLE. No customer is ever happy if you go along with everything they ask for and say should happen only to have a failed implementation in the end. And the excuse of ‘the customer made us do it’ will never fly. Thankfully, I don’t know this from experience, but trust me…no one will buy it. It’s the PM’s job and the delivery team’s job to know the path to take and to reset customer expectations on the project and the solution as necessary to ensure project success. Silence and compliance is never the answer.

Summary

I realize this is straightforward information, but it never ceases to amaze me when I see things like this in every day life…where someone uses the excuse that they didn’t have the power to do this or that and that’s the reason it failed. I’ve seen it in every day life and I’ve seen it in the IT project world as well. And…surprise!….the customer wasn’t happy in the end even though that project manager listened to and followed their every request.

My most difficult to manage customers have always expected me and my team to have the final answers…”that’s what we’re paying you for” they would say. It’s truly empowering to hear that and it works. You’re a team with the customer, but you must take control.

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.

Five Signs You Aren’t Cut Out to be a Project Manager

Not everyone is cut out to be a Project Manager.  Being a PM is not an exclusive club.  It’s not even necessarily a highly desirable profession.  You get a lot of visibility, but not necessarily a lot of recognition.  That often goes more to the technical team than the PM, unless the project is very successful and highly visible.

I’ve written an article on the Background of an IT Project Manager and I’ve written five articles so far on the Characteristics of a Project Manager.  Here I’d like to look at five possible signs that indicate you may not be choosing the right career as a Project Manager.

Like Technology more than People

If you’re not a people person and prefer technology over people, then it’s not likely that you’re ready for a career as a Project Manager.  PMs are often thrust into customer-facing roles and are looked upon to lead a team of skilled resources on projects.  They must be ready to present materials, lead status meetings and status calls, initiate adhoc communication, and just in general be very confident dealing with people. 

If that’s not you, then run don’t walk.  If you prefer technology more than people you may be more designed for the role of the techie on the project – the person who develops the solution, not the individual who maps out how and when it will be delivered.  And patience with your team and the customer is critical.  If you don’t have patience, don’t sign up to be a PM.

All People, No Technology

Likewise, if you’re all about people but do not have any technical background then running IT projects as a PM is not for you.  I still contend that a good IT PM must have some technical background in order to be trusted, understood, and followed by the technical resources they are leading on a long project. 

You might get away with it on a very short engagement just by being a strong, confident leader.  But on a 6-12 month engagement or longer you’ll be exposed and the technical team will question decisions, etc.  I’ve seen it happen and I’ve witnessed very frustrated PMs who aren’t PMs anymore.

Don’t Handle Pressure Well

Being a PM means you have the target on your forehead for the entire project.  The Project Manager has to stay on top of status, project schedules, issues, risks and all project communications constantly.  Pressure is frequent throughout the project. 

If you don’t handle pressure well, then being a PM is probably not the best choice for you.  Being anything in IT is probably not for you, for that matter….because pressure on IT projects is felt pretty much throughout the entire team and throughout the entire project duration.

Need for Constant Recognition and Praise

Like I said earlier, you can get a lot of recognition, but it’s harder to get good recognition than it is to get bad recognition.  On the surface, much of the good recognition for a successful project will often go to the technical resources that developed the solution.  This, of course, depends on the company, but it is common…and it’s ok.  The developers likely did great work on a successful solution.  You led, but you didn’t create…and that’s ok. 

If you are one who needs constant praise, then a Project Management path is probably not for you.  It’s rewarding, but most of your rewards will likely come from the relationships you build on your teams with your team members and with your customer, not from the overflowing of praise and recognition you hope to get on a project.

Shaky Problem-Solver

Being a PM means you’re required to be a confident decision-maker.  Look to your team and other available resources – including your customer – as sources to help you solve issues and make decisions.  But if you’re inclined to run from problems or put them off and hope that they resolve themselves or that someone else steps up to solve them, then a PM career is not for you.

At every critical problem point, both your team and your customer’s team are going to look to you as the key leader and decision-maker and you can’t back down.  If you’re shaky in your decision-making or tend to be wishy-washy when it comes to problem solving and leadership, seek a different path for your own good.

Summary

These are just five – I’m sure I could come up with more and I probably will.  I would definitely welcome your input, as I’m sure the list could be nearly endless.  Please share your thoughts on what you’ve seen ‘not work’ in the PM field.  I’m sure everyone has some great colleague stories.  Thanks.

What the Customer is Trying to Tell You

I’ve discussed the effective listening issue previously. In order to avoid miscommunication, misunderstanding, and heading down the wrong path with something, it is imperative that we listen carefully to our team members and to our customer. We know this…and we all try hard to practice this.

So let’s examine things that our customer says or does and try to figure out what they’re really trying to tell us.

What the Customer Says…

Have you ever been told by your customer that “that’s not what Sales told us”? Or have you been told by your customer that they needed Phase 3 implemented in place of Phase 2 and Phase 2 pushed out to the Phase 3 timeframe? Have they ever said, we’re still gathering our internal requirements from our SMEs and we’ll fine-tune things as we go along?

What They Really Mean…

I have heard each of these things and other similar requests and pieces of information from my customers at one time or another. They are telling you something. Deep down, the customer is telling you indirectly that they’re ill-prepared to start this engagement and therefore risk and issue assessment better be a top priority because you’re going to have a few of them to deal with.

A customer who didn’t iron things out well with Sales isn’t truly ready to start. If possible, you – as the PM – need to step back, have another Sales-to-Professional Services handoff meeting and postpone the start of the project long enough to figure out what you’re walking into.

A customer who hasn’t mapped out their needs, requirements, and business processes well enough for a multi million dollar enterprise-wide implementation to know what phase needs to be implemented when is clearly not fully prepared. Yes, things can change on their end of the business that can switch their priorities around slightly, but for some of these large implementations we’re all dealing with clients who have spent considerable time preparing and acquiring funding. Major changes like switching phases around – which can have major project, budget, and personnel implications – should not be taking place at that late date.

And certainly a customer who is still fine-tuning their requirements while meeting with you to document functional requirements clearly wasn’t ready to get started. Again, this is an example where it is best to halt the project, send the customer back to perform further work on requirements, and then proceed.

Point of View

Now clearly I’m writing this from the Project Manager’s standpoint and what’s best for the delivery team and what’s best for the overall success of the project. I’m not writing this from a customer satisfaction standpoint, or from the standpoint of your organization’s bottom line or the executive management viewpoint. I’m fully aware that most of the time your management is not going to support the notion of pulling the plug on the project to give the customer more time to prepare – especially if that is not a request coming from your customer.

How We Have to Respond…

So, how do we make this work? Well, since we’re all Supermen and Superwomen in Professional Services organizations, we just DO make it work. But seriously, we put our heads down and push forward with the customer to fully define what it is they need. Additional requirements definition, switching phases around, more training, etc. etc. Whatever they need, we try to accommodate.

We still need to pay attention to the timeline and budget and identify where change orders are needed and present those to the customer. But when we’re flexing for the customer, those things that require more time or money are easier to push through with the customer anyway.

Never Say No to the Customer

Sales says “yes” to everything, right? Come on, that’s the stereotype that we all have, isn’t it? Sales promises the moon, hands it off to us and now we have to deliver. Or worse, Sales promises some vague idea of the moon and now the customer is expecting the full moon and we have to work very hard (and dance) to reset those customer expectations.

Why Not?

So, we think we have to go into the engagement saying ‘no’ and resetting expectations. And we think that we need to monitor scope – which we do – and say ‘no’ constantly to customer changes and requests – which we don’t. Here’s why….

• Saying yes leads to change and change leads to more work and more revenue
• Saying no is usually unacceptable to most clients (the customer is always right, remember?)
• Saying yes or at least entertaining a ‘yes’ makes the customer think you’re easier to work with

What is the customer usually asking for? Training that they thought should be included as part of the engagement? Additional data integrations beyond what the SOW called for? New or additional functionality that wasn’t mapped out during Exploration? There are a million different things that the customer can be asking for and all can mean additional revenue if negotiated properly. And saying ‘yes’ rather than ‘no’ will likely mean a happy, referenceable, and return customer.

Approach is Everything

How you handle the customer requests or the needs that have caused this decision point is very important. Take a deep breath, avoid the urge to say ‘no’ and utter something like…

“This is an important request, but I believe that it might fall outside the scope of the original SOW and the original requirements of this engagement. If so, it can mean an impact to the project timeline and budget and may necessitate a change order. We will review the SOW and requirements and propose a solution by ‘x’.

You haven’t said ‘yes’, though you likely will. And the customer now has the expectation that the request is doable, but may cost money…the foot is in the door.

Increasing the Bottom Line

Another thing to keep in mind is that the later in the process that a change or addition (both are ‘changes’ in terms of the SOW and requirements) is made, the more revenue it will likely mean. A change order for an additional data integration made during Exploration may mean 5 hours of additional Design work, 10 hours of additional Development work, and 3 hours of additional Testing work. This is 18 hours of additional work and if your organization is billing at, say, $150/hour then that’s $2,700.

This same request made during Testing would take a greater effort since the system is already developed at this point and only Testing and Deployment remain. This same request may now mean 5 hours of Exploration effort, 10 hours in Design, 15 hours of Development, and 10 hours of specific Testing effort to ensure everything is integrated properly. That’s 40 hours or $6,000. This is just one example and a very small one – but it shows that a change requested later on can result double the revenue in some cases…maybe even more.

Summary

Saying ‘yes’ to change requested by the customer makes good sense. You’ll come across as willing and able and you’ll likely have a happier customer because you’re meeting their needs. But you’ll also be increasing your revenue for the project. I said yes, yes, yes to one large industrial supply organization located in the Midwest last year and it resulted in over $100k in additional revenue over a 4-month period prior to the Deployment of Phase 1 of their software solution. I was happy, executive management was happy, but most of all the customer was happy and very willing to pay for it.