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.

Project Management from a Distance – Part 2

In Part 1 of this six-part series, we covered the concept of “Why remote?” In this Part 2, we’ll discuss if it will work for you and how you can ensure that it will:

Part 1 – Why remote?

Part 2 – Will it work for you?

Part 3 – What type of job enables remote PM?

Part 4 – What setup do you need?

Part 5 – Negotiating when it’s not an obvious move

Part 6 – Staying the course

I keep calling this remote but I should probably call it telecommuting – or at least refer to it that way occasionally for the benefit of search engines.

When trying to decide if telecommuting or remote project management will work for you, it is necessary to examine it from all angles:

• Management and corporate policy
• Project scenario
• Customer
• Home setup

Let’s look at each of these in more detail:

Management and Corporate Policy

If you’re just coming onboard with an organization, you can sometimes make this part of the negotiation process. However, introducing it as an option that interests you too early on in negotiations can turn off the hiring manager and may end the process right there.  If you’re already an employee and want to bring it up, make sure the time is right and the scenario is the right one (see the next section).  Asking to work remotely on a project when it doesn’t make sense at all will make you look like you’ve lost touch with reality or are not concerned enough with your project’s needs.

One final thought on this – know what your corporate policy is on this…assuming there is one.  There may not be anything in place, but if there is, it will be helpful to know that before bring up the subject to your manager or HR.

Project Scenario

The next thing to consider – will your project work with a remote project manager? Is the project such that you can maintain control of it from afar and you don’t need the hands-on, in-person representation with the customer and/or the customer team on a daily basis?

If the project is for an external customer and it’s of a long duration, the answer is probably yes. If it’s an internal customer or of a relatively short duration, the answer is likely going to be no. Internal customers want you there, interacting with them so they can reach out and touch you when they need to. I suppose that’s not always the case, but in my experience it has been.

If you’re running a project for an external customer and it’s a long-term engagement, then it’s likely that you can do most of it remotely with some hands-on, onsite time with the customer…especially to kickoff the project. It depends on several things – the type of project, the amount of detailed meetings that need to be held on a weekly basis and the customer themselves (we’ll discuss that next). Projects involve a long-term software implementation with a geographically dispersed team make it relatively easy to handle remotely.

Customer

The customer and their preferences play into the decision-making process of whether or not you can manage a given project remotely. For the past three years, I’ve managed all of my projects remotely, but I’ve had two customers that demanded an onsite resource 24/7. In the case of these two projects, they were not PM resources they needed onsite. One required that a Business Analyst be available 24/7 and they paid dearly for it through the change order process as it was not part of the original agreement. In the other case, the customer requested that a development resource be onsite for an extended period of time to work through software modifications with them. In neither case did they have the budget available to also afford having a PM onsite 24/7, however.

Home Setup

Your home situation also plays a role – actually, a major role – in whether or not you can pull off the telecommuting scenario. First, you must have a place to call your own – the high-speed home office. You don’t have to work in it full-time…I certainly don’t. But you do need that availability for seclusion to handle conference calls and just to be able to have a quiet place to get work done fast when necessary.

Secondly, your family must be supportive. You don’t have to be childless…I’m certainly not…but they need to understand your boundaries and the work demands on your time. I’m stating the obvious here, but the bottom line is they need to understand that you have to work and that you can’t always be ‘dad’ or ‘mom’ when you’re home.

Summary

As with answering the question of ‘why remote?’, it’s very important to know if it will work for you before trying it or before even bringing it to the attention of your hiring manager or your current employer. If you’re an independent consultant, then it’s all up to you and whether you can pull it off given your distractions at home. The decision, for the most part, is often yours.

Managing Project Change Control

In my never-ending quest to bring you different points of view on specific topics and not just subject you to whatever I decide to write, I’d like to present to you a section from Jason Charvat’s book entitled “Project Management Nation.” This portion deals with the concept of project change control. I’ve previously discussed in several of my articles ways of dealing with scope management and the handling of change orders. I will now present a similar discussion from Mr. Charvat’s book.

Project Change Control

Change can be generated by anyone, but this is not to say that the required change will be actually implemented on a project. Changes to a project may be a result of a (1) deviation or waiver, (2) issue management process, or (3) a change in scope as requested by the client.

If a deviation is identified from the agreed-upon assumptions and constraints, or if the client is unwilling to meet their obligations, a change in the project or the project targets may result. Resolving an issue may mean changing the way the project is being approached or changing scope. In many cases, there may be a clear modification to scope wherein the client requests additional functionality or deliverables, or perhaps even a reduction in functionality or deliverables.

Developers and designers sometimes introduce technical “requirements” to a project that do not actually contribute to the business success of the project. Essentially, no matter how “nice” something is, it should not be done unless there is a clear business benefit that is within the scope of the project.

Project managers should at least be aware of new requirements before they are implemented. Many projects suffer from users, business analysts, and even technical architects wandering from developer to developer and inserting “good ideas” into the project. While this is done with the best of intentions, it has a terrible impact on the schedule and must be controlled. This is not to say that all “techie” tasks should be dismissed out of hand; however, things that are necessary should be sold to the business on the basis of benefit to the business, and they should be included in the business requirements for the project.

Change Control: A Process

