How Do We Agree on “Finished” in Projects? – Project Management Life Cycle
By James Clements
When I worked as a Proposal Manager during my days in the defense industry, I remember when we’d do what was called a Gold Review, which was the final pricing review with the CEO prior to the submission of a bid. I would be pitching the bid and the Group Commercial Manager would always have the same question of me, and whilst I always knew it was coming and was prepared for it, I hated it because there were so many opportunities for me to get it wrong, as well as project’s to get it wrong in the project management life cycle.
He’d ask “What is the Acceptance Criteria?”, complete silence would fall over the room, here was a guy who’d bore the brunt of many projects that had been unnecessarily difficult to complete and if he didn’t give the CEO the nod, the bid would still be submitted, but would go in with a big fat contingency attached, we might as well not bid.
What he meant was, “demonstrate to me we know exactly what the scope of work is, it is documented in the contract set with no ambiguity, and there is clearly defined criteria against which we can measure, achieve and prove our work is complete and the project meets all the performance requirements.
Whether it’s a bid, proposal or project you need to start with the end in mind, obvious – yes, corny – yes, done well in projects – rarely!
But it’s a project killer, if you do not agree and document the acceptance criteria and develop a plan to demonstrate this to the client, this is where the classic last 5% of the project costs as much and takes as long as the first 95% of the project.
So what does this mean in practice?
You now need to define the criteria against which acceptance will occur at the end of the project management lifecycle, whether at the project level or for each individual deliverable or work pack, the level is dependent on the project. It needs to be clear and beyond doubt that the color, size, shape, quality, operation, performance or benefits of the product the contract says you will produce, does in fact tick all the boxes. There are many ways of doing this and you should decide which is best suited to your situation, three that I’ve used most are as follows;
- Requirements Management – This is where you extract each and every project ‘requirement’ from the statement of requirements if one is provided or the project specification/contract. Against each of these requirements that you identify, you state how you will measure achievement and you agree this with your client.
3rd Party Regulatory & Certification – In many industries there are usually regulatory bodies that are very prescriptive about the rules, regulations and standards for design, construction and operation of the infrastructure in it. If this applies to your project, you need to ensure that the specific standards, rules and regulations are stated in both the specification and contract and achievement of these, verified by a 3rd Party (not the client) is considered acceptance. You should have already done most of this work, in your estimating anyway.
Progressive Acceptance – In your acceptance plan you need to ensure that wherever possible acceptance is granted as each portion of the project completes so that it is not crammed into the last part of the project, this puts too much pressure on everyone concerned, including the client, who I’ve had the misfortune once to stage a go-slow with acceptance sign off because we were late, working around the clock and wanted their people on site 24/7 for the last month of the project, probably an un-reasonable request.
It’s true that we all want to satisfy the client and this should always be our ultimate goal, but a good client that knows his stuff will always push for more than what he’s paying for, it’s their job. But when they won’t accept your project or part of, you want to ensure you have a documented rule/standard/description that you can use to argue the point with.
I have seen many contracts and specifications with terms like “to the owners satisfaction”, “best engineering practices” and “at the owner’s discretion” these are killers and need to be removed from specifications and contracts at contract negotiation by offering an acceptance criteria that is agreeable to both parties. Don’t just say you don’t like the clause because the client will argue he needs to be satisfied and this is hard to mount a case against, come with an acceptance criteria already prepared you can agree to or negotiate with.
Finally, this work must be done prior to agreeing the contract or project charter with the client, it is nearly impossible to reverse engineer this after the project has started, clients always win when there is vagueness in contracts and specifications.
James Clements, MBA, MPD has been managing, directing, winning projects and developing project management processes in diverse industries around the world for the past 20 years. You can contact James via his website here and you can read more from him on his blog