Project Sign Off - Something Must Be Planned Right At The Beginning

For Project Manager (PM), getting project acceptance agreement (or project sign-off) is the most important achievement. It looks like professional cyclists reaching the destination after hundreds of kilometers. The winner of the tour is the one who understands the game and practices frequently. Similarly, giving the same project to project managers, you could be the one who can easily get the sign-off early or you could leave the game when you've still not reached the destination.

While most of PMs often do a very good job during the phases of execution, monitoring and control, they often get stuck at the closure phase when it looks like their project team's work will never get done. One important activity needs to be done to get the project accepted by client is doing the acceptance test (or scope verification according to PMBOK v4). However, PMs who are new to project management or lack of training cannot achieve this acceptance. The tricky point is that this activity must be planned very early even when the project is not started yet. As the result, the project team gets panic when they have tried a lot but the work seems never get done.

1. Background
    This article is to give you a full view on how the project acceptance test should be taken care (in PMBOK v4 it is called scope verification, however, in software projects the term project acceptance test is used more popularly). Sometimes, it is called User Acceptance Test (UAT) if the project team works directly to the end-users.

    Basically, the following artifacts need to be considered to get client's acceptance agreement on the project:

* Project Acceptance Criteria: defines the condition in which the project must be accepted.
* Project Acceptance Approach: defines in principle how client will validate the project for acceptance.
* Project Acceptance Test Cases: defines how the system must be tested by client (or end-users).
* Project Acceptance Agreement: a mechanism to have client's official sign-off for the project (meaning they accept to pay money).
* Project Acceptance Test Plan: defines the overall plan of how the project is validated for acceptance.

Lacking of any of above will lead the project into problems and the project likely never gets done. Now, let's see two particular problems which often happen in the real software projects.

2. Problems

Case study 1: Thanh runs a software project to create a Payroll system. After 4 months of development and testing, it is now ready for release. Thanh writes an email to inform client and asks them for testing the system but he has no response timely. He reminds client and gets the answer. Client says that it is the year end now and the Payroll staffs are busy with calculation not only for the current month but also for the whole year. They don't have time for testing until January next year. Thanh has no other choice rather than keeping the project on hold until January but then he has another problem. After two weeks of testing, the Payroll staffs feel uncertain and unconfident when they're asked for sign-off. They have played with the system according to their Payroll experience but they're worried whether it is safe to give the sign-off.

Case study 2: Tuan has been managing his project very carefully. He has got major sign-offs from client during the project life cycle including sign-off for Requirement Specification, sign-off for Architecture Document, etc. He's now moving to getting the final and the most important sign-off which is project sign-off. With the attempt to have no bug in the release for UAT (User Acceptance Test), the team has worked hard in the last few days, but unluckily there are still bugs and the deadline comes now. Tuan has decided to deliver the products to client and will have the team continuously fix the remaining bugs during 2 weeks of UAT. During the UAT, the team not only fixes the remaining bugs but also fixes the new bugs reported by client. After two weeks, bugs are still remaining and Tuan is afraid of asking client for accepting the project. So, he's decided to expand some days in order to clean all bugs. On the last day which Tuan planned for release, there're still two remaining minor bugs which make him feel a bit frustrated. However, he has to deliver the products to client as committed. After a few days, client comes back and reports six new bugs. Especially, client played with the product in strange scenarios which the team never tried and found two new bugs. Tuan has to sit down with the team again and plan for the next release with the hope to get the project accepted soon.

In case study 1, there is no consideration, no plan for Project Acceptance Test at all. PM just assumes that client will test the system after the team completes the development. This is a particular case when PMs are new to project management and lack of training on knowledge and processes.

In case study 2, PM seems to have knowledge on project management. He seems to do every activity right except lacking project acceptance criteria. He assumes the project acceptance criteria to be zero defect. Now, question for everyone who is reading to this point, do you think a project can be delivered with zero defect?

3. What should we do to quickly and safely have project sign-off?

    Firstly, the Project Acceptance Criteria (PAC) must be agreed upfront. If PM involves in the presale/bidding phase of the project, he/she should define PAC clearly. If PM involves in the project late, he/she should consider PAC as soon as possible, do not leave it until too late.

    The Project Acceptance Approach should be defined together with PAC. PM should tell client not only the condition but also the way how they will validate and test the project until it is mutually agreed/accepted.

    The next step is defining the Project Acceptance Test Plan. Normally the plan will also include or refer to Project Acceptance Test Cases, Project Acceptance Approach and Project Acceptance Agreement. Many PMs are confused when they think that their project team has the Test Plan and Test Cases and this is enough. Let me explain:

    * Normal Test Plan & Test Cases: this is normally used by project team to test the project internally. Most of the time, client doesn't really care these artifacts except when they want to understand the methodologies or the development processes of the software vendors.

    * Acceptance Test Plan & Acceptance Test Cases: this is used by client to test released software packages. If client is familiar with software development they often take care of this. Otherwise, the project team has to consult client for this. The project team can even use normal Test Plan and Test Cases and modify to produce Acceptance Test Plan & Acceptance Test Cases. No matter who provides these artifacts, the principle is that the procedure and the schedule of the test must be agreed before it is executed.

    The final step which is the most important one is asking client for signing off the Project Acceptance Agreement. This is done when the project meet the criteria defined at the beginning of the project.

    Up to now, I have mentioned a lot on PAC, acceptance approach, etc, however, I haven't given specific examples of how they really look like. You can find this in the section Templates

4. Conclusion
The project sign-off is something we can control and achieve as expected. Lance Armstrong has won 7 seasons of Tour de France which is the toughest tournament of the world because he and his team

understand the game and practice carefully. Similarly, if you understand the method, you will have client accept your project as planned. A very short review is:

* Having client agree on the criteria
* Having client agree on the acceptance test plan
* Communicating to make the plan happen
* Asking client for signing off when the project meets the criteria