project work with difficult client

Question

My company takes in projects from a variety of clients in the region I am in. One of these clients is a firm that kind of competes with us on some things, but in other ways we cooperate. The relationship there is complex. Anyway, I am managing a project where our development group configures and dumps a bunch of stuff onto their server for them. It's actually pretty drab work. It should also be noted that there is a pretty tight timeline on this particular project. We have about 2 weeks from getting the project to deployment.

Before we get the project, I collect the requirements, document the scope in a statement of work, and get it signed by all involved. A week goes by and we start executing the project according to the agreed upon scope. So now we have one week left. We have a meeting this morning and lo-and-behold - he starts trying to add a bunch of features.

What else can I do to ensure that we get as much of the requirements as possible up front? My business unit really isn't in a position to reject work; we could definitely use the business. I should also add that the other guy is pretty new to the job, and comes across as such. He also might have a small-man problem, in that he might be trying to show us all that he's large and in-charge of the project (although this is immaterial to the question).

So here's the question: How do you handle people who obliviously try to add and change scope at the worst possible time in the project life cycle?

Answer 1

I agree with CodeGnome's well-founded comments about change control procedures. However the scenario you described and your question could occur regardless of how effective your change control procedures are. For now let's assume you have good controls in place but are still concerned about "how do you handle people who obviously try to add and change scope at the worst possible time in the project life cycle?"

There are several issues in play here.

• Is the project at risk due to a lack of accurate requirements?

By asking "what else we can do to ensure that we get as much of the requirements as possible up front?" you suggest that maybe these are valid requirements that were missed. So here are some things to think about:

1. You had the right process in place (engage, document, and sign-off). Did you produce the right document? In a two week “configure and dump” project should there be Requirements and a Statement of Work or an actual Specification? If the Statement of Work was viewed as a specification by everyone than the situation is different than if you are working with a less definitive set of requirements mapped to deliverables.

2. The most obvious next place you might look is whether the process involved the right people? Compare the source of the original requirements to the actual source of the requirements that are arising now (this may take some detective work). Compare the people who signed off on the project to the people behind these new issues. One of the most common problems I see with requirements gathering is involvement of the wrong people within the customer's organization. Requirements are relayed by someone in IT who heard them from a manager who heard them from a programmer or an end-user. Then someone with no real understanding of the requirements signs the specification.

3. Even if requirements were missed, are they important enough that their exclusion places the project at risk? One thing is for certain: adding requirements at this stage in a two week project will definitely place the project at risk. With a two week “configure and dump” deliverable this is not a question of staying with a sprint. Either the deadline mattered or it didn't. Either these requirements are critical to success or they are not.

4. Sometimes the client has a valid point in saying “you guys are the experts and should have known while we don’t even understand what questions to ask.” That does not seem to be the case here. The client is also expert in the field and competes with you for business. Frankly it sounds like you should have been given a specification as opposed to having to document the requirements.

If requirements were missed it might provide an opportunity for process improvement while still meeting the deliverable date by sticking to the original requirements.

• Why is this person causing disruption?

You started to voice a question but pulled back: "What is the motivation of this person who is causing the disruption?" You mentioned that he is new, and that he might have issues with establishing his control. I think understanding his motivation has everything to do with handling the situation. Does this come from a fear (or knowledge) that he made the mistake? Is he really just trying to establish his control? Most of the time I see this type of disruption coming from someone who is unsure of the stance that they are taking and almost asking for push back that reassures them you know what you are doing.

• How does a project manager effectively control disruption?

I am sure that it is this human factor of understanding the stakeholders in a project that makes the difference between success and failure. A computer could replace the project manager if consideration to the human factors was not important. Understanding why someone is disruptive (be it change requests or something else) is the best chance you have at maintaining control. Ultimately the other person will benefit from your insight.

Answer 2

Timing is Immaterial

When you ask:

How do you handle people who...change scope at the worst possible time in the project life cycle?

you're missing the forest for the trees. It doesn't matter that the scope change comes at "the worst possible time." The issue is that your project should already have change controls in place to deal with scope issues and new specifications.

Contractual Controls

With an external client, change control is often a contractual issue. You should review your contracting process to make sure that changes to scope or clients requirements are addressed properly in during contract negotiations, although that may not help you now if this critical issue was overlooked.

Process Controls

Regardless of what framework your projects use, good project management frameworks always have a change control process of some sort.

• In traditional project management, this may be a formal change control process such as submitting new requirements to a steering committee for approval.
• In agile frameworks like Scrum, changes must be introduced through the Product Backlog for a future sprint, rather than the current iteration.

Reboot Your Change Control

If you don't have change control processes currently in place, you will need to create a new process for it. If implementing the new process requires client cooperation, then you will most likely need to pitch the change control process as a benefit to the client—perhaps in terms of lowered costs, lowered defect rates, or increased on-time performance.

The most important thing is not to go it alone. Your entire organization must get behind the need for change control, the necessity of engaging your client constructively within the new process, and the absolute requirement to support the project team in the face of client opposition to agreed-upon change controls.

Answer 3

Communication is key. At times, you might need to over-communicate to keep your stakeholders in sync. Creating rapport and building trust takes its own sweet time.

As a service provider, the number of features you deliver or the number of tickets you close will be your currency. Defining your invoice cycle with your SPOC will hasten the sign-off process.

Meanwhile, you will have to motivate your employees to curb attrition. A well-defined KRAs will aid your employees to deliver effectively.

The most important skill that could help the project manager sail through is soft skill.

Today, realistically speaking, the survival of the fittest wins the game.

Answer 4

Great answers by both Todd and Michael, though I think a bit more focus on the guy new to the job is warranted. Hardening your processes will most certainly help but I think you have the game of politics here for which you need devote a considerable amount of energy.

Notwithstanding the mission agenda we all support in our jobs, all of us have a personal agenda that we push everyday to achieve that may or may not be consistent with our organization's agenda at any given time. Whether that person's personal agenda lines up with your project who knows. But I think you need to understand that this guy has a personal agenda, it will never go away, you have zero chance of changing it, and you need to find away to uncover what it is and exploit it in such a way that your project is impacted favorably at least in most cases.

So you need to build a better relationship with this person, a different kind of relationship than perhaps what you're accustomed to. And when you discover what his agenda is, then you need to feed it. You don't do that by allowing your scope to run amok and to disregard solid, proven processes. You figure out a way to do it earlier in the game so your project does not suffer.

Since it's politics, it's hard to give you a step 1, step 2, and step 3. And I am personally not that great at the game. I have just come to learn it's there and a huge part of work and a part of work where processes don't do much for you.

So, with the other two great answers, give politics some thought, too.