It is important to control the change requests that are proposed during the course of the project. The following step-by-step process will help project managers implement successful change control.

1. Initiate scope change requests by completing a scope change request form.
2. Track scope change requests by logging them in a scope change control log.
3. Determine how the scope change will be identified and prioritized.
4. Assess the impact; examine the tasks, schedule, cost, and quality affected by the scope change.
5. Select the recommended solution to the scope change.
6. Meet with the owner to accept or reject the change.
7. Implement the scope changes order, if required, and document the changes.
8. Communicate to the project team so all members understand the affect of the scope change.

Does the Project Manager Drive or Just Steer?

Sounds like an odd concept, doesn’t it? But seriously, does the project manager drive or just steer? Are they the ‘straw that stirs the drink’ (as Reggie Jackson of the NY Yankees and Darryl Strawberry of the NY Mets used to say about themselves)?  Or are they merely someone who lets others lead while they help steer the project toward a successful conclusion?

The Alternatives

In some organizations, overbearing PMO Directors want ultimate control over the portfolio of projects – even to the point of participating in all visible, critical projects on at least the status meeting level. I’m not of the opinion that PMO Directors should actually be leading many, if any, projects themselves – they should be concerned with the PMO, the overall portfolio of projects and the processes that make the PMO and the organization successful. But clearly the PMO Director who insists on participating in every visible project’s status meeting and kickoff sessions just needs more to do…they must have too much time on their hands or their responsibilities have not been clearly defined to them.

In other organizations, I’ve seen other managers have major control over a project. This most often happens on software projects where the software development manager – or possibly the tech lead – ends up with ultimate control of the project. This can happen for two reasons:

• Company policy or general practices dictate this
• Because the project manager lacks the authority, confidence or leadership ability to maintain control of his/her own project

The PM Must Take the Lead

Obviously, I’m of the opinion that the project manager is the straw that stirs the drink. The customer expects there to be one central leader on the delivery team side and customer confidence is usually much higher if that leader – that central point-of-contact – is the same individual who produces the status report, manages the budget, leads the status meeting, kicks off the project, handles the scope management and leads the delivery resources. That person needs to be the project manager. It’s what the customer expects and it’s what they should be allowed to expect.

Many of the projects I’ve been called in to fix or re-set customer expectations on or take over because customer confidence has been lost have been projects that were being led either by a business analyst acting in a dual role, a developer acting in a dual role or a project manager with little to no customer handling experience.

BAs and developers have enough on their plate without asking them to also be the organization’s main face to the customer and lead meetings and handle the normal daily project management communication and deliverables that every customer should expect. They have critical jobs to do and usually excel when they’re not interfered with and expected to lead the project.

Summary

The customer expects and strong leader on the delivery side and in order to maintain customer confidence and satisfaction, it is critical – especially on highly visible projects and projects with tight schedules and budgets. On these projects, the role of the project manager and the tasks that they perform are even more critical and should not be passed on to another manager or a talented resource on the team who is also expected to develop requirements and the ultimate solution. The project manager needs to be that straw that stirs the drink. They must be the one driving.

Managing Multiple Projects – Stagger the Lifecycles

I was reading a book on managing projects and how to handle multiple projects at once and this concept jumped out at me. Not that we don’t all know it…I think we may just take it for granted.

Re-Stating the Obvious

I’ve mentioned many times that I’ve usually been managing multiple engagements at once – and I believe that most project managers are probably in that situation much of the time. Usually, you have a group of 5-6 active projects that you’re overseeing at any given time. What I have never discussed is the concept of how you survive that – at least not in any detail. Not that I’m going to really break any new ground here…but it was a bit of a revelation (for some reason) to me that having these projects in much different points in their project life cycles is what keeps us sane. I guess I was just taking it for granted.

One of the most frustrating times I’ve had recently was about 2 years ago when I actually had to kickoff two projects within a week of each other (one was the project where my business analyst ended up crying in the hall and during a customer meeting – see “The Worst Project I Ever Managed”).

Avoid Overload

Having your project life cycles staggered is definitely one key to sanity and greatly increases your chances of success. One can not sanely go through life managing 5 projects that are at the same point in their project life cycles at the same time. The demands on the project manager vary by phase – and are weighted more heavily at the front end and usually then again around Testing and Deployment. The lull usually occurs with Design and Development – phases that require much more attention from business analysts and developers than the project manager other than general oversight and reporting.

As happened with me during that one approximate 6 week period nearly two years ago is that I kicked off two projects a week apart and then took both of them into Exploration (that’s where the breakdown occurred). Kickoff and Exploration are both PM-intensive phases and I was stretched thin along with having 4 other less time-intensive projects to manage also. I’ve written about how the situation was righted, but it still took awhile for sanity to return because even though the situation with the customer on the initially troubled project was corrected and expectations were reset, we were all still stretched too thin.

Summary

If you find yourself assigned to projects that are critical, visible, vital, etc. etc. AND they happen to have PM heavy phases overlapping, then do yourself, your customer, your team and your organization a favor and step back to assess the situation. Don’t try to be Superman. If you can’t provide each project the amount of attention that is needed, let your management know. Better to offload a project than to fail at one or more of them. Way better…. There’s nothing wrong with admitting when your plate is too full.