IT 顧問項目生命週期流程圖
IT 顧問項目生命週期範本，涵蓋資格評估、建議書、合約、啟動、探索、設計、交付、品質保證、客戶驗收、交接及結案。
甚麼是it 顧問項目生命週期流程
顧問項目往往在責任轉換的位置失去連貫性：銷售人員評估商機、顧問界定工作、項目經理動員交付、技術專家建立方案、品質保證人員審閱，最後由客戶判斷結果是否符合議定驗收準則。這個範本把所有交接放在同一條橫向生命週期。流程由合適程度、預算及時間開始，把假設帶入建議書及合約，在啟動時檢查存取權及持份者是否就緒，並要求客戶先批准設計，才把可供審閱的交付增量送進內部品質保證。
本圖不綁定供應商，涵蓋一項 IT 顧問工作的商務至交付生命週期，而不是每項交付內容的詳細方法。若 RAID、變更控制、督導及階段證據需要更深入的治理圖，項目經理可使用 /yue/templates/項目治理流程。軟件實施顧問項目亦可把業務測試連到 /yue/templates/用戶驗收測試流程，而不是把本圖兩個驗收方格當成完整測試計劃。最終交接仍屬於本生命週期，因為只有文件、知識轉移、支援責任及客戶驗收完成，顧問工作才真正成為客戶可用的成效。
本流程圖涵蓋的內容
本範本包含
- 八個階段，由商機資格評估，經建議書、合約、啟動、探索與設計、交付與品質保證、客戶驗收，到結案
- 七條角色泳道，分開客戶、客戶經理、項目經理、顧問、技術團隊、品質保證及客戶審批人責任
- 建議書及合約關卡確保範圍、假設、估算及變更路徑在動員前保持一致
- 啟動前提、客戶批准設計，以及受項目 RAID、變更及預算管控的增量交付
- 獨立品質保證、客戶驗收、文件、知識轉移、責任交接及有記錄的結案經驗
何時使用本範本
- IT 顧問公司需要由合資格查詢到交付交接的一致路徑，但不想限定一種技術方法
- 銷售假設在建議書、合約、啟動及實際探索團隊之間流失
- 客戶驗收出現爭議，因為設計審批、品質準則或交付項目驗收從未明確
- 已完成工作仍依賴顧問，因為文件、知識轉移及支援責任被視為可有可無的結案工作
運作方式
界定資格及不合適準則
列明繼續所需的客戶需要、策略配合、預算範圍、時間、權限及交付能力。為客戶經理提供尊重客戶的不合適結束路徑，避免薄弱商機無限消耗建議書及技術資源。
把假設帶入合約
把範圍、客戶輸入、相依項、估算假設、驗收準則及排除內容，由建議書追溯至已簽署協議。啟動前先界定變更路徑，讓探索可以完善工作，而不會把每項新事實變成爭議。
令動員可以測試
列出開始探索所需的持份者、存取權、數據、環境、決定及客戶可用時間。為缺口指定負責人及日期，不要把舉行啟動會當成團隊可以開始有效工作的證明。
設定審閱及驗收準則
界定顧問、技術團隊、品質審閱人及客戶審批人在各階段檢查甚麼。把驗收連到議定成效及交付項目、保存審閱證據，並把變更送回可供審閱的增量，而不是留到最後才談判。
由開始設計交接
在規劃時指明客戶未來負責人、所需文件、知識分享、支援邊界、未完成行動處理及結案證據。整個交付期間都要安排知識轉移，令交接成為核實，而不是最後一次過傳送文件。
常見問題
IT 顧問項目生命週期有哪些階段？
完整生命週期會評估商機、擬定及審閱建議書、議定合約及變更路徑、動員客戶與顧問團隊、進行探索、批准設計、以可供審閱的增量交付、執行內部品質保證、取得客戶驗收、轉交文件及知識、交接責任及支援，再記錄結案。具體交付方法可以不同，但這些責任轉換不可省略。
為甚麼要分開客戶管理與項目管理？
客戶經理負責商機是否合適、建議書連貫性及商務關係；項目經理則負責動員、預測、RAID、交付協調及受控變更。小型顧問公司可以由一人兼任，但清楚分開責任可以避免銷售假設消失，亦避免在不了解商務影響時同意交付變更。
應如何界定客戶驗收？
在建議書及合約中，以與交付項目及預定成效相連的可觀察準則界定驗收。列明獲授權審批人、審閱期、證據、問題或變更路徑，以及部分驗收的處理方式。內部品質保證應先完成，但不能取代客戶判斷議定工作是否可接受。
IT 顧問項目交接應包括甚麼？
包括最新文件、適用的設定或設計紀錄、決策及變更歷史、已知問題、營運及支援程序、存取權責任、培訓或知識轉移證據、有負責人的未完成行動，以及結案後的支援邊界。客戶負責人應確認資料可以使用，而不只是確認收到檔案。