I was recently hired as the consulting project manager lead for a client who was on a tight budget. At project kickoff time he made a peculiar announcement: “No change orders, period.”

The only other time I had ever heard of such a thing was when I was working at a company that no longer exists. The CEO wanted to land a very large project so badly that he announced there would be no change orders on the whole project no matter what. It was a gutsy move and it won him the contract.

To find yourself in a situation where there’s a limited budget and an imposed “no change orders” rule is a little scary. Especially when you’re the PM with the target on your head and you know that something always comes up, requirements change, a business process gets overlooked. Change happens!

It’s a tough situation all around, but here’s a 3-point plan that I followed when I handled my No Change Orders project.

Gather the team and give the guidelines

First, I met with the project team to discuss the situation. I let them know that budget management was going to be crucially important. I laid out some rules: Don’t do any work that isn’t specifically included in the requirements; no gold plating, and be sure to raise any concerns of scope issues as soon as one appears.

Since big software companies issue change orders quite often, I wasn’t sure if our “no change orders” rule was going to be absolutely literally followed. But since it was all I had to go on, I knew that if we did propose one, it better be just one and it better be a good one. And I mentally prepared myself for a project destined to include a fair amount of negotiation skills.

Re-assess your schedule

Next, I worked with the team to review our schedule. It was imperative that we spent extra in the planning phases and had our requirements properly mapped out – and that the proper amount of planning time was built into the schedule. Then, I shifted some of what I hoped was padded development hours (after talking with my development team) into requirements planning because I knew it was critical that we get requirements right at the start of this project, and we couldn’t leave much of that work up to just the customer to handle.

Develop requirements matrices

I like to do detailed requirements matrices that let us take the requirements we work out from the customer – in detail – and tie them into the design of the project solution. This definitely helps when it’s time for testing and customer user acceptance testing (UAT). But the process also gives design and development resources a check-off process, that guarantees that the proper functionality has been built into the solution. The requirement matrices are also a nice check off to hand to the customer to show that you’ve covered every detail that was to be built into the solution.

How did the No Change Order turn out?

In the end, we had to propose two change orders. They weren’t large; they were for two reports that the customer deemed absolutely necessary but had not included in the initial requirements. So, it was not an oversight by the delivery team. And thankfully, the changes weren’t budget breakers or showstoppers for the customer.

At the end of the project, we had a satisfied customer who knew we had done everything we could to stay on budget. Due to all our extra planning, the budget did go over by 6%, but it was worth it to deploy the solution to a happy customer, and my client was pleased with our overall project performance as well.

Have you ever experienced a No Change Order mandate? How did it work out? Share your story with us in the comment section below.