The High Road

I was recently involved in a “discussion” that prompted the thought process and communication exchange that I am about to discuss. And by “discussion” I mean argument.

What happens during an argument? Tempers flare…sometimes even nostrils, voice levels escalate, faces may even turn red and neck veins may even bulge. When these things start to happen you’ve probably already lost the battle because losing control is never a good thing. In fact, losing control is something a Project Manager should never do.

Thankfully, in a cordial…or at least, professional…business environment these types of “discussions” rarely happen. But there’s always someone in the workplace – perhaps even on your project team – who is somewhat volatile given the right (or wrong?) situation. Sometimes it’s even worse than that…sometimes it’s the customer. Those are the situations you would like to run away from at all costs…but since it’s the customer you simple can’t. So deal. Here’s how to take the high road.

The Volatile Team Member

If you’re unlucky enough to have a ticking time bomb on one of your project teams, then you know that something can set that person off – potentially at any given time and it could be for any one of a number of reasons. For a volatile person to get this far in an organization without being shown the door must mean they have some critical skills that would be hard to part with. Unfortunately, much like the baby throwing a tantrum, since they haven’t been spanked yet they’re pretty secure in the knowledge that they can get away with it.

If you have a volatile team member blow up either at a customer or within the team itself, here are a few things you can do to possible maintain control of the team and the project:

• Escalate the resource issue to their direct manager – Try this one first. After all, you’re not their direct manager and therefore it’s allowable to delegate some of this problem/resolution to someone who is because you already have enough to do without additional babysitting thrown into the mix.
• Conduct offline meeting with resource in question – Meet with the resource and identify the true root of the problem. It may be something you can alleviate quickly in a one-on-one session or at least you can drive home the idea that it better never happen again.
• Immediate replacement of the resource – This is the most desperate and probably worst option unless the project has just started. If you’re deep into the project, then go into this option knowing how much of an impact losing this skill set is going to have on your project and act accordingly.

The Volatile Customer

If you’re unlucky enough to have a customer that seems to “lose it” easily or is constantly arguing or calling for yours or a team member’s head on a platter, there is less you can do other than figure out some damage control methods. The exception to this is if you’re an independent consultant and the customer is directly yours…then you can just choose to pull the plug on the whole project and go home, but that’s a situation that everyone would like to avoid because it does little for your pocketbook.

In the case of the volatile customer, they’ve blown up over something real or something perceived, and in either case you have to do something. Here are your potential courses of action:

• One-on-one meeting with the customer project sponsor or customer team lead – This is an ideal first course of action whether this person is the volatile member or not. Why? Because they have the power on the customer side to hopefully resolve the issue or remove their team member. Discuss what the root cause of the project is and what action you will be taking with your project team to fix whatever caused the issue with the volatile customer.
• Full team meeting on both sides to discuss – Depending on the underlying cause, this may or may not be helpful. Taking it to the source is always best first, but involve both full teams for a full-on discussion of the issue if option #1 isn’t possible or doesn’t help. Remember, this is a customer and project that you want to keep going, so be ready to negotiate and be prepared to have to take corrective action on your side if it’s required in order to save the project.
• Get your executive leadership involved – This is the worst possible scenario because once you’ve escalated to executive leadership you’ve essentially sent the message – in some organizations – that you can’t handle the problem on your own or you’ve given the customer the idea that you don’t have the authority to do that. This can create an open door for the customer to take future issues straight to your executive leadership…so avoid this if at all possible.

The Project Change Order Request – Version 2

As promised – another version of the love-hate Change Order Request.  This is a cut/paste from a Word doc template that I would be happy to share.  The Word doc version looks much better, but this at least gives you an idea of the content that is being captured here for customer approval.

The main concept is to capture as much information about the proposed scope change as possible and estimate each task effort that it’s going to take to get there.  Once that effort and budget info is captured here, that information can easily be rolled into the project schedule to show your customer how the change order request is going to affect the overall project timeline.

