Project acceptance plan is one aspect of the project delivery that a scary number of Project Managers overlook.

This article will cover one specific part of the project risk evaluation, Project Acceptance planning and all the risks associated with project acceptance.

The risk of not having a good project acceptance plan in place could significantly jeopardize project margin and timely revenue recognition.

What many Project Managers do is to define acceptance of phases, probably five or six of them. They define several deliverables for each phase and once deliverables are accepted, the phase is accepted. And, when they get acceptance for all phases, they ask for final sign off for whole project acceptance. Then, they can proceed with project closure.

Nothing wrong with this approach in project acceptance planning, right?

What problems can we expect with this approach?

What we usually have is the client who is putting a condition for acceptance of one big deliverable or phase upon delivering some “small feature”, some extra work not in the scope. These are usually small things you can cover with contingency. On the other hand, you can easily find yourself in the situation that either these small things added up to a significant effort or that you have a requirement to deliver something that is not so small and trivial. Sometimes, you have a reluctant person not “comfortable” to accept the deliverable before checking with other team members. The document is overwhelming and takes time to analyze and confirm acceptance. All these could lead to scope creep or time lost in correcting some small issues or waiting for acceptance.

I know you covered the acceptance time frame in the contract and you have a Change Request/Control procedure in place. But we all know that, in reality, you will play that card when things are really out of control. Or, when the change requested is clearly a candidate for the CR procedure.

All those things could bring your margin down, or quarter revenue for your project is going to slip to the next one.

How to plan project acceptance, how to minimize this “acceptance” risk?

Here comes the art and creativeness of Project Management.

You want to define deliverables in a way that each one is easy for assessment and acceptance. Next, you need to define a realistic value for each of these deliverables. Now, you want to group them in “sets” that could be recognized as a milestone and invoiced. Build your milestones using this method until you cover all project deliverables.

Why does this approach for project acceptance planning work?

People are more willing to accept a big deliverable when it is just the confirmation of several smaller already accepted deliverables.

Also, if the PM needs to sign the acceptance of a huge milestone that has a big invoice amount attached to it, he will be more “reserved” to sign it off. He will try to get confirmations and sign off from other team members as well. Either to share the responsibility or to make sure that everything is delivered.

If you have smaller and regular milestones for invoices you will have less friction on signing them off. It also helps the PM on the other side to be more confident in controlling the scope and deliverables. 

All this will ensure the easier acceptance of deliverables, phases and overall projects. Also, it will put you both in an equal position when negotiating something during the execution of the project. Bear in mind, the side that has more invested (negative project cash-flow) is weaker when negotiating. One additional advantage is that with smaller deliverables you have the value on a smaller portion of phase. This allows you to defend the value of requests for additional work.

You can be as creative with this as you want. Of course, you need to negotiate it, but I never had problems accepting this approach from the PM on the other side. 

One example to help you understand:

Deliverable milestone:

Three servers delivered and environments installed as defined in RFP for the solution and training for Sysadmin. Value – 300.000 USD

Here is how you can define Acceptance plan for the above situation:

• Defined sizing of servers for the solution – 10.000 USD 
• Delivered Server for development environment – 50.000 USD
• Delivered Server for Testing environment – 50.000 USD
• Delivered Server for Production environment – 100.000 USD
• Installed development environment – 10.000 USD
• Installed Testing environment – 5.000 USD
• Installed Production environment – 5.000 USD
• Licenses – 65.000 USD 
• Trained Sys Admins – 5.000 USD

Each deliverable is easy to confirm. Cash-flow is optimal for both sides. If there are issues with any of the deliverables (i.e. server delivered is missing something) other deliverables can be accepted and invoiced. Or let’s say that your trainer is sick and cannot deliver the training at scheduled time. You postpone the training for two weeks, your acceptance for 300.000 USD is late, and you will miss revenue recognition for this quarter. So, for the sake of 5.000 USD, you need to wait for the 300.000 USD milestone.

Or let’s say that you have delivered training, but one of the trainees just resigned. The PM is asking you to deliver one more training session for the guy who will take his place. It is only three days after all. And he is dangling a 300.000 USD milestone that he is ready to sign. However, he can’t, as he needs this guy to be trained to provide support as planned. There is usually no point in arguing. And, you need to deliver to get the acceptance. If you got acceptances on everything else, it would be no big issue for you to deliver the training and even ask to be paid for additional effort.