How Pro’s Deal With Project Change

A big thanks to Uncommon Elite for keeping this newsletter free.

I know many of us have a business coach, or need one.

When you work one on one with the coaches at Uncommon Elite, you work with the best.

They are all former Navy SEALS, Green Berets, or Night Stalkers and also lead successful small businesses.

Imagine having someone like that on your side, 24/7. You’ll have weekly calls with them, and they’ll help you perform better than your “A” game.

Nothing is certain but death, taxes, and project change.

Change in projects is a question of when. Not if.

If you know that, you make a plan on how to deal with change, right?

I didn’t in one of my first projects, and it nearly cost me my job…

It’s a classic story of a young and hungry guy who is trying to impress the boss with one of his first bigger projects.

As with all projects, we got change requests from the client during execution.

Eager beaver Jasper analyzed the requests and decided they were indeed critical to project success. I accepted the change and got busy implementing it, and that was a huge mistake.

I accepted the change. Me, myself, and I.

While we were working on the changed scope, the client asked the sponsor about our progress on the change. She said that this was not part of the agreement, but the client said it was.

Long story short: they got into an argument about scope, brought up contracts and it almost escalated. Until she involved me, and I had to explain that I accepted the changes without telling her.

The client was right, and she looked like a fool. Not a great move…

I got away with it, and we delivered a great project. But I vowed to never mess up change requests again. Here’s how I handle them today:

What is a change request?

You’ve initiated your project, got everything planned out, and head down into execution. And then, something pops up. There are different kinds of change that we’ll cover soon. But let’s set the definition first:

A change request is a formal request to deviate from your baseline plan.

You’ve made your plan, and for some reason, someone thinks it should be done differently after all. This is often scope, but can also be budget, people, timeline, quality requirements - the list is endless.

Change is usually brought up by the client or someone on your team, but I’ve seen the change coming from the most unexpected directions. From CEOs that heard something at the country club (true story) to regulatory change.

Not all change is created equal

There are 4 broad categories of change:

1. Strategic: This is a large-scale change in the overall direction of the organization or client relationship. It has a big impact on your project and usually means you have to (partially) rewrite your project plan. Example: company-wide reorganization.

2. Anticipated: This blurs the line between change management and risk management. You expected this kind of change, and you have a plan in place. Example: the new innovative tech platform is a year delayed. (Surprise!)

3. Reactive: These changes are unexpected but not as dramatic as strategic change. They require adjustment, not reinvention of your plan. Example: A key team member leaves.

4. Incremental: This is the most dangerous kind of change and is often closely related to scope creep. None of these are a red flag, but combined they are a serious issue. Example: ongoing scope adjustments or feature additions.

In any case, change management starts with change identification. Sounds obvious, but change often sneaks its way into a project.

And that’s why you should make a change management plan.

Your change management plan

A change management plan sounds like a pile of paperwork. But trust me, it’s not, and it’s worth the effort.

It involves thinking through how you’ll deal with change when it hits, and can often be re-used for future projects.

A change management plan ensures that you answer the most important questions that you also answered when you planned your project:

• Who

• What

• Why

• When

• Where

• How

Let’s walk through the steps 1 by 1.

Step 1: Change management roles

You need to establish beforehand who can:

• Request a change

• Evaluate a change request

• Authorize a change request

Note to self: “Me” is not the right answer.

This often means a select few team members & client representatives who request, you plus key team members evaluate, and the sponsor + client authorize.

Step 2: Standardize change requests

A simple form is often more than enough. Just putting this up as barrier will already make sure you only get the serious requests, and it means you’ll get all the information you need to evaluate it.

Your form should make sure that a requester explains clearly what they want, why they want it, and what the impact is. This helps you in your evaluation.

Step 3: Evaluate incoming changes

When you get a change, you’ll need to assess the impact and make a recommendation whether to accept it or not.

We covered the 4 variables in a newsletter a few weeks ago. This tweet sums it up:

A change always has primary impact on of those variables. But if you touch one, you touch all 4. Think through the consequences of accepting the change.

Based on that, make a recommendation for your steering committee about accepting the change or not, and explain clearly what the impact is.

“Business critical, 2-week delay, $1M extra contract value. I suggest we do it, but under the condition of X, Y, and Z.”

That’s the conversation you want to have with your steering committee.

Step 4: Build a changelog

A changelog is a document where you track all change requests. You mark them as accepted or rejected, and summarize what the impact of the decision is.

A changelog will help you keep track of the overall project, as many small changes add up to big deviations.

Step 5: Communicate your changes

This sounds obvious, but gets missed often. If you accept changes, tell your team and your stakeholders about it.

Tell them what change you’ve accepted and what the impact is. Then explain how you’ll deal with the change and what parts of the initial plan are adjusted.

Project management is communication. Make the implicit explicit, and manage expectations. And above all: check if you were understood.

Step 6: Implement and control the change

Once you’ve approved and communicated the change, you’ll need to make sure it gets done. Put checks in place when you accept the changes, and mark them as done in your changelog when the change is implemented.

Communicate to the steering committee and the person who requested the change that you’re done, and move on with implementation.

Wrapping up

I know what you’re thinking: this sounds like work.

And you’re right. It is work. But in practice:

• 90% is the same for every project you do

• In smaller projects, most steps involve the same people

• Authorizing changes by the steerco can be batched or even sent as email. Not nearly as formal or cumbersome as it sounds.

Controlling change, risk, and stakeholders are the differentiations between technical project managers and real project leaders.

Build a process, follow it, and turn change from a risk into an opportunity to stand out.

Interested in getting your brand in front of 11,000 project managers & decision-makers? There are a few sponsorship slots left for the summer! Reply “sponsor” and I’ll get back to you with key numbers and a proposal!

That’ll do for this week. Next week, we’re digging into a big one: remote teams. Have any questions or ideas for me to include? Hit reply and let me know!

Cheers,
Jasper