Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer
    
This is a great answer, and it helps me out. You are correct; the document that we made was a little ambiguous; when we scoped the work, we said that we would configure a specific piece of the application and do one specific customization. The document read "we will do basic app configuration and the specific piece of customization." The problem is that there is a lot of things that can be considered "basic app configuration." The other problem, as you noted, is that he is new in his job. He made an error telling my boss how much money he has to spend on the project. When we... –  jdb1a1 Feb 13 '13 at 13:14
    
...sent the proposal, my boss added $5k to the cost. So the other guy is trying to get his money's worth, while I am trying to keep the project on time and on budget. Anyway, thanks. –  jdb1a1 Feb 13 '13 at 13:15
1  
Hi Michael, welcome to PMSE! Thanks for the thoughtful answer, that's exactly the kind of expertise PMSE needs. +1! –  Tiago Cardoso Feb 13 '13 at 18:48
    
Very happy it was helpful. Looking forward to participating and learning from this site. A great resource! @Tiago Thank you for the +1! –  Michael Boses Feb 14 '13 at 7:13
add comment

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.

share|improve this answer
    
This is a good answer; my company doesn't DO change control, and although i have tried to use it where I can, a more formal approach would definitely be helpful. –  jdb1a1 Feb 13 '13 at 13:09
2  
As usual, a great answer, Code! One thing to bear in mind is that, although the entire organization needs to apply the change control, it needs to start somewhere... and this specific case is a great opportunity! Just highlighting this point to avoid excuses like 'if my company does do, I won't do it either'. :) –  Tiago Cardoso Feb 13 '13 at 18:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.