I’ve been using this version – or at least some variation of it – for most of the past three years on projects and it’s served me very well.  The change order request is always a delicate subject for both the project manager and the customer so handling it carefully and in the greatest detail possible is critical to good decision-making and for on-going customer satisfaction since it usually results in the customer paying more on the project (but not always because even things that decrease the project scope and cost should be documented using this same process….it affects the project, too!).

Again, if you want a Word doc version of the template let me know.  And if you have a version you can share, I’d like to see it and share it with our PM Tips readers as well.

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.

Managing Issues and Risks on a Project

The concept of tracking issues and risks on a project is rudamentory. It’s fundamental. It’s critical. It’s necessary to the life and success of the project and it’s an absolute must when you’re trying to ensure the long-term satisifaction of your customer. And it’s also something that we often easily overlook – or at least we don’t do a very good job at it.

Defined

An issue is a function associated with the project that may impede the continuation, impact the cost or manpower or otherwise adversely affect the project. An issue is something real, something that has been encountered and must be dealt with.

A risk is a potential issue that needs mitigation strategy to avoid impacting a project’s success potential. A risk is an uncertainty with some degree of likeliness to happen.

Managing Issues and Risks

So what’s more critical to manage….Issues or Risks? The answer is BOTH. It doesn’t really matter too much HOW you manage issues and risks, just that you manage them. It really doesn’t matter if you separate them out either – just so you DO actually manage them. Issues and risks are not something the project manager makes note of and then tucks them away somewhere on a sheet of paper.

Remember, if we don’t learn from our mistakes, we are destined to repeat them. How true! And if we don’t document issues and their impacts to the project as well as risks and their potential impacts to the project and likeliness to happen, then both types of these project ‘bumps in the road’ are going to hit us and they are going to catch us completely off guard.

Make Everyone Aware

So how do we manage issues and risks on a project? There are probably 100 different ways and every good PMO should have a template and process for managing issues and risks. The key is to document them, bring them to the customer’s attention and to the attention of everyone on your team and make a discussion of the issues and risks an on-going topic on your weekly status call. Make it a recurring piece of your weekly status report. Make sure that it is in front of every critical participant and decision-maker for the project every week. An issue that slips through the cracks can’t be dealt with and a risk that is ignored can not be prepared for and mitigated.

The Customer’s Role

The customer is often your best friend when attempting to resolve issues and mitigate risks. Remember, this is their project, too. They actually want nothing more than for you and your team to be very successful and they’ll often do whatever is necessary to help achieve that success. It is financially in their best interests to see that happen. So, be sure that they are always aware of issues and risks as they arise and make them an active player in issue resolution and risk mitigation. It’s rarely beneficial to hide issues or bad news from the customer and they’ll never truly understand the value and hard work required of the project manager if they think your job is too easy.

Summary

A repeatable, formalized process for managing issues and risks is critical. More critical than how you separate and differentiate between the two. On most projects, they are a combined list for me. It’s as simple as documenting them in detail on a spreadsheet – but the key is always to have them in front of every key person on both teams, assign followup to the right key people and review status every week (or more often when necessary) on the weekly status calls and status reports.

How the IRCTC used knowledge management to its benefit

In recent years, globally competitive companies have discovered the importance of an organization-wide knowledge management system (KMS).

KMS provides employees with instant access to knowledge gained throughout the organization, thereby enhancing business effectiveness. From being a hygiene factor, KMS has now evolved into a “must-have” component for customer-facing units or departments. For organizations that are spread across the globe, this is a necessity.

Customers contact the firm at various touch points, i.e. physical office or branch, the telephone and internet access 24×7. They expect instant resolution for a bulk of their queries, if not all of them. Successful companies utilize the opportunity of constant contact to build loyalty. And how? By giving frontline staff rapid access to adequate customer and product information, thus speeding up problem resolution.

As an example, in the mid-1990s, Citibank India changed the rules of competition with its campaign “The Citi never sleeps”. It was the first bank to introduce phone banking to the Indian customer where he could call and transact anytime — day or night.

By announcing that it worked 24×7 for its customers, in striking contrast to its competitors who operated strict business hours, it raised the bar so high that it enjoyed unassailable competitive advantage and high brand recall for a very long time. This was made possible by ensuring information availability to employees at all times.

Read the entire story here.