Never Say No - Managing Change in a Project

So, your project is up and running. You've defined Project Requirements and had them signed off in blood by the sponsor. All you need to do now is watch your New Model Army get on and deliver. Right? Ahhh no. Life is never that simple, and you can reasonably safely bet hard currency that the requirements will change during delivery. Managing those changes is a potential cause of massive disruption to your project and your relationship with the client if you don't do it well.

Never Say No To a Client

Change is Bad

It's often said that Salespeople never say No. And it's often true - whatever the customer asks for, they invariably say Yes, we can do that. And Project Managers generally hate that as it paints us into a corner where our projects are not under our control. Some PMs therefore retreat into a Yoda-like mantra:

• Saying Yes leads to Change
• Change leads to Lack of Control
• Lack of control leads to Suffering (which is a PM technical term for missing deadlines, budgets or quality objectives)

But as a client-facing PM, you soon learn that to say No is just unacceptable to most clients. It's seen as pure stonewalling; that you're not prepared to be cooperative, or (worse) that your team just isn't competent. Either can cause you serious problems in your sponsor relationship, maintaining which is one of your top priorities.

Change is Good

On the other hand, saying Yes to client requests tends to result in more work. In the other Yoda mantra:

• Saying Yes leads to Change
• Change leads to More Work
• More Work leads to Happiness (another PM technical term for Increased Project Revenue and Gross Profit, which you're often responsible for)

Balance - a Neat Trick

Balancing between stonewalling (pretending that nothing can be changed and rejecting all proposed changes) and accepting all proposed changes and causing major project control problems is a tough act. Trying to work it out mid-project is even tougher. Trying to work it out on the hoof is nigh on impossible. Here's the basic magic formula - if you take nothing else away from this article, take the following sentence. Put it in your wallet, stick it to your monitor, brand it on the back of your hand:

Your request makes sense, but it raises potential risks and issues that might cost time and money.

Use The Sentence even if the client request doesn't make sense. Some requests will, some won't, but The Sentence usually ends up with one of 2 results:

1. Client backs off
2. Client agrees to more time, more money or lower quality

In either case, it's a useful holding action that then lets you wheel out the Change Control Process that you thoughtfully included in your standard statement of work.

Change Control Process

This is a process to consistently handle the inevitable Change Requests that crop up mid-project, ensuring that the good ones get through, with associated adjustments to the cost/time/quality Holy Trinity, but the bad ones don't. You maintain control of your project, you're contractually covered, the client gets what they want, but pays for it if necessary.

What is a Change Request?

This one's easy: A Change Request is any request that changes the Project Requirements.

Do We Need a Change Control Process?

Again, easy. Yes. Every project must have a change process. Every change request must use it.

Time and time again, I've heard inexperienced clients, developers and sales people starting to say things like: This project is too small/rapid/ low-budget to have a change process. or This change is too small to go through change control. To which I invariably respond: Only if the project policy is to refuse all change requests - which is of course a change process, just a really simple one to operate - or find yourselves another PM.

Strict? Yes. But here's why: because Project Requirements are a contractual document, any change to Requirements is also a contractual document. If the appropriate project authorities (the Sponsor and you) haven't signed up to a Change to the Requirements, you will fail UAT, your project won't be accepted by the sponsor, and there's a good chance you won't be paid.

Here's an example: a stakeholder has a wizard wheeze. It's a pretty simple change to the requirements and won't take much effort to implement. Realising this, the stakeholder takes it straight to one of the developers, who codes it up and tests it in a couple of hours. Doesn't break anything else, doesn't noticeably impact timescales or budgets. But come UAT, the Sponsor notes that the delivered site doesn't match the requirements, and rightly asks Where did I agree to this? You cannot allow your project to get to that point, because the only honest answer is You didn't with the enevitable followups of When did you agree to it? and Who died and gave you authority over what I want. That's A Bad Place to be.

You don't need to follow the same process for small CRs as large ones, though. You can use a light weight process for small CRs, as long as the 2 processes are documented and agreed, including - vitally - the definition of a small CR.

Sample Change Control Process

Here's an example of a simple Change Control Process. It's not the only possible process you could use, but it is in line with most PMI- compliant methodologies, so would be generally accepted by most professionally run projects.

1. Someone submits a CR. You need to agree and document who is able to do this.
2. Assess the CR to see if it's worth investigating. Here, you need to work out how long it's going to take to analyse the impact of the CR, and compare that with the projected benefits. This is a quick preflight check to weed out the obvious non-starters. If it's going to take a week just to work out how much change is involved, and the benefit is tiny, or there's not a hope in hell of it being accepted (for example, it changes the objective of the project) then this gets thrown in the bucket of CRs that are a waste of time from the outset.
3. Document and Communicate. Essential for all outcomes of any process.
4. Analyse the impact. Answers the questions: If we implement the change, how is it going to hit the Holy Trinity? What's the Risk?

   To do this, you will possibly need to replan a large chunk of the project - schedules, WBS, staffing, budgets and all. You may need time from developers for them to contribute - time they would otherwise spend delivering the project.

   You must have allowed for this in your original budget and schedule, and have it explicitly written into your contract. Avoiding doing this unnecessarily is why you had the pre-assessment in step 2.

5. Document and Communicate
6. Approve the CR? This is where you take your assessment and put it in front of your sponsor. It's then the sponsor who decides whether the CR should go ahead, accepting the changes in Schedule, Cost, Quality and Risk. If the sponsor decides against the CR, you've been co-operative and (I hope) objective in putting it forward, and you're not the one saying No.
7. Document and Communicate
8. Document and Communicate
9. Implement Change

Which is where your developers think the real work starts.