一個專案完成驗收不一定是100分優質的專案，但專案驗收不通過肯定不及格是失敗的。

PMP十大知識領域中的「專案整合管理 Project Integration Management」，最後一步要「結束專案或階段 Close Project or Phase」有很關鍵的Input項目【驗收的可交付成果 Accepted Deliverables】。
英文Accepted代表這是「被客戶接受」的成果。

PM時刻需記得專案原則：利害關係人「有共識」認同的規格才是允收標準。

PM、分析師或工程師自說自話設計開發得很開心，客戶、客戶的長官或是第一線使用者都不認同程式理念，即使資料結構多元、系統功能花俏，無法允收即失敗。

確保驗收通過至少必須滿足3大條件：

一、系統設計獲得「利害關係人」共識

專案辨識出「利害關係人」很大的原因，是為了認識到每個人對專案的影響力，所謂影響力可能大到一句話翻盤已經開發好的系統設計。
需求訪談時自然得對影響力高的「利害關係人」特別上心，任何的設計概念、預期成效、評估風險等等，都需要和「利害關係人」說明溝通。
有時也許PM提出的方案是為了客戶好，但客戶聽不進去不買單，切勿和客戶硬碰硬，記得「客戶認同的規格才是允收標準」，只是務必請PM將討論過程的會議紀錄詳細寫清楚「何年何月因為誰的決定而如此設計可能有何利弊」 以此來保護自家團隊。
「會議紀錄」絕對要包含「簽到表」並寄給參與者們，敘明有疑義請在N個工作天內回覆（不回覆等於默認會議紀錄沒問題），代表這份會議紀錄立刻給大家並審閱過了。
可能功能上線後客戶才發現系統不好用，為保顏面直接失憶怪罪PM不專業未能引導訪談，此時翻出清楚的會議紀錄能保命。

二、約定允收方式

前項的「會議紀錄」是允收項目的功能細節描述，PM必須記得還要和客戶訂定驗收時的「允受方式」，大致可分為2類：
1.書面驗收：可能除了「測試報告」還需包含「客戶簽核過的雙向允收表」，視專案而定。
2.實地驗收：交付履約文件以外，報驗後還需約會議現場展示功能。

除了允收方式，「允收標準」與負責允收的「利害關係人」也很關鍵。

「允收標準」以什麼文件為準，須在分析階段獲得共識。
小專案或許依「會議紀錄」就可以驗收。
一般專案應將合約、會議需求等轉換為「雙向允收表（需求雙向追溯矩陣）」，以確保每項功能有客觀的規格可供客戶有驗收標準。

若允收的「利害關係人」未在訪談階段參與，驗收時發難說系統設計不符需求的風險很高。
約定允收方式的同時，PM絕對需要再三強調應「訪談者=測試者=允收者」，否則前人提出的需求、後人無法理解目的是常見的驗收卡關問題。

三、驗收前完善規劃並溝通

按照已經約定好的驗收方式，剩下就看驗收前的準備工作充不充足了：

1.系統功能需全面性測試

完整流程順一遍、所有報表列印一次、寄信/寄簡訊/介接等功能確認⋯⋯PM不負責展示也必須看預計展示的分析師或工程師操作一次，將每個功能都與「雙向允收表」比對有無差異。
這邊所謂的「全面性測試」是演練的概念，待測試階段都沒問題了在驗收前一天再確認一次功能。
前一天這個時間點很關鍵：太早確認，若測完到驗收前的期間環境被動到，可能功能異常；太晚在驗收前一兩個小時測試，測出問題會來不及修復。

2.確保負責允收的客戶已經認同系統沒問題

PM應將「驗收」當成只是簽名「走過場」的表面會議。
客戶是否會簽名讓專案驗收通過，在驗收前早就定案了。
驗收前，應該完成所有的測試、系統展示等工項，PM需頻繁和客戶溝通，確認系統測試已沒有任何BUG或不符合契約之處，系統才算具備Accepted Deliverables的條件。

3.和客戶主窗研擬可能發生的風險與對策

若「實地驗收」PM須提前和客戶了解預計出席的「利害關係人」名單。
除了常和PM接觸的「主窗」以外，還會有高層長官、其他預期外利害關係人出現的場合，多半驗收走調有困難的機率很高。
預期外出現的人對PM來說是surprise，只能仰賴客戶主窗對他們家生態的熟悉，一起討論這些出席者的相處眉角在哪裡，準備相對的措施比較保險。
例如客戶長官個性嚴謹，每一項功能與合約每個字都必須分毫不差對上，那「雙向允收表」的準備得多費心思，契約內大小標題名稱和頁面最好都註記在「雙向允收表」，一是長官突然提問時PM可以胸有成竹回答，二來長官看到專案文件規矩細膩、覺得PM態度端正應該不太會刁難驗收。