心智圖資源庫 PMP知識圖譜
PMP的知識圖譜,總結了專案整合管理、專案範圍管理、專案進度管理、專案成本管理、專案品質管理等 。
編輯於2024-01-20 18:06:07Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
基礎知識
專案特點
獨特性
產品
服務
成果
臨時性
目標達成
無法達成
資源不足
法律其他
創造商業價值
有形
貨幣資產
股東權益
無形
商譽
品牌認知度
專案驅動變革
目前狀態
未來狀態
專案啟動背景
符合法規、法律或社會要求
有毒材料
市政工程
滿足相關方的要求或需求
衛生教育
創造、改進或修復產品、流程或服務
實施六西格瑪
市政工程修復
執行、變更業務或技術策略
經費變更
降低生成版本
專案管理模式
獨立專案
不包括在專案組合或專案集中
專案集
一組相互關聯且協調關聯的項目、子項目集和項目集活動
獲得分別管理所無法獲得的利益
專案集和專案管理的重點在於以「正確」的方式進行專案集和專案
項目組合
為實現策略目錄而組合在一起管理的專案、專案集、子專案組合和營運工作
專案組合管理著重於開展「正確」的專案集和項目
項目與營運
階段關口
審查依據
專案商業論證
專案章程
專案管理計劃
效益管理計劃
作出決定
進入下一個階段
整改後進入下一個階段
結束專案
停留在當前階段
重複階段或某個要素
五大過程組
啟動
規劃
執行
監控
收尾
專案管理過程群組
專案生命週期
預測型(瀑布)生命週期
在生命週期的早期階段確定專案範圍、時間和成本。對任何範圍的變更都要仔細管理。
迭代型生命週期
迭代方法是透過一系列重複的循環的活動來開發產品。
增量型生命週期
透過在預定的時間區間內漸進增加產品功能的一系列迭代來產出可交付成果。
適應型(敏捷)生命週期
詳細範圍在迭代開始之前就已經定義和批准了。適應型生命週期也稱為敏捷或變更驅動型生命週期。
混合型生命週期
預測型生命週期和適應型生命週期的組合。
專案管理數據和訊息
商業文件
專案商業論證
文件化的經濟可行性報告,用來對尚缺乏充分定義的所選方案的效益進行有效性論證,是啟動後續專案管理活動的依據。
商業論證列出了專案啟動的目標和理由。它有助於在專案結束時根據專案目標衡量專案是否成功。
在專案啟動之前通過商業論證,可能會作出繼續/終止專案的決策。
專案效益管理計劃
對創造、提高和維持專案效益的過程進行定義的書面文件。
說明
專案發起人通常負責專案商業論證文件的製定和維護。
專案經理負責提供建議和見解,使專案商業論證、專案管理計劃、專案章程和專案效益管理計劃中的成功標準一致,並與組織的目的和目標保持一致。
需求評估
需求評估通常是在商業論證之前進行,包括了解業務的目的和目標、問題及機會,並提出處理建議。需求評估結果可能會在商業論證文件中進行總結。
識別問題或機會
辨識待解決的問題或待尋求的機會的過程。
評估當前狀態
檢查所分析的當前環境以了解組織內部或外部的重要因素的過程,這些因素可能是問題或機會的原因。
確定將來狀態
確定現有的能力中存在的差距,以及為了達到所期望的將來狀態而需要提出一系列變更的過程,以解決分析中存在的問題或抓住分析中出現的機會。
確定可行選項和提供建議
應用各種分析技術來檢查可能的解決方案的過程,這些解決方案可以滿足商業目的和目標,並確定哪些選項是組織所追求的最佳方案。
引導產品路線圖開發
支援產品路線圖開發的過程。產品路線圖在高層上描繪了產品的哪些方面計劃在專案組合、專案集,或一個或多個專案迭代或發布的過程中交付,以及這些方面交付的潛在順序。
組合商業論證
綜合經過深入研究和分析的訊息,以支持選擇最佳的項目組合組件、項目集或項目,從而打成商業目的和目標的過程。
支援章程開發
利用在需要評估和商業論證開發工作中獲得的商業分析知識、經驗和產品信息,與發起人實體和相關方資源協作開發章程的過程。
專案效益管理計劃
目標效益
例如預期透過專案執行可以創造的有形價值和無形價值;財務價值體現為淨現值;
目標效益策略一致性
例如專案效益與組織業務策略的一致程度;
實現效益的時限
例如階段效益、短期效益、長期效益和持續效益
效益責任人
例如在計劃確定的整個時限內負責監督、記錄和報告已實現效益的負責人
測量指標
例如用於顯示已實現效益的直接測量值和間接測量值
假設
例如預期存在或顯而易見的因素
風險
例如實現效益的風險
事業環境因素
事業環境因素(EEFs)是指專案團隊無法控制的,將對專案產生影響、限製或指令作用的各種條件。這些條件可能來自於組織的內部和(或)外部。事業環境因素是許多專案管理過程,尤其是大多數規劃過程的輸入。這些因素可能會提高或限制專案管理的靈活性,並可能對專案結果產生正面或負面的影響。
組織內部的事業環境因素
組織文化、結構與治理
例如包括願景、使命、價值觀、信念、文化規範、領導風格、階級制度和職權關係、組織風格、德道和行為規範。
設施和資源的地理分佈
例如包括工廠位置、虛擬團隊、共享系統和雲端運算。
基礎設施
例如包括現有設施、設備、組織通訊管道、資訊科技硬體、可用性和功能。
資訊科技軟體
例如包括進度規劃軟體工具、組態管理系統、進入其他線上自動化系統的網路介面和工作授權系統。
資源可用性
例如包括合約和採購限制因素、獲得批准的供應商和分包商以及合作協議。
員工能力
例如包括現有人力資源的專業知識、技能、能力和特定知識。
組織外部的事業環境因素
市場條件
例如包括競爭對手、市場佔有率、品牌認知度和商標。
社會和文化影響和問題
例如包括政治氛圍、行為規範、道德和信念。
法律限制
例如包括與安全、資料保護、商業行為、僱用和採購有關的國家或地方法律法規。
商業資料庫
例如包括標竿對照成果、標準化的成本估算資料、產業風險研究資料和風險資料庫。
學術研究
例如包括產業研究、出版品和標竿對照成果。
政府或行業標準
例如包括與產品、生成、環境、品質和工藝有關的監督機構條例和標準。
財務考慮因素
例如包括貨幣匯率、利率、通貨膨脹率、關稅和地理位置。
物理環境因素
例如包括工作環境、天氣和限制因素。
組織過程資產
組織過程資產是執行組織所特有並使用的計畫、流程、政策、程序和知識庫,會影響對特定專案的管理。
組織過程資產包括來自任何(或所有)專案執行組織的,可用於執行或治理專案的任何工件、實踐或知識,也包括來自組織以往專案的經驗和歷史資訊。
組織流程資產可能還包括完成的進度計劃、風險資料和掙值資料。
組織過程資產是許多專案管理過程的輸入。
由於組織流程資產存在於組織內部,在整個專案期間,專案團隊成員可對組織流程資產進行必要的更新與增補。
分類
過程、政策和程序
第一類資產的更新通常不是專案工作的一部分,而是由專案管理辦公室(PMO)或專案以外的其他職能部門完成。更新工作僅須遵循與流程、政策和程序更新相關的組織政策。有些組織鼓勵團隊剪裁專案的模板、生命週期和核對單。在這種情況下,專案管理團隊應根據專案需求裁剪這些資產。
組織用於執行專案工作的流程與程序
啟動和規劃
指南和標準,用於裁剪組織標準流程和程序以滿足專案的特定要求
特定的組織標準,例如政策(如人力資源政策、健康與安全策略、安保與保密政策、品質政策、採購政策和環境政策)
產品和專案生命週期,以及方法和程序(如專案管理方法、評估指標、流程審計、改善目標、核對單、組織內部使用的標準化的流程定義)
範本(如專案管理計畫、專案文件、專案登記冊、報告格式、合約範本、風險分類、風險描述範本、機率與影響的定義、機率與影響矩陣,以及相關方登記冊範本)
預先批准的供應商清單和各種合約協議類型(如總價合約、成本補償合約和工料合約)
組織知識庫
第二類資產是在整個專案期間結合專案資訊而更新的。例如,整個專案期間會持續更新與財務績效、經驗教訓、績效指標和問題以及缺陷相關的資訊。
組織用來存取資訊的知識庫
配置管理知識庫,包括軟體和硬體元件版本以及所有執行組織的標準、政策、程序和任何專案文件的基準
財務資料庫,包括人工時、實際成本、預算和成本超支等方面的信息
歷史資訊與經驗教訓知識庫(如專案記錄與文件、完整的專案收尾資訊與文件、關於以往專案選擇決策的結果及以往專案績效的信息,以及從風險管理活動中獲取的資訊)
問題與缺陷管理資料庫,包括問題與缺陷的狀態、控制資訊、解決方案以及相關行動的結果
測量指標資料庫,用來收集與提供過程和產品的測量數據
以往專案的檔案(如範圍、成本、進度與績效衡量基準,專案日曆,專案進度網圖,風險登記冊,風險報告以及相關方登記冊)
組織治理框架
專案治理架構提供專案經理和團隊管理專案的結構、流程、決策模式和工具,同時對專案進行支援和控制,已實現專案的成功交付。
專案治理由專案組合、專案集或發起組織來定義,並要與之相適應,但需要與組織治理分開。專案治理需要幹係人的參與,需要依據書面政策、流程和標準,需要規定職責和職權。
專案成功標註和可交付成果驗收標準
協調專案治理和組織策略的指南
用於識別、升級和解決專案期間的問題的流程
專案生命週期方法
專案團隊、組織團體與外部利害關係人之間的關係
階段關口或階段審查流程
專案組織圖,其中定義了專案角色
超出專案經理權限的預算、範圍、品質和進度變更的審批流程
資訊溝通的流程和程序
保證內部關係人遵守專案流程要求的流程
專案決策流程
組織結構類型
專案管理辦公室
Project Management Office(PMO)
分類
支持性
資源庫
最佳實踐
訓練
經驗教訓
控制型
支援
服從
方法論
模板工具
治理
指令型
直接管控
專案經理
指定
報告
支持者
項目審計
遵守程度
制定管理
組織過程資產
管理
共享資源
協調
跨專案溝通
決策者
提出建議
知識傳遞
領導
終止項目
項目相關方
相關方是指可能影響專案決策、活動或結果的個人、群體或組織,以及會受或自認為會受專案決策、活動或結果影響的個人、群體或組織。專案相關方可能來自專案內部或外部,可能主動或被動參與項目,甚至完全不了解專案。專案相關方可能對專案施加正面或負面影響,也可能受專案的正面或負面影響。
內部相關方
發起人
資源經理
專案管理辦公室(PMO)
專案組合指導委員會
專案集經理
其他專案的專案經理
團隊成員
外部相關方
客戶
最終用戶
供應商
股東
監管機構
競爭者
發起人
發起人是為專案提供資源和支持的個人或團體,負責為成功創造條件。從提出初始概念到專案收尾,發起人一直在推動專案的進展,包括遊說更高層的管理人員,以獲得組織的支持,並宣傳專案為組織帶來的利益。在整個啟動過程中,發起人始終領導著項目,直到項目正式批准。發起人對制定專案初步範圍與章程也扮演著重要的角色。對於那些超出專案經理控制範圍的事項,將向上報告給發起人。發起人可能也參與其他重要事項,如果範圍變更審批、階段末評審,以及當風險很大時對專案是否繼續進行作出決定。專案發起人也要保證專案結束後專案可交付成果能夠順利移交給相關組織。
注意:不要輕易麻煩發起人
專案經理
角色和定義
職能經理
專注於對某個職能領域或業務部門的管理監督
營運經理
負責確保業務營運的高效性
專案經理
是由執行組織委派,領導團隊達成專案目標的個人
PM影響
專案
實現
專案目標
相關方期望
溝通
組織
互動
其他專案經理
配合發起人
政治問題
戰略問題
知識管理
學習
轉移整合
報告
職能經理
項目集等
跨領域
傳播專案管理方法
專業學科
傳遞
整合
知識
產業
關注
應用
新趨勢
PMI人才三角
權力分類
人身
參照
專家
魅力
職位
正式
獎勵
處罰
加壓
複合
資訊
情境
人際
關係
迎合
愧疚
說服
迴避
領導力風格
放任型
例如,允許團隊自主決策和設定目標,又被稱為“無為而治”
交易型
例如,專注於目標、回饋和成就以確定獎勵,例外管理
服務型
例如,作出服務承諾,處處先為他人著想;關注他人的成長、學習、發展、自主性和福祉;關注人際關係、團隊與合作;服務優先於領導
變革型
例如,透過理想化特質和行為、鼓舞性激勵、促進創新和創造,以及個人關懷來提高追隨者的能力
魅力型
例如,能夠激勵他人;精神飽滿、熱情洋溢、充滿自信;說服力強
互動型
例如,結合了交易型、變革型和魅力型領導的特點
馬斯洛需求層次理論
生理需求
這些是指基本的身體需求,如口渴時喝水或餓了吃東西。根據馬斯洛的說法,其中一些需求涉及我們努力滿足身體對體內平衡的需求;也就是說,在不同的身體系統中保持一致的水平(例如,保持98.6°的體溫)。 馬斯洛認為生理需求是我們最基本的需求。如果有人缺乏不只一種需求,他們可能會先嘗試滿足這些生理需求。例如,如果某人非常餓,除了食物之外,很難專注於其他任何事情。生理需求的另一個例子是需要充足的睡眠。
安全需求
一旦人們的生理需求得到滿足,下一個需求就是一個安全的環境。即使在童年早期,我們的安全需求也很明顯,因為兒童需要安全和可預測的環境,當這些需求得不到滿足時,通常會做出恐懼或焦慮的反應。馬斯洛指出,在生活在已開發國家的成年人中,安全需求在緊急情況(例如戰爭和災難)中更為明顯,但這種需求也可以解釋為什麼我們傾向於喜歡熟悉的東西,或者為什麼我們做一些事情,例如購買保險和為儲蓄帳戶供款。
不成功的領導
愛與歸屬感-社交需求
根據馬斯洛的說法,等級制度中的下一個需求包括感到被愛和被接受。這種需求既包括浪漫關係,也包括與朋友和家人的聯繫。它也包括我們需要感覺自己屬於一個社會群體。重要的是,這種需求包括感受到被愛和感受到對他人的愛。 自馬斯洛時代以來,研究人員一直在探索愛和歸屬感需求如何影響幸福感。例如,擁有社會關係與更好的身體健康有關,相反,感到孤立(即歸屬感未被滿足)會對健康和福祉產生負面影響。
尊重需求
我們的自尊需求包括自我感覺良好的願望。根據馬斯洛的說法,尊重需求包括兩個組成部分。首先是感到自信和自我感覺良好。第二個組成部分包括感到被他人重視;也就是說,感覺我們的成就和貢獻得到了別人的認可。當人們的尊重需求得到滿足時,他們會感到自信,並將自己的貢獻和成就視為有價值和重要。然而,當他們的自尊需求沒有得到滿足時,他們可能會經歷心理學家阿爾弗雷德·阿德勒(Alfred Adler)所說的「自卑感」。
一般的領導
自我實現
自我實現是指感到滿足,或感覺我們正在發揮自己的潛能。自我實現的一個獨特特徵是,每個人看起來都不一樣。對於一個人來說,自我實現可能涉及幫助他人;對另一個人來說,它可能涉及藝術或創意領域的成就。從本質上講,自我實現意味著感覺我們正在做我們認為我們應該做的事情。根據馬斯洛的說法,實現自我實現是相對罕見的,他著名的自我實現個體的例子包括亞伯拉罕林肯,阿爾伯特愛因斯坦和特蕾莎修女。
成功的領導
十大知識領域
專案整合管理
概述說明
專案整合管理包括對隸屬於專案管理過程群組的各個流程和專案管理活動進行識別、定義、組合、統一和協調的各個流程。
資源分配
平衡競爭性需求
研究各種備選方法
為實現專案目標而裁剪過程
管理各個專案管理知識領域之間的依賴關係
制定專案章程
專案章程是編寫一份正式批准專案並授權專案經理在專案活動中使用組織資源文件的過程。這個過程的主要角色是,明確專案與組織策略目標之間的直接聯繫,確立專案的正式地位,並展現組織對專案的承諾。
專案章程在專案執行組織與需求組織之間建立起夥伴關係。在執行外部專案時,通常需要用正式的合約來達成合作協議。在這種情況下,仍可能要用專案章程來建立組織內部的合作關係,以確保正確交付合約內容。專案章程一旦被批准,就標誌著專案的正式啟動。在專案中,應儘早確認並任命專案經理,最好在製定專案章程時就任命,且總應在規劃開始之前任命。專案章程可由發起人編制,或由專案經理與發起機構合作編製。透過這種合作,專案經理可以更了解專案目的、目標和預期效益,以便更有效地向專案活動分配資源。專案章程授權專案經理規劃、執行和控制專案。
專案由專案以外的機構啟動,如發起人、專案集或專案管理辦公室(PMO)、專案組合治理委員會主席或其授權代表。計畫啟動者或發起人應該具有一定的職權,能為計畫取得資金並提供資源。專案可能因內部經營需求或外部影響而啟動,故通常需要編制需求分析、可行性研究、商業論證或有待專案處理的情況的描述。透過編制專案章程,來確認專案符合組織策略和日常營運的需要。不要把專案章程看做合同,因為其中未承諾報酬或金錢或用於交換的對價。
ITTO
輸入
商業文件
商業論證
雖然商業文件是在專案之前製定的,但需要定期審核。
經批准的商業論點或類似文件是最常用於制定專案章程的商業文件。商業論證從商業視角描述必要的信息,並且據此決定項目的期望結果是否值得所需投資。高於專案層級的經理和高階主管通常使用該文件作為決策的依據。一般情況下,商業論證會包含商業需求和成本效益分析,以論證專案的合理性並確定專案邊界。
效益管理計劃
協定
協議用於定義啟動專案的初衷。協議有多種形式,包括合約、諒解備忘錄(MOUs)、服務等級協議(SLA)、協議書、意向書、口頭協議、電子郵件或其他書面協議。為外部客戶做專案時,通常會以何用的形式出現。
事業環境因素
組織過程資產
能夠影響制定專案章程過程的組織過程資產包括(但不限於)
組織的標準政策、流程和程序
專案組合、專案集和專案的治理架構(用於提供指導和製定決策的治理職能和流程)
監督和報告方法
範本(如專案章程範本)
歷史資訊與經驗教訓知識庫(如專案記錄與文件、關於以往專案選擇決策的結果及以往專案績效的資訊)
工具與技術
專家判斷
專家判斷是指基於應用領域、知識領域、學科和行業等的專業知識而做出的,關於當前活動的合理判斷,這些專業知識可來自具有專業學歷、知識、技能、經驗或培訓經驗的任何小組或個人。
獲取管道包括(但不限於)
組織內的其他部門(FM)
顧問
相關方,包括客戶或發起人
專業與技術協會
產業協會
主題專家(SME)
主題專家指精通某一領域或主題的專家。
專案管理辦公室(PMO)
數據收集
腦力激盪
用於在短時間內獲得大量創意,適用於團隊環境,需要引導者引導。
腦力激盪由兩個部分構成:創意產生和創意分析。
制定專案章程時可透過腦力激盪向相關方、主題專家和團隊成員收集數據、解決方案或創意。
補充:延遲評價,追求數量。
焦點小組
焦點小組召集相關方和主題專家討論專案風險、成功標準和其他議題,比一對一訪談更有利於互動交流。
焦點小組是召集預定的相關方和主題專家,以了解他們對所討論的產品、服務或成果的期望和態度。有一位受過訓練的主持人引導大家進行互動式討論。焦點小組往往比「一對一」的訪談更熱烈。
訪談
訪談是指透過與相關方直接交談來了解高層級需求、假設條件、限制因素、審批標準以及其他資訊。
訪談是透過與相關方直接交談,來獲取資訊的正式或非正式的方法。訪談的典型做法是想被訪者提出假設和即興的問題,並記錄他們的答案。訪談經常是一個訪談者或一個被訪談者之間的「一對一」對話,但也可以包括多個訪談者和/或多個被訪談者。訪談有經驗的專案參與者、發起人和其他主管,以及主題專家,有助於識別和定義所需產品可交付成果的特徵和功能。訪談也可用於取得機密資訊。
人際關係與團隊技能
衝突管理
衝突管理有助於相關方就目標、成功標準、高階需求、專案描述、整體里程碑和其他內容達成一致意見。
引導
引導是指有效引導團隊活動成功以打成決定、解決方案或結論的能力。引導者確保參與者有效參與,互相理解,考慮所有意見,按既定決策流程全力支持得到的結論或結果,以及所達成的行動計劃和協議在之後得到合理執行。
會議管理
會議管理包括準備議程、確保邀請每個關鍵相關方群體的代表,以及準備和發送後續的會議記錄和行動計劃。
會議
在製定專案章程的過程中,與關鍵相關方舉行會議的目的是識別專案目標、成功標準、主要可交付成果、高層級需求、總體里程碑和其他概述資訊。
補充:六頂思考帽
藍色思考帽
藍色思考帽負責控制和調節思考過程。負責控制各種思考帽的使用順序,規劃和管理整個思考過程,並負責做出結論。
白色思考帽
白色是中立客觀的。戴上白色思考帽,人們思考的是關注客觀的事實和數據。
紅色思考帽
紅色是情感的色彩。戴上紅色思考帽,人們可以表現自己的情緒,人們也可以表達直覺、感受、預感等方面的看法。
黃色思考帽
黃色代表價值與肯定。戴上黃色思考帽,人們從正面考慮問題,表達樂觀的、充滿希望的、建設性的觀點。
黑色思考帽
戴上黑色思考帽,人們可以運用否定、懷疑、質疑的看法,合乎邏輯的進行批判,盡情發表負面的意見,找出邏輯上的錯誤。
綠色思考帽
綠色代表茵茵芳草,象徵勃勃生機。綠色思考帽寓意創造力與想像。具有創意思考、腦力激盪、求異思維等功能。
輸出
專案章程
專案章程是由啟動者或發起人發布的,正式批准專案成立,並授權專案經理使用組織資源進行專案活動的文件。它記錄了關於專案和專案預期交付的產品、服務或成果的高階資訊。
項目目的
可測量的專案目標和相關的成功標準
專案目標
高層需求
高階專案描述、邊界定義以及主要可交付成果
專案範圍
整體專案風險
專案風險
整體里程碑進度計劃
專案進度
預先核准的財務資源
專案成本
關鍵相關方名單
項目相關方
高階基準
專案審核要求(例如,用什麼標準評估專案成功,由誰對專案成功下結論,由誰來簽署專案結束)
專案退出標準(例如,在何種條件下才能關閉或取消專案或階段)
專案目標
委派的專案經理及其職責及職權
發起人或其他批准專案章程的人員的姓名和職權
職權職責
專案章程確保相關方在整體上就主要可交付成果、里程碑以及每個專案參與者的角色和職責達成共識。
假設日誌
通常,在專案啟動之前編製商業論證時,識別高階的策略和營運假設條件與限制因素。這些假設條件與限制因素應納入專案章程。較低層級的活動和任務假設條件在專案期間隨著定義技術規格、估算、進度和風險等活動的開展而產生。假設日誌用於記錄整個專案生命週期中的所有假設條件和限制因素。
假設條件
在製定計劃時,不需要驗證即可視為正確、真實或確定的因素。同時也應描述如果這些因素不成立,可能造成的潛在影響。在專案規劃過程中,專案團隊應該經常辨識、記錄並確認假設條件。
限制因素
對專案或過程的執行有影響的限制性因素。需要列出並描述與專案範圍有關且會影響專案執行的各種內部外部限製或限制條件,例如,客戶或執行組織事先確定的預算、強制性日期或進度里程碑。如果專案時根據協議實施的,那麼合約條款通常也是限制因素。
制定專案管理計劃
概述制定專案管理計劃是定義、準備和協調專案計劃的所有組成部分,並將它們整合為一份綜合專案管理計劃的過程。本過程的主要作用是,產生一份綜合文件,用於確定所有專案工作的基礎及其執行方式,它僅開展一次貨僅在專案的預定義點開展。
專案管理計畫與專案文件
制定專案管理計畫的原則
專案管理計畫決定專案的執行、監控和收尾方式,會因專案所在的應用領域和複雜程度差異而有所不同。
專案管理計劃需要主要相關方的批准
在確定基準之前,可能要對專案管理計畫進行多次更新,且這些更新無需遵循正式流程
在執行和監控過程中提出必要的變更請求,並報告實施整體變更控制過程審批
所有專案相關方的參與,專案經理扮演總負責與整合的作用
ITTO
輸入
專案章程
專案團隊把專案章程當作初步專案規劃的起始點。專案章程所包含的資訊種類數量因專案的複雜程度和已知的資訊而異。在專案章程中至少應該定義專案的高階訊息,以供將來在專案管理計畫的各個組成部分中進一步細化。
其他過程的輸出
建立專案管理計劃需要整合諸多流程的資料。其他規劃過程所輸出的子計畫和基準都是本過程的輸入。此外,對於這些子計畫和基準的變更都可能導致專案管理計畫的相應的更新。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
腦力激盪
核對單
許多組織基於自身經驗制定了標準化的核對單,或採用所在產業的核對單。核對單可以指導專案經理制定計畫或協助檢查專案管理計畫是否包含所需全部資訊。
焦點小組
訪談
人際關係與團隊技能
衝突管理
引導
會議管理
會議
在此過程中,可以透過會議討論專案方法,確定為達成專案目標而採用的工作執行方式,以及製定專案監控方式。
Kick-Off Meeting 計畫開工會
專案開工會議通常意味著規劃階段結束和執行階段開始,旨在傳達專案目標、獲得團隊對專案的承諾,以及闡明每個相關方的角色和職責。開工會議可能在不同時間點舉行,具體取決於專案的特徵
對於小型項目,通常由同一個團隊進行專案規劃和執行。在這種情況下,專案在啟動之後很快就會開工(規劃過程小組),因為執行團隊參與了規劃。
對於大型項目,通常由專案管理團隊進行大部分規劃工作。在初始規劃工作完成、開發(執行)階段開始時,專案團隊其他成員才參與其中。在這種情況下,將隨同執行過程組的相關過程召開開工會議。
對於多階段項目,通常在每個階段開始時都要舉行一次開工會議。
輸出
專案管理計劃
計劃專案
實體計劃
專案管理計劃
成本基準
進度基準
範圍基準
更新必須經過變更程序
程序計劃
風險管理計劃
變更管理計劃
成本管理計劃
品質管理計劃
範圍管理計劃
需求管理計劃
進度管理計劃
變更管理計劃
採購管理計劃
除非程序本身有問題才能變更,變更必須經過變更程序
綜合計劃
資源管理計劃
溝通管理計劃
相關方參與計劃
原則要變更單可以直接更新
指導與管理專案工作
指導與管理專案工作是為實現專案目標而領導和執行專案管理計畫中所確定的工作,並實施已批准變更的流程。本過程的主要作用是,對專案工作和可交付成果進行全面管理,以提供專案成功的可能性。
ITTO
輸入
專案管理計劃
專案管理計劃的任何組件都可用作此流程的輸入
專案文件
變更日誌
經驗教訓登記冊
里程碑清單
專案溝通記錄
專案進度計劃
需求追蹤矩陣
風險登記冊
風險報告
批准的變更請求
核准的變更請求是實施整體變更控制過程的輸出,包括專案經理審查和批准的變更請求,必要時可經變更控制委員會(CCB)審查和批准。核准的變更請求可能是糾正措施、預防措施或缺陷補救,並由專案團隊納入專案進度計畫付諸實施,可能對專案或專案管理計畫的任一領域產生影響,也可能導致修正正式受控的項目管理計劃組件或專案文件。
事業環境因素
組織過程資產
工具與技術
專家判斷
專案管理資訊系統
作為事業環境因素的一部分,本系統也可用於自動收集和報告關鍵績效指標KPI
會議
輸出
可交付成果
可交付成果是在某一流程、階段或專案完成時,必須產出的任何獨特且可核實的產品、成果或服務能力。它通常是專案結果,並可包括專案管理計劃的組成部分。
可拆分為:可交付物 成果
工作績效數據
工作績效數據是在執行專案工作的過程中,從每個正在執行的活動中收集到的原始觀察和測量值。數據通常是最低層次的細節,將交由其他過程從中提煉出資訊。在工作執行過程中收集數據,再交由控制過程做進一步分析。
例如,工作績效數據包括已完成的工作、關鍵績效指標(KPI)、技術績效測量結果、進度活動的實際開始日期和完成日期、已完成的故事點、可交付成果狀態、進度進度、變更請求的資料量、缺陷的數量、實際發生的成本、實際持續時間等。
問題日誌
在整個專案生命週期中,專案經理通常會遇到問題、差距、不一致或意外衝突。專案經理需要採取某些行動加以處理,以免影響專案績效。問題日誌是一種記錄和跟進所有問題的專案文件。
所需記錄和跟進的內容可能包括
問題類型
問題提出者和提出時間
問題描述
問題優先級
由誰負責解決問題
目標解決日期
問題狀態
最終解決情況
問題日誌可以幫助專案經理有效跟進和管理問題,確保它們得到調查和解決。作為本過程的輸出,問題日誌被首次創建,儘管在專案期間任何時候都可能發生問題。在整個專案生命週期應該隨同監控活動更新問題日誌。
補充:問題VS風險
問題:發生機率為0%或100%,為確定值。
風險:發生機率為0%至100%之間,但不包含。
變更請求
變更請求是關於修改任何文件、可交付成果或基準的正式提議。如果在進行專案工作時發現問題,就可提出變更要求,對專案政策或程序、專案或產品範圍、專案成本或預算、專案進度計畫、專案或產品結果的品質進行修改。其他變更請求包括必要的預防措施或糾正措施,用來防止日後的不利後果。任何專案相關方都可以提出變更請求,應該透過實施整體變更控制流程對變更請求進行審查和處理。變更請求源自於專案內部或外部,是可選或由法律(合約)強制的。
變更請求可能包括
糾正措施
預防措施
缺陷補救
更新
專案管理計畫更新
任何組件
專案文件更新
活動清單
假設日誌
經驗教訓登記冊
需求文件
風險登記冊
相關方登記冊
組織過程資產更新
專案管理知識
管理專案知識是使用現有知識並產生新知識,以實現專案目標,並幫助組織學習的過程。這個過程的主要作用是,利用現有的組織知識來創造或改進專案成果,並且使當前專案創造和知識可用於支援組織運作和未來的專案或階段。
知識籃理貫穿頂目全過程
知識通常分為「顯性知識」(易使用文字、圖片和數字進行編撰的知識)和「隱性知識」(個別知識以及難以明確表達的知識,如信念、洞察力、經驗和「訣竅」)兩種。知識管理指管理顯性和隱性知識,旨在重複使用現有知識並產生新知識。有助於達成這兩個目的的關鍵活動是知識分享和知識整合(不同領域的知識、情境知識和專案管理知識)
一個常見的誤解是,知識管理只是將知識記錄下來用於分享;另一個常見的誤解是,知識管理只是在專案結束時總結經驗教訓,以供未來使用。這樣的話,只有經編撰的顯性知識可以被分享。因為顯性知識缺乏情境,可作不同解讀,所以,雖易分享,但無法確保正確理解或應用。隱性知識雖蘊含情境,卻很難編撰。它存在於專家個人的思想中,或存在於社會團體和情境中,通常由人際交流和互動來分享。
從組織的角度來看,知識管理指的是確保專案團隊和其他相關方的技能、經驗和專業知識在專案開始之前、進行期間和結束之後得到運用。因為知識存在於人們的思想中,無法強迫人們分享自己的知識或關注他們的知識,所以,知識管理最重要的環節就是營造一種相互信任的分為,激勵人們分享知識或關注他人的知識。如果不激勵人們分享知識或關注他們知識,即便最好的知識管理工具和技術也無法發揮作用。在實踐中,聯合使用知識管理工具和技術(用於人際互動)以及資訊管理工具和技術(用於編撰顯性知識)來分享知識。
隨時記錄
ITTO
輸入
專案管理計劃
所有組件
專案文件
經驗教訓登記冊
經驗教訓登記冊提供了有效的知識管理實務。
專案團隊派遣工單
專案團隊派工單說明了專案已具有的能力和經驗以及可能缺乏的知識。
資源分解結構
各種不同類型的資源(人),缺乏哪些知識。
供方選擇標準
相關方登記冊
相關方登記冊包含已識別的相關方的詳細情況,有助千了解他們可能擁有的知識。
可交付成果
事業環境因素
組織過程資產
工具與技術
專家判斷
知識管理
知識管理工具和技術將員工連結起來,使他們能夠合作產生新知識、分享隱性知識,以及整合不同成員所擁有的知識。適用於專案的工具和技術取決於專案的性質,尤其是創新程度、專案複雜性,以及團隊的多元化(包括學科背景多元化)程度。
人際交往,包括非正式的社交和線上社交。可以進行開放式提問(如「誰知道......?」)的線上論壇有協助千與專家進行知識分享對話
實踐社群(有時稱為「興趣社群」 或「社群" ) 和特別興趣小組
會議,包括使用通訊技術進行互動的虛擬會議
工作跟隨和跟隨指導
可以透過面對面和(或)虛擬方式來應用所有這些工具和技術。通常,面對面互動最有利於建立知識管理所需的信任關係,一旦信任關係建立,就可以用虛擬互動來維持這種信任關係。
資訊管理
資訊管理工具和技術用於創建人們與知識之間的聯繫,可以有效促進簡單、明確的顯性知識的分享
編撰顯性知識的方法
經驗教訓登記冊
圖書館服務
資訊收集,例如搜尋網路和閱讀已發表的文章
專案管理資訊系統(PMIS)
專案管理資訊系統通常包括文件管理系統。
透過增加互動要素,如「與我聯繫」的功能,使用戶能夠與經驗教訓發文者聯繫,並向其尋求與特定項目和情境相關的建議。這樣一來,就能夠強化資訊管理工具和技術的使用。
人際關係與團隊技能
積極傾聽
回饋
收到
回應
總結
複述
理解
傾聽二層次
內容
情緒
高層次
消除障礙
環境
地點
時間
其他
文化
專業
引導
領導力
以身作則:理念溝通,言行一致
第一項承諾 明確自己的價值觀,找到自己的聲音。
第二個承諾 讓行動與共同的價值觀一致,為他人樹立榜樣。
共啟願景:展望未來,感動他人
第三項承諾 展望未來,想像令人激動的崇高的各種可能。
第四項承諾 訴諸共同願景,感召他人為共同的願景奮鬥。
挑戰現狀:尋找機會,努力探索
第五項承諾 透過捕捉創意和從外部獲取創新方法來獵取改進的機會。
第六項承諾 進行嘗試和冒險,不斷取得小小的成功,從實踐中學習。
使眾人行:促進合作,善於分享
第七項承諾 透過建立信任和增進關係來促進協作。
第八項承諾 透過增強自主意識和發展能力來增強他人的實力。
激勵人心:表彰貢獻,慶祝勝利
第九項承諾 透過表彰個人的卓越表現來認可他人的貢獻。
第十項承諾 透過創造一種集體主義精神來慶祝價值的實現和勝利。
人際交往
政治意識
輸出
經驗教訓登記冊
經驗教訓登記冊可以包含情況的類別和描述,經驗教訓登記冊還可以包括與情況相關的影響、建議和行動方案。經驗教訓登記冊可以記錄遇到的挑戰、問題、意識到的風險和機會,或其他適用的內容。
經驗教訓登記冊在專案早期創建,作為本過程的輸出。因此,在整個專案期間,它可以作為許多流程的輸入,也可以作為輸出而不斷更新。參與工作的個人和團隊也參與記錄經驗教訓。可以透過影片、圖片、音訊會其他適當的方式進行記錄知識,確保有效吸取經驗教訓。
在專案或階段結束時,把相關資訊歸入經驗教訓知識庫,成為組織過程資產的一部分。
專案管理計畫更新
任何組件
組織過程資產更新
所有項目都會產生新知識。有些知識應該被編撰,並在管理專案知識過程中被嵌入可交付成果。或被用於改進過程和程序。在此過程中,也可以首次編撰或使用現有知識,例如,關於新程式的現有想法在本專案中試用並獲得成功。
可在本過程中更新任一組織流程資產。
監控專案工作
監控專案工作時追蹤、審查和報告整體專案進展,以實現專案管理計畫中確定的績效目標的過程。本過程的主要作用是,讓相關方了解專案的當前狀態並認可為處理績效問題而採取的行動,以及透過成本和進度預測,讓相關方了解未來專案狀態。
監督是貫穿整個專案的專案管理活動之一,包括收集測量和分析測量結果,以及預測趨勢,以便推動流程改進。持續的監督使專案管理團隊能洞察專案的健康狀況,並識別須特別關注的任何方面。控制包括制定糾正或預防措施重新規劃,並追蹤行動計畫的實施過程,以確保它們能有效解決問題。
監控專案工作過程關注內容
把專案的實際績效與專案管理計畫進行比較
定期評估專案績效,決定是否需要採取糾正或預防措施,並建議必要措施
檢查單一專案風險的狀態
在整個專案期間,維護一個準確且及時更新的資訊庫,以反映專案產品及相關文件的情況
為狀態報告、進展測量和預測提供信息
做出預測,以更新當前的成本和進度訊息
監督已批准變更的實施情況
如果專案時專案集的一部分,也應向專案集管理層報告專案進度和狀態
確保專案與商業需求保持一致
補充:監控專案工作的數據流向圖
ITTO
輸入
專案管理計劃
任何組件
專案文件
假設日誌
估算依據
成本預測
成本預測是基於專案以往的績效,用於確定專案是否仍在預算的公差區間內,並識別任何必要的變更。
問題日誌
問題日誌用於記錄和監督由誰負責在目標日期內解決特定問題。
經驗教訓登記冊
經驗教訓登記冊可能包含應對偏差的有效方法以及糾正措施和預防措施。
里程碑清單
品質報告
品質報告包含品質管理問題,針對流程、專案和產品的改善建議,糾正措施建議(含括 返工、缺陷(漏洞)補救、100%檢查等),以及在控製品質過程中發現的情況的概述。
風險登記冊
風險登記冊提供在專案執行過程中發生的各種威脅和機會的相關資訊。
風險報告
風險報告提供整體專案風險和單一風險的資訊。
進度預測
進度預測是基於專案以往的績效,用於確定專案是否確定專案是否仍處於進度的公差區間內,並識別任何必要的變更。
工作績效訊息
在工作執行過程中收集工作績效數據,再交由控制過程做進一步分析。將工作績效資料與專案管理計畫元件、專案文件和其他專案變數比較之後產生工作績效資訊。透過這種比較可以了解專案的執行情況。
例如,關於成本的工作績效數據可能包含已支出的資金,但必須與預算、已執行的工作、用於完成工作的資源以及資金使用計劃進行比較之後才能有用。這些附加資訊為確定專案是否符合預算或是否存在偏差提供了相應的情境;也有助於了解偏差的嚴重程度。透過與專案管理計劃中的偏差臨界值進行比較,就可以確定是否需要採取預防或糾正措施。對工作績效數據和附加資訊進行綜合分析,可以為專案決策提供可靠的基礎。
協定
採購協議中包括條款和條件,也可包括其他條目,如買方就賣方應實施的工作或應交付的產品所做的規定。如果專案將部分工作外包出去,專案經理需要監督承包商的工作,確保所有協議都符合專案的特定要求,以及組織的採購政策。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據分析
備選方案分析
備選方案分析用於在出現偏差時選擇要執行的糾正措施或糾正措施和預防措施的組合。
成本效益分析
成本效益分析有助於在專案出現偏差時確定最節約成本的修正措施
掙值分析
掙值分析對範圍、進度和成本績效進行了綜合分析。
根本原因分析
根本原因分析著重於識別問題的主要原因。它可用於識別偏差的原因以及專案經理為達成專案目標應重點關注的領域。
趨勢分析
趨勢分析根據以往結果預測未來績效,它可以預測專案的進度延誤,提前讓專案經理意識到,按照既定趨勢發展,後期進度可能出現的問題。應該在足夠早的專案時間進行趨勢分析,使專案團隊有時間分析和糾正任何異常。可以根據趨勢分析的結果,提出必要的預防措施建議。
偏差分析
偏差分析檢視目標績效與實際績效之間的差異(或偏差),可涉及持續時間估算、成本估算、資源使用、資源費率、技術績效和其他測量指標。
可以在每個知識領域,針對特定變量,進行偏差分析。在監控專案工作過程中,透過偏差分析對成本、時間、技術和資源偏差進行綜合分析,以了解專案的整體偏差情況。這樣就便於採取適當的預防或矯正措施。
決策
會議
輸出
工作績效報告
工作績效資訊可以用實體或電子形式加以合併、記錄和分發。基於工作績效訊息,以實體或電子形式編制工作績效報告,以製定決策、採取行動或引起關注。根據專案溝通管理計劃,透過溝通過程向專案相關方發送工作績效報告。
工作績效報告的範例包括狀態報告和進展報告。工作績效報告可以包含掙值圖表和資訊、趨勢線和預測、儲備燃盡圖、缺陷直方圖、合約績效資訊和風險情況概述。可以表現為有助於引起關注、制定決策和採取行動的儀表指示圖、熱點報告、信號燈圖或其他形式。
變更請求
專案管理計畫更新
任何組件
專案文件更新
成本預測
問題日誌
經驗教訓登記冊
風險登記冊
進度預測
實施整體變更控制
實施整體變更控制是審查所有變更要求、批准變更,管理可交付成果、專案文件和專案管理計畫的變更,並對變更處理結果進行溝通的過程。本流程審查專案文件、可交付成果或專案管理計畫的所有變更請求,並決定變更請求的處置方案。本過程的主要作用是確保對專案中已記錄在案的變更做全面評審。如果不考慮變更對整體專案目標或計畫的影響就進行變更,往往會加劇整體專案風險。
變更控制委員會(CCB)
實施整體變更控管流程貫穿專案始終,專案經理對此承擔最終責任。變更要求可能影響專案範圍、產品範圍以及任一專案管理計畫元件或任一專案文件。在整個專案生命週期的任何時間,參與專案的任何相關方都可以提出變更要求。變更控制的實施程度,取決於專案所在應用領域、專案複雜程度、合約要求,以及專案所處的背景與環境。
在基準確定之前,變更無需正式受控於實施整體變更控制流程。一旦確定了專案基準,就必須透過此流程來處理變更請求。依照常規,每個專案的組態管理計畫應規定哪些專案工件受控於組態控製程序。對配置要素的任何變更都應該提出變更請求,並經過正式控制。
儘管也可以口頭提出,但所有變更請求都必須以書面形式記錄,並納入變更管理和(或)配置管理系統中。在批准變更之前,可能需要了解變更對進度的影響和對成本的影響。在變更請求可能影響任一專案基準的情況下,都需要進行正式的整體變更控制流程。每項記錄在案的變更請求都必須由一位責任人批准、延遲或否決,而這個責任人通常是專案發起人或專案經理。應在專案管理計畫或組織程序中指定這位責任人,必要時,應由變更控制委員會(CCB)來進行實施整體變更控制過程。 CCB是一個正式組成的團體,負責審查、評估、批准、延遲或否決專案變更,以及記錄和傳達變更處理決定。
補充:變更專題
變更流程圖
變更
預防變更
充分收集需求
相關方支持參與
內部變更
非增值變更
拒絕
加值變更
首先分析影響
溝通相關方(如需要)
提出變更請求
相關方
專案經理
收尾變更
建議另立新項目
或遵從變更流程
有缺陷必須修復
標準變更
提出
提出變更請求
書面
口頭
補書面
處理
全面分析影響
制定變更方案
相關方溝通
取消變更
繼續變更
提交CCB批准
未核准
記錄
通知
核准
實施
實施
更新專案管理計畫和專案文件
更新變更日誌
通知相關方
實施變更
追蹤變更
總結經驗教訓
ITTO
輸入
專案管理計劃
變更管理計劃
變更管理計畫為管理變更控制過程提供指導,並記錄變更控制委員會(CCB)的角色和職責。
配置管理計劃
配置管理計畫描述專案的配置項目、識別應記錄和更新的配置項,以便維持專案產品的一致性和有效性。
範圍基準
進度基準
成本基準
專案文件
估算依據
需求追蹤矩陣
風險報告
工作績效報告
變更請求
很多過程都會輸出變更請求。變更請求可能包含糾正措施、預防措施、缺陷補救,以及對正式受控的專案文件或可交付成果的更新,以反映修改或增加的意見或內容。變更可能影響專案基準,也可能不影響專案基準,而只影響相對於基準的專案績效。變更決定通常由專案經理做出。
對於會影響專案基準的變更,通常應該在變更請求中說明執行變更的成本、所需的計劃日期修改、資源需求以及相關的風險。這種變更應由CCB(如有)和客戶或發起人審批,除非他們本身就是CCB的成員。只有經批准的變更才能納入修改後的基準。
事業環境因素
組織過程資產
工具與技術
專家判斷
變更控制工具
為了方便進行配置和變更管理,可以使用一些手動或自動化的工具。配置控制重點在於可交付成果及各個流程的技術規範,而變更控制則著重於識別、記錄、批准或否決專案文件、可交付成果或基準的變更。
工具的選擇應基於專案相關方的需要,包括考慮組織和環境情況和(或)限制因素。
工具應支援的組態管理活動
識別配置項
識別與選擇配置項,從而為定義與核實產品配置、標記產品和文件、管理變更和明確責任提供基礎。
記錄並報告配置項狀態
關於各個配置項的資訊記錄和報告。
進行配置項核實與審計
透過配置核實與審計,確保專案的配置項目組成的正確性,以及相應的變更都被登記、評估、批准、追蹤和正確實施,從而確保配置文件所規定的功能要求都已實現。
工具應支援的變更管理活動
識別變更
識別並選擇流程或專案文件的變更項。
記錄變更
將變更記錄為適當的變更要求。
做出變更決定
審查變更,批准、否決、推遲對專案文件、可交付成果或基準的變更或做出其他決定。
追蹤變更
確認變更被登記、評估、批准、追蹤並向相關方傳達最終結果。也可以使用工具來管理變更請求和後續的決策,同時也要格外注意溝通,以幫助變更控制委員會的成員履行職責,以及向相關方傳達決定。
補充內容
軟體專案可能遇到的問題
找不到某個文件的歷史版本;
開發人員使用錯誤的程式版本;
開發人員未經授權修改程式碼或文件;
人員流動,交接工作不徹底;
無法重新編譯軟體的某個歷史版本;
因協同開發,或異地開發,版本變更混亂導致整個專案失敗;
.....
常見的軟體設定項
需求規格說明書
設計規格說明書
原始碼
測試計劃
測試用例
使用者手冊
.....
軟體組態管理的主要功能
版本控制
採用相應的流程和工具,對軟體開發過程中產生的各種文件的版本進行管理。是軟體組態管理的核心內容。
變更管理
為防止開發人員對軟體的隨意變更而進行的管理上的審核過程,包括變更請求、變更評估、變更批准/拒絕、變更實現。
其它
配置審計、配置狀態統計等。
數據分析
備選方案分析
此技術用於評估變更請求,並決定哪些請求可接受、應否決或需修改。
成本效益分析
此分析有助於確定變更請求是否值得投入相關成本。
決策
投票
投票是一種為達成某種期望結果,而對多個未來行動方案進行評估的集體決策技術和過程。本技術用於產生、歸類和排序產品需求。
投票技術包括
一致同意
每個人都同意某個行動方案。
大多數同意
獲得群體中超過50%人員的支持,就能做出決策。將參與決策的小組人數定為奇數,可防止因平局而無法達成決策。
相對多數同意
根據群體中相對多數人的意見來做決策,即便未能獲得多數人的支持。通常在候選項超過兩個時使用。
獨裁型決策制定
採用這種方法,將由一個人負責為整個集體制定決策。
多標準決策分析
該技術借助決策矩陣,以系統分析方法建立諸如風險水平、不確定性和價值收益等多種標準,以對眾多創意進行評估和排序。
會議
與變更控制委員會(CCB)一起召開變更控制會。變更控制委員會負責審查變更請求,並做出批准、否決或推遲的決定。大部分變更會對時間、成本、資源或風險產生一定的影響,因此,評估變更的影響也是會議的基本工作。此外,會議上可能還要討論並提議所要求變更的備選方案。最後,將會議決定傳達給提出變更請求的責任人或小組。
CCB也可以審查配置管理活動。應明確規定變更控制委員會的角色和職責,並經相關方一致同意後,記錄在變更管理計畫中。 CCB的決定都應記錄在案,並向相關方傳達,以便其知曉並採取後續行動。
輸出
批准的變更請求
由專案經理、CCB或指定的團隊成員,根據變更管理計畫處理變更請求,做出批准、延遲或否決的決定。核准的變更請求應透過指導與管理專案工作流程加以實施。對於延遲或否決的變更請求,應通知提出變更請求的個人或小組。
以專案文件更新的形式,在變更日誌中記錄所有變更要求的處理。
專案管理計畫更新
任何組件
專案管理計畫的任一正式受控的組成部分,都可透過此流程進行變更。基準的變更,只能基於最新版本的基準且針對未來的情況,而不能變更以往的績效。這有助於保護基準和歷史績效數據的嚴肅性和完整性。
專案文件更新
變更日誌
正式受控的任一專案文件都可在本過程變更,通常在本過程更新的一種專案文件是變更日誌。變更日誌用於記錄專案期間發生的變更。
結束專案或階段
結束專案或階段是終結專案、階段或合約的所有活動的過程。本過程的主要作用是,存檔專案或階段訊息,完成計劃的工作,釋放組織團隊資源以展開新的工作。
在結束專案時,專案經理需要回顧專案管理計劃,確保所有專案工作都已完成以及專案目標均已實現。
專案或階段行政收尾所需的必要活動包括(但不限於)
為達到階段或專案的完工或退出標準所必須的行動和活動
確保所有文件和可交付成果都已是最新版本,且所有問題都已解決
確認可交付成果已交付給客戶並已獲得客戶的正式驗收
確保所有成本都已記入項目成本賬
關閉專案帳戶
重新分配人員
處理多餘的項目資料
重新分配專案設施、設備和其他資源
根據組織政策編制詳盡的最終專案報告
關閉專案合約協議或專案階段合約協議所必須進行的活動
確認賣方的工作已通過正式驗收
最終處置未決索賠
更新記錄以反映最後的結果
存檔相關資訊供未來使用
為完成下列工作所必須進行的活動
收集項目或階段記錄
審計項目成敗
管理知識分享與傳遞
總結經驗教訓
存檔項目資訊以供組織未來使用
為向下一個階段,或向生產和(或)營運部門移交專案的產品、服務或成果所必須進行的行動和活動
收集關於改進或更新組織政策和程序的建議,並將它們發送給相應的組織部門
測量相關方的滿意程度
如果專案在完工前就提前終止,結束專案或階段過程還需要製定程序,來調查和記錄提前終止的原因為了實現上述目的,專案經理應該引導所有合適的相關方參與本過程
補充:專案收尾流程
ITTO
輸入
專案章程
專案章程記錄了專案成功標準、審批要求,以及由誰來簽署專案結束。
專案管理計劃
所有組件
專案文件
假設日誌
估算依據
變更日誌
問題日誌
經驗教訓登記冊
里程碑清單
專案溝通記錄
品質控制測量結果
品質報告
需求文件
風險登記冊
風險報告
驗收的可交付成果
在分階段實施的專案或被取消的專案中,可能會包括未全部完成的可交付成果或中間可交付成果。
商業文件
商業論證
商業論點記錄了作為專案依據的商業需求和成本效益分析,以確定專案是否達到經濟可行性研究的預期結果。
效益管理計劃
效益管理計劃概述了專案的目標效益,用於測量專案是否達到了計劃的效益。
協定
先外後內
採購文件
組織過程資產
工具與技術
專家判斷
數據分析
文件分析
經驗教訓
迴歸分析
分析專案結果的不同變數之間的相互關係,以提高未來專案的績效
趨勢分析
最小平方法
偏差分析
偏差分析可透過比較計劃目標與最終結果來改善組織的測量指標
會議
收尾報告會
客戶總結會
經驗教訓總結會
慶祝會
輸出
專案文件更新
經驗教訓登記冊
在專案活動中產生的各種文件並標記為最終版本(各版本計劃、風險影響評估等)
最終產品、服務或成果移交
專案交付的產品、服務或成果可轉交給另一團隊或組織,並由其在整個生命週期中進行營運、維護和支持
最終報告(總結專案績效)
目標達成情況(範圍、品質、成本、進度等)
商業需求達成情形(預期效益、業務需求)
管理過程總結(風險或問題及其解決情況)
組織過程資產更新
營運和支援文件,用來將完成的專案或階段可交付成果移交給他人(如營運部門或下一階段)的正式文件。
確認範圍過程所產生的客戶驗收文件,以及合約協議(如果有的話),以確保在達到全部專案要求之後才正式關閉專案。
如果專案在完工前提前終止,則需要在正式的收尾文件中說明專案終止的原因,並規定正式程序,將該專案的已完成和未完成的可交付成果移交他人。
經驗教訓知識庫
專案範圍管理
概述說明
產品範圍VS專案範圍
產品範圍
某項產品、服務或成果所具有的特徵和功能。
專案範圍
為交付具有規定特性與功能的產品、服務或成果而必須完成的工作。專案範圍有時也包括產品範圍。
ITTO
輸入
工具與技術
輸出
從預測型方法到適應型或敏捷型方法,專案生命週期可以處於這個連續區間內的任何位置。在預測型生命週期中,在專案開始時就對專案可交付成果進行定義,對任何範圍變更都要漸進式管理。而在適應型或敏捷型生命週期中,透過多次迭代來開發可交付成果,並在每次迭代開始時定義和批准詳細的範圍。
採用適應型生命週期,旨在應對大量變更,需要相關方持續參與專案;因此,應將適應型專案的整體範圍分解為一系列擬實現的需求和擬執行的工作(有時稱為產品未完項) 。在一個迭代開始時,團隊將努力確定產品未完項中,哪些最優先項應在下一次迭代中交付。在每次迭代中,都會重複進行三個流程:收集需求、定義範圍和建立WBS。相反,在預測型專案中,這些流程在專案開始時開展,並在必要時透過實施整體變更控制流程進行更新。
規範範圍管理
規劃範圍管理是為記錄如何定義、確認和控制專案範圍及產品範圍,而建立範圍管理計畫的過程。本過程的主要作用是,在整個專案期間對如何管理範圍提供指南和方向。
ITTO
輸入
專案章程
專案管理計劃
品質管理計劃
專案生命週期描述
開發方法
事業環境因素
組織過程資產
工具與技術
專家判斷
數據分析
備選方案分析
會議
輸出
範圍管理計劃
範圍管理計畫是專案管理計畫的組成部分,描述將如何定義、制定、監督、控制和確認專案範圍。範圍管理計畫要對將用於下列工作的管理過程做出規定。
需求管理計劃
需求管理計劃是專案管理計劃的組成部分,描述將如何分析、記錄和管理專案和產品需求。根據《從業者商業分析:實踐指南》【7】,有些組織稱之為「商業分析計畫」。
收集需求
收集需求是為實現目標而確定、記錄和管理相關方的需要和需求的過程。本流程的主要作用是,為定義產品範圍和專案範圍奠定基礎,且僅進行一次或僅在專案的預定義點開展。
ITTO
輸入
專案章程(高層需求)
專案管理計劃
範圍管理計劃
需求管理計劃
相關方參與計劃
從相關方參與計畫中了解相關方的溝通需求和參與程度,以便評估並適應相關方對需求活動的參與程度
專案文件
假設日誌
經驗教訓登記冊
相關方登記冊
相關方登記冊也記錄了相關方對專案的主要需求和期望
商業文件
商業論證
相關方需求要與商業論證(初心)裡面的目標一致
協定
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
腦力激盪
腦力激盪是一種用來產生和收集對專案需求與產品需求的多種創意的技術
訪談
訪談是透過與相關方直接交談,來獲取資訊的正式或非正式的方法。訪談的典型做法是向受訪者提出預設和即興的問題,並記錄他們的答案。訪談經常是一個訪談者和一個被訪者之間的「一對一」對話,但也可以包括多個訪談者和/或多個被訪者。訪談有經驗的專案參與者、發起人和其他主管,以及主題專家,有助於識別和定義所需產品可交付成果的特徵和功能。訪談也可用於獲取機密信息
焦點小組
焦點小組是召集預定的相關方和主題專家,以了解他們對所討論的產品、服務或成果的期望和態度。由一位受過訓練的主持人引導大家進行互動式討論。焦點團體往往比「一對一」的訪談更熱烈
問卷調查
問卷調查是指設計一系列書面問題,向眾多受訪者快速收集資訊。問卷調查方法非常適合以下情況:受眾多樣化,需要快速完成調查,受訪者地理位置分散,適合進行統計分析。
標竿對照
標竿對照將實際或計劃的產品、流程和實踐,與其他可比較組織的實踐進行比較,以便識別最佳實踐,形成改進意見,並為績效考核提供依據。標竿對照所採用的可比較組織可以是內部的,也可以是外部的。
數據分析
文件分析
文件分析包括審核和評估任何相關的文件資訊。在此過程中,文件分析用於透過分析現有文件,識別與需求相關的資訊來獲取需求。有助於取得相關需求的文件很多。
可供分析的文件包括(但不限於)
協定
商業計劃
決策
投票
投票是一種為達成某種期望結果,而對多個未來行動方案進行評估的集體決策技術和過程。本技術用於產生、歸類和排序產品需求。
投票技術範例
一致同意
每個人都同意某個行動方案。
大多數同意
獲得群體中超過50%人員的支持,就能做出決策。將參與決策的小組人數定為奇數,可防止因平局而無法達成決策。
相對多數同意
根據群體中相對多數人的意見來做決策,即便未能獲得多數人的支持。通常在候選項超過兩個時使用。
獨裁型決策制定
採用這種方法,將由一個人負責為整個集體制定決策。
多標準決策分析
該技術借助決策矩陣,以系統分析方法建立諸如風險水平、不確定性和價值收益等多種標準,以對眾多創意進行評估和排序。
數據表現
親和圖
用來對大量創意進行分組的技術,以便進一步審查和分析。
心智圖
把從腦力激盪中獲得的創意整合成一張圖,用以反映創意之間的共性與差異,激發新創意。
心智圖繪製內容
中心主題
形式
影像
位置
中央
大小
適宜
顏色
三色
線條
類型
主幹
連線
中心主題
由粗到細
支幹
連接
主幹
下級支幹
細線
連接線
跨越
顏色
同一主幹
同色
影像
突顯
重點
強化
記憶
建議
動感
多色
立體
文字
關鍵字
動詞
名詞
其他
方向
左向右
顏色
黑色
線條
人際關係與團隊技能
名義小組技術
名義小組技術是用於促進腦力激盪的一種技術,透過投票排列最有用的創意,以便進一步進行腦力激盪或優先排序。
名義小組技術是一種結構化的腦力激盪形式,由四個步驟組成
向集體提出一個問題或難題。每個人在沉思後寫出自己的想法。
主持人在活動掛圖上記錄所有人的想法。
集體討論各個想法,直到全體成員達成明確的共識。
個人私下投票決出各種想法的優先排序,通常採用5分制,1分最低,5分最高。為減少想法數量、集中關注想法,可進行數輪投票。每輪投票後,都將清點選票,得分最高者被選出。
觀察/交談
觀察和交談是指直接察看個人在各自的環境中如何執行工作(或任務)和實施流程。當產品使用者難以或不願清楚說明他們的需求時,就特別需要透過觀察來了解他們的工作細節。觀察,也稱為“工作跟隨”,通常由旁站觀察者觀察業務專家如何執行工作,但也可以由“參與觀察者”來觀察,通過實際執行一個流程或程序,來體驗該流程或程序是如何實施的,以便挖掘隱藏的需求。
引導
引導與主題研討會結合使用,把主要相關方召集在一起定義產品需求。研討會可用於快速定義跨職能需求並協調相關方的需求差異。因為具有團體互動的特點,有效引導的研討會有助於參與者之間建立信任、改善關係、改善溝通,從而有利於相關方達成一致意見。此外,與分別召開會議相比,研討會能夠更早發現並解決問題。
適合採用引導技能的情境包括(但不限於)
聯合應用設計或開發(JAD)
JAD會議適用於軟體開發產業。這種研討會著重於把業務主題專家和開發團隊集中在一起,以收集需求和改進軟體開發過程。
Joint Application Design Or Development
品質功能展開(QFD)
製造業則採用QFD這種引導技能來幫助確定新產品的關鍵特徵。 QFD從收集客戶需求(又稱「客戶聲音」)開始,然後客觀地對這些需求進行分類和排序,並為實現這些需求而設定目標。
Quality Function Display
使用者故事
使用者故事是對所需功能的簡短文字描述,經常產生於需求研討會。使用者故事描述哪個相關方將從功能中受益(角色),他需要實現什麼(目標),以及他期望獲得什麼利益(動機)。
參與者一起創造相關方需求的故事,故事包括
角色?想要什麼?為什麼想?
使用者故事通常按照此格式來表達:作為一個<角色>,我想要<活動>,以便於<商業價值>
舉例:作為一個“網站管理員”,我想要“統計每天有多少人訪問了我的網站”,以便於“我的贊助商了解我的網站會給他們帶來什麼收益。”
哪個相關方從功能中受益(角色)
需要實現什麼(目標)
獲得的利益(動機/商業價值)
使用者故事,廣泛應用於敏捷方法中
系統互動圖
原型法
原型法是指在實際製造預期產品之前,先造出該產品的模型,並據此徵求對需求的早期回饋。原型包括微縮產品、電腦生成的二維和三維模型、實體模型或模擬。因為原型是有形的實物,它使得相關方可以體驗最終產品的模型,而不是僅限於討論抽象的需求描述。原型法支持漸進明細的理念,需要經歷從模型創建、使用者體驗、回饋收集到原型修改的反覆循環過程。在經過足夠的回饋循環之後,就可以透過原型獲得足夠的需求訊息,從而進入設計或製造階段。
故事板是一種原型技術,透過一系列的圖像或圖示來展示順序或導航路徑。故事板用於各種行業的各種專案中,如電影、廣告、教學設計,以及敏捷和其他軟體開發專案。在軟體開發中,故事板使用實體模型來展示網頁、螢幕或其他使用者介面的導航路徑。
輸出
需求文件
需求文件描述各種單一需求將如何滿足與專案相關的業務需求。一開始可能只有高層的需求,然後隨著需求資訊的增加而逐步精進。只有明確的(可測量和可測試的)、可追蹤的、完整的、相互協調的,且主要相關方願意認可的需求,才能作為基準。需求文件的格式多種多樣,既可以是一份按相關方和優先級分類列出全部需求的簡單文件,也可以是一份包括內容提要、細節描述和附件等的詳細文件。
業務需求
整個組織的高層需要,例如,解決業務問題或抓住業務機會,以及實施專案的原因。
相關方需求
相關方或相關方群體的需要。
解決方案需求
為滿足業務需求和相關方需求,產品、服務或成果必須具備的特性、功能和特徵。解決方案需求進一步分為功能需求與非功能需求
功能需求
功能需求描述產品應具備的功能,例如,產品應該執行的行動、流程、資料和互動。
非功能需求
非功能需求是功能需求的補充,是產品正常運作所需的環境條件或品質要求,例如,可靠性、保密性、性能、安全性、服務水準、可支援性、保留或清除等。
過渡和就緒需求
這些需求描述了從「當前狀態」過渡到「將來狀態」所需的臨時能力,如資料轉換和培訓需求。
專案需求
專案需要滿足的行動、過程或其他條件,例如里程碑日期、合約責任、限制等。
品質需求
用於確認專案可交付成果的成功完成或其他專案需求的實現的任何條件或標準,例如測試、認證、確認等。
需求追蹤矩陣
將需求與業務目標或專案目標連結,確保每個需求都具有商業價值。
需求追蹤矩陣提供了在整個專案生命週期中追蹤需求的一種方法,有助於確保需求文件中被批准的每項需求在專案結束的時候都能交付。
需求追蹤矩陣也為管理產品範圍變更提供了框架。
定義範圍
定義範圍是製定項目和產品詳細描述的過程。本過程的主要作用是,描述產品、服務或成果的邊界和驗收標準。
ITTO
輸入
專案章程
專案章程中包含專案的高層描述、產品特徵和批准要求。
專案管理計劃
範圍管理計劃
其中記錄如何定義、確認和控制專案範圍
專案文件
假設日誌
假設日誌識別了有關產品、專案、環境、相關方以及會影響專案和產品範圍的假設條件和限制因素。
需求文件
需求文件識別了應納入範圍的需求。
風險登記冊
風險登記冊包含了可能影響專案範圍的因應策略,例如縮小或改變專案和產品範圍,以規避或緩解風險。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據分析
備選方案分析
決策
多標準決策分析
人際關係與團隊技能
引導
產品分析
產品分析可用於定義產品和服務,包括針對產品或服務提問並回答,以描述要交付的產品的用途、特徵及其他方面。
每個應用領域都有一種或幾種普遍公認的方法,用以把高層的產品或服務描述轉變為有意義的可交付成果。
首先取得高層級的需求,然後將其細化到最終產品設計所需的詳細程度。
輸出
專案範圍說明書
專案範圍說明書是專案範圍、主要可交付成果、假設條件和限制因素的描述。它記錄了整個範圍,包括專案和產品範圍;詳細描述了專案的可交付成果;也代表專案相關方之間就專案範圍所達成的共識。為便於管理相關方的期望,專案範圍說明書可明確指出哪些工作不屬於本專案範圍。
專案範圍說明書使專案團隊能進行更詳細的規劃,在執行過程中指導專案團隊的工作,並為評價變更請求或額外工作是否超過專案邊界提供基準。
專案範圍說明書描述要做和不要做的工作的詳細程度,決定專案管理團隊控制整個專案範圍的有效程度。
詳細的項目範圍說明書包括內容(可能直接列出或參考其他文件)
產品範圍描述
逐步細化在專案章程和需求文件中所述的產品、服務或成果的特徵。
可交付成果
為完成某一流程、階段或專案而必須產出的任何獨特且可核實的產品、成果或服務能力,可交付成果也包括各種輔助成果,如專案管理報告和文件。可交付成果的描述可略可詳。
驗收標準
可交付成果透過驗收前必須滿足的一系列條件。
項目的除外責任
識別排除在項目之外的內容。明確說明哪些內容不屬於專案範圍,有助於管理相關方的期望及減少範圍蔓延。
專案文件更新
假設日誌
需求文件
需求追蹤矩陣
相關方登記冊
創建WBS
創建工作分解結構(WBS)是把專案可交付成果和專案工作分解成較小、更易於管理的組件的過程。這個過程的主要作用是,為所要交付的內容提供架構,它僅進行一次或僅在專案的預先定義點開展。
ITTO
輸入
專案管理計劃
範圍管理計劃
專案文件
專案範圍說明書
需求文件
事業環境因素
組織過程資產
工具與技術
專家判斷
分解
時間:以專案生命週期的各階段作為分解的第二層,把產品和專案可交付成果放在第三層
結構:以主要可交付成果作為分解的第二層
工作包
工作包是WBS最低層的工作,可對其成本和持續時間進行估算和管理(80小時)
每個工作包都是控制帳戶的一部分,而控制帳戶則是一個管理控制點。在該控制點上,把範圍、預算和進度加以整合,並與掙值相比較,以測量績效。
規劃包,其是一種低於控制帳戶而高於工作包的工作分解結構組件。
輸出
範圍基準
專案範圍說明書
包括專案範圍、主要可交付成果、假設條件和限制因素的描述
WBS
WBS是專案團隊為實現專案目標、創建所需可交付成果而需要實施的全部工作範圍的層級分解
工作包
WBS最低層的組成部分稱為工作包,其中包括計劃的工作。工作包對相關活動進行歸類,以便對工作安排進、進行估算、進行監督與控制。
規劃包
一種低於控制帳戶而高於工作包的工作分解結構組件,工作內容已知,但詳細的進度活動未知。
WBS
WBS字典
WBS字典是針對WBS中的每個元件,詳細描述可交付成果、活動和進度資訊的文件。
WBS字典對WBS提供支持,其中大部分資訊由其他過程創建,然後在後期添加到字典中。
WBS字典中的內容可能包括(但不限於)
帳戶編碼標識
工作說明
假設條件和限制因素
負責的組織
進度里程碑
相關的進度活動
所需資源
成本估算
品質要求
驗收標準
專案文件更新
假設日誌
需求文件
確認範圍
確認範圍是正式驗收已完成的專案可交付成果的過程。這個過程的主要作用是,使驗收過程具有客觀性;同時透過確認每個可交付成果,來提高最終產品、服務或成果獲得驗收的可能性。
由客戶或發起人審查從控製品質流程輸出的核實的可交付成果,確認這些可交付成果已圓滿完成並通過正式驗收。本流程對可交付成果的確認與最終驗收,需要依據:從專案範圍管理知識領域的各規劃流程所獲得的產出(如需求文件或範圍基準),以及從其他知識領域的各執行流程所獲得的工作績效數據。
確認範圍過程與控製品質過程的不同之處在於,前者關注可交付成果的驗收,而後者關注可交付成果的正確性及是否滿足品質要求。控製品質過程通常先於確認範圍過程,但二者也可同時進行。
ITTO
輸入
專案管理計劃
範圍管理計劃
需求管理計劃
範圍基準
使用範圍基準與實際結果比較,以決定是否有必要進行變更、採取糾正措施或預防措施。
專案文件
經驗教訓登記冊
在專案早期所獲得的經驗教訓可以運用到後期階段,以提高驗收可交付成果的效率與效果。
品質報告
品質報告的內容可包括由團隊管理或需回報的全部品質保證事項、改進建議,以及在控製品質過程中發現的情況的概述。在驗收產品之前,需要查看所有這些內容。
需求文件
將需求與實際結果進行比較,以決定是否有必要進行變更、採取糾正措施或預防措施。
需求追蹤矩陣
需求追蹤矩陣含有與需求相關的訊息,包括如何確認需求。
核實的可交付成果
核實的可交付成果是指已經完成,並被控製品質過程檢查為正確的可交付成果。
補充:專案管理的成果線
可交付成果
指導與管理專案工作
核實的可交付成果
控製品質
內部
QC
依據
品質測量指標
測試與評估文件
驗收的可交付成果
確認範圍
外部
客戶
發起人
依據
範圍基準
需求文件
移交的可交付成果
結束專案或階段
形式驗收
最終驗收不通過?
原因
確認範圍環節
控製品質環節
工作績效數據
工具與技術
檢查
檢查是指進行測量、審查與確認等活動,來判斷工作和可交付成果是否符合需求和產品驗收標準。檢查有時也被稱為審查、產品審查和巡檢等。在某些應用領域,這些術語具有獨特和具體的含義。
決策
可用於本過程的決策技術包括(但不限於)投票。當由專案團隊和其他相關方進行驗收時,使用投票來形成結論。
輸出
驗收的可交付成果
符合驗收標準的可交付成果應由客戶或發起人正式簽署批准。應該從客戶或發起人取得正式文件,證明相關方對專案可交付成果的正式驗收。這些文件將提交給結束專案或階段流程
工作績效訊息
工作績效資訊包括專案進度訊息,例如,哪些可交付成果已經被驗收,哪些未通過驗收以及原因。這些資訊應該被記錄下來並傳遞給相關方。
變更請求
對已完成但未通過正式驗收的可交付成果及其未通過驗收的原因,應記錄在案。可能需要針對這些可交付成果提出變更請求,以進行缺陷補救。變更請求應該由實施整體變更控制流程進行審查與處理。
專案文件更新
經驗教訓登記冊
需求文件
需求追蹤矩陣
控制範圍
控制範圍是監督專案和產品的範圍狀態,管理範圍基準變更的過程。本過程的主要作用是,在整個專案期間保持對範圍基準的維護,且需要在整個專案期間進行。
控制專案範圍確保所有變更要求、建議的糾正措施或預防措施都透過實施整體變更控制流程進行處理。在變更實際發生時,也要採用控制範圍流程來管理這些變更。控制範圍過程應該與其他控制過程協調進行。未經控制的產品或專案範圍的擴大(未對時間、成本和資源進行相應調整)稱為範圍蔓延。變更不可避免,因此在每個項目上,都必須強制實施某種形式的變更控制。
範圍蔓延
範圍鍍金(主動)
鍍金指的是,專案成員自行添加功能到專案中,例如某人發現某個功能加到軟體上會很新穎,有賣點,結果自行添加進去。這種行為方式造成了專案的鍍金行為
範圍潛變(被動)
範圍潛變是指客戶不斷提出小的、不易察覺的範圍改變,如果不加控制,累計起來導致專案嚴重偏離既定的範圍基準,導致專案失控失敗。
ITTO
輸入
專案管理計劃
範圍管理計劃
需求管理計劃
變更管理計劃
配置管理計劃
範圍基準
使用範圍基準與實際結果比較,以決定是否有必要進行變更、採取糾正措施或預防措施。
績效衡量基準
使用掙值分析時,將績效衡量基準與實際結果進行比較,以決定是否有必要進行變更、採取糾正措施或預防措施。
專案文件
經驗教訓登記冊
在專案早期獲得的經驗教計川可以運用到後期階段,以改善範圍控制。
需求文件
需求文件用於發現任何對商定的項目或產品範圍的偏離。
需求追蹤矩陣
需求追蹤矩陣有助於探查任何變更或對範圍基準的任何偏離對專案目標的影響,它還可以提供受控需求的狀態。
工作績效數據
組織過程資產
工具與技術
數據分析
偏差分析
偏差分析用於將基準與實際結果進行比較,以確定偏差是否處於臨界值區間內或是否有必要採取糾正或預防措施。
趨勢分析
趨勢分析旨在審查專案績效隨時間的變化情況,以判斷績效是正在改善還是正在惡化。確定偏離範圍基準的原因和程度,並決定是否需要採取糾正或預防措施,是專案範圍控制的重要工作。
輸出
工作績效訊息
本流程產生的工作績效資訊是有關專案和產品範圍實施情況(對照範圍基準)的、相互關聯且與各種背景相結合的信息,包括收到的變更的分類、識別的範圍偏差和原因、偏差對進度和成本的影響,以及對將來範圍績效的預測。
變更請求
分析專案績效後,可能會就範圍基準和進度基準,或專案管理計畫的其他組成部分提出變更要求。變更請求需要經過實施整體變更控制流程的審查和處理。
專案管理計畫更新
範圍管理計劃
範圍基準
進度基準
成本基準
績效衡量基準
專案文件更新
經驗教訓登記冊
需求文件
需求追蹤矩陣
專案進度管理
概述說明
規劃進度管理
規劃進度管理是為規劃、編制、管理、執行和控制專案進度而製定政策、程序和文件的過程。本過程的主要作用是,為如何在整個專案期間管理專案進度提供指南和方向。
ITTO
輸入
專案章程
專案章程中規定的整體里程碑進度計畫會影響專案的進度管理。
專案管理計劃
範圍管理計劃
範圍管理計劃描述如何定義和製定範範圍,並提供有關如何制定進度計劃的資訊。
開發方法
產品開發方法有助於定義進度規劃方法、估算技術、進度計畫編制工具以及用來控制進度的技術。
事業環境因素
組織過程資產
工具與技術
專家判斷
應徵求具備專業知識或在以往類似計畫中接受過相關訓練的個人或小組的意見
進度計畫的編制、管理與控制
進度規劃方法(如預測型或適應型生命週期)
進度規劃軟體
專案所在的特定產業
數據分析
適用於本流程的資料分析技術包括(但不限於)備選方案分析。備選方案分析可包括確定採用哪些進度規劃方法,以及如何將不同方法整合到專案中;此外,它還可以包括確定進度計劃的詳細程度、滾動式規劃的持續時間,以及審查和更新頻率。管理進度所需的計劃詳細程度與更新計劃所需的時間量之間的平衡,應針對各個項目具體而言。
會議
專案團隊可能會舉行規劃會議來制定進度管理計劃。與會者可能包括專案經理、專案發起人、選定的專案團隊成員、選定的相關方、進度計劃或執行負責人,以及其他必要人員。
輸出
進度管理計劃
專案進度模型製定
需要規定用於制定專案進度模型的進度規劃方法論和工具。
進度計劃的發布和迭代長度
使用適應型生命週期時,應指定固定時間的發佈時段、階段和迭代固定時間段指專案團隊穩定地朝著目標前進的持續時間,它可以推動團隊先處理基本功能,然後在時間允許的情況下再處理其他功能,從而盡可能減少範圍蔓延。
準確度
活動及項目的工期估算應該要準確到什麼程度,允許有多大的誤差。
計量單位
組織程式連結
專案的進度管理應該如何與執行組織的管理系統連結。
專案進度模型維護
需要規定在專案執行期間,將如何在進度模型中更新專案狀態,記錄專案進度。
控制臨界值
可能需要規定偏差臨界值,用於監督進度績效。它是在需要採取某種措施前,允許出現的最大差異。臨界值通常以偏離基準計畫中的參數的某個百分數來表示。
績效衡量規則
需要規定用於績效測量的掙值管理(EVM) 規則或其他測量規則。例如, 進度管理理計畫可能規定:決定完成百分比的規則; EVM技術,進度績效衡量指標, 如進度偏差(SV) 和進度績效指數(SPI) , 用來評估偏離原始進度基準的程度。
報告格式
需要規定各種進度報告的格式和編制頻率。
定義活動
定義活動是識別和記錄為完成專案可交付成果而須採取的具體行動的過程。此過程的主要作用是,將工作包分解為進度活動,作為專案工作進行進度估算、規劃、執行、監督和控制的基礎。
ITTO
輸入
專案管理計劃
進度管理計劃
進度管理計畫定義進度規劃方法、滾動式規劃的持續時間,以及管理工作所需的詳細程度。
範圍基準
在定義活動時,需明確考慮範圍基準中的專案WBS、可交付成果、限制因素及假設條件。
事業環境因素
組織過程資產
工具與技術
專家判斷
分解
分解是一種把專案範圍和專案可交付成果逐步劃分為更小、更便於管理的組成部分的技術。活動表示完成工作包所需的投入。定義活動過程的最終輸出是活動而非可交付成果,可交付成果是建立WBS流程的輸出。
WBS、WBS字典和活動清單可依序或同時編制,其中WBS和WBS字典是製定最終活動清單的基礎。 WBS中的每個工作包都需分解成活動,以便透過這些活動來完成相應的可交付成果。讓團隊成員參與分解過程,有助於得到更好、更準確的結果。
滾動式規劃
滾動式規劃是一種迭代式的規劃技術,即詳細規劃近期要完成的工作,同時在較高層級上粗略規劃遠期工作。它是一種漸進明細的規劃方式,適用於工作包、規劃包以及採用敏捷或瀑布式方法的發布規劃。因此,在專案生命週期的不同階段,工作的詳細程度會有所不同。在早期的策略規劃階段,資訊尚不夠明確,工作包只能分解到已知的詳細水平;而後,隨著了解到更多的信息,近期即將實施的工作包就可以分解到具體的活動。
會議
輸出
活動清單
活動清單包含項目所需的進度活動。對於使用滾動式規劃或敏捷技術的項目,活動清單會在專案進度中定期更新。活動清單包括每個活動的識別及工作範圍詳述,使專案團隊成員知道需要完成什麼工作。
活動屬性
活動屬性是指每項活動所具有的多重屬性,用來擴充活動的描述,活動屬性隨時間演進。在專案初始階段,活動屬性包括唯一活動識別(ID)、WBS識別和活動標籤或名稱;在活動屬性編製完成時,活動屬性可能包括活動描述、緊前活動、緊後活動、邏輯關係、提前量和滯後量、資源需求、強制日期、限制和假設條件。活動屬性可用於識別開展工作的地點、編制開展活動的項目日曆,以及相關的活動類型。活動屬性也可用於編制進度計畫。根據活動屬性,可在報告中以各種方式對計劃進度活動進行選擇、排序和分類。
里程碑清單
里程碑是專案中的重要時點或事件,里程碑清單列出了所有專案里程碑,並指明每個里程碑是強制性的(如合約要求的)還是選擇性的(如根據歷史資訊確定的)。里程碑的持續時間為零,因為它們代表的是一個重要時間點或事件。
變更請求
專案管理計畫更新
進度基準
成本基準
排列活動順序
排列活動順序是識別和記錄專案活動之間的關係的過程,本過程的主要作用是定義工作之間的邏輯順序,以便在既定的所有專案限制因素下獲得最高的效率。
ITTO
輸入
專案管理計劃
進度管理計劃
範圍基準
專案文件
活動屬性
活動屬性中可能描述了事件之間的必然順序或確定的緊前或緊後關係,以及定義的提前量與滯後量,和活動之間的邏輯關係。
活動清單
活動清單列出了項目所需的、待排序的全部進度活動,這些活動的依賴關係和其他限制因素會對活動排序產生影響。
假設日誌
假設日誌所記錄的假設條件和限制因素可能影響活動排序的方式、活動之間的關係,以及對提前量和滯後量的需求,並且有可能產生一個會影響專案進度的風險。
里程碑清單
里程碑清單中可能已經列出特定里程碑的實現日期,這可能會影響活動排序的方式。
事業環境因素
組織過程資產
工具與技術
緊前關係繪圖法
緊前關係繪圖法(PDM)是創建進度模型的技術,以節點表示活動,以一種或多種邏輯關係連接活動,以顯示活動的實施順序。
PDM包括四種依賴關係或邏輯關係。緊前活動是在進度計畫的邏輯路徑中,排在非開始活動前面的活動。緊後活動是在進度計畫的邏輯路徑中,排在某個活動後面的活動。
PDM關係
完成到開始(FS)
只有緊前活動完成,緊後活動才能開始的邏輯關係。例如,只有完成組裝PC硬體(緊前活動),才能開始在PC上安裝作業系統(緊後活動)
完成到完成(FF)
只有緊前活動完成,緊後活動才能完成的邏輯關係。例如,只有完成文件的撰寫(緊前活動),才能完成文件的編輯(緊後活動)
開始到開始(SS)
只有緊前活動開始,緊後活動才能開始的邏輯關係。例如,開始地基澆灌(緊前活動)之後,才能開始混凝土的找平(緊後活動)
開始到完成(SF)
只有緊前活動開始,緊後活動才能完成的邏輯關係。例如,只有啟動新的應付帳款系統(緊前活動),才能關閉舊的應付帳款系統(緊後活動)
確定和整合依賴關係
強制性依賴關係
強制性依賴關係是法律或合約要求的或工作乍的內在性質決定的依賴關係,強制性依賴關係往往與客觀限制有關。例如,在建築工程中,只有在地基建成後,才能建立地面結構;在電子專案中,必須先把原型製造出來,然後才能進行測試。強制性依賴關係又稱硬邏輯關係或硬依賴關係,技術依賴關係可能不是強制性的在活動排序過程中,專案團隊應明確哪些關係是強制性依賴關係,不應把強制性依賴關係和進度計劃編制工具中的進度限制因素混淆。
選擇性依賴關係
選擇性依賴關係有時又稱為首選邏輯關係、優優先邏輯關係或軟邏輯關係。即便還有其他依賴關係可用,選擇性依賴關係應基於具體應用領域的最佳實踐或項目的某些特殊性質對活動順序的要求來創建。例如,根據普遍公認的最佳實踐在建造期間,應先完成衛生管道工程,才能開始電氣工程。這個順序並不是強制性要求,兩個工程可以同時(並行)開展工作,但如按先後順序進行可以降低整體專案風險。選擇性依賴關係應進行全面記錄,因為它們會影響總浮動時間,並限制後續的進度安排。如果打算進行快速跟進,則應審查相應的選擇性依賴關係,並考慮是否需要調整或移除。在排列活動順序過程中,專案團隊應明確哪些依賴關係屬於選擇性依賴關係。
外部依賴關係
外部依賴關係是專案活動與非專案活動之間的依賴關係,這些依賴關係往往不在專案團隊的控制範圍內。例如,軟體專案的測試活動取決於外部硬體的到貨;建築專案的現場準備,可能要在政府的環境聽證會之後才能開始。在排列活動順序過程中,專案管理團隊應明確哪些依賴關係屬於外部依賴關係。
內部依賴關係
內部依賴關係是專案活動之間的緊前關係,通常在專案團隊的控制範圍內。例如,只有機器組裝完畢,團隊才能對其測試,這是一個內部強制性的依賴關係。在排列活動順序過程中,專案管理團隊應明確哪些依賴關係屬於內部依賴關係。
提前量和滯後量
專案管理資訊系統
輸出
專案進度網圖
帶有匯聚和分支的活動受到多個活動的影響或能夠影響多個活動,因此存在更大的風險。 I活動被稱為“路徑匯聚””,因為它擁有多個緊前活動,而K活動被稱為“路徑分支”,因為它擁有多個緊後活動。
專案文件更新
活動屬性
活動清單
假設日誌
里程碑清單
估算活動持續時間
估算活動持續時間是根據資源估算的結果,估算完成單一活動所需工作時段數的過程。這個過程的主要作用是,確定完成每個活動所需花費的時間量。
估算活動持續時間依據的資訊包括:工作範圍、所需資源類型與技能水平、估算的資源數量和資源日曆,而可能影響持續時間估算的其他因素包括對持續時間受到的約束、相關人力投入、資源類型(如固定持續時間、固定人力投入或工作、固定資源數量)以及所採用的進度網路分析技術。應該由專案團隊中最熟悉特定活動的個人或小組提供持續時間估算所需的各種輸入,對持續時間的估算也應該漸進明細,取決於輸入資料的數量和品質。例如,在工程與設計專案中,隨著數據越來越詳細,越來越準確,持續時間估算的準確性和品質也會越來越高。
在這個過程中,應先估算出完成活動所需的工作量和計畫投入該活動的資源數量,然後結合專案行事曆和資源行事曆,據此估算出完成活動所需的工作時段數(活動持續時間) 。在許多情況下,預計可用的資源數量以及這些資源的技能熟練程度可能會決定活動的持續時間,更改分配到活動的主導性資源通常會影響持續時間,但這不是簡單的「直線」或線性關係。有時候,因為工作的特性(即受到持續時間的約束、相關人力投入或資源數量),無論資源分配如何(如24小時應力測試),都需要花預定的時間才能完成工作。
估算持續時間時需要考慮的其他因素
收益遞減規律
在保持其他因素不變的情況下,增加一個用於確定單位產出所需投入的因素(如資源)會最終達到一個臨界點,在該點之後的產出或產出會隨著增加這個因素而遞減。
資源數量
增加資源數量,使其達到初始數量的兩倍不一定能縮短一半的時間,因為這樣做可能會因風險而造成持續時間增加;在某些情況下,如果增加太多活動資源,可能會因知識傳遞、學習曲線、額外合作等其他相關因素而造成持續時間增加。
技術進步
在確定持續時間估算時,這個因素也可能發揮重要作用。例如,透過採購最新技術,製造工廠可以提高產量,而這可能會影響持續時間和資源需求。
員工激勵
專案經理也需要了解「學生症候群」(即拖延症)和帕金森定律,前者指出,人們只有在最後一刻,即快到期限時才會全力以赴;後者指出,只要還有時間,工作就會不斷擴展,直到用完所有的時間。
應該把活動持續時間估算所依據的全部數據與假設都記錄在案。
ITTO
輸入
專案管理計劃
進度管理計劃
範圍基準
專案文件
活動屬性
活動清單
假設日誌
經驗教訓登記冊
里程碑清單
專案團隊派遣工單
將合適的人員分派到團隊,為專案配備人員。
資源分解結構
資源分解結構依照資源類別和資源類型,提供了已識別資源的層級結構。
資源日曆
資源行事曆中的資源可用性、資源類型和資源性質,都會影響進度活動的持續時間。資源日曆規定了在專案期間特定的專案資源何時可用及可用多久。
資源需求
估算的活動資源需求會對活動持續時間產生影響。對於大多數活動來說,所分配的資源能否達到要求,將對其持續時間有顯著影響。例如,在某個活動中新增資源或分配低技能資源,就需要增加溝通、訓練和協調工作,這可能導致活動效率或生產力下降,由此需要估算更長的持續時間。
風險登記冊
單一專案風險可能影響資源的選擇和可用性。風險登記冊的更新包括在專案文件更新中
事業環境因素
組織過程資產
工具與技術
專家判斷
類比估算
類比估算是一種使用相似活動或專案的歷史數據,來估算當前活動或專案的持續時間或成本的技術。類比估算以過去類似項目的參數值(如持續時間、預算、規模、重量和複雜性等)為基礎,來估算未來專案的同類參數或指標。在估算持續時間時,類比估算技術以過去類似專案的實際持續時間為依據,來估算目前專案的持續時間。這是一種粗略的估算方法,有時需要根據專案複雜性方面的已知差異進行調整,在專案詳細資訊不足時,就經常使用類比估算來估算專案持續時間。
相對於其他估算技術,類比估算通常成本較低、耗時較少,但準確性也較低。類比估算可以針對整個專案或專案中的某個部分進行,或可以與其他估算方法合併使用。如果以往活動是本質上而不是表面上類似,而從事估算的專案團隊成員具備必要的專業知識,那麼類比估算就最為可靠。
參數估算
參數估算是一種基於歷史資料和專案參數,使用某種演算法來計算成本或持續時間的估算技術。它是指利用歷史資料之間的統計關係和其他變數(如建築施工二中的平方英尺),來估算諸如成本、預算和持續時間等活動參數。
把需要實施的工作量乘以完成單位工作量所需的工時,即可計算出持續時間。例如,對於設計項目,將圖紙的張數乘以每張圖紙所需的工時;或者對於電纜鋪設項目,將電纜的長度乘以鋪設每米電纜所需的工時。如果所使用的資源每小時能夠鋪設25公尺電纜,那麼鋪設1000公尺電纜的持續時間是40小時(1000公尺除以25公尺/小時)
參數估算的準確性取決於參數模型的成熟度和基礎資料的可靠性。且參數進度估算可以針對整個專案或專案中的某個部分,並且可以與其他估算方法合併使用。
三點估算
計劃評審技術(PERT) , 又稱三點估算法(Program Evaluation and Review Technique)
透過考慮估算中的不確定性和風險,可以提高持續時間估算的準確性。使用三點估算有助於界定活動持續時間的近似區間
最可能時間(tM)。基於最可能取得的資源、最可能取得的資源生:產率、對資源可用時間的現實預期、資源對其他參與者的可能依賴關係及可能發生的各種幹擾等,所估算的活動持續時間。
最樂觀時間(t0)。基於活動的最好情況所估算的活動持續時間。
最悲觀時間(tP)。基於活動的最差情況所估算的持續時間。
基於持續時間在三種估算值區間內的假定分佈情況,可計算期望持續時間tE。
計算方式
第一步:計算期望時間
基於貝塔分佈:te=(to 4tw tp)/6
基於三角分佈:tg=(to ty tp)/3
第二步:計算標準差
標準差Sigma:o=(tp-to)/6
變異數:o2=[(tp-to)/6]2
歷史資料不充分或使用判斷資料時,使用三角分佈,基於三點的假定分佈估算出期望持續時間,並說明期望持續時間的不確定區間。
由下而上估算
自下而上估算是一種估算專案持續時間或成本的方法,透過從下到上逐層總結WBS組成部分的估算而得到專案估算。如果無法以合理的可信度對活動持續時間進行估算,則應將活動中的工作進一步細化,然後估算具體的持續時間,接著再匯總這些資源需求估算,得到每個活動的持續時間。活動之間可能存在或不存在會影響資源利用的依賴關係;如果存在,就應該對相應的資源使用方式加以說明,並記錄在活動資源需求中。
數據分析
備選方案分析
替代方案分析用於比較不同的資源能力或技能等級、進度壓縮技術、不同工具(手動和自動),以及關於資源的創建、租賃和購買決策。這有助於團隊權衡資源、成本和持續時間變量,以確定完成專案工作的最佳方式。
儲備分析
應急儲備是包含在進度基準中的一段持續時間,用來應對已接受的已識別風險。應急儲備與「已知一未知」風險相關,需要加以合理估算,用於完成未知的工作量。應急儲備可取活動持續時間估算值的某一百分比或某一固定的時間段,亦可把應急儲備從各個活動中剝離出來並匯總。隨著專案資訊越來越明確,可以動用、減少或取消應急儲備,應該在專案進度文件中清楚列出應急儲備。
也可以估算專案進度管理所需的管理儲備量。管理儲備是為管理控制的目的而特別留出的專案預算,用來應對專案範圍中不可預見的工作。管理儲備用來應對會影響專案的「未知-未知」風險,它不包括在進度基準中,但屬於專案總持續時間的一部分。依據合約條款,使用管理儲備可能需要變更進度基準。
決策
適用於本過程的決策技術包括(但不限於)投票。舉手錶決是從投票方法衍生出來的一種形式,經常用於敏捷專案中。採用這種技術時,專案經理會讓團隊成員針對某個決定示意支持程度,舉拳頭表示不支持,伸五個手指表示完全支持,伸出三個以下手指的團隊成員有機會與團隊討論其反對意見。專案經理會不斷進行舉手錶決,直到整個團隊達成共識(所有人都伸出三個以上手指)或同意進入下一個決定。
會議
專案團隊可能會召開會議來估算活動持續時間。如果採用敏捷方法,則有必要舉行衝刺或迭代計劃會議,以討論按優先順序排序的產品未完項(使用者故事),並決定團隊在下一個迭代中會致力於解決哪個未完項。然後團隊將使用者故事分解為按小時估算的底層任務,然後根據團隊在持續時間(迭代)方面的能力確認估算可行。該會議通常在迭代的第一天舉行,與會者包括產品負責人、開發團隊和專案經理,會議結果包括迭代未完項、假設條件、關注事項、風險、依賴關係、決定和行動。
輸出
持續時間估算
持續時間估算是對完成某項活動、階段或專案所需的工作時段數的定量評估,其中並不包括任何滯後量,但可指出一定的變動區間。
估算依據
持續時間估算所需的支援資訊的數量和種類,因應用領域而異。不論其詳細程度如何,支持性生文件都應該清晰、完整地說明持續時間估算是如何得出的。
持續時間估算的支持資訊可包括
關於估算依據的文件(如估算是如何編製的)
關於全部假設條件的文件
關於各種已知限制因素的文件
估算區間的說明(如「±10%"),以指出預期持續時間的所在區間
最終估算的置信水準的說明
有關影響估算的單一專案風險的文件
專案文件更新
活動屬性
假設日誌
經驗教訓登記冊
制定進度計劃
制定進度計畫是分析活動順序持續時間、資源需求和進度限制因素,建立進度模型,從而落實專案執行和監控的過程。本過程的主要作用是,為完成專案活動而製定具有計劃日期的進度模型。
ITTO
輸入
專案管理計劃
進度管理計劃
範圍基準
專案文件
活動屬性
活動清單
假設日誌
估算依據
持續時間估算
經驗教訓登記冊
里程碑清單
專案進度網圖
專案團隊派遣工單
專案團隊派工單明確了分配到每個活動的資源。
資源日曆
資源日曆規定了在專案期間的資源可用性。
資源需求
活動資源需求明確了每個活動所需的資源類型和數量,用於建立進度模型。
風險登記冊
風險登記冊中的所有已識別的會影響進度模型的風險的詳細資訊及特徵。進度儲備則透過預期或平均風險影響程度,反映了與進度相關的風險資訊。
協定
在製定如何執行專案工作以履行合約承諾的詳細資訊時,供應商為專案進度提供了輸入。
事業環境因素
組織過程資產
工具與技術
進度網分析
進度網路分析是創建專案進度模型的一種綜合技術,它採用了其他幾種技術,例如關鍵路徑法、資源最佳化技術和建模技術。
其他分析包括(但不限於)
當多個路徑在同一時間點匯聚或分叉時,評估匯總C總進度儲備的必要性,以減少進度落後的可能性。
檢視網絡,看看關鍵路徑是否存在高風險活動或具有較多提前量的活動,是否需要使用進度儲備或執行風險應對計劃來降低關鍵路徑的風險。
進度網路分析是一個反覆進行的過程,一直持續到創建出可行的進度模型。
關鍵路徑法
關鍵路徑法用於在進度模型中估算專案最短工期,確定邏輯網路路徑的進度彈性大小。這種進度網路分析技術在不考慮任何資源限制的情況下,沿著進度網路路徑使用順推與逆推法,計算出所有活動的最早開始、最早結束、最晚開始和最晚法完成日期。
關鍵路徑是專案中時間最長的活動順序,決定可能的專案最短工期。最長路徑的總浮動時間最少,通常為零。由此得到的最早和最晚的開始和結束日期並不一定就是專案進度計劃,而只是把既定的參數(活動持續時間、邏輯關係、提前量、滯後量和其他已知的限制因素)輸入進度模型後所得到的一種結果,顯示活動可以在該時段內實施。關鍵路徑法用來計算進度模型中的關鍵路徑、總浮動時間和自由浮動時間,或邏輯網路路徑的進度彈性大小。
在任一網路路徑上,進度活動可以從最早開始日期延遲或拖延的時間,而不至於延誤專案完成日期或違反進度限制因素,就是總浮動時間或進度彈性。正常情況下,關鍵路徑的總浮動時間為零。在進行緊前關係繪圖法排序的過程中,取決於所使用的限制因素,關鍵路徑的總浮動時間可能是正值、零或負值。總浮動時間為正值,是由於逆推計算所使用的進度限制因素要晚於順推計算所得出的最早完成日期;總浮動時間為負值,是由於持續時間和邏輯關係違反了對最晚日期的限制因素。負值浮動時間分析是一種有助於找到推動延遲的進度回到正軌的方法的技術。進度網圖可能有多條次關鍵路徑。許多軟體允許使用者自行定義用於確定關鍵路徑的參數。為了使網路路徑的總浮動時間為零或正值,可能需要調整活動持續時間(可增加資源或縮減範圍時)、邏輯關係(針對選擇性依賴關係時)、提前量和滯後量,或其他進度制約因素。一旦計算出總浮動時間和自由浮動時間,自由浮動時間就是指在不延誤任何緊後活動最早開始日期或不違反進度限制因素的前提下,某進度活動可以推遲的時間量。
正推法與逆推法
最早開始時間ES(指向該活動的所有緊前活動未完成前,該活動不能開始),最早完工時間EF=ES d(活動歷時),採用正推法得到。
最遲完工時間LF(從該活動出發的所有緊後活動開始前,該活動必須完成),最遲開始時間LS=LF-d,採用逆推法得到。
總浮時和自由浮時
總時差TF=LF-EF或LS-ES_,活動在不延誤專案完成日期或違反進度限制因素的前提下,某進度活動可以延後的總時間量(最早開始時間可以延後的量),TF為0的路徑為CP(關鍵路徑)o
自由時差FF=緊後ES-EF,活動在不延誤其緊後進度活動最早開始日期的前提下,某進度活動可以推遲的時間量(最早結束時間可以延遲的量)。
資源最佳化
資源平滑
對進度模型中的活動進行調整,從而使專案資源需求不超過預定的資源限制的一種技術。相對於資源平衡而言,資源平滑不會改變專案關鍵路徑,完工日期也不會延遲。也就是說,活動只在其自由和總浮動時間內延遲,但資源平滑技術可能無法實現所有資源的最佳化。
資源平衡
為了在資源需求與資源供給之間取得平衡,根據資源限制因素對開始日期和完成日期進行調整的一種技術。如果共享資源或關鍵資源只在特定時間可用,數量有限,或被過度分配,如一個資源在同一時段內被分配至兩個或多個活動,就需要進行資源平衡。也可以為維持資源使用量處於均衡水準而進行資源平衡。資源平衡往往導致關鍵路徑改變。因此,在專案進度規劃期間,關鍵路徑可能會發生變化。
數據分析
假設情境分析
假設情境分析是對各種情境進行評估,預測它們對專案目標的影響(正面或負面的)。假設情境分析就是對「如果情境X出現,情況會怎樣?」這樣的問題進行分析,即基於已有的進度計劃,考慮各種各樣的情景。例如,延後某主要零件的交貨日期,延長某設計工作的時間,或加入外部因素(如罷工或許可證申請流程變更等)可以根據假設情境分析的結果,評估專案進度計畫在不同條件下的可行性,以及為應對意外情況的影響而編制進度儲備和應對計劃。
模擬
模擬是把單一專案風險和不確定性的其他來源模型化的方法,以評估它們對專案目標的潛在影響。最常見的模擬技術是蒙特卡羅分析,它利用風險和其他不確定資源來計算整個專案可能的進度結果。模擬包括基於多種不同的活動假設、限制、風險、問題或情景,使用機率分佈和不確定性的其他表現形式,來計算出多種可能的工作包持續時間。
提前量和滯後量
進度壓縮
進度壓縮技術是指在不縮減專案範圍的前提下,縮短或加速進度工期,以滿足進度限制、強制日期或其他進度目標。負值浮動時間分析是一種有用的技巧。關鍵路徑是浮動時間最少的方法。在違反限制因素或強制日期時,總浮動時間可能會變成負值。
趕工
透過增加資源,以最小的成本代價來壓縮進度工期的一種技術。趕工的例子包括:批准加班、增加額外資源或支付加急費用,以加快關鍵路徑上的活動。趕工只適用於那些透過增加資源就能縮短持續時間的,且位於關鍵路徑上的活動。但趕工並非總是切實可行的,因它可能導致風險和/或成本的增加。
快速跟進
一種進度壓縮技術,將正常情況下依序進行的活動或階段改為至少部分並行。例如,在大樓的建築圖尚未全部完成前就開始建造地基。快速跟進可能造成返工和風險增加,所以它只適用於能夠透過並行活動來縮短關鍵路徑上的專案工期的情況。以防進度加快而使用提前量通常增加相關活動之間的協調工作,並增加品質風險。快速跟進還有可能增加專案成本。
專案管理資訊系統
敏捷發布規劃
輸出
進度基準
進度基準是經過核准的進度模型,只有透過正式的變更控管程序才能進行變更,用作與實際結果進行比較的依據。經相關方接受並批准,進度基準包含基準開始日期和基準結束日期。在監控過程中,將以實際開始和完成日期與核准的基準日期進行比較,以確定是否有偏差。進度基準是專案管理計畫的組成部分。
專案進度計劃
工作進度是透過截止日期或狀態日期表示的。針對一個簡單的項目,進度計劃的三種形式:(1)里程碑進度計劃,也叫里程碑圖;(2)概括性進度計劃,也叫橫道圖;(3)詳細進度計劃,也叫項目進度關聯橫道圖。
進度數據
專案進度模型中的進度資料是用來描述和控制進度計畫的資訊集合。進度資料至少包括進度里程碑、進度活動、活動屬性,以及已知的全部假設條件與限制因素,而所需的其他資料因應用領域而異。
經常可用作支援細節的資訊包括(但不限於)
按時段計列的資源需求,往往以資源直方圖表示;
備選的進度計劃,如最佳情況或最壞情況下的進度計劃、經資源平衡或未經資源平衡的進度計
劃、有強制日期或無強制日期的進度計畫;
使用的進度儲備。
進度資料還可包含資源直方圖、現金流量預測,以及訂購與交付進度安排等其他相關資訊。
專案日曆
在專案日曆中規定可以進行進度活動的可用工作日和工作班次,它把可用於進行進度活動的時間段(按天或更小的時間單位)與不可用的時間段區分開來。在一個進度模型中,可能需要採用不只一個專案日曆來編制專案進度計劃,因為有些活動需要不同的工作時段。因此,可能需要對專案日曆進行更新。
變更請求
專案管理計畫更新
進度管理計劃
成本基準
專案文件更新
活動屬性
假設日誌
持續時間估算
經驗教訓登記冊
資源需求
風險登記冊
控制進度
控制進度是監督專案狀態,以更新專案進度和管理進度基準變更的流程。本過程的主要作用是在整個專案期間保持對進度基準的維護,且需要在整個專案期間進行。
ITTO
輸入
專案管理計劃
進度管理計劃
進度基準
範圍基準
績效衡量基準
專案文件
經驗教訓登記冊
在專案早期獲得的經驗教訓可以運用到後期階段,以改善進度控制。
專案日曆
在一個進度模型中,可能需要不只一個專案日曆來預測專案進度,因為有些活動需要不同的工作時段。
專案進度計劃
專案進度計劃是最新版本的專案進度計劃,其中圖示了截至指定日期的更新、已完成活動和已開始活動。
資源日曆
資源行事曆顯示了團隊和物質資源的可用性。
進度數據
在控制進度過程中需要對進度資料進行審查和更新。
工作績效數據
工作績效數據包含關於專案狀態的數據,例如哪些活動已經開始,它們的進度如何(如實際持續時間、剩餘持續時間和實際完成百分比),哪些活動已經完成
組織過程資產
工具與技術
數據分析
掙值分析
迭代燃盡圖
這類圖用於追蹤迭代未完項中尚待完成的工作。它基於迭代規劃中確定的工作,分析與理想燃盡圖的偏差。可使用預測趨勢線來預測迭代結束時可能出現的偏差,以及在迭代期間應該採取的合理行動。在燃盡圖中,先用對角線表示理想的燃盡情況,再每天畫出實際剩餘工作,最後基於剩餘工作計算出趨勢線以預測完成情況。
績效審查
績效審查是指根據進度基準,測量、對比和分析進度績效,如實際開始和完成日期、已完成百分比,以及目前工作的剩餘持續時間。
趨勢分析
趨勢分析檢視專案績效隨時間的變化情況,以確定績效是在改善還是惡化。圖形分析技術有助於理解截至目前為止的績效,並與未來的績效目標(以完工日期表示)進行比較。
偏差分析
偏差分析著重實際開始和完成日期與計畫的偏離,實際持續時間與計畫的差異,以及浮動時間的偏差。它包括確定偏離進度基準的原因與程度,評估這些偏差對未來工作的影響,以及確定是否需要採取糾正或預防措施。例如,非關鍵路徑上的某個活動發生較長時間的延誤,可能不會對整體專案進度產生影響;而某個關鍵或次關鍵活動的稍許延誤,卻可能需要立即採取行動。
假設情境分析
假設情境分析是基於專案風險管理流程的輸出,對各種不同的情境進行評估,促使進度模型符合專案管理計畫和核准的基準。
關鍵路徑法
專案管理資訊系統
資源最佳化
提前量和滯後量
進度壓縮
輸出
工作績效訊息
工作績效資訊包括與進度基準相比較的專案工作執行情況。可以在工作包層級和控制帳戶層級,計算開始和完成日期的偏差以及持續時間的偏差。對於使用掙值分析的項目,進步偏差(SV)和進度績效指數(SP)將記錄在工作績效報告中。
進度預測
進度更新即進度預測,指根據現有的資訊和知識,對專案未來的情況和事件進行的估算或預計。隨著專案執行,應該基於工作績效訊息,更新和重新發布預測。這些資訊是基於專案的過去績效,並取決於糾正或預防措施所期望的未來績效,可能包括掙值績效指數,以及可能在未來對專案造成影響的進度儲備資訊。
變更請求
專案管理計畫更新
進度管理計劃
進度基準
成本基準
績效衡量基準
專案文件更新
假設日誌
估算依據
經驗教訓登記冊
專案進度計劃
資源日曆
風險登記冊
進度數據
專案成本管理
概述說明
規劃成本管理
規劃成本管理是確定如何估算、預算、管理、監督和控制專案成本的過程。本過程的主要作用是,在整個專案期間為如何管理專案成本提供指南和方向。
ITTO
輸入
專案章程
專案管理計劃
進度管理計劃
風險管理計劃
事業環境因素
組織過程資產
工具與技術
專家判斷
數據分析
會議
輸出
成本管理計劃
成本管理計畫是專案管理計畫的組成部分,描述將如何規劃、安排和控制專案成本。成本管理過程及其工具與技術應記錄在成本管理計畫中。
需要成本管理計畫中規定的內容
計量單位
需要規定每種資源的計量單位,例如用於測量時間的人時數、人天數或週數,用於計量數量的米、公升、噸、千米或立方碼,或用貨幣表示的總價。
精確度
根據活動範圍和項目規模,設定成本估算向上或向下取整的程度(例如995.59美元取整為1,000美元)
準確度
為活動成本估算規定一個可接受的區間(如±10%),其中可能包括一定數量的緊急儲備。
組織程式連結
工作分解結構為成本管理計劃提供了框架,以便據此規範地進行成本估算、預算和控制。在專案成本會計中使用的WBS組成部分,稱為控制帳戶(CA),每個控制帳戶都有唯一的編碼或帳號,直接與執行組織的會計制度相聯繫。
控制臨界值
可能需要規定偏差臨界值,用於監督成本績效。它是在需要採取某種措施前,允許出現的最大差異,通常用偏離基準計劃的百分數來表示。
績效衡量規則
需要規定用於績效測量的掙值管理(EVM)規則。例如,成本管理計畫應該:定義WBS中用於績效測量的控制帳戶;確定擬用的EVM技術(如加權里程碑法、固定公式法、完成百分比法等);規定追蹤方法,以及用於計算專案完工估算(EAC)的EVM公式,此公式計算出的結果可用於驗證透過自下而上方法得出的完工估算。
報告格式
需要規定各種成本報告的格式和編制頻率。
其他細節
關於成本管理活動的其他細節包括(但不限於):對策略性籌資方案的說明;處理匯率波動的程序;記錄專案成本的程序。
估算成本
估算成本是對完成專案工作所需資源成本進行近似估算的過程。本過程的主要作用是,確定專案所需的資金。
估算成本的原則
成本估算是對完成活動所需資源可能成本的量化評估;
估算應該由最熟悉活動或工作包的人來進行;
通常以某種貨幣單位(如美元、歐元、日圓等)進行成本估算,但有時也可採用其他計量單位,如人時數或人天數,以消除通貨膨脹的影響,便於成本比較。估算時需識別及分析備選成本方案;
在啟動階段可得出專案的粗略量級估算(Rough Order of Magnitude,ROM),其區間為-25%到75%;之後,隨著資訊越來越詳細,確定性估算的區間可縮小至- 5%到10%;
估算的額度請務必附上對應的估算依據。
ITTO
輸入
專案管理計劃
成本管理計劃
品質管理計劃
範圍基準
專案文件
經驗教訓登記冊
專案早期與制定成本估算相關的經驗教訓可以運用到專案後期階段,以提高成本估算的準確度和精確度。
專案進度計劃
進度計畫包括專案可用的團隊和實體資源的類型、數量和可用時間長短。如果資源成本取決於使用時間的長短,且成本出現季節波動,則持續時間估算會對成本估算產生影響。進度計劃還為包含融資成本(包括利息)的項目提供有用資訊。
資源需求
資源需求明確了每個工作包或活動所需的資源類型和數量。
風險登記冊
風險登記冊包含了已識別並按優先順序排列的單一項目風險的詳細信息,及針對這些風險採取的應對措施。風險登記冊還提供了可用於估算成本的詳細資訊。
事業環境因素
組織過程資產
工具與技術
專家判斷
類比估算
參數估算
由下而上估算
三點估算
數據分析
備選方案分析
備選方案分析是一種對已識別的可選方案進行評估的技術,用來決定選擇哪種方案或使用何種方法來執行專案工作。例如評估購買和製造可交付成果分別對成本、進度、資源和品質的影響。
儲備分析
為因應成本的不確定性,成本估算中可以包括應急儲備(有時稱為「應急費用」應急儲備是包含在成本基準內的一部分預算,用來應對已識別的風險;應急儲備也通常是預算的一部分,用來應對那些會影響專案的「已知-未知」風險。的返工工作。
而隨著專案資訊越來越明確,可以動用、減少或取消應急儲備。應該在成本文件中清楚列出應急儲備。應急儲備是成本基準的一部分,也是專案整體資金需求的一部分。
品質成本
專案管理資訊系統
決策
投票
輸出
成本估算
成本估算包括完成專案工作可能需要的成本、應對已識別風險的緊急儲備,以及應對計劃外工作的管理儲備的量化估算。成本估算可以是匯總的或詳細分列的。成本估算應涵蓋專案所使用的全部資源,包括(但不限於)直接人工、材料、設備、服務、設施、資訊技術,以及一些特殊的成本種類,如融資成本(包括利息)、通貨膨脹補貼、匯率或成本應急儲備。若間接成本也包含在專案估算中,則可在活動層次或更高層次上計算間接成本。
估算依據
成本估算所需的支援資訊的數量和種類,因應用領域而異,不論其詳細程度如何,支持性文件都應該清晰、完整地說明成本估算是如何得出的。
成本估算的支援資訊可包括
關於估算依據的文件(如估算是如何編製的);
關於全部假設條件的文件;
關於各種已知限制因素的文件;有關已識別的、在估算成本時應考慮的風險的文件;
估算區間的說明(如「10,000美元±10%」就說明了預期成本的所在區間);
最終估算的置信水準的說明。
專案文件更新
假設日誌
經驗教訓登記冊
風險登記冊
制定預算
制定預算是匯總所有單一活動或工作包的估算成本,建立一個經批准的成本基準的過程。本過程的主要作用是,確定可據以監督和控制專案績效的成本基準。
專案預算包括經批准用於執行專案的全部資金,而成本基準是經過批准且按時間段分配的專案預算,包括緊急儲備,但不包括管理儲備。
ITTO
輸入
專案管理計劃
成本管理計劃
資源管理計劃
範圍基準
專案文件
估算依據
在估算依據中包含基本的假設條件,例如,專案預算中是否應該包含間接成本或其他成本。
成本估算
各工作包內每個活動的成本估算加總後,即得到各工作包的成本估算。
專案進度計劃
專案進度計劃包括專案活動、里程碑、工作包和控制帳戶的計劃開始和完成日期。可根據這些信息,把計劃成本和實際成本匯總到對應的日曆時段。
風險登記冊
應該審查風險登記冊,以確定如何彙總風險應對成本。風險登記冊的更新包含在專案文件更新中
商業文件
商業論證
商業論證識別了專案成功的關鍵因素,包括財務成功因素。
效益管理計劃
效益管理計畫包括目標效益,例如淨現值的計算、實現效益的時限,以及與效益相關的測量指標。
協定
事業環境因素
組織過程資產
工具與技術
專家判斷
成本匯總
先把成本估算匯總到WBS中的工作包,再由工作包匯總至WBS的更高層次(如控制帳戶),最後得出整個專案的總成本。
數據分析
儲備分析
可用於制定預算過程的資料分析技術包括(但不限於)可以建立專案管理儲備的儲備分析。管理儲備是為了管理控制的目的而特別留出的專案預算,用來應對專案範圍中不可預見的工作,目的是用來應對會影響專案的「未知-未知」風險。管理儲備不包括在成本基準中,但屬於專案總預算和資金需求的一部分。當動用管理儲備資助不可預見的工作時,就要把動用的管理儲備增加到成本基準中,進而導致成本基準變更。
歷史資訊審核
審核歷史資訊有助於進行參數估算或類比估算。歷史資訊可包括各種項目特徵(參數),它們用於建立數學模型預測項目總成本。這些數學模型可以是簡單的(例如,建造住房的總成本取決於單位面積建造成本),也可以是複雜的(例如,軟體開發專案的成本模型中有多個變量,每個變數又受許多因素的影響)。
資金限制平衡
應該根據對專案資金的任何限制,來平衡資金支出。如果發現資金限制與計劃支出之間的差異,則可能需要調整工作的進度計劃,以平衡資金支出水準。這可以透過在專案進度計劃中新增強制日期來實現。
融資
融資是指為專案獲取資金。長期的基礎設施、工業和公共服務項目通常會尋求外部融資。如果專案使用外部資金,出資實體可能會提出一些必須滿足的要求。
輸出
成本基準
專案資金需求
根據成本基準,確定總資金需求和階段性(如季度或年度)資金需求。成本基準中既包括預計支出及預計債務。專案資金通常以增量的方式投入,並且可能是非均衡的,呈現上圖所示的階梯狀。如果有管理儲備,則總資金需求等於成本基準加管理儲備。在資金需求文件中,也可說明資金來源。
專案文件更新
成本估算
專案進度計劃
風險登記冊
控製成本
控製成本是監督專案狀態,以更新專案成本和管理成本基準變更的過程。本過程的主要作用是,在整個專案期間保持對成本基準的維護。
要更新預算,就需要了解截至目前為止的實際成本。只有經過實施整體變更控制流程的批准,才可以增加預算。只監督資金的支出,而不考慮由這些支出所完成的工作的價值,對專案沒有意義,最多只能追蹤資金流。所以在成本控制中,應著重分析專案資金支出與相應完成的工作之間的關係。有效成本控制的關鍵在於管理經批准的成本基準。
專案成本控制包括
對造成成本基準變更的因素施加影響;
確保所有變更請求都得到及時處理;
當變更實際發生時,管理這些變更;
確保成本支出不超過核准的資金限額, 既不超出按時、按WBS
組件、依活動分配的限額,
也不超出專案總限額;
監督成本績效,找出並分析與成本基準間的偏差;
對照資金支出,監督工作績效;
防止在成本或資源使用報告中出現未經批准的變更;
向相關方報告所有經批准的變更及其相關成本;
設法把預期的成本超支控制在可接受的範圍內。
ITTO
輸入
專案管理計劃
成本管理計劃
成本基準
績效衡量基準
專案文件
經驗教訓登記冊
專案資金需求
工作績效數據
組織過程資產
工具與技術
專家判斷
數據分析
掙值分析
偏差分析
趨勢分析
儲備分析
在控製成本過程中,可以採用儲備分析來監督專案中緊急儲備和管理儲備的使用情況,從而判斷是否還需要這些儲備,或者是否需要增加額外的儲備。隨著專案工作的進展,這些儲備可能已按計劃用於支付風險或其他應急情況的成本;反之,如果抓住機會節約了成本,節約下來的資金可能會增加到應急儲備中,或作為盈利/利潤從項目中剝離。
如果已識別的風險沒有發生,就可能要從專案預算中扣除未使用的緊急儲備,為其他專案或營運騰出資源。同時,在專案中進行進一步風險分析,可能會發現需要為專案預算申請額外的儲備。
完工尚需績效指數
專案管理資訊系統
輸出
工作績效訊息
成本預測
變更請求
專案管理計畫更新
成本管理計劃
成本基準
績效衡量基準
專案文件更新
假設日誌
估算依據
成本估算
經驗教訓登記冊
風險登記冊
專案品質管理
概述說明
「品質」與「等級」不是相同的概念。品質作為實現的性能或成果,是「一系列內在特性滿足要求的程度」(ISO9000)【18】。等級作為設計意圖,是對用途相同但技術特性不同的可交付成果的等級分類。專案經理及專案管理團隊負責權衡,以便同時達到所要求的品質與等級。品質等級未達到品質要求肯定是個問題,而低等級產品不一定是個問題。
一個低等級(功能有限)產品具備高品質(無明顯缺陷),也許不是問題。本產品適合一般使用。
一個高等級(功能繁多)產品品質低(有許多缺陷),也許是個問題。本產品的功能會因品質低劣而無效和/或低效。
預防勝於檢查。最好將品質設計到可交付成果中,而不是在檢查時發現品質問題。預防錯誤的成本通常遠低於在檢查或使用中發現並糾正錯誤的成本。
根據不同的專案和產業領域,專案團隊可能需要具備統計控製過程的實用知識,以便評估控製品質的輸出中所包含的資料。
專案管理團隊應了解以下術語之間的差別
「預防」(保證過程中不出現錯誤)與「檢查」(保證錯誤不會落在客戶手中);
「屬性抽樣」(結果為合格或不合格)與「變數抽樣」(在連續的量表上標示結果所處的位置,表示合格的程度)
「公差」(結果的可接受範圍)與「控制界限」(在統計意義上穩定的過程或過程績效的普通偏差的邊界)。
依有效性遞增排列的五種品質管理水平
通常,代價最大的方法是讓客戶發現缺陷。這種方法可能會導致擔保問題、召回、商譽受損和返工成本。
控製品質過程包括先檢測和糾正缺陷,再將可交付成果發送給客戶。這個過程會帶來相關成本,主要是評估成本和內部失敗成本。
透過品質保證檢查並糾正過程本身,而不僅僅是特殊缺陷。將品質融入專案和產品的規劃和設計中。
在整個組織內創造一種關注並致力於實現流程和產品品質的文化。
專案品質管理的趨勢和新興實踐
現代品質管理方法力求縮小差異,交付符合既定相關方要求的成果
專案品質管理的趨勢可能包括(但不限於)
客戶滿意
了解、評估、定義和管理要求,以便滿足客戶的期望。這就需要把「符合要求」(確保專案產出預定的成果)和「適合使用」(產品或服務必須滿足實際需求)結合起來。在敏捷環境中,相關方與專案管理團隊合作可確保在整個專案期間始終做到客戶滿意。
持續改進
由休哈特提出並經戴明完善的「計畫-實施-檢查-行動(PDCA)」循環是品質改善的基礎。另外,諸如全面品質管理(TQM)、六西格瑪和精益六西格瑪等品質改善措施也可以提高專案管理的品質以及最終產品、服務或成果的品質。
管理階層的責任
專案的成功需要專案團隊全體成員的參與。管理階層在其品質職責內,肩負著為專案提供具有足夠能力的資源的相應責任。
與供應商的互利合作關係
組織與其供應商相互依賴。相對傳統的供應商管理而言,與供應商建立合作關係對組織和供應商都更有益。組織應著眼於長期關係而不是短期利益。互利合作關係增強了組織和供應商互相為對方創造價值的能力,推動他們共同實現客戶的需求和期望,並優化成本和資源。
專案品質管理的過程之間關係
規劃品質管理
規劃品質管理是識別專案及其可交付成果的品質要求和(或)標準,並書面描述專案將如何證明符合品質要求和(或)標準的流程。本過程的主要作用是,為在整個專案期間如何管理和核實品質提供指南和方向。
ITTO
輸入
專案章程
專案管理計劃
需求管理計劃
風險管理計劃
相關方參與計劃
範圍基準
在確定適用於專案的品質標準和目標時,以及在確定要求品質審查的專案可交付成果和流程時,需要考慮WBS和專案範圍說明書中記錄的可交付成果。範圍說明書包含可交付成果的驗收標準。此標準的界定可能導致品質成本並進而導致專案成本的顯著升高或降低。滿足所有的驗收標準意味著滿足相關方的需求。
專案文件
假設日誌
需求文件
需求文件記錄項目和產品為滿足相關方的期望應達到的要求,它包括(但不限於)針對項目和產品的品質要求。這些需求有助於專案團隊規劃將如何實施專案品質控制。
需求追蹤矩陣
需求追蹤矩陣將產品需求連接到可交付成果,有助於確保需求文件中的各項需求都得到測試。矩陣提供了核實需求時所需測試的概述。
風險登記冊
相關方登記冊
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
標竿對照
腦力激盪
訪談
數據分析
成本效益分析
成本效益分析是用來估算備選方案優勢和劣勢的財務分析工具,以確定可以創造最佳效益的替代方案。成本效益分析可協助專案經理確定規劃的品質活動是否有效利用了成本。達到品質要求的主要效益包括減少返工、提高生產力、降低成本、提升相關方滿意度及提升贏利能力。對每個品質活動進行成本效益分析,就是要比較其可能成本與預期效益。
品質成本
與專案相關的品質成本(COQ)包含以下一種或多種成本
預防成本
預防特定專案的產品、可交付成果或服務品質低劣所帶來的相關成本。
評估成本
評估、測量、審計和測試特定項目的產品、可交付成果或服務所帶來的相關成本。
失敗成本(內部/外部)
因產品、可交付成果或服務與相關方需求或期望不一致而導致的相關成本。
最優COQ能夠在預防成本和評估成本之間找到適當的投資平衡點,以規避失敗成本。有關模型表明,最優項目品質成本,指在投資額外的預防/評估成本時,既無益處又不具備成本效益。
決策
多標準決策分析
數據表現
流程圖
流程圖,也稱為流程圖,用來顯示在一個或多個輸入轉換成一個或多個輸出的過程中,所需的步驟順序和可能分支。它透過映射水平價值鏈的過程細節來顯示活動、決策點、分支循環、並行路徑及整體處理順序。
圖中展示了其中一個版本的價值鏈,即SIPOC(供應商、輸入、流程、輸出和客戶)模型。
流程圖可能有助於了解和估算一個流程的品質成本。透過工作流程的邏輯分支及其相對頻率來估算品質成本。這些邏輯分支細分為完成符合要求的輸出而需要進行的一致性工作和非一致性工作。用於展示流程步驟時,流程圖有時又被稱為“流程流程圖”或“流程流向圖”,可協助改善流程並識別可能出現品質缺陷或可以納入品質檢查的地方。
邏輯資料模型
邏輯資料模型把組織資料視覺化,以商業語言加以描述,不依賴任何特定技術。邏輯資料模型可用於識別會出現資料完整性或其他品質問題的地方。
矩陣圖
矩陣圖在行列交叉的位置顯示因素、原因和目標之間的關係強弱。根據可用來比較因素的數量,專案經理可使用不同形狀的矩陣圖,如L型、T型、Y型、X型、C型和屋頂型矩陣。在本過程中,它們有助於識別對專案成功至關重要的品質測量指標。
心智圖
測試與檢查的規劃
在規劃階段,專案經理和專案團隊決定如何測試或檢查產品、可交付成果或服務,以滿足相關方的需求和期望,以及如何滿足產品的績效和可靠性目標。不同行業有不同的測試與檢查,可能包括軟體專案的α測試和β測試、建築專案的強度測試、製造和實地測試的檢查,以及工程的無損傷測試。
會議
輸出
品質管理計劃
品質管理計畫是專案管理計畫的組成部分,描述如何實施適用的政策、程序和指南以實現品質目標。它描述了專案管理團隊為實現一系列專案品質目標所需的活動和資源。品質管理計劃可以是正式或非正式的,非常詳細或高度概括的,其風格與詳細程度取決於專案的具體需求。應該在專案早期就對品質管理計劃進行評審,以確保決策是基於準確資訊的。這樣做的好處是,更關注專案的價值定位,降低因返工而造成的成本超支金額和進度延誤次數。
品質管理計劃包括(但不限於)的組成部分
專案採用的品質標準
專案的品質目標
品質角色與職責
需要品質審查的專案可交付成果和流程
為專案規劃的品質控制和品質管理活動
專案使用的品質工具
與專案有關的主要程序,例如處理不符合要求的情況、糾正措施繪製程序,以及持續改進程序。
品質測量指標
品質測量指標專用於描述項目或產品屬性,以及控製品質流程將如何驗證符合程度。品質測量指標的例子包括按時完成的任務的百分比、以CPI測量的成本績效、故障率、識別的日缺陷數量、每月總停機時間、每個代碼行的錯誤、客戶滿意度分數,以及測試計劃所涵蓋的需求的百分比(即測試覆蓋度)
專案管理計畫更新
風險管理計劃
範圍基準
專案文件更新
經驗教訓登記冊
需求追蹤矩陣
風險登記冊
相關方登記冊
管理品質
管理品質是把組織的品質政策用於項目,並將品質管理計畫轉化為可執行的品質活動的過程。
本過程的主要作用是,提高實現品質目標的可能性,以及識別無效過程和導致品質低劣的原因。管理品質使用控製品質過程的數據和結果向相關方展示專案的整體品質狀態。
管理品質有時被稱為“品質保證”,但“管理品質”的定義比“品質保證”更廣,因其可用於非專案工作。在專案管理中,品質保證著眼於專案使用的過程,旨在有效地執行專案過程,包括遵守和滿足標準,向相關方保證最終產品可以滿足他們的需求、期望和要求。管理品質包括所有品質保證活動,也與產品設計和流程改進有關。管理品質的工作屬於品質成本架構中的一致性工作。
專案經理和專案團隊可以透過組織的品質保證部門或其他組織職能執行某些管理品質活動,例如故障分析、實驗設計和品質改進。品質保證部門在品質工具和技術的使用方面通常擁有跨組織經驗,是良好的專案資源。
管理品質被認為是所有人的共同職責,包括專案經理、專案團隊、專案發起人、執行組織的管理階層,甚至是客戶。所有人在管理專案品質方面都扮演一定的角色,儘管這些角色的人數和工作量不同。參與品質管理工作的程度取決於所在產業和專案管理風格。在敏捷專案中,整個專案期間的品質管理由所有團隊成員執行;但在傳統專案中,品質管理通常是特定團隊成員的職責。
ITTO
輸入
專案管理計劃
品質管理計劃
專案文件
經驗教訓登記冊
專案早期與品質管理相關的經驗教訓,可以運用到專案後期階段,以提高品質管理的效率與效果。
品質控制測量結果
品質控制測量結果用於分析和評估專案過程和可交付成果的品質是否符合執行組織的標準或特定要求。品質控制測量結果也有助於分析這些測量結果的產生過程,以確定實際測量結果的正確程度。
品質測量指標
核實品質測量指標是控製品質過程的一個環節。管理品質過程依據這些品質測量指標設定專案的測試場景和可交付成果,用作改善措施的依據。
風險報告
管理品質過程使用風險報告來識別整體專案風險的來源以及整體風險敞口的最重要的驅動因素,這些因素能夠影響專案的品質目標。
組織過程資產
工具與技術
數據收集
核對單
適用於本流程的資料收集技術包括(但不限於)核對單。核對單是一種結構化工具,通常列出特定組成部分,用來核實所要求的一系列步驟是否已執行或檢查需求清單是否已滿足。基於專案需求和實踐,核對單可簡可繁。許多組織都有標準化的核對單,用來規範地執行經常性任務。在某些應用領域,核對單也可從專業協會或商業性服務機構取得。品質核對單應該涵蓋在範圍基準中定義的驗收標準。
數據分析
備選方案分析
該技術用於評估已識別的可選方案,以選擇那些最合適的品質方案或方法。
文件分析
分析專案控制過程所產出的不同文件,如品質報告、測試報告、績效報告和偏差分析,可以重點指出可能超出控制範圍之外並阻礙專案團隊滿足特定要求或相關方期望的過程。
過程分析
過程分析可以識別流程改善機會,同時檢查在製程期間遇到的問題、限制因素,以及非增值活動。
根本原因分析
根本原因分析(RCA)是確定造成偏差、缺陷或風險的根本原因的一種分析技術。一項根本原因可能引起多項偏差、缺陷或風險。根本原因分析還可以作為一項技術,用於識別問題的根本原因並解決問題。消除所有根本原因可以杜絕問題再次發生。
決策
多標準決策分析
數據表現
親和圖
親和圖可以將潛在缺陷成因分類,顯示最應關注的領域。
因果圖
因果圖,又稱「魚骨圖」、「why-why分析圖」和「石川圖」將問題陳述的原因分解為離散的分支,有助於識別問題的主要原因或根本原因。
流程圖
流程圖展示了引發缺陷的一系列步驟。
直方圖
直方圖是一種展示數字資料的長條圖,可以顯示每個可交付成果的缺陷數量、缺陷成因的排列、各個流程的不合規次數,或其他項目或產品缺陷的表現。
矩陣圖
矩陣圖在行列交叉的位置顯示因素、原因和目標之間的關係強弱。
散點圖
散佈圖是種展示兩個變數之間的關係的圖形,它能夠展示兩支軸的關係,一個軸表示過程、環境或活動的任何要素,另一個軸表示品質缺陷。
帕累托圖
審計
審計是用來確定專案活動是否遵循了組織和專案的政策、過程與程序的一種結構化且獨立的過程。品質審計通常由專案外部的團隊進行,如組織內部審計部門、專案管理辦公室(PMO)或組織外部的審計師。
品質審計目標可能包括(但不限於)
識別全部正在實施的良好及最佳實踐
辨識所有違規做法、差距及不足
分享所在組織和/或行業中類似專案的良好實踐
積極、主動地提供協助,以改善流程的執行,從而幫助團隊提高生產效率;
強調每次審計都應對組織經驗教訓知識庫的累積做出貢獻。
採取後續措施糾正問題,可以降低品質成本,並提高發起人或客戶對專案產品的接受度。品質審計可事先安排,也可隨機進行;可由內部或外部審計師進行。
品質審計還可確認已批准的變更請求(包括更新、糾正措施、缺陷補救和預防措施)的實施。
面向X的設計
面向X的設計(DfX)是產品設計期間可採用的一系列技術指南,旨在優化設計的特定方面,可以控製或提高產品最終特性。 DfX中的「X」可以是產品開發的不同方面,例如可靠性、調配、組裝、製造、成本、服務、可用性、安全性和品質。使用DfX可以降低成本、改善品質、提高績效和客戶滿意度。
問題解決
問題解決發現解決問題或應對挑戰的解決方案。它包括收集其他資訊、具有批判性思考的、創造性的、量化的和/或邏輯性的解決方法。有效和系統地解決問題是品質保證和品質改進的基本要素。問題可能在控製品質過程或品質審計中發現,也可能與過程或可交付成果有關。使用結構化的問題解決方法有助於消除問題和製定長久有效的解決方案。
問題解決方法通常包括以下要素
定義問題
識別根本原因
產生可能的解決方案
選擇最佳解決方案
執行解決方案
驗證解決方案的有效性
品質改進方法
品質改善的發展,可基於品質控制過程的發現與建議、品質審計的發現,或管理品質流程的問題解決。計劃一實施一檢查一行動和六西格瑪是最常用於分析和評估改進機會的兩種品質改進工具。
輸出
品質報告
品質報告可能是圖形、數據或定性文件,其中包含的資訊可協助其他流程和部門採取糾正措施,以實現專案品質期望。品質報告的資訊可以包含團隊回報的品質管理問題,針對製程、專案和產品的改善建議,糾正措施建議(包括重工、缺陷/漏洞補救、100%檢查等),以及在控製品質過程中發現的情況的概述。
測試與評估文件
可基於產業需求和組織範本建立測試與評估文件。它們是控製品質過程的輸入,用於評估品質目標的實現情況。這些文件可能包括專門的核對單和詳盡的需求追蹤矩陣。
變更請求
專案管理計畫更新
品質管理計劃
範圍基準
進度基準
成本基準
專案文件更新
問題日誌
經驗教訓登記冊
風險登記冊
控製品質
控製品質是為了評估績效,確保專案輸出完整、正確且滿足客戶期望,而監督和記錄品質管理活動執行結果的過程。
此流程的主要作用是,核實專案可交付成果和工作已達到主要相關方的品質要求,可供最終驗收。控製品質過程確定專案輸出是否達到預期目的,這些輸出需要滿足所有適用標準、要求、法規和規範。
控製品質過程的目的是在使用者驗收和最終交付之前測量產品或服務的完整性、合規性和適用性。本流程透過測量所有步驟、屬性和變量,來核實與規劃階段所描述規範的一致性和合規性。
在整個專案期間應執行品質控制,並用可靠的數據來證明專案已達到發起人和/或客戶的驗收標準。
控製品質的努力程度和執行程度可能會因所在行業和專案管理風格而有所不同。例如,相較於其他行業,製藥、醫療、運輸和核能產業可能擁有更嚴格的品質控管程序,為滿足標準付出的工作也會更廣;在敏捷專案中,控製品質活動可能由所有團隊成員在整個在專案生命週期中執行,而在瀑布式專案中,控製品質活動由特定團隊成員在特定時間點或專案或階段快結束時執行。
補充:變更線
變更請求
預防措施
糾正措施
缺陷補救
讓現實符合計劃
更新
讓計劃符合現實
批准的變更請求
實施整體變更控管流程
實施變更請求
指導與管理專案工作
控制採購
檢查變更請求實施情況
控製品質
管理品質
監控專案工作
ITTO
輸入
專案管理計劃
品質管理計劃
品質管理計劃
經驗教訓登記冊
品質測量指標
品質測量指標專用於描述項目或產品屬性,以及控製品質流程將如何驗證符合程度。
測試與評估文件
測試與評估文件用於評估品質目標的實現程度。
批准的變更請求
在實施整體變更控制過程中,透過更新變更日誌,顯示哪些變更已經被批准,哪些變更沒有被批准。核准的變更請求可包括各種修正,如缺陷補救、修訂的工作方法和修訂的進度計畫。完成局部變更時,如果步驟不完整或不正確,可能會導致不一致和延遲。批准的變更請求的實施需要核實,並需要確認完整性、正確性,以及是否重新測試。
可交付成果
可交付成果指的是某一流程、階段或專案完成時,必須產出的任何獨特且可核實的產品、成果或服務能力。作為指導與管理專案工作流程的輸出的可交付成果將被檢查,並與專案範圍說明書定義的驗收標準進行比較。
工作績效數據
事業環境因素
組織過程資產
工具與技術
數據收集
核對單
核對單有助於以結構化方式管理控製品質活動。
核查表
核查表,又稱計數表,用於合理排列各種事項,以便有效地收集關於潛在品質問題的有用資料。在進行檢查以識別缺陷時,用核查表收集屬性資料就特別方便,例如關於缺陷數量或後果的資料。
統計抽樣
統計抽樣是指從目標總體中選取部分樣本進行檢查(如從75張工程圖中隨機抽取10張)。樣本用於測量控制和確認品質。抽樣的頻率和規模應在規劃品質管理過程中決定。
問卷調查
問卷調查。問卷調查可用於在部署產品或服務之後收集關於客戶滿意度的資料。在問卷調查中識別的缺陷相關成本可被視為COQ模型中的外部失敗成本,對組織帶來的影響將超出成本本身。
數據分析
績效審查
績效審查針對實際結果,測量、比較和分析規劃品質管理過程中定義的品質測量指標。
根本原因分析
根本原因分析用於識別缺陷成因。
檢查
檢查是指檢驗工作產品,以確定是否符合書面標準。檢查的結果通常包括相關的測量數據,可在任何層面上進行。可以檢查單一活動的成果,也可以檢查專案的最終產品。檢查也可稱為審查、同儕審查、審計或巡檢等,而在某些應用領域,這些術語的含義比較狹窄和具體。檢查也可用於確認缺陷補救。
測試/產品評估
測試是一種有組織的、結構化的調查,旨在根據項目目需求提供有關被測產品或服務品質的客觀資訊。測試的目的是找出產品或服務中存在的錯誤、缺陷、漏洞或其他不合規問題。用於評估各項需求的測試的類型、數量和程度是專案品質計畫的一部分,取決於專案的性質、時間、預算或其他限制因素。測試可以貫穿整個項目,可以隨著專案的不同組成部分變得可用時進行,也可以在專案結束(即交付最終可交付成果)時進行。早期測試有助於識別不合規問題,幫助減少修補不合規組件的成本。
數據表現
因果圖
因果圖用於識別品質缺陷和錯誤可能造成的結果。
控製圖
控製圖用於確定一個製程是否穩定,或是否具有可預頁測的績效。規格上限和下限是根據要求制定的,反映了可允許的最大值和最小值。上下控制界限不同於規格界限。控制界限根據標準的統計原則,透過標準的統計計算確定,代表一個穩定過程的自然波動範圍。專案經理和相關方可基於計算出的控制界限,識別須採取糾正措施的檢查點,以預防不在控制界限內的績效。控製圖可用於監測各種類型的輸出變數。雖然控製圖最常用來追蹤大量生產中的重複性活動,但也可用於監控成本與進度偏差、產量、範圍變更頻率或其他管理工作成果,以便協助確定專案管理流程是否受控。
直方圖
直方圖可依來源或組成部分展示缺陷數量
散點圖
散佈圖可在一軸上展示計畫的績效,在另一軸上展示實際績效。
會議
輸出
品質控制測量結果
控製品質的測量結果是對品質控制活動的結果的書面記錄,應以品質管理計畫所確定的格式加以記錄。
核實的可交付成果
控製品質過程的一個目的是確定可交付成果的正確性。進行控製品質過程的結果是核實的可交付成果,後者又是確認範圍過程的一項輸入,以便正式驗收。如果存在任何與可交付成果相關的變更要求或改進事項,可能會執行變更、進行檢查並重新核實。
工作績效訊息
工作績效資訊包含有關專案需求實現的資訊、拒絕的原因、要求的返工、糾正措施建議、核實的可交付成果清單、品質測量指標的狀態,以及流程調整需求。
變更請求
專案管理計畫更新
品質管理計劃
專案文件更新
問題日誌
經驗教訓登記冊
風險登記冊
測試與評估文件
專案資源管理
概述說明
規劃資源管理
規劃資源管理是定義如何估算、取得、管理和利用團隊以及實體資源的過程。
本過程的主要作用是,根據專案類型和複雜程度來確定適用於專案資源的管理方法和管理程度。
資源規劃用於確定和識別一種方法,以確保專案的成功完成有足夠的可用資源。專案資源可能包括團隊成員、用品、材料、設備、服務和設施。有效的資源規劃需要考慮稀缺資源的可用性和競爭,並編制相應的計劃。
這些資源可以從組織內部資產取得,或透過採購流程從組織外部取得。其他專案可能在同一時間和地點競爭專案所需的相同資源,從而對專案成本、進度、風險、品質和其他專案領域造成顯著影響。
ITTO
輸入
專案章程
專案章程提供專案的高層描述和要求,此外還包括可能影響專案資源管理的關鍵相關方名單、里程碑概況,以及預先批准的財務資源。
專案管理計劃
品質管理計劃
範圍基準
專案文件
專案進度計劃
專案進度計劃提供了所需資源的時間軸。
需求文件
需求文件指出了專案所需的資源的類型和數量,並可能影響管理資源的方式。
風險登記冊
風險登記冊包含可能影響資源規劃的各種威脅和機會的資訊。
相關方登記冊
相關方登記冊有助於識別對專案所需資源有特別興趣或影響的那些相關方,以及會影響資源使用偏好的相關方。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據表現
層級型
與WBS交叉,確認部門的全部專案職責。
責任分配矩陣
顯示工作包或活動與專案團隊成員之間的關係。
責任分配矩陣展示專案資源在各個工作包中的任務分配。矩陣型圖表的一個例子是職責分配矩陣(RAM),它顯示了分配給每個工作包的專案資源,用於說明工作包或活動與專案團隊成員之間的關係。在大型專案中,可以製定多個層次的RAM。例如,高階的RAM可定義專案團隊、小組或部門負責WBS中的哪一部分工作,而低層次的RAM則可在各小組內為具體活動分配角色、職責和職權。矩陣圖能反映與每個人相關的所有活動,以及與每項活動相關的所有人員,它也可確保任何一項任務都只有一個人負責,從而避免職權不清。 RAM的一個例子是RACI(執行、負責、諮詢和知情)矩陣,如圖9-4所示。圖中最左邊的一列表示有待完成的工作(活動)。分配合每項工作的資源可以是個人或小組,專案經理也可依專案需要,選擇「領導」或「資源」等適用詞彙,來分配專案責任。如果團隊是由內部和外部人員組成,RACI矩陣對明確劃分角色和職責特別有用。
文字型
提供諸如職責、職權、能力和資格等方面的資訊。
組織理論
會議
輸出
資源管理計劃
作為專案管理計劃的一部分,資源管理計劃提供了關於如何分類、分配、管理和釋放專案資源的指南。資源管理計畫可依專案的具體情況分為團隊管理計畫和實體資源管理計畫。
資源管理計劃可能包括(但不限於)
識別資源
用於識別和量化專案所需的團隊和實體資源的方法。
獲取資源
關於如何取得專案所需的團隊和實體資源的指南。
角色與職責
角色
在專案中,某人承擔的職務或分配給某人的職務,如土木工程師、商業分析師和測試協調員。
職權
使用專案資源、做出決策、簽署批准、驗收可交付成果並影響他人進行專案工作的權力。例如,下列事項都需要由具有明確職權的人來做決策:選擇活動的實施方法,品質驗收標準,以及如何應對項目偏差等。當個人的職權程度與j職責相符時,團隊成員就能最好地開展工作。
職責
為完成專案活動,專案團隊成員必須履行的職責和工作。
能力
為完成專案活動,專案團隊成員需具備的技能和才幹。如果專案團隊成員不具備所需的能力,就無法有效地履行職責。一旦發現成員的能力與職責不匹配,就應主動採取措施,例如安排訓練、招募新成員、調整進度計畫或工作範圍。
專案組織圖
專案組織圖以圖形方式顯示專案團隊成員及其報告關係。基於專案的需要,專案組織圖可以是正式或非正式的,非常詳細或高度概括的。例如,一個3000人的災害應變團隊的專案組織圖,比僅有20人的內部專案的組織圖詳盡得多。
專案團隊資源管理
關於如何定義、配備、管理和最終遣散專案團隊資源的指南。
訓練
針對計畫成員的培訓策略。
團隊建立
建設專案團隊的方法。
資源控制
依據需要確保實體資源充足可用、並為專案需求優化實體資源採購,而採用的方法。包括有關整個專案生命週期期間的庫存、設備和用品管理的資訊。
認可計劃
將給予團隊成員哪些認可和獎勵,以及何時給予。
團隊章程
團隊章程是為團隊創建團隊價值觀、共識和工作指南的文件。
團隊章程可能包括(但不限於):
團隊價值觀
溝通指南
決策標準和過程
衝突處理過程
會議指南
團隊共識
團隊章程對專案團隊成員的可接受行為確定了明確的期望。儘早認可並遵守明確的規則,有助於減少誤解,提高生產力;討論諸如行為規範、溝通、決策、會議禮儀等領域,團隊成員可以了解彼此重要的價值觀。由團隊制定或參與制定的團隊章程可發揮最佳效果。所有專案團隊成員都分擔責任,確保遵守團隊章程中規定的規則。可定期檢討和更新團隊章程,確保團隊始終了解團隊基本規則,並引導新成員融入團隊。
專案文件更新
假設日誌
風險登記冊
估算活動資源
估算活動資源是估算執行專案所需的團隊資源,以及材料、設備和用品的類型和數量的過程。
本過程的主要作用是,明確完成專案所需的資源種類、數量和特性。
ITTO
輸入
專案管理計劃
資源管理計劃
範圍基準
專案文件
活動屬性
活動屬性為估算活動清單中每項活動所需的團隊和實體資源提供了主要資料來源,這些屬性的例子包括資源需求、強制日期、活動地點、假設條件和限制因素。
活動清單
活動清單識別了需要資源的活動。
假設日誌
假設日誌可能包含有關生產力因素、可用性、成本估算以及工作方法的信息,這些因素會影響團隊和實體資源的性質和數量。
成本估算
資源成本從數量和技能水平方面會影響資源選擇。
資源日曆
資源日曆識別了每種特定資源可用時的工作日、班次、正常營業的上下班時間、週末和公共假期。在規劃活動期間,潛在的可用資源資訊(如團隊資源、設備和材料)用於估算資源可用性。資源日曆還規定了在專案期間確定的團隊和實體資源何時可用、可用多久。這些資訊可以在活動或專案層面建立,這考慮了諸如資源經驗和/或技能水平以及不同地理位置等屬性。
風險登記冊
風險登記冊描述了可能影響資源選擇和可用性的各個風險。
事業環境因素
組織過程資產
工具與技術
專家判斷
由下而上估算
團隊和實物資源在活動層級上估算,然後匯總成工作包、控制帳戶和整體專案層級上的估算。
類比估算
類比估算將以往類似專案的資源相關資訊作為估算未來專案的基礎。這是一種快速估算方法,適用於專案經理只能識別WBS的幾個高階層級的情況。
參數估算
參數估算是基於歷史資料和項目參數,使用某種演算法或歷史資料與其他變數之間的統計關係,來計算活動所需的資源數量。例如,如果一項活動需要4000個小時的編碼時間,而且需要在1年之內完成,則需要兩個人來編碼(每人每年付出2000小時)參數估算的準確性取決於參數模型的成熟度和基礎數據的可靠性。
數據分析
備選方案分析
適用於本流程的資料分析技術包括(但不限於)備選方案分析。備選方案分析是一種對已識別的可選方案進行評估的技術,用來決定選擇哪種方案或使用何種方法來執行專案工作。許多活動有多個備選的實施方案,例如使用能力或技能水平不同的資源、不同規模或類型的機器、不同的工具(手工或自動),以及關於資源自製、租賃或購買的決策。備選方案分析有助於提供在定義的限制因素範圍內執行專案活動的最佳方案。
專案管理資訊系統
專案管理資訊系統可以包括資源管理軟體,這些軟體有助於規劃、組織與管理資源庫,以及編制資源估算。根據軟體的複雜程度,可以確定資源分解結構、資源可用性、資源費率和各種資源日曆,有助於優化資源使用。
會議
專案經理可以和職能經理一起舉行規劃會議,以估算每項活動所需的資源、支援型活動(LoE)、團隊資源的技能水平,以及所需材料的數量。與會者可能包括專案經理、專案發起人、選定的專案團隊成員、選定的相關方,以及其他必要人員。
輸出
資源需求
資源需求識別了各個工作包或工作包中每個活動所需的資源類型型和數量,可以匯總這些需求,以估算每個工作包、每個WBS分支以及整個專案所需的資源。資源需求描述的細節數量與具體程度因應用領域而異,而資源需求文件也可包含為確定所用資源的類型、可用性和所需數量所做的假設。
估算依據
資源估算所需的支援資訊的數量和種類,因應用領域而異。但不論其詳細程度如何,支持性文件都應該清楚完整地說明資源估算是如何得出的。
資源估算的支援資訊可包括
估算方法
用於估算的資源,如以往類似項目的信息
與估算有關的假設條件
已知的限制因素
估算範圍
估算的信心水準
有關影響估算的已識別風險的文件
資源分解結構
資源分解結構是資源依類別和類型的層級展現。資源類別包括(但不限於)人力、材料、設備和用品,資源類型則包括技能等級、要求證書、等級等級或適用於專案的其他類型。在規劃資源管理過程中,資源分解結構用於指導專案的分類活動。在這過程中,資源分解結構是一份完整的文件,用於獲取和監督資源。
專案文件更新
活動屬性
假設日誌
經驗教訓登記冊
獲取資源
取得資源是取得專案所需的團隊成員、設施、設備、材料、用品和其他資源的過程。這個過程的主要作用是,概述和指導資源的選擇,並將其分配給相應的活動。
專案所需資源可能來自專案執行組織的內部或外部。內部資源由職能經理或資源經理負責取得(分配),而外部資源則是透過採購流程取得。
因為集體勞資協議、分包商人員使用、矩陣型專案環境、內部和外部報告關係或其他原因,專案管理團隊可能或可能不對資源選擇有直接控制權。
重要的是,在取得專案資源過程中應注意下列事項:
專案經理或專案團隊應該進行有效談判,並影響那些能為專案提供所需團隊和實體資源的人員。
當您無法獲得專案所需的資源時,可能會影響專案進度、預算、客戶滿意度、品質和風險;資源或人員能力不足會降低專案成功的機率,最壞的情況可能導致專案取消。
如因限制因素(如經濟因素或其他專案對資源的佔用)而無法獲得所需團隊資源,專案經理或專案團隊可能必須使用也許能力和成本不同的替代資源。在不違反法律、規章、強制規定或其他具體標準的前提下可以使用替代資源。
ITTO
輸入
專案管理計劃
資源管理計劃
採購管理計劃
成本基準
專案文件
專案進度計劃
專案進度計畫展示了各項活動及其開始和結束日期,有助於確定需要提供和取得資源的時間。
資源日曆
資源日曆記錄了每個專案資源在專案中的可用時間段。編制出可靠的進度計劃,應依據對各個資源的可用性和時間限制(包括時區、工作時間、休假時間、當地節假日、維護計劃和在其他項目的工作時間)的良好了解。資源日曆需要在整個專案過程中漸進明細和更新。資源日曆是本過程的輸出,在重複此過程時隨時可用。
資源需求
資源需求識別了需要取得的資源。
相關方登記冊
相關方登記冊可能會發現相關方對專案特定資源的需求或期望,在取得資源過程中應加以考慮。
事業環境因素
組織過程資產
工具與技術
決策
多標準決策分析
適用於取得資源流程的決策技術包括(但不限於)多標準決策分析選擇標準常用於選擇專案的實體資源或專案團隊。使用多標準決策分析工具來制定標準,用於對潛在資源進行評級或評分(例如,在內部和外部團隊資源之間進行選擇)。根據標準的相對重要性對標準進行加權,加權值可能會因資源類型的不同而改變。
可使用的選擇標準包括:
可用性
確認資源能否在專案所需時段內為專案所用。
成本
確認增加資源的成本是否在規定的預算內。
能力
確認團隊成員是否提供了專案所需的能力。
有些選擇標準對團隊資源來說是獨特的,包括:
經驗
確認團隊成員具備專案成功所需的相關經驗。
知識
團隊成員是否掌握關於客戶、執行過的類似專案和專案環境細節的相關知識。
技能
確認團隊成員擁有使用專案工具的相關技能。
態度
團隊成員能否與他人協同工作,以形成有凝聚力的團隊。
國際因素
團隊成員的位置、時區和溝通能力。
人際關係與團隊技能
談判
許多專案需要針對所需資源進行談判,專案管理團隊需要與下列各方談判:
職能經理
確保專案在要求的時限內獲得最佳資源,直到完成職責為止。
執行組織中的其他專案管理團隊
合理分配稀缺或特殊資源。
外部組織和供應商
提供合適的、稀缺的、特殊的、合格的、經認證的或其他特殊的團隊或實體資源。特別需要注意與外部談判有關的政策、慣例、流程、指南、法律及其他標準。
在資源分配談判中,專案管理團隊影響他人的能力很重要,就像組織中的政治能力一樣重要。例如,說服職能經理,讓他/她看到專案有良好的前景,會影響他/她把最佳資源分配給這個專案而不是競爭專案。
預分派
預分派指事先確定專案的實體或團隊資源,可在下列情況下發生:在競標過程中承諾分派特定人員進行專案工作;專案取決於特定人員的專有技能;在完成資源管理計劃的前期工作之前,制定專案章程過程或其他過程已經指定了某些團隊成員的工作分派。
虛擬團隊
虛擬團隊的使用為招募專案團隊成員提供了新的可能性。虛擬團隊可定義為具有共同目標、在完成角色任務的過程中很少或沒有時間面對面工作的一群人現代溝通技術(如電子郵件、電話會議、社交媒體、網絡會議和視訊會議等)使虛擬團隊成為可行行。
虛擬團隊模式使人們有可能
在組織內部地處不同地理位置的員工之間組成團隊
為專案團隊增加特殊技能,即使相應的專家不在同一地理區域
將在家工作的員工納入團隊
在工作班次、工作小時或工作日不同的員工之間組成團隊
將行動不便者或殘疾人士納入團隊
執行那些原本會因差旅費用過高而被擱置或取消的項目
節省員工所需的辦公室和所有實體設備的開支。
在虛擬團隊的環境中,溝通規劃變得日益重要。可能需要花更多時間,來設定明確的期望、促進溝通、制定衝突解決方法、召集人員參與決策、理解文化差異,以及共享成功喜悅。
輸出
物質資源分配單
實體資源分配單記錄了專案將使用的材料、設備、用品、地點點和其他實體資源。
專案團隊派遣工單
專案團隊派工單記錄了團隊成員及其在專案中的角色和職責可包括專案團隊名錄,還需要把人員姓名插入專案管理計畫的其他部分,如專案組織圖和進度計計畫。
資源日曆
資源日曆識別了每種特定資源可用時的工作日、班次、正常營業的上下班時間、週末和公共假期。在規劃活動期間,潛在的可用資源資訊(如團隊資源、設備和材料)用於估算資源可用性。資源日曆規定了在專案期間確定的團隊和實體資源何時可用、可用多久。這些資訊可以在活動或專案層面建立,這考慮了諸如資源經驗和/或技能水平以及不同地理位置等屬性。
變更請求
專案管理計畫更新
資源管理計劃
成本基準
專案文件更新
經驗教訓登記冊
專案進度計劃
資源分解結構
資源需求
風險登記冊
相關方登記冊
事業環境因素更新
組織過程資產更新
建設團隊
建立團隊是提高工作能力,促進團隊成員互動,改善團隊整體氛圍,以提高專案績效的過程。
這個過程的主要作用是,改善團隊協作、增強人際關係技能、激勵員工、減少摩擦以及提升整體專案績效。
專案經理在全球化環境和富有文化多樣性的專案中工作:團隊成員經常來自不同的行業,講不同的語言,有時甚至會在工作中使用一種特別的「團隊語言」或文化規範,而不是使用他們的母語;專案管理團隊應該利用文化差異,在整個專案生命週期中致力於發展和維護專案團隊,並促進在相互信任的氛圍中充分協作;透過建立專案團隊,可以改善人際技巧、技術能力、團隊環境及專案績效。在整個專案生命週期中,團隊成員之間都要保持明確、及時、有效(包括效果和效率兩個面向)的溝通。
建設專案團隊的目標包括(但不限於):
提升團隊成員的知識和技能,以提高他們完成專案可交付成果的能力,並降低成本、縮短工期和提高品質;
提升團隊成員之間的信任和認同感,以提高士氣、減少衝突和增進團隊協作;
創造一個富有生氣、凝聚力和協作性的團隊文化,從而:(1)提高個人和團隊生產力,振奮團隊精神,促進團隊合作;(2)促進團隊成員之間的交叉培訓和輔導,以分享知識和經驗;
提升團隊參與決策的能力,使他們承擔起對解決方案的責任,進而提高團隊的生產效率,獲得
更有效和有效率的成果。
「塔克曼」團隊發展5階段
有一個關於團隊發展的模型叫做塔克曼階梯理論,其中包括團隊建立通常要經過的五個階段。儘管這些階段通常按順序進行,然而,團隊停滯在某個階段或退回到較早階段的情況也並非罕見;而如果團隊成員曾經共事過,專案團隊建立也可跳過某個階段。
形成階段
在這個階段,團隊成員彼此認識,並了解專案狀況及他們在專案中的正式角色與職責。在這一階段,團隊成員傾向於相互獨立,不一定是開誠佈公。
震盪階段
在這個階段,團隊開始從事專案工作、制定技術決策和討論專案管理方法。如果團隊成員無法以合作和開放的態度對待不同觀點和意見,團隊環境可能變得事與願違。
規範階段
在規範階段,團隊成員開始協同工作,並調整各自的工作習慣和行為來支持團隊,團隊成員會學習相互信任。
成熟階段
進入這一階段後,團隊就像一個組織有序的單位一樣工作,團隊成員之間相互依靠,並平穩且有效率地解決問題。
解散階段
在解散階段,團隊完成所有工作,團隊成員離開專案。通常在專案可交付成果完成之後,或者,在結束專案或階段過程中,釋放人員,解散團隊。
ITTO
輸入
專案管理計劃
資源管理計劃
專案管理計劃組件包括(但不限於)資源管理計劃。資源管理計劃為如何透過團隊績效評估和其他形式的團隊管理活動,為專案團隊成員提供獎勵、提出回饋、增加培訓或採取懲罰措施提供了指南。資源管理計畫可能包括團隊績效評估標準。
專案文件
經驗教訓登記冊
專案早期與團隊建立相關的經驗教訓可以運用到專案後期階段,以提高團隊績效。
專案進度計劃
專案進度計畫定義瞭如何以及何時為專案團隊提供培訓,以培養不同階段所需的能力,並根據專案執行期間的任何差異(如有)識別所需的團隊建立策略。
專案團隊派遣工單
專案團隊派工單辨識了團隊成員的角色與職責。
資源日曆
資源日曆定義了專案團隊成員何時能參與團隊建立活動,有助於說明團隊在整個專案期間的可用性。
團隊章程
團隊章程包含團隊工作指南。團隊價值觀和工作指南為描述團隊的合作方式提供了架構。
事業環境因素
組織過程資產
工具與技術
集中工作
集中辦公是指把許多或全部最活躍的專案團隊成員安排在同一個實體地點工作,以增強團隊工作能力。集中辦公既可以是臨時的(如僅在專案特別重要的時期),也可以貫穿整個專案。實施集中辦公策略,可藉助團隊會議室、張貼進度計畫的場所,以及其他能增進溝通和集體感的設施。
虛擬團隊
虛擬團隊的使用能帶來許多好處,例如,使用更多技術熟練的資源、降低成本、減少出差及搬遷費用,以及拉近團隊成員與供應商、客戶或其他重要相關方的距離。虛擬團隊可以利用技術來創造線上團隊環境,以供團隊儲存文件、使用線上對話來討論問題,以及保存團隊日曆。
溝通技術
在解決集中辦公或虛擬團隊的團隊建立問題方面,溝通技術至關重要。它有助於為集中辦公團隊創造一個融洽的環境,促進虛擬團隊(尤其是團隊成員分散在不同時區的團隊)更好地相互理解。
可採用的溝通技術包括:
共享入口網站
共享資訊庫(例如網站、協作軟體或內部網路)對虛擬專案團隊很有幫助。
視訊會議
視訊會議是一種可有效與虛擬團隊溝通重要技術。
音訊會議
音訊會議有助於與虛擬團隊建立融洽的相互信任的關係。
電子郵件/聊天軟體
使用電子郵件和聊天軟體定期溝通也是一種有效的方式。
人際關係與團隊技能
衝突管理
專案經理應及時以建設性方式解決衝突,從而創造高績效團隊。
影響力
本過程的影響力技能收集相關的關鍵訊息,在維護相互信任的關係時,來解決重要問題並達成一致意見。
激勵
激勵為某人採取行動提供了理由。提高團隊參與決策的能力並鼓勵他們獨立工作。
談判
團隊成員之間的談判旨在就專案需求達成共識。談判有助於團隊成員之間建立融洽的相互信任的關係。
團隊建立
團隊建立是透過舉辦各種活動,強化團隊的社交關係,打造積極合作的工作環境。團隊建立活動既可以是狀態審查會上的五分鐘議程,也可以是為改善人際關係而設計的、在非工作場所專門舉辦的專業提升活動。團隊建立活動旨在幫助各團隊成員更有效地協同工作。如果團隊成員的工作地點相距甚遠,無法進行面對面接觸,就特別需要有效的團隊建立策略。非正式的溝通和活動有助於建立信任和良好的工作關係。團隊建立在專案前期必不可少,但它更是個持續的過程。專案環境的變化不可避免,要有效應對這些變化,就需要持續不斷地進行團隊建立。專案經理應該持續監督團隊機能和績效,確定是否需要採取措施來預防或糾正各種團隊問題。
認可與獎勵
在建立專案團隊過程中,需要對成員的優良行為給予認可與獎勵。最初的獎勵計畫是在規劃資源管理過程中編製的,只有能滿足被獎勵者的某個重要需求的獎勵,才是有效的獎勵。在管理專案團隊過程中,可以正式或非正式的方式做出獎勵決定,但在決定認可與獎勵時,應考慮文化差異。
當人們感受到自己在組織中的價值,並且可以透過獲得獎勵來體現這種價值,他們就會受到激勵。通常,金錢是獎勵制度中的有形獎勵,然而也存在著各種同樣有效、甚至更有效的無形獎勵。大多數專案團隊成員會因為得到成長機會、獲得成就感、讚賞以及用專業技能迎接新挑戰,而受到激勵。專案經理應該在整個專案生命週期中盡可能地給予表彰,而不是等到專案完成時。
訓練
培訓包括旨在提升專案團隊成員能力的完整活動,可以是正式或非正式的,方式包括課堂培訓、線上培訓、電腦輔助培訓、在職培訓(由其他專案團隊成員提供)、輔導和訓練。如果專案團隊成員缺乏必要的管理或技術技能,可以把這種技能的培養當作專案工作的一部分。專案經理應該按資源管理計劃中的安排來實施預定的培訓,也應該根據管理專案團隊過程中的觀察、交談和專案績效評估的結果,來開展必要的計劃外培訓,培訓成本通常應該包括在項目預算中,或如果增加的技能有利於未來的項目,則由執行組織承擔。培訓可以由內部或外部培訓師來執行。
個人和團隊評估
個人和團隊評估工具能讓專案經理和專案團隊洞察成員的優點和缺點。這些工具可協助專案經理評估團隊成員的偏好和願望、團隊成員如何處理和整理資訊、如何制定決策,以及團隊成員如何與他人打交道。有各種可用的工具,如態度調查、專案評估、結構化訪談、能力測試及焦點小組。這些工具有助於增進團隊成員間的理解、信任、承諾和溝通,在整個專案期間持續提升團隊成效。
會議
輸出
團隊績效評價
隨著專案團隊建立工作(如培訓、團隊建立和集中辦公等)的開展,專案管理團隊應該對專案團隊的有效性進行正式或非正式的評估。有效的團隊建立策略和活動可以提高團隊績效,從而提高實現專案目標的可能性。
評估團隊有效性的指標可包括
個人技能的改進,從而使成員更有效地完成工作任務;
團隊能力的改進,從而使團隊成員更好地開展工作;
團隊成員離職率的降低;
團隊凝聚力的加強,從而使團隊成員公開分享資訊和經驗,並互相幫助來提升專案績效。
透過對團隊整體績效的評價,專案管理團隊能夠辨識出所需的特殊訓練、教練、輔導、協助或改變,以提升團隊績效。專案管理團隊也應該識別出合適或所需的資源,以執行和實現在績效評估過程中提出的改進建議。
變更請求
專案管理計畫更新
資源管理計劃
專案文件更新
經驗教訓登記冊
專案進度計劃
專案團隊派遣工單
資源日曆
團隊章程
事業環境因素更新
作為建設專案團隊過程的結果,需要更新的事業環境因素包括(但不限於)
員工發展計劃的記錄
技能評估
組織過程資產更新
作為建設團隊過程的結果,需要更新的組織過程資產包括(但不限於)
培訓需求
人事評測
管理團隊
管理團隊是追蹤團隊成員工作表現,提供回饋,解決問題並管理團隊變更,以優化專案績效的過程。本過程的主要作用是,影響團隊行為、管理衝突、解決問題。
ITTO
輸入
專案管理計劃
資源管理計劃
專案文件
問題日誌
在管理專案團隊過程中,總是會出現各種問題。此時,可用問題日誌記錄由誰負責在目標日期內解決特定問題,並監督解決情況。
經驗教訓登記冊
專案早期的經驗教訓可以運用到專案後期階段,以提高團隊管理的效率與效果。
專案團隊派遣工單
專案團隊派工單辨識了團隊成員的角色與職責。
團隊章程
團隊章程為團隊應如何決策、舉行會議和解決衝突提供指南。
工作績效報告
工作績效報告是為制定決策、採取行動或引起關注所形成的實物或電子工作績效信息,它包括從進度控制、成本控制、品質控制和範圍確認中得到的結果,有助於專案團隊管理。績效報告和相關預測報告中的信息,有助於確定未來的團隊資源需求,認可與獎勵,以及更新資源管理計劃。
團隊績效評價
專案管理團隊應該持續對專案團隊績效進行正式或非正式的評估。不斷評估專案團隊績效,有助於採取措施解決問題、調整溝通方式、解決衝突和改善團隊互動。
事業環境因素
組織過程資產
工具與技術
人際關係與團隊技能
衝突管理
在專案環境中,衝突不可避免。衝突的來源包括資源稀缺、進度優先排序和個人工作風格差異等。採用團隊基本規則、團隊規範及成熟的專案管理實務(如溝通規劃和角色定義),可以減少衝突的數量。
成功的衝突管理可提高生產力,改善工作關係。同時,如果管理得當,意見分歧有利於提高創造力和改進決策。如果意見分歧成為負面因素,應該首先由專案團隊成員負責解決;如果衝突升級,專案經理應提供協助,促成滿意的解決方案,採用直接和合作的方式,儘早並且通常在私下處理衝突。如果破壞性衝突持續存在,則可使用正式程序,包括採取懲戒措施。
專案經理解決衝突的能力往往決定其管理專案團隊的成敗。不同的專案經理可能採用不同的解決衝突方法。
影響衝突解決方法的因素包括
衝突的重要性與激烈程度
解決衝突的迫切性
涉及衝突的人員的相對權力
維持良好關係的重要性
永久或暫時解決衝突的動機
有五種常用的衝突解決方法,每種技巧都有各自的作用和用途
撤退/迴避
從實際或潛在衝突中退出,將問題推遲到準備充分的時候,或將問題推給其他人員解決。
緩和/包容
強調一致而非差異;為維持和諧與關係而退讓一步,考慮其他方的需要。
妥協/調解
為了暫時或部分解決衝突,尋找能讓各方都在某種程度上滿意的方案,但這種方法有時會導致「雙輸」局面。
強迫/命令
以犧牲其他方為代價,推行某一方的觀點;只提供贏輸方案。通常是利用權力來強行解決緊急問題,這種方法通常會導致「贏輸」局面。
合作/解決問題
綜合考慮不同的觀點和意見,採用合作的態度和開放式對話引導各方達成共識和承諾,這種方法可以帶來雙贏局面。
制定決策
在這種情況下,決策包括談判能力以及影響組織與專案管理團隊的能力,而不是決策工具集所描述的一系列工具。
進行有效決策需要
著眼於所要達到的目標
遵循決策流程
研究環境因素
分析可用資訊
激發團隊創造力
理解風險
情緒智商
情緒智商指辨識、評估及管理個人情緒、他人情緒及團體情緒的能力。專案管理團隊能用情緒智商來了解、評估及控制專案團隊成員的情緒,預測團隊成員的行為,確認團隊成員的關注點及追蹤團隊成員的問題,來達到減輕壓力、加強合作的目的。
影響力
在矩陣環境中,專案經理對團隊成員通常沒有或僅有很小的命令職權,所以他們適時影響相關方的能力,對確保專案成功非常關鍵。
影響力主要體現在下列各方面
說服他人
清晰表達觀點與立場
積極且有效的傾聽
了解並綜合考慮各種觀點
收集相關信息,在維護相互信任的關係下,解決問題並達成一致意見
領導力
成功的專案需要強而有力的領導技能,領導力是領導團隊、激勵團隊做好本質工作的能力。它包括各種不同的技巧、能力和行動。且領導力在專案生命週期中的所有階段都很重要。有多種領導理論,定義了適用於不同情形或團隊的領導風格。領導力對溝通願景及鼓舞專案團隊高效工作十分重要。
專案管理資訊系統
輸出
變更請求
如果管理團隊流程中出現變更要求,或建議措施、糾正措施或預防措施影響了專案管理計畫的任何組成部分或專案文件,專案經理應提交變更請求。並透過實施整體變更控管流程對變更請求進行審查和處理。
例如,人員配備變更,無論是自主選擇還是由不可控事件造成,都會幹擾專案團隊,這種幹擾可能導致進度落後或預算超支。人員配備變更包括轉派人員、外包部分工作,或替換離職人員。
專案管理計畫更新
資源管理計劃
進度基準
成本基準
專案文件更新
問題日誌
經驗教訓登記冊
專案團隊派遣工單
事業環境因素更新
控制資源
控制資源是確保按計劃為專案分配實體資源,以及根據資源使用計劃監督資源實際使用情況並採取必要糾正措施的過程。
本過程的主要作用是,確保所分配的資源適時適地可用於項目,且在不再需要時被釋放。
ITTO
輸入
專案管理計劃
資源管理計劃
專案文件
問題日誌
問題日誌用於識別有關缺乏資源、原材料供應延遲,或低等級原材料等問題。
經驗教訓登記冊
在專案早期所獲得的經驗教訓可以運用到後期階段,以改善實體資源控制。
物質資源分配單
實體資源分配描述了資源的預頁期使用情況以及資源的詳細信息,例如類型、數量、地點以及屬於組織內部資源還是外購資源
專案進度計劃
資源分解結構
資源需求
風險登記冊
工作績效數據
工作績效數據包含有關專案狀態的數據,例如已使使用的資源的數量和類型。
協定
組織過程資產
工具與技術
數據分析
備選方案分析
替代方案分析有助於選擇最佳解決方案以糾正資源使用偏差,可以將加班和增加團隊資源等備選方案與延期交付或階段性交付相比較,以權衡利弊。
成本效益分析
成本效益分析有助於在專案成本出現差異時確定最佳的糾正措施。績效審查。
績效審查
績效審查是測量、比較和分析計劃的資源使用和實際資源使用的不同。分析成本和進度工作績效資訊有助於指出可能影響資源使用的問題。
趨勢分析
在專案進展過程中,專案團隊可能會使用趨勢分析,基於當前績效資訊來確定未來專案階段所需的資源。趨勢分析檢視專案績效隨時間的變化情況,可用於確定績效是在改善還是惡化。
問題解決
人際關係與團隊技能
談判
專案經理可能需要就增加實體資源、變更實體資源或資源相關成本進行談判。
影響力
影響力有助於專案經理及時解決問題並千獲得所需資源。
專案管理資訊系統
專案管理資訊系統(PMIS)可包含資源管理或進度規劃軟體件,可用於監督資源的使用情況,協助確保適當的資源適時適地用於適當的活動。
輸出
工作績效訊息
工作績效資訊包括專案工作進度訊息,此資訊將資源需求和資源分配與專案活動期間的資源使用相比較,從而發現需要處理的資源可用性方面的差異。
變更請求
如果控制資源流程出現變更要求,或建議的糾正措施或預防措施影響了專案管理計畫的任何組成部分或專案文件,專案經理應提交變更請求。並透過實施整體變更控管流程對變更請求進行審查和處理。
專案管理計畫更新
資源管理計劃
進度基準
成本基準
專案文件更新
假設日誌
問題日誌
經驗教訓登記冊
物質資源分配單
資源分解結構
風險登記冊
專案溝通管理
概述說明
溝通是指有意或無意的訊息交換。交換的訊息可以是想法、指示或情緒。
資訊交換的方法包括
書面形式
實物或電子形式。
口頭形式
面對面或遠距形式。
正式或非正式形式(用正式紙本或社交媒體)
手勢動作
語調和臉部表情。
媒體形式
圖片、行動,甚至只是遣詞造句。
遣詞造句
表達一個想法的字詞往往不只一個,各字的意思都會有細微差異。
溝通活動可依多種構面分類,包括(但不限於)
內部
針對專案內部或組織內部的相關方。
外部
針對外部相關方,如客戶、供應商、其他項目、組織、政府,公眾和環保倡議者。
正式
報告、正式會議(定期及臨時)、會議議程和記錄、相關方簡報和演示。
非正式
採用電子郵件、社群媒體、網站,以及非正式臨時討論的一般溝通活動。
層級溝通
相關方或相關方群體相對於專案團隊的位置將會以下列方式影響訊息傳遞的形式和內容
向上溝通
針對高層相關方。
向下溝通
針對承擔專案工作的團隊和其他人員。
橫向溝通
針對專案經理或團隊的同級人員。
官方溝通
年報,呈交監管機構或政府部門的報告。
非官方溝通
採用靈活(往往為非正式)的手段,來建立和維護專案團隊及其相關方對專案狀況的了解和認可,並在他們之間建立強有力的關係。
書面與口頭溝通
口頭(用詞和音調變化)及非口頭(肢體語言和行為),社交媒體和網站、媒體發布。
在編制傳統(非社群媒體)的書面或口頭訊息的時候,應用書面溝通的5C原則,可以減輕但無法消除理解錯誤
正確的語法和拼寫
語法不當或拼字錯誤會分散注意力,還有可能扭曲訊息意義,降低可信度。
簡潔的表達與無多餘字
簡潔且精心組織的訊息能降低誤解訊息意圖的可能性。
清晰的目的和表達(適合讀者的需要)
確保在訊息中包含能滿足受眾需求與激發其興趣的內容。
連貫的思維邏輯
寫作思路連貫,以及在整個書面文件中使用諸如“引言”和“小結”的小標題。
受控的語句和想法承接
可能需要使用圖表或小結來控制語句和想法的承接。
書面溝通的5C原則需要用下列溝通技巧來配合
積極傾聽。與說話者保持互動,並總結對話內容,以確保有效的訊息交換。
理解文化和個人差異。提升團隊對文化及個人差異的認知,以減少誤解井提升溝通能力。
識別、設定並管理相關方期望。與相關方磋商,減少相關方社群中的自相矛盾的期望。
強化技能。強化所有團隊成員進行以下活動的技能:
說服個人、園隊或組織採取行動
激勵和鼓勵人們,或幫功人們重自信
指導人們改善績效和取得期望結果
透過磋商達成共識以及減輕審批或決策延誤
解決衝突,防止破壞性影響
有效的溝通活動和工件創建具有以下基本屬性
溝通目的明確
盡量了解溝通接收方,滿足其需求及偏好
監督井衡量溝通的效果
規劃溝通管理
規劃溝通管理是基於每個相關方或相關方群體的資訊需求、可用的組織資產,以及具體專案的需求,為專案溝通活動制定適當的方法和計劃的過程。
本過程的主要作用是,為及時向相關方提供相關訊息,引導相關方有效參與項目,而編製書面溝通計畫。
ITTO
輸入
專案章程
專案管理計劃
資源管理計劃
指導如何對專案資源進行分類、分配、管理和釋放。團隊成員和小組可能有溝通要求,應該在溝通管理計畫中列出。
相關方參與計劃
相關方參與計畫確定了有效吸引相關方參與所需的管理策略,而這些策略通常透過溝通來落實。
專案文件
需求文件
需求文件可能包含專案相關方對溝通的需求。
相關方登記冊
相關方登記冊用於規劃與相關方的溝通活動。
事業環境因素
組織過程資產
工具與技術
專家判斷
溝通需求分析
分析溝通需求,確定專案相關方的資訊需求,包括所需資訊的類型和格式,以及資訊對相關方的價值。
常用於識別和確定專案溝通需求的資訊包括(但不限於)
相關方登記冊及相關方參與計畫中的相關資訊及溝通需求
潛在溝通管道或途徑數量,包括一對一、一對多和多對多溝通
組織結構圖
專案組織與相關方的職責、關係及相互依賴
開發方法
專案所涉及的學科、部門和專業
有多少人在什麼地點參與項目
內部資訊需要(如何時在組織內部溝通)
外部資訊需要(如何時與媒體、公眾或承包商溝通)
法律要求
溝通技術
用於在專案相關方之間傳遞訊息的方法很多。資訊交換和協作的常見方法包括對話、會議、書面文件、資料庫、社交媒體和網站。
可能影響溝通技術選擇的因素包括
資訊需求的迫切性
訊息傳遞的緊迫性、頻率和形式可能因專案而異,也可能因專案階段而異。
技術的可用性與可靠性
用於發布專案溝通工件的技術,應該在整個專案期間都具備相容性和可用性,且對所有相關方都可用。
易用性
溝通技術的選擇應適合計畫參與者,並應在適當的時候安排適當的訓練活動。
專案環境
團隊會議與工作是面對面還是在虛擬環境中開展,成員處於一個還是多個時區,他們是否使用多語種溝通,是否還有能影響溝通效率的其他環境因素(如與文化有關的各個方面?)
資訊的敏感性和保密性
需要考慮的一些方面有
擬傳遞的資訊是否屬於敏感或機密資訊?如果是,可能需要採取合理的安全措施。
為員工製定社交媒體政策,以確保行為適當、資訊安全和智慧財產權保護。
溝通模型
溝通模型可以是最基本的線性(發送方和接收方)溝通過程,也可以是增加了回饋元素(發送方、接收方和回饋)、更具互動性的溝通形式,甚至可以是整合了發送方或接收方的人性因素、試圖考慮溝通複雜性的更複雜的溝通模型。
基本的發送方和接收方溝通模型範例
此模型將溝通描述為一個過程,並由發送方和接收方兩方參與;其關注的是確保訊息送達,而非訊息理解。
基本溝通模式中的步驟順序為:
編碼
把訊息編碼為各種符號,如文字、聲音或其他可供傳遞(發送)的形式。
傳遞訊息
透過溝通管道發送訊息。訊息傳遞可能受各種物理因素的不利影響,如不熟悉的技術,或不完整的基礎設施。可能存在噪音和其他因素,導致訊息傳遞和(或)接收過程中的資訊損耗。
解碼
接收方將收到的資料還原為對自己有用的形式。
互動溝通模型範例
此模型也將溝通描述為由發送方與接收方參與的溝通過程,但它也強調確保訊息理解的必要性。此模型包括任何可能幹擾或阻礙訊息理解的噪音,如接收方注意力分散、接收方的認知差異,或缺乏適當的知識或興趣。
互動溝通模式中的新增步驟有:
確認已收到
收到訊息時,接收方需告知對方已收到訊息(確認已收到)。這並不一定意味著同意或理解訊息的內容,僅表示已收到訊息。
回饋/回應
將收到的訊息解碼並理解之後,接收方把還原出來的想法或觀點編碼成訊息,再傳遞給最初的發送方。如果發送方認為回饋與原來的訊息相符,代表溝通已成功完成。在溝通中,可以透過積極傾聽來實現回饋。
在跨文化溝通中,確保訊息理解會面臨挑戰。溝通風格的差異可源自於工作方法、年齡、國籍、專業學科、民族、種族或性別差異。不同文化的人們會以不同的語言(如技術設計文件、不同的風格)溝通,並喜歡採用不同的溝通過程和禮節。
所示的溝通模型展示了發送方的當前情緒、知識、背景、個性、文化和偏見會如何影響訊息本身及其傳遞方式。類似地,接收方的當前情緒、知識、背景、個性、文化和偏見也會影響訊息的接收和解讀方式,導致溝通中的障礙或噪音。
溝通方法
專案相關方之間用於分享資訊的溝通方法有幾種。這些方法可以大致分為
互動溝通
在兩方或多方之間進行的即時多向資訊交換。它使用諸如會議、電話、即時訊息、社交媒體和視訊會議等溝通工件。
推式溝通
向需要接收訊息的特定接收方發送或發布訊息。這種方法可以確保訊息的發送,但不能確保訊息送達目標受眾或被目標受眾理解。在推式溝通中,可以採用的溝通工件包括信件、備忘錄、報告、電子郵件、傳真、語音郵件、部落格、新聞稿。
拉式溝通
適用於大量複雜資訊或大量資訊受眾的情況。它要求接收方在遵守有關安全規定的前提之下自行存取相關內容。這種方法包括入口網站、企業內網、電子線上課程、經驗教訓資料庫或知識庫。
應該採用不同方法來實現溝通管理計劃所規定的主要溝通需求
人際溝通
個人之間交換訊息,通常以面對面的方式進行。
小組溝通
在三到六名人員的小組內部進行。
公眾溝通
單一演講者面向一群人。
大眾傳播
訊息發送人員或小組與大量目標受眾(有時為匿名)之間只有最低程度的聯繫。
網路和社交工具溝通
透過社群工具和媒體,進行多對多的溝通。
人際關係與團隊技能
溝通風格評估
規劃溝通活動時,用於評估溝通風格並識別偏好的溝通方法、形式和內容的一種技術。常用於不支援專案的相關方。可先進行相關方參與度評估,再進行溝通風格評估。在相關方參與度評估中,找出相關方參與度的差距。為彌補這種差距,就需要特別裁剪溝通活動和工件。
政治意識
政治意識有助於專案經理根據專案環境和組織的政治環境來規劃溝通。政治意識是指對正式和非正式權力關係的認知,以及在這些關係中工作的意願。理解組織策略、了解誰能行使權力和施加影響,以及培養與這些相關方溝通的能力,都屬於政治意識的範疇。
文化意識
文化意識指瞭解個人、群體和組織之間的差異,並據此調整專案的溝通策略。具有文化意識並採取後續行動,能夠最小化因專案相關方社群內的文化差異而導致的理解錯誤和溝通錯誤。文化意識和文化敏感度有助於專案經理依據相關方和團隊成員的文化差異和文化需求來規劃溝通。
數據表現
相關方參與度評估矩陣
適用於本過程的資料表現技術包括(但不限於)相關方參與度評估矩陣。相關方參與度評估矩陣顯示了個體相關方目前和期望參與度之間的差距。在本過程中,可進一步分析此評估矩陣,以便為填補參與度差距而識別額外的溝通需求(除常規報告以外的)
會議
輸出
溝通管理計劃
溝通管理計畫是專案管理計畫的組成部分,描述將如何規劃,結構化、執行與監督專案溝通,以提高溝通的有效性。
溝通管理計劃包括訊息
相關方的溝通需求
需溝通的訊息,包括語言、形式、內容和詳細程度
上報步驟
發布資訊的原因
發布所需資訊、確認已收到,或作出回應(若適用)的時限和頻率
負責溝通相關資訊的人員
負責授權保密資訊發布的人員
接收訊息的人員或群體,包括他們的需要、需求和期望
用於傳遞訊息的方法或技術,如備忘錄、電子郵件、新聞稿,或社交媒體
為溝通活動分配的資源,包括時間和預算
隨著專案進展,如專案不同階段相關方社群的變化,而更新與優化溝通管理計畫的方法
通用術語表
項目資訊流向圖、工作流程(可能包含審批程序)、報告清單和會議計畫等
來自法律法規、技術、組織政策等的限制因素
溝通管理計畫中還包括關於專案狀態會議、專案團隊會議、網路會議和電子郵件等的指南和範本。如果專案要使用專案網站和專案管理軟體,那就要把它們寫進溝通管理計畫。
專案管理計畫更新
相關方參與計劃
專案文件更新
專案進度計劃
相關方登記冊
管理溝通
管理溝通是確保專案資訊及時且適當地收集、產生、發布、儲存、檢索、管理、監督和最終處置的過程。此過程的主要角色是,促成專案團隊與相關方之間的有效資訊流動。
ITTO
輸入
專案管理計劃
資源管理計劃
溝通管理計劃
相關方參與計劃
專案文件
變更日誌
變更日誌用於向受影響的相關方傳達變更,以及變更請求的批准、延遲和否決情況。
問題日誌
將與問題有關的資訊傳達給受影響的相關方。
經驗教訓登記冊
專案早期所獲得的與管理溝通有關的經驗教訓,可用於專案後期階段改善溝通過程,提高溝通效率與效果。
品質報告
品質報告包括與品質問題、專案和產品改進,以及流程改善相關的資訊。這些資訊應交給能夠採取糾正措施的人員,以便達成專案的品質期望。
風險報告
風險報告提供關於整體專案風險的來源的信息,以及關於已識別的單一專案風險的概述資訊。這些資訊應傳達給風險責任人及其他受影響的相關方。
相關方登記冊
相關方登記冊確定了需要各類資訊的人員、群體或組織。
工作績效報告
根據溝通管理計畫的定義,工作績效報告會透過此流程傳遞給專案相關方。工作績效報告的典型範例包括狀態報告和進展報告。工作績效報告可以包含掙值圖表和資訊、趨勢線和預測、儲備燃盡圖、缺陷直方圖、合約績效資訊以及風險概述資訊。可以表現為有助於引起關注、制定決策和採取行動的儀表指示圖、熱點報告、信號燈圖或其他形式。
事業環境因素
組織過程資產
工具與技術
溝通技術
會影響技術選用的因素包括團隊是否集中辦公、需要分享的資訊是否需要保密、團隊成員的可用資源,以及組織文化會如何影響會議和討論的正常發展。
溝通方法
溝通方法的選擇應具有彈性,以因應相關方社群的成員變化,或成員的需求和期望變化。
溝通技能
溝通勝任力
經過裁剪的溝通技能的組合,有助於明確關鍵訊息的目的、建立有效關係、實現資訊共享和採取領導行為。
回饋
回饋是關於溝通、可交付成果或情況的反應訊息。回饋支持專案經理和團隊及所有其他專案相關方之間的互動溝通。例如,指導、輔導和磋商。
非言語
也稱非口頭技能。透過示意、語調和臉部表情等適當的肢體語言來表達意思。鏡像模仿和眼神交流也是重要的技能。團隊成員應該知道如何透過說什麼和不說什麼來表達自己的想法。
示範
演示是資訊和/或文件的正式交付。向專案相關方明確有效地示範專案訊息
專案管理資訊系統
專案管理資訊系統(PMIS)能夠確保相關方及時且方便地取得所需資訊。用來管理和分發專案資訊的工具很多,包括:
電子專案管理工具
專案管理軟體、會議和虛擬辦公室支援軟體、網路介面、專門的專案入口網站和狀態儀表板,以及協同工作管理工具。
電子溝通管理
電子郵件、傳真和語音郵件,音訊、視訊和網路會議,以及網站和網路發布。
社群媒體管理
網站和網路發布;以及為促進相關方參與和形成線上社群而建立部落格和應用程式。
專案報告
專案報告發布是收集和發布專案資訊的行為。專案資訊應發布給眾多相關方群體。應針對每種相關方來調整專案資訊發布的適當層次、形式和細節。從簡單的溝通到詳盡的客製化報告和演示,報告的形式各不相同。可以定期準備資訊或基於例外情況準備。雖然工作績效報告是監控專案工作過程的輸出,但本過程會編制臨時報告、專案演示、博客,以及其他類型的資訊。
人際關係與團隊技能
積極傾聽
積極傾聽技術包括告知已收到、澄清與確認訊息、理解,以及消除妨礙理解的障礙。
衝突管理
文化意識
會議管理
會議管理是採取步驟確保會議有效且有效率地達到預期目標。
人際交往
人際互動是透過與他人互動交流訊息,建立連結。人際互動有利於專案經理及其團隊透過非正式組織解決問題,影響相關方的行動,以及提高相關方對專案工作和成果的支持,進而改善績效。
政治意識
政治意識有助於專案經理在專案期間引導相關方參與,以保持相關方的支持。
會議
輸出
專案溝通記錄
專案溝通工件可包括(但不限於):績效報告、可交付成果果的狀態、進度進度、產生的成本、演示,以及相關方所需的其他資訊。
專案管理計畫更新
溝通管理計劃
如果這個過程導致了專案溝通方法發生變更,就要把這種變更反映在專案溝通計畫中。
相關方參與計劃
本過程將導致相關方的溝通需求以及商定的溝通策略需要更新。
專案文件更新
問題日誌
經驗教訓登記冊
專案進度計劃
風險登記冊
相關方登記冊
組織過程資產更新
監督溝通
監督溝通是確保滿足專案及其相關方的資訊需求的過程。此流程的主要角色是,依溝通管理計畫和相關方參與計畫的要求優化訊息傳遞流程。
透過監督溝通過程,來確定規劃的溝通工件和溝通活動是否如預期提高或保持了相關方對專案可交付成果與預期結果的支持力度。專案溝通的影響和結果應該接受認真的評估和監督,以確保在正確的時間,透過正確的管道,將正確的內容(發送方和接收方對其理解一致)傳遞給正確的受眾。監督溝通可能需要採取各種方法,例如,進行客戶滿意度調查、整理經驗教訓、進行團隊觀察、審查問題日誌中的數據,或評估相關方參與度評估矩陣中的變更。
監督溝通過程可能觸發規劃溝通管理和(或)管理溝通過程的迭代,以便修改溝通計畫並進行額外的溝通活動,以提升溝通的效果。這種迭代體現了專案溝通管理各過程的持續性質。問題、關鍵績效指標、風險或衝突,都可能立即觸發重新進行這些過程。
ITTO
輸入
專案管理計劃
資源管理計劃
溝通管理計劃
溝通管理計劃是關於及時收集、產生和發布資訊的現行計劃,它確定了溝通過程中的團隊成員、相關方和相關工作。
相關方參與計劃
相關方參與計畫確定了計畫用以引導相關方參與的溝通策略。
專案文件
問題日誌
問題日誌提供專案的歷史資訊、相關方參與問題的記錄,以及它們如何解決。
經驗教訓登記冊
在專案早期所獲得的經驗教訓可用於專案後期階段,以改善溝通效果。
專案溝通記錄
提供已進行的溝通的資訊。
工作績效數據
工作績效數據包含關於實際已進行的溝通類型和數量的數據。
事業環境因素
組織過程資產
工具與技術
專家判斷
專案管理資訊系統
專案管理資訊系統為(PMIS)專案經理提供一系列標準化工具,以根據溝通計畫為內部和外部的相關方收集、儲存與發布所需的資訊。應監控該系統中的資訊以評估其有效性和效果。
數據分析
相關方參與度評估矩陣
它可以提供與溝通活動效果有關的資訊。應該檢查相關方的期望與當前參與度的變化情況,並對溝通進行必要調整。
人際關係與團隊技能
觀察/交談
適用於本過程的人際關係與團隊技能包括(但不限於)觀察與交談。與專案團隊展開討論和對話,有助於確定最合適的方法,用於更新和溝通專案績效,以及回應相關方的資訊請求。透過觀察和交談,專案經理能夠發現團隊內的問題、人員間的衝突,或個人績效問題。
會議
輸出
工作績效訊息
變更請求
監督溝通過程往往會導致需要對溝通管理計畫所定義的溝通活動進行調整、採取行動和介入。變更請求需要透過實施整體變更控制流程進行處理。
此類變更請求可能導致:修正相關方的溝通要求,包括相關方對資訊發布、內容或形式,以及發布方式的要求;建立消除瓶頸的新程序。
專案管理計畫更新
溝通管理計劃
需要更新溝通管理計劃,記錄能讓溝通更有效的新資訊。
相關方參與計劃
需要更新相關方參與計劃,反映相關方的實際情況、溝通需求和重要性。
專案文件更新
問題日誌
經驗教訓登記冊
相關方登記冊
專案風險管理
概述說明
單一專案風險是一旦發生,會對一個或多個專案目標產生正面或負面影響的不確定事件或條件。
整體專案風險是(所有)不確定性對專案整體的影響,是相關面向的專案結果正面和負面變異區間。它源自於包括單一風險在內的所有不確定性。
整體風險決定因素
專案複雜性
立項前
策劃階段
遺傳因素
項目所處環境
組織文件
組織結構
規章制度
生活環境
相關方複雜性
矛盾較多
人數較多
周圍人影響
專案團隊能力
能力強
能力弱
自我關注程度
風險敞口(Risk Exposure).在某個項目、項目集或項目組合中,針對任一特定對象,而適時作出的對所有風險的潛在影響的綜合評估。
可能性和後果聯合決定了風險敞口(Risk Exposure)。
兩者量化後的乘積就是風險敞口。
風險敞口(risk exposure)反應了你應該預留多少時間或資金來容納風險。要計算這個,首先應估計風險的數值機率,然後把它乘以風險的影響。在考慮影響的時候,不要忘記你在緩解行為中可能已經有所付出,但應變行為是風險影響的一部分。例如,你可能認為因為太受歡迎而造成的宕機機率大約是35%,而其影響是3天額外的開發時間,再加上頻寬、場地租用和新設備的費用共2萬美元。你的整體風險敞口就是7000美元加上一天。
有些風險有100%的發生幾率。這種就不再是風險一而是現實。修改你的發布計劃來應付它們。
風險四要素
風險原因
風險起因
風險條件
風險事件
風險機率
風險後果
風險敞口
風險分類
已知-已知風險
已經識別出並分析過的風險,人們不僅知道它們是什麼風險,而且知道它們發生的可能性和後果。
已知-未知風險
已經識別出但其發生的可能性或後果還不清楚的風險,通常在專案預算和進度計劃中列出一定的應急儲備(包括應急資金和時間)來應對。
未知-未知風險
過去從未遇到過的完全未知的風險。也叫突發風險,需要透過提高專案韌性來應對。
除了為已知風險列出具體風險預算,還不要為突發性風險預留合理的緊急預算和時間
採用靈活的專案過程,包括強而有力的變更管理,以便在保持朝專案目標推進的正確方向的
授權目標明確且值得信賴的專案團隊在商定限制範圍內完成工作等等
風險偏好(Risk Appetite)
為了預期的回報,組織或個人願意承擔不確定性的程度。需要把風險偏好轉變成可測量的風險臨界值。
風險臨界值(Risk Threshold.)
某種特定的風險敞口級別,高於該級別的風險需要處理,低於該級別的風險則可接受。
風險承受力
是指個人或組織能承受的最高風險程度。
規劃風險管理
規劃風險管理是定義如何實施專案風險管理活動的過程。本過程的主要作用是,確保風險管理的程度、方法和可見度與專案風險程度,以及專案對組織和其他相關方的重要性相符。
ITTO
輸入
專案章程
專案管理計劃
所有組件
在規劃專案風險管理時,應考慮所有已核准的內子管理計劃,使風險管理計劃與之相協調;同時,其他專案管理計劃組件中所列出的方法論可能也會影響規劃風險管理流程。
專案文件
相關方登記冊
相關方登記冊包含專案相關方的詳細信息,並概述其在專案中的角色和對專案風險的態度;可用於確定專案風險管理的角色和職責,以及為專案設定風險臨界值。
事業環境因素
會影響規劃風險管理過程的事業環境因素包括(但不限於)由組織或關鍵相關方設定的整體風險臨界值。
組織過程資產
工具與技術
專家判斷
數據分析
相關方分析
可透過相關方分析確定專案相關方的風險偏好。
會議
風險管理計畫的編制可以是專案開工會議上的工作,或是可以舉辦專門的規劃會議來編制風險管理計畫。與會者可能包括專案經理、指定專案團隊成員、關鍵相關方,或負責管理專案風險管理流程的團隊成員;如果需要,也可邀請其他外部人員參加,包括客戶、賣方和監管機構。熟練的會議引導者能夠幫助與會者專注於會議事項,就風險管理方法的關鍵方面達成共識,識別和克服偏見,以及解決任何可能出現的分歧。
在此類會議上確定開展風險管理活動的計劃,並將其記錄在風險管理計劃中。
輸出
風險管理計劃
風險管理計劃是專案管理計劃的組成部分,描述如何安排與實施風險管理活動。
風險管理計劃可包括以下部分或全部內容
風險管理策略
描述用於管理本專案的風險的一般方法。
方法論
確定用於進行本專案的風險管理的具體方法、工具及資料來源。
角色與職責
確定每項風險管理活動的領導者、支持者和團隊成員,並明確他們的職責。
資金
確定進行專案風險管理活動所需的資金,並制定緊急儲備和管理儲備的使用方案。
時間安排
確定在專案生命週期中實施專案風險管理流程的時間和頻率,確定風險管理活動並將其納入專案進度計畫。
風險類別
確定對單一項目風險進行分類的方式。通常藉助風險分解結構(RBS)來建構風險類別。風險分解結構是潛在風險來源的層級展現。風險分解結構有助於專案團隊考慮單一專案風險的全部可能來源,對識別風險或歸類已識別風險特別有用。
相關方風險偏好
應在風險管理計畫中記錄專案關鍵相關方的風險偏好。他們的風險偏好會影響規劃風險管理過程的細節。特別是,應該針對每個專案目標,把相關方的風險偏好表述成可測量的風險臨界值。這些臨界值不僅將聯合決定可接受的整體專案風險敞口水平,而且還用於制定機率和影響定義。以後將根據機率和影響定義,對單一專案風險進行評估和排序。
風險機率和影響定義
根據具體的專案環境,組織和關鍵相關方的風險偏好和臨界值,來制定風險機率和影響定義。專案可能自行製定關於機率和影響等級的具體定義,或以組織提供的通用定義作為出發點。應該根據擬進行專案風險管理過程的詳細程度,來確定機率和影響等級的數量,即:更多等級(通常為五級)對應於更詳細的風險管理方法,較少等級(通常為三級)對應於更簡單的方法。
機率和影響矩陣
組織可在專案開始前確定優先排序規則,並將其納入組織流程資產,或也可為具體專案量身訂做優先排序規則。在常見的機率和影響矩陣中,會同時列出機會和威脅;以正面影響定義機會,以負面影響定義威脅。機率和影響可以用描述性術語(如很高、高、中、低和很低)或數值來表達。如果使用數值,就可以把兩個數值相乘,得出每個風險的機率-影響分值,以便據此在每個優先組別之內排列單一風險相對優先順序。
報告格式
確定將如何記錄、分析和溝通專案風險管理過程的結果。在這一部分,描述風險登記冊、風險報告以及專案風險管理過程的其他產出的內容和格式。
追蹤
追蹤是確定將如何記錄風險活動,以及將如何審計風險的管理過程。
識別風險
識別風險是識別單一專案風險以及整體專案風險的來源並記錄風險特徵的過程。本過程的主要作用是,記錄現有的單一專案風險,以及整體專案風險的來源;同時,匯集相關信息,以便專案團隊能夠適當地應對已識別的風險。
ITTO
輸入
專案管理計劃
需求管理計劃
需求管理計劃可能指出了特別有風險的專案目標。
進度管理計劃
成本管理計劃
品質管理計劃
資源管理計劃
風險管理計劃
範圍基準
進度基準
成本基準
專案文件
假設日誌
假設日誌所記錄的假設條件和限制因素可能引發單一專案風險,也可能影響整體專案風險的等級。
成本估算
持續時間估算
問題日誌
經驗教訓登記冊
需求文件
資源需求
相關方登記冊
協定
如果需要從外部採購專案資源,協議所規定的里程碑日期、合約類型、驗收標準和獎罰條款等,都可能造成威脅或創造機會。
採購文件
如果需要從外部採購專案資源,就應該審查初始採購文檔,因為從組織外部採購商品和服務可能會提高或降低整體專案風險,並可能引發更多的單一專案風險。隨著採購文檔在專案期間的不斷更新,也應該審查最新的文檔,例如,賣方績效報告、核准的變更請求和與檢查相關的資訊。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
腦力激盪
核對單
基於從類似項目和其他資訊來源累積的歷史資訊和知識來編制核對單。編制核對單,列出過去曾出現且可能與當前專案相關的具體單一專案風險,這是吸取已完成的類似專案的經驗教訓的有效方法。組織可能基於自己已完成的專案來編制核對單,或者可能採用特定行業的通用風險核對單。雖然核對單簡單易用,但它不可能窮盡所有風險。所以,必須確保不要用核對單來取代所需的風險識別工作;同時,專案團隊也應該注意考察未在核對單中列出的事項。此外,還應該不時地審查核對單,增加新訊息,刪除或存檔過時資訊。
訪談
可以透過對資深專案參與者、相關方和主題專家的訪談,來識別單一專案風險以及整體專案風險的來源。應該在信任和保密的環境下進行訪談,以獲得真實可信、不帶偏見的意見。
數據分析
根本原因分析
根本原因分析常用於發現導致問題的深層原因並制定預防措施。可以用問題陳述(如專案可能延誤或超支)作為出發點,來探討哪些威脅可能導致此問題,從而識別出相應的威脅。也可以用收益陳述(如提前交付或低於預算)作為出發點,來探討哪些機會可能有利於實現該效益,從而識別出相應的機會。
假設條件與限制分析
進行假設條件和限制因素分析,來探討假設條件和限制因素的有效性,確定其中哪些會引發專案風險。從假設條件的不準確、不穩定、不一致或不完整,可以識別出威脅,透過清除或放鬆會影響專案或流程執行的限制因素,可以創造出機會。
SWOT分析
這是對專案的優勢、劣勢、機會和威脅(SWOT)進行逐一檢查。在識別風險時,它會將內部產生的風險包含在內,從而擴大識別風險的範圍。首先,專注於專案、組織或一般業務領域,識別組織的優勢和劣勢;然後,找出組織優勢可能為專案帶來的機會,組織劣勢可能造成的威脅。也可以分析組織優勢能在多大程度上克服威脅,組織劣勢是否會妨礙機會的產生。
文件分析
透過對專案文件的結構化審查,可以識別出一些風險。可供審查的文件包括(但不限於)計劃、假設條件、限制、以往專案檔案、合約、協議和技術文件。專案文件中的不確定性或模糊性,以及同一文件內部或不同文件之間的不一致,都可能是專案風險的指示訊號。
人際關係與團隊技能
引導
引導能提高用於識別單一專案風險和整體專案風險來源的許多技術的有效性。熟練的引導者可以幫助與會者專注於風險識別任務、準確遵循與技術相關的方法,有助於確保風險描述清晰、找到並克服偏見,以及解決任何可能出現的分歧。
提示清單
提示清單是關於可能引發單一專案風險以及可作為整體專案風險來源的風險類別的預設清單。在採用風險識別技術時,提示清單可作為框架協助專案團隊形成想法。可以用風險分解結構底層的風險類別作為提示清單,來辨識單一項目風險。某些常見的策略架構較適用於識別整體專案風險的來源,如PESTLE(政治、經濟、社會、技術、法律、環境)、TECCOP(技術、環境、商業、營運、政治),或VUCA(易變性、不確定性、複雜性、模糊性)
會議
輸出
風險登記冊
風險登記冊記錄已識別單一項目風險的詳細資料。隨著實施定性風險分析、規劃風險因應、實施風險因應和監督風險等過程的進行,這些過程的結果也要記進風險登記冊。取決於特定的項目變數(如規模和複雜性),風險登記冊可能包含有限或廣泛的風險資訊。
當完成識別風險流程時,風險登記冊的內容可能包括(但不限於)
已識別風險的清單
在風險登記冊中,每項單一項目風險都被賦予一個獨特的識別號碼。要以所需的詳細程度對已識別風險進行描述,確保明確理解。可以使用結構化的風險描述,來把風險本身與風險原因及風險影響區分開來。
潛在風險責任人
如果在識別風險過程中已識別出潛在的風險責任人,就要把該責任人記錄到風險登記冊中。隨後將由實施定性風險分析過程進行確認。
潛在風險因應措施清單
如果在識別風險過程中已識別出某種潛在的風險應對措施,就要把它記錄到風險登記冊中。隨後將由規劃風險因應過程進行確認。
風險報告
風險報告提供關於整體專案風險的信息,以及關於已識別的單一專案風險的概述資訊。在專案風險管理過程中,風險報告的編制是一項漸進的工作。隨著實施定性風險分析、實施定量風險分析、規劃風險應對、實施風險應對和監督風險過程的完成,這些過程的結果也需要記錄在風險登記冊中。
在完成識別風險過程時,風險報告的內容可能包括(但不限於)
整體專案風險的來源
說明哪些是整體專案風險敞口的最重要驅動因素。
關於已識別單一專案風險的概述訊息
例如,已識別的威脅與機會的數量、風險在風險類別中的分佈、測量指標和發展趨勢。
根據風險管理計畫中規定的報告要求,風險報告中可能還包含其他資訊。
專案文件更新
假設日誌
問題日誌
經驗教訓登記冊
實施定性風險分析
實施定性風險分析是透過評估單一專案風險發生的機率和影響以及其他特徵,對風險進行優先排序,從而為後續分析或行動提供基礎的過程。本過程的主要作用是重點關注高優先級的風險。
實施定性風險分析,使用專案風險的發生機率、風險發生時對專案目標的相應影響以及其他因素,來評估已識別單一專案風險的優先順序。這種評估是基於專案團隊和其他相關方對風險的認知程度,從而具有主觀性。所以,為了實現有效評估,就需要認清和管理本過程關鍵參與者對風險所持的態度。風險感知會導致評估已識別風險時出現偏見,所以應該注意找出偏見並加以糾正。如果由引導者來引導本過程的發展,那麼找出並糾正偏見就是該引導者的重要工作。同時,評估單一專案風險的現有資訊的質量,也有助於澄清每個風險對專案的重要性的評估。
實施定性風險分析能為規劃風險因應過程確定單一專案風險的相對優先順序。本過程會為每個風險識別出責任人,以便由他們負責規劃風險應對措施,並確保應對措施的實施。如果需要進行實施定量風險分析流程,那麼實施定性風險分析也能為其奠定基礎。
根據風險管理計畫的規定,在整個專案生命週期中要定期進行實施定性風險分析流程。在敏捷開發環境中,實施定性風險分析流程通常在每次迭代開始前進行。
ITTO
輸入
專案管理計劃
風險管理計劃
本過程中需要特別注意的是風險管理的角色和職責、預算和進度活動安排,以及風險類別(通常在風險分解結構中定義)機率和影響定義、機率和影響矩陣和相關方的風險臨界值。通常已經在規劃風險管理過程中把這些內容裁剪成適合特定專案的需要。如果還沒有這些內容,則可以在實施定性風險分析過程中編制,並經專案發起人批准之後用於此流程。
專案文件
假設日誌
假設日誌用於識別、管理和監督可能影響專案的關鍵假設條件和限制因素,它們可能影響對單一專案風險的優先順序的評估。
風險登記冊
風險登記冊包括將在本過程評估的、每個已識別的單一項目風險的詳細資訊。
相關方登記冊
它包括可能被指定為風險責任人的專案相關方的詳細資訊。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
訪談
適用於本流程的資料收集技術包括(但不限於)訪談。結構化或半結構化的訪談可用於評估單一專案風險的機率和影響,以及其他因素。訪談者應該營造信任和保密的訪談環境,以鼓勵被訪者提出誠實和無偏見的意見。
數據分析
風險數據品質評估
風險資料是進行定性風險分析的基礎。風險數據品質評估旨在評估關於單一項目風險的數據的準確性和可靠性。使用低品質的風險數據,可能導致定性風險分析基本上對專案沒用。如果數據品質不可接受,就可能需要收集更好的數據。可以進行問卷調查,了解項目相關方對資料品質各方面的評價,包括資料的完整性、客觀性、相關性和及時性,進而對風險資料的品質進行全面評估。可以計算這些方面的加權平均數,將其作為資料品質的總體分數。
風險機率和影響評估
風險機率評估考慮的是特定風險發生的可能性,而風險影響評估考慮的是風險對一項或多項專案目標的潛在影響,如進度、成本、品質或績效。威脅將產生負面的影響,機會將產生正面的影響。要對每個已識別的單一專案風險進行機率和影響評估。此,也記錄相應的說明性細節,例如,確定機率水平或影響等級所依據的假設條件。應該採用風險管理計畫中的機率和影響定義,來評估風險的機率和影響。低機率和影響的風險將被列入風險登記冊中的觀察清單,以供未來監控。
其他風險參數評估
為了方便未來分析和行動,在對單一專案風險進行優先排序時,專案團隊可能會考慮(除機率和影響以外的)其他風險特徵。
此類特徵可能包括(但不限於)
緊迫性
為有效因應風險而必須採取因應措施的時間段。時間短就表示緊迫性高。
鄰近性
風險在多久後會影響一項或多項專案目標。時間短就表示鄰近性高。
潛伏期
從風險發生到影響顯現之間可能的時間段。時間短就表示潛伏期短。
可管理性
風險責任人(或責任組織)管理風險發生或影響的容易程度。如果容易管理,可管理性就高。
可控性
風險責任人(或責任組織)能夠控制風險後果的程度。如果後果很容易控制,可控性就高。
可監測性
對風險發生或即將發生進行監測的容易程度。如果風險發生很容易監測,可監測性就高。
連通性
風險與其他單一項目風險存在關聯的程度大小。如果風險與多個其他風險有關聯,連通性就高。
戰略影響力
風險對組織策略目標潛在的正面或負面影響。如果風險對戰略目標有重大影響,戰略影響力就大。
密切度
風險被一名或多名相關方認為要緊的程度。被認為很要緊的風險,密切度就高。
相對於僅評估機率和影響,考慮上述某些特徵有助於進行更穩健的風險優先排序。
人際關係與團隊技能
引導
風險分類
專案風險可依據風險來源(如採用風險分解結構【RBS】)、受影響的專案領域(如採用工作分解結構【WBS】),以及其他實務類別(如專案階段、專案預算、角色和職責)來分類,確定哪些項目領域最容易被不確定性影響;風險也可以根據共同的根本原因進行分類。應在風險管理計畫中規定可用於專案的風險分類方法。
將風險分類,有助於把注意力和精力集中到風險敞口最大的領域,或針對一組相關的風險制定通用的風險應對措施,從而有利於更有效地開展風險應對。
數據表現
機率和影響矩陣
機率和影響矩陣是把每個風險發生的機率和一旦發生對專案目標的影響映射起來的表格。基於風險的機率和影響,對風險進行優先排序,以便未來進一步分析並制定應對措施。組織可針對每個專案目標(如成本、時間和範圍)制定單獨的機率和影響矩陣,並用它們來評估風險針對每個目標的優先順序。組織也可以用不同的方法為每個風險確定一個總體優先等級。即可綜合針對不同目標的評估結果,也可採用最高優先等級(無論針對哪個目標),作為風險的整體優先等級。
層級型
如果使用了兩個以上的參數來對風險進行分類,那就不能使用機率和影響矩陣,而需要使用其他圖形。例如,氣泡圖能顯示三維資料。在氣泡圖中,把每個風險都繪製成一個氣泡,並用x軸值、y軸值和氣泡大小來表示風險的三個參數。圖例是氣泡圖的範例,其中,X軸代表可監測性,Y軸代表鄰近性,影響值則以氣泡大小表示。
會議
輸出
專案文件更新
假設日誌
在實施定性風險分析過程中,可能做出新的假設、識別出新的限制因素,或現有的假設條件或限制因素可能被重新審查和修改。應該更新假設日誌,應記錄這些新資訊。
問題日誌
應該更新問題日誌,記錄發現的新問題或當前問題的變更。
風險登記冊
用實施定性風險分析過程產生的新訊息,去更新風險登記冊。風險登記冊的更新內容可能包括:每個單一項目風險的機率和影響評估、優先等級或風險分值、指定風險責任人、風險緊迫性資訊或風險類別,以及低優先級風險的觀察清單或需要進一步分析的風險。
風險報告
更新風險報告,記錄最重要的單一專案風險(通常為機率和影響最高的風險)、所有已識別風險的優先順序清單以及簡要的結論。
實施定量風險分析
實施定量風險分析是就已識別的單一專案風險和不確定性的其他來源對整體專案目標的影響進行定量分析的過程。本過程的主要作用是,量化整體專案風險敞口,並提供額外的定量風險信息,以支持風險應對規劃。
並非所有專案都需要實施定量風險分析。能否進行穩健的分析取決於是否有關於單一專案風險和其他不確定性來源的高品質數據,以及與範圍、進度和成本相關的紮實專案基準。定量風險分析通常需要運用專門的風險分析軟體,以及編製和解釋風險模式的專業知識,還需要額外的時間和成本投入。專案風險管理計畫會規定是否需要使用定量風險分析,定量分析最可能適用於大型或複雜的專案、具有策略重要性的專案、合約要求進行定量分析的項目,或主要相關方要求進行定量分析的項目。透過評估所有單一專案風險和其他不確定性來源對專案結果的綜合影響,定量風險分析就成為評估整體專案風險的唯一可靠的方法。
在實施定量風險分析過程中,要使用被定性風險分析流程評估為對專案目標有重大潛在影響的單一專案風險的資訊。
實施定量風險分析過程的輸出,則要用作規劃風險應對過程的輸入,特別是要據此為整體專案風險和關鍵單一專案風險推薦應對措施。定量風險分析也可以在規劃風險應對過程之後開展,以分析已規劃的應對措施對降低整體專案風險敞口的有效性。
ITTO
輸入
專案管理計劃
風險管理計劃
範圍基準
進度基準
成本基準
專案文件
假設日誌
估算依據
成本估算
成本預測
持續時間估算
里程碑清單
資源需求
風險登記冊
風險報告
進度預測
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
訪談
可用於針對單一專案風險和其他不確定性來源,產生定量風險分析的輸入。當需要向專家徵求資訊時,訪談尤其適用。訪談者應該營造信任和保密的訪談環境,以鼓勵被訪者提出誠實和無偏見的意見。
人際關係與團隊技能
引導
不確定性表現方式
要進行定量風險分析,就需要建立能反映單一專案風險和其他不確定性來源的定量風險分析模型,並提供輸入。
數據分析
模擬
在定量風險分析中,使用模型來模擬單一專案風險和其他不確定性來源的綜合影響,以評估它們對專案目標的潛在影響。模擬通常採用蒙特卡羅分析。對成本風險進行蒙特卡羅分析時,使用專案成本估算作為模擬的輸入;對進度風險進行蒙特卡羅分析時,使用進度網路圖和持續時間估算作為模擬的輸入。在進行綜合定量成本-進度風險分析時,同時使用這兩種輸入。其輸出為定量風險分析模型。
用電腦軟體數千次迭代運行定量風險分析模型。每次運行,都要隨機選擇輸入值(如成本估算、持續時間估算或機率分支發生頻率)。這些運行的產出構成了專案可能結果(如專案結束日期、專案完工成本)的區間。典型的輸出包括:表示模擬得到特定結果的次數的直方圖,或表示獲得等於或小於特定數值的結果的累積機率分佈曲線(S曲線)。
在定量進度風險分析中,還可以執行關鍵性分析,以確定風險模型的哪些活動對專案關鍵路徑的影響最大。對風險模型中的每項活動計算關鍵性指標,即:在全部模擬中,該活動出現在關鍵路徑上的頻率,通常以百分比表示。透過關鍵性分析,專案團隊就能夠專注於那些對專案整體進度績效有最大潛在影響的活動,來規劃風險因應措施。
敏感度分析
敏感度分析有助於確定哪些單一專案風險或其他不確定性來源對專案結果具有最大的潛在影響。它在專案結果變異與定量風險分析模型中的要素變異之間建立連結。
敏感度分析的結果通常用龍捲風圖來表示。在該圖中,標示出定量風險分析模型中的每項要素與其能影響的項目結果之間的關聯係數。這些要素可包括單一專案風險、易變的專案活動,或具體的不明確性來源。每個要素依關聯強度降序排列,形成典型的龍捲風形狀。
決策樹分析
用決策樹在若干備選行動方案中選擇一個最佳方案。在決策樹中,以不同的分支代表不同的決策或事件,即專案的替代路徑。每個決策或事件都有相關的成本和單一專案風險(包括威脅和機會)。決策樹分支的終點表示沿著特定路徑發展的最後結果,可以是負面或正面的結果。
在決策樹分析中,透過計算每條分支的預期貨幣價值,就可以選出最優的路徑。
影響圖
輸出
專案文件更新
風險報告
更新風險報告,反映定量風險分析的結果,通常包括:
整體專案風險敞口的評估結果
專案詳細機率分析的結果
列出定量風險分析的重要輸出,如S曲線、龍捲風圖和關鍵性指標,以及它們的敘述性解釋。
定量風險分析的詳細結果可能包括
所需的緊急儲備,以達到實現目標的特定置信水平
對專案關鍵路徑有最大影響的單一專案風險或其他不確定定性來源的清單
整體專案風險的主要驅動因素,即:對專案結果的不確定性有最大影響的因素
單一專案風險優先清單
定量風險分析結果的趨勢
風險應對建議
規劃風險因應
規劃風險因應是為處理整體專案風險敞口,以及應對單一專案風險,而製定可選方案、選擇應對策略並商定應對行動的過程。本流程的主要作用是,制定應對整體專案風險和單一專案風險的適當方法;本流程還將分配資源,並根據需要將相關活動新增至專案文件和專案管理計劃。
有效且適當的風險因應可以最小化單一威脅,最大化單一機會,並降低整體專案風險敞口;不恰當的風險因應則會適得其反。一旦完成對風險的識別、分析和排序,指定的風險責任人就應該編制計劃,以應對專案團隊認為足夠重要的每項單一專案風險。這些風險會對專案目標的實現造成威脅或提供機會。專案經理也應該思考如何針對整體專案風險的當前層級做出適當的應對。
風險應對方案應該與風險的重要性相符、能經濟有效地應對挑戰、在當前專案背景下現實可行、能獲得全體相關方的同意,並由一名責任人具體負責。往往需要從幾套可選方案中選出最優的風險因應方案。應該為每個風險選擇最可能有效的策略或策略組合。可用結構化的決策技術來選擇最適當的因應策略。對於大型或複雜項目,可能需要以數學最佳化模型或實際方案分析為基礎,進行更穩健的備選風險因應策略經濟分析。
ITTO
輸入
專案管理計劃
資源管理計劃
風險管理計劃
成本基準
專案文件
經驗教訓登記冊
專案進度計劃
專案團隊派遣工單
資源日曆
風險登記冊
風險登記冊包含了已識別並排序的、需要應對的單一項目風險的詳細資訊。每項風險的優先順序有助於選擇適當的風險因應措施。例如,針對高優先級的威脅或機會,可能需要採取優先措施和積極主動的應對策略;而針對低優先級的威脅和機會,可能只需要把它們列入風險登記冊的觀察清單部分,或者只需要為之增加緊急儲備,而不必採取主動的管理措施。
風險登記冊列出了每項風險的指定風險責任人,也可能包含在早期的專案風險管理過程中識別的初步風險應對措施。風險登記冊可能還會提供有助於規劃風險應對的、關於已識別風險的其他信息,包括根本原因、風險觸發因素和預警信號、需要在短期內應對的風險,以及需要進一步分析的風險。
風險報告
風險報告中的專案整體風險敞口的當前級別,會影響選擇適當的風險應對策略。風險報告也可能按優先順序列出了單一專案風險,並對單一專案風險的分佈進行了更多分析;這些資訊都會影響風險應對策略的選擇。
相關方登記冊
相關方登記冊列出了風險應對的潛在責任人。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
訪談
人際關係與團隊技能
引導
威脅因應策略
針對威脅,可以考慮下列五種備選策略
上報
如果專案團隊或專案發起人認為某威脅不在專案範圍內,或提議的因應措施超出了專案經理的權限,就應該採用上報策略。被上報的風險將在專案集層面、專案組合層面或組織的其他相關部門加以管理,而不在專案層面。專案經理確定應就威脅通知哪些人員,並向該人員或組織部門傳達關於該威脅的詳細資訊。對於被上報的威脅,組織中的相關人員必須願意承擔應對責任,這一點非常重要。威脅通常要上報給其目標會受該威脅影響的那個層級。威脅一旦上報,就不再由專案團隊做進一步監督,雖然仍可出現在風險登記冊中供參考。
規避
風險規避是指專案團隊採取行動來消除威脅,或保護專案免受威脅的影響。它可能適用於發生機率較高,且具有嚴重負面影響的高優先級威脅。規避策略可能涉及變更專案管理計畫的某些方面,或改變會受負面影響的目標,以便於徹底消除威脅,將它的發生機率降低到零。風險責任人也可以採取措施,分離專案目標與風險萬一發生的影響。規避措施可能包括消除威脅的原因、延長進度計畫、改變專案策略,或縮小範圍。有些風險可以透過澄清需求、獲取資訊、改善溝通或取得專有技能來規避。
轉移
轉移涉及將應對威脅的責任轉移給第三方,讓第三方管理風險並承擔威脅發生的影響。採用轉移策略,通常需要向承擔威脅的一方支付風險轉移費用。風險轉移可能需要透過一系列行動才實現,包括(但不限於)購買保險、使用履約保函、使用擔保書、使用保證書等。也可以透過簽訂協議把具體風險的歸屬和責任轉移給第三人。
減輕
風險減輕是指採取措施來降低威脅發生的機率和(或)影響。提前採取減輕措施通常比威脅出現後嘗試彌補更有效。減輕措施包括採用較簡單的流程,進行更多測試,或選用更可靠的賣方。也可能涉及原型開發,以降低從實驗台模型放大到實際製程或產品的風險。如果無法降低機率,也許可以從決定風險嚴重性的因素著手,來減輕風險發生的影響。例如,在一個系統中加入冗餘零件,可以減輕原始零件故障所造成的影響。
接受
風險接受是指承認威脅的存在,但不主動採取措施。此策略可用於低優先級威脅,也可用於無法以任何其他方式加以經濟有效應對的威脅。接受策略又分為主動或被動方式。最常見的主動接受策略是建立緊急儲備,包括預留時間、資金或資源以應對出現的威脅;被動接受策略則不會主動採取行動,而只是定期對威脅進行審查,確保其並未發生重大改變。
機會因應策略
針對機會,可以考慮下列五種備選策略
上報
如果專案團隊或專案發起人認為某機會不在專案範圍內,或提議的因應措施超出了專案經理的權限,就應該取用上報策略。被上報的機會將在專案集層面、專案組合層面或組織的其他相關部門加以管理,而不是在專案層面。專案經理確定應就機會通知哪些人員,並向該人員或組織部門傳達關於該機會的詳細資訊。對於被上報的機會,組織中的相關人員必須願意承擔應對責任,這一點非常重要。機會通常要上報給其目標會受該機會影響的那個層級。機會一旦上報,就不再由專案團隊做進一步監督,雖然仍可出現在風險登記冊中供參考。
開拓
如果組織想確保把握住高優先順序的機會,就可以選擇開拓策略。此策略將特定機會的出現機率提高到100%,確保其肯定出現,從而獲得與其相關的收益。開拓措施可能包括:把組織中最有能力的資源分配給專案來縮短完工時間,或採用全新技術或技術升級來節省專案成本並縮短專案持續時間。
分享
分享涉及將應對機會的責任轉移給第三方,使其享有機會所帶來的部分利益。必須仔細為已分享的機會安排新的風險責任人,讓那些最有能力為專案抓住機會的人擔任新的風險責任人。採用風險分享策略,通常需要向承擔機會應對責任的一方支付風險費用。分享措施包括建立合夥關係、合作團隊、特殊公司或合資企業來分享機會。
提高
提高策略用於提高機會出現的機率和(或)影響。提前採取提高措施通常比機會出現後嘗試改善收益更有效。透過關注其原因,可以提高機會出現的機率;如果無法提高機率,也許可以針對決定其潛在收益規模的因素來提高機會發生的影響。機會提高措施包括為早日完成活動而增加資源。
接受
接受機會是指承認機會的存在,但不主動採取措施。此策略可用於低優先級機會,也可用於無法以任何其他方式加以經濟有效地應對的機會。接受策略又分為主動或被動方式。最常見的主動接受策略是建立應急儲備,包括預留時間、資金或資源,以便在機會出現時加以利用;被動接受策略則不會主動採取行動,而只是定期對機會進行審查,確保其並未發生重大改變。
緊急應變策略
可以設計一些僅在特定事件發生時才採用的因應措施。對於某些風險,如果專案團隊相信其發生會有充分的預警訊號,那麼就應該制定僅在某些預定條件出現時才執行的應對計畫。應該定義並追蹤緊急應變策略的觸發條件,例如,未實現中間的里程碑,或獲得賣方更高程度的重視。採用此技術制定的風險應對計劃,通常稱為應急計劃或彈回計劃,其中包括已識別的、用於啟動計劃的觸發事件。
整體專案風險因應策略
風險因應措施的規劃和實施不應只針對單一專案風險,還應針對整體專案風險。用於應對單一專案風險的策略也適用於整體專案風險。
規避
如果整體專案風險有嚴重的負面影響,並且已超出商定的專案風險臨界值,就可以採取規避策略。此策略涉及採取集中行動,弱化不確定性對專案整體的負面影響,並將專案拉回臨界值以內。例如,取消專案範圍中的高風險工作,就是一種整個專案層面的規避措施。如果無法將項目拉回臨界值以內,則可能取消項目。這是最極端的風險規避措施,僅適用於威脅的整體等級在當前和未來都不可接受。
開拓
如果整體專案風險有顯著的正面影響,並已超出商定的專案風險臨界值,就可以採用開拓策略。此策略涉及採取集中行動,去獲得不確定性對整體專案的正面影響。例如,在專案範圍中增加高收益的工作,以提高專案對相關方的價值或效益;或者,也可以與關鍵相關方協商修改專案的風險臨界值,以便將機會納入。
轉移或分享
如果整體專案風險的等級很高,組織無法有效加以應對,就可能需要讓第三方代表組織對風險進行管理。若整體專案風險是負面的,就需要採取轉移策略,這可能涉及支付風險費用;如果整體專案風險高度正面,則由多方分享,以獲得相關效益。整體專案風險的轉移和分享策略包括(但不限於):建立買方和賣方分享整體專案風險的協作式業務結構、成立合資企業或特殊目的公司,或對專案的關鍵工作進行分包。
減輕或提高
本策略涉及變更整體專案風險的級別,以優化實現專案目標的可能性。減輕策略適用於負面的整體專案風險,而提高策略則適用於正面的整體專案風險。減輕或提高策略包括重新規劃專案、改變專案範圍和邊界、調整專案優先順序、改變資源配置、調整交付時間等。
接受
即使整體專案風險已超出商定的臨界值,如果無法針對整體專案風險採取主動的應對策略,組織可能選擇繼續以目前的定義推動專案進度。接受策略又分為主動或被動方式。最常見的主動接受策略是為專案建立整體應急儲備,包括預留時間、資金或資源,以便在專案風險超出臨界值時使用;被動接受策略則不會主動採取行動,而只是定期對整體專案風險的級別進行審查,確保其未發生重大變更。
數據分析
備選方案分析
成本效益分析
決策
多標準決策分析
輸出
變更請求
專案管理計畫更新
進度管理計劃
成本管理計劃
品質管理計劃
資源管理計劃
採購管理計劃
範圍基準
進度基準
成本基準
專案文件更新
假設日誌
成本預測
經驗教訓登記冊
專案進度計劃
專案團隊派遣工單
風險登記冊
需要更新風險登記冊,錄選擇和商定的風險應對措施。
風險登記冊的更新可能包括(但不限於)
商定的因應策略
實施所選因應策略所需的具體行動
風險發生的觸發條件、徵兆和預警訊號
實施所選因應策略所需的預算和進度活動
應急計劃,以及啟動該計劃所需的風險觸發條件
彈回計劃,供風險發生且主要應對措施不足以應對時使用
在採取預定應對措施之後仍然存在的殘餘風險,以及被有意接受的風險
由實施風險因應措施而直接導致的次生風險。
風險報告
更新風險報告,記錄針對當前整體專案風險敞口和高優先級風險的經商定的應對措施,以及實施這些措施之後的預期變化。
實施風險應對
實施風險因應是執行商定的風險因應計畫的過程。本過程的主要作用是,確保按計畫執行商定的風險因應措施,來管理整體專案風險敞口、最小化單一專案威脅,以及最大化單一專案機會。
ITTO
輸入
專案管理計劃
風險管理計劃
專案文件
經驗教訓登記冊
計畫早期所獲得的與實施風險因應有關的經驗教訓,可用於計畫後期提高本過程的有效性。
風險登記冊
風險登記冊記錄了每項單一風險的協定風險應對措施,以及負責應對的指定責任人。
風險報告
風險報告包括對目前整體專案風險敞口的評估,以及商定的風險應對策略,還會描述重要的單一專案風險及其應對計劃。
組織過程資產
工具與技術
專家判斷
人際關係與團隊技能
影響力
有些風險因應措施可能由直屬專案團隊以外的人員去執行,或由存在其他競爭性需求的人員i去執行。在這種情況下,負責引導風險管理過程的專案經理或人員就需要施展影響力,去鼓勵指定的風險責任人採取所需的行動。
專案管理資訊系統
專案管理資訊系統(PMIS)可能包括進度、資源和成本車飲件,用於確保把商定的風險應對計劃及其相關活動,連同其他專案活動,一併納入整個專案。
輸出
變更請求
專案文件更新
問題日誌
作為實施風險因應過程的一部分,已識別的問題會被記錄到問題日誌中。
經驗教訓登記冊
更新經驗教訓登記冊,記錄實施風險因應時所遇到的挑戰、本可採取的規避方法,以及實施風險因應的有效方式。
專案團隊派遣工單
一旦確定風險因應策略,應為每項與風險應對計畫相關的措施分配必要的資源,包括用於執行商定的措施的具有適當資格和經驗的人員、合理的資金和時間,以及必要的技術手段。
風險登記冊
可能需要更新風險登記冊,反映開展本過程所導致的對單一專案風險的已商定應對措施的任何變更。
風險報告
可能需要風險報告,反映開展本過程所導致的對整體專案風險敞口的已商定應對措施的任何變更。
監督風險
監督風險是在整個專案期間,監督商定的風險應對計劃的實施、追蹤已識別風險、識別和分析新風險,以及評估風險管理有效性的過程。本過程的主要作用是,使專案決策都基於關於整體專案風險敞口和單一專案風險的當前資訊。
為了確保專案團隊和關鍵相關方了解當前的風險敞口級別,應該透過監督風險流程對專案工作進行持續監督,來發現新出現、正變化和過時的單一專案風險。
監督風險過程採用專案執行期間產生的績效訊息,以確定
實施的風險應對是否有效
整體專案風險等級是否已改變
已識別單一專案風險的狀態是否已改變
是否出現新的單一專案風險
風險管理方法是否仍適用
項目假設條件是否仍然成立
風險管理政策和程序是否已遵守
成本或進度應急儲備是否需要修改
專案策略是否仍然有效
ITTO
輸入
專案管理計劃
風險管理計劃
風險管理計畫規定了應如何及何時審查風險,應遵守哪些政策和程序,與本監督過程有關的角色和職責安排,以及報告格式。
專案文件
問題日誌
問題日誌用於檢查未決問題是否已更新,並對風險登記冊進行必要更新。
經驗教訓登記冊
在專案早期獲得的與風險相關的經驗教訓可用於專案後期階段。風險登記冊。
風險登記冊
風險登記冊的主要內容包括;已識別單一專案風險、風險責任人、商定的風險因應策略,以及具體的因應措施。它可能還會提供其他詳細信息,包括用於評估應對計劃有效性的控制措施、風險的症狀和預警信號、殘餘及次生風險,以及低優先級風險觀察清單。
風險報告
風險報告包括對目前整體專案風險敞口的評估,以及商定的風險應對策略,還會描述重要的單一專案風險及其應對計劃和風險責任人。
工作績效數據
工作績效報告
工具與技術
數據分析
技術績效分析
進行技術績效分析,把專案執行期間所取得的技術成果與取得相關技術成果的計畫進行比較。它要求定義關於技術績效的客觀的、量化的測量指標,以便據此比較實際結果與計劃要求。技術績效衡量指標可能包括:重量、處理時間、缺陷數量、儲存容量等。實際結果偏離計畫的程度可以代表威脅或機會的潛在影響。
儲備分析
在整個專案執行期間,可能發生某些單一專案風險,對預算和進度應急儲備產生正面或負面的影響。儲備分析是指在專案的任一時點比較剩餘應急儲備與剩餘風險量,從而確定剩餘儲備是否仍然合理。可以用各種圖形(如燃盡圖)來顯示應急儲備的消耗情況。
審計
風險審計是一種審計類型,可用於評估風險管理過程的有效性。專案經理負責確保依照專案風險管理計畫所規定的頻率進行風險審計。風險審計可以在日常專案審查會上進行,可以在風險審查會上進行,團隊也可以召開專門的風險審計會。在實施審計前,應明確定義風險審計的程序和目標。
會議
適用於本流程的會議包括(但不限於)風險審查會應該定期安排風險審查,以檢查和記錄風險應對在處理整體專案風險和已識別單一專案風險方面的有效性。在風險審查中,還可以識別出新的單一專案風險(包括已商定因應措施所引發的次生風險)重新評估當前風險,關閉已過時風險,討論風險發生所引發的問題,以及總結可用於當前專案後續階段或未來類似專案的經驗教訓。根據風險管理計畫的規定,風險審查可以是定期專案狀態會中的一項議程,或者也可以召開專門的風險審查會。
輸出
工作績效訊息
工作績效資訊是經過比較單一風險的實際發生情況和預計發生情況,所得到的關於專案風險管理執行績效的資訊。它可以說明風險應對規劃和應對實施過程的有效性。
變更請求
執行監督風險流程後,可能會就成本基準和進度基準,或專案管理計畫的其他元件提出變更請求,應該透過實施整體變更控制流程對變更請求進行審查和處理。
變更請求可能包括:建議的糾正與預防措施,以處理當前整體專案風險等級或單一專案風險。
專案管理計畫更新
任何組件
專案文件更新
假設日誌
在監督風險過程中,可能做出新的假設、識別出新的限制因素,或現有假設條件或限制因素可能被重新審查和修改。需要更新假設日誌,記錄這些新資訊。
問題日誌
作為監督風險過程的一部分,已識別的問題會記錄到問題日誌中。
經驗教訓登記冊
更新經驗教訓登記冊,記錄風險審查期間得到的任何與風險相關的經驗教訓,以便用於專案的後期階段或未來專案。
風險登記冊
更新風險登記冊,記錄在監督風險過程中產生的關於單一專案風險的信息,可能包括新增風險、更新已過時風險或已發生風險,以及更新風險應對措施,等等。
風險報告
應該隨著監督風險過程產生新信息,而更新風險報告,反映重要單一專案風險的當前狀態,以及整體專案風險的當前等級。風險報告還可能包括有關的詳細信息,諸如最高優先級單一專案風險、已商定的應對措施和責任人,以及結論與建議。風險報告也可以收錄風險審計所給予的關於風險管理過程有效性的結論。
組織過程資產更新
專案採購管理
概述說明
雖然專案經理不必成為採購管理法規領域的專家,但應對採購流程有足夠了解,以便做出與合約及合約關係相關的明智決策。
通常情況下,專案經理無權簽署對組織有約束力的法律協議,這項工作僅由具備相關職權的人員執行。其書寫形式也應符合地方、所在國或國際法中關於合約簽署的規定。組織規定誰有權代表組織簽署和管理協議。
協議是買賣雙方之間的法律文件,合約是對雙方都有約束力的協議,規定賣方有義務提供有價值的東西,如規定的產品、服務或成果,買方有義務支付貨幣或其他有價值的補償
賣方通常應把相關工作當作一個專案來管理,合約條款和條件成為賣方許多管理過程的關鍵輸入
因應用領域不同,協議可以是合約、服務等級協定(SLA)、諒解備忘錄、協議備忘錄(MOA)或訂購單
規劃採購管理
規劃採購管理是記錄專案採購決策、明確採購方法,及辨識潛在賣方的過程。這個過程的主要作用是,確定是否從項目外部獲取貨物和服務,如果是,則還要確定將在什麼時間、以什麼方式獲取什麼貨物和服務。貨物和服務可從執行組織的其他部門採購,或從外部管道採購。
ITTO
輸入
專案章程
商業文件
商業論證
效益管理計劃
專案管理計劃
範圍管理計劃
範圍管理計畫說明如何在專案的湯匙實施階段管理承包商的工作範圍。
品質管理計劃
品質管理計劃包含專案需要遵循的行業標準與準則。這些標準與準則應寫入招標文件,如建議邀請書,並將最終在合約中引用。這些標準與準則也可用於供應商資格預審,或作為供應商甄選標準的一部分。
資源管理計劃
資源管理計劃包括關於哪些資源需要採購或租賃的信息,以及任何可能影響採購的假設條件或限制因素。
範圍基準
範圍基準包含範圍說明書、WBS和WBS字典。在專案早期,專案範圍可能仍要繼續演進。應該針對專案範圍中已知的工作,編制工作說明書(SOW)和工作大綱(TOR).
專案文件
里程碑清單
重要里程碑清單說明賣方需要在何時交付成果。
專案團隊派遣工單
專案團隊派遣工單包含關於專案團隊技能和能力的信息,以及他們可用於支援採購活動的時間。若專案團隊不具備進行採購活動的能力,則需要外聘人員或對現有人員進行培訓,或二者同時進行。
需求文件
需求文件可能包括
賣方需要滿足的技術要求
具有合約和法律意義的需求,如健康、安全、安保、績效、環境、保險、智慧財產權、同等就業機會、執照、許可證,以及其他非技術要求
需求追蹤矩陣
需求追蹤矩陣將產品需求從其來源連接到能滿足需求的可交付成果。
資源需求
源需求包含關於某些特定需求的信息,例如,可能需要採購的團隊及實體資源。
風險登記冊
風險登記冊列明風險清單,以及風險分析與風險因應規劃的結果。有些風險應透過採購協議轉移給第三方。
相關方登記冊
相關方登記冊提供有關計畫參與者及其計畫利益的詳細信息,包括監管機構、合約簽署人員和法務人員。
事業環境因素
組織過程資產
組織所使用的各種合約協議類型也會影響規劃採購管理理過程中的決策。
能夠影響規劃採購管理流程的組織流程資產包括(但不限於)
預先核准的賣方清單
經過適當審查的賣方清單可以簡化招標所需的步驟,並縮短賣方甄選過程的時間。
正式的採購政策、程序和指南
大多數組織都有正式的採購政策和採購機構。如果沒有,專案團隊就應該配備相關的資源和專業技能,來實施採購活動。
合約類型
所有法律合約關係通常可分為總價和成本補償兩大類。此外,還有第三種常用的混合類型,即工料合約。下文將分別討論上述幾類較常用的合約類型。但在實務中,單次採購合併使用兩種或更多合約類型的情況也並不罕見。
總價合約
此類合約為既定產品、服務或成果的採購設定一個總價。這種合約應在已明確定義需求,且不會出現重大範圍變更的情況下使用
總價合約的類型包括
固定總價(FFP)
FFP是最常用的合約類型。大多數買方都喜歡這種合同,因為貨物採購的價格在一開始就已確定,並且不允許改變(除非工作範圍發生變更)
總價加激勵費用(FPIF)
這種總價合約為買方和賣方提供了一定的靈活性,允許一定的績效偏離,並對實現既定目標給予相關的財務獎勵(通常取決於賣方的成本、進度或技術績效)。 FPIF合約中會設定價格上限,高於此價格上限的全部成本將由賣方承擔。
總價加經濟價格調整(FPEPA)
此合約適用於兩種情況:賣方履約期將跨越幾年時間或將以不同貨幣支付價款。它是總價合約的一種類型,但合約中包含了特殊條款,允許根據條件變化,如通貨膨脹、某些特殊商品的成本增加(或降低),以事先確定的方式對合約價格進行最終調整。
成本補償合約
此類合約向賣方支付為完成工作而發生的全部合法實際成本(可報銷成本),外加一筆費用作為賣方的利潤。這種合約適用於:工作範圍預計會在合約執行期間發生重大變更。
成本補償合約可分為:
成本加固定費用(CPFF)
為賣方報銷履行合約工作所發生的一切可列支成本,並向賣方支付一筆固定費用。此費用以專案初始估算成本的某一百分比計列。除非專案範圍發生變更,否則費用金額維持不變。
成本加激勵費用(CPIF)
為賣方報銷履行合約工作所發生的一切可列支成本,並在賣方達到合約規定的績效目標時,向賣方支付預先確定的激勵費用。在CPIF合約中,如果最終成本低於或高於原始估算成本,則買方和賣方需要根據事先商定的成本分攤比例來分享節約部分或分擔超支部分。例如,基於賣方的實際成本,以80/20的比例分擔(分享)超過(低於)目標成本的部分。
成本加獎勵費用(CPAF)
為賣方報銷一切合法成本,但只有在賣方滿足合約規定的、某些籠統主觀的績效批准的情況下,才向賣方支付大部分費用。獎勵費用完全由買方根據自己對賣方績效的主觀判斷來決定,通常不允許申訴。
工料合約(T&M)
工料合約(又稱時間和手段合約),是兼具成本補償合約和總價合約特徵的混合合約。這種合約往往適用於:在無法快速編制出準確的工作說明書的情況下擴充人員、聘用專家或尋求外部支援。
工具與技術
專家判斷
數據收集
市場研究
市場調查包括考察產業狀況和具體賣方的能力。採購團隊可運用從會議、線上評論和各種其他管道得到的信息,來了解市場狀況。採購團隊也可以調整具體的採購目標,以便在平衡與有能力提供所需材料或服務的賣方的範圍有關的風險的同時,利用成熟技術。
數據分析
自製或外購分析
自製或外購分析用於確定某項工作或可交付成果最好由專案團隊自行完成,還是應該從外部採購。制定自製或外購決策時應考慮的因素包括;組織當前的資源配置及其技能和能力,對專業技術的需求,不願承擔永久僱用的義務,以及對獨特技術專長的需求;還要評估與每個自製或外購決策相關的風險。
在自製或外購分析中,可以使用回收期、投資報酬率(ROI)、內部報酬率(RR)、現金流量折現、淨現值(NPV)、收益成本(BCA)或其他分析技術,來決定某種貨物或服務是應該在專案內部自製,還是從外部購買。
供方選擇分析
在確定選擇方法之前,有必要審查專案競爭性需求的優先順序。由於競爭性選擇方法可能要求賣方在事前投入大量時間和資源,因此,應該在採購文件中寫明評估方法,讓投標者了解將會如何評估。
常用的選擇方法包括
最低成本
最低成本法適用於標準化或常規採購。此類採購有成熟的實務與標準,有具體明確的預期成果,可以用不同的成本來取得。
僅憑資質
僅憑資質的選擇方法適用於採購價值相對較小,不值得花時間和成本進行完整選擇過程的情況。買方會確定短名單,然後根據可信度、相關資格、經驗、專業知識、專長領域和參考資料選擇最佳的投標者。
基於品質或技術方案得分
邀請一些公司提交建議書,同時列明技術和成本詳情;如果技術建議書可以接受,再邀請它們進行合約談判。採用此方法,會先對技術建議書進行評估,並檢視技術方案的品質。如果經過談判,證明它們的財務建議書是可接受的,那麼就會選擇技術建議書得分最高的賣方。
基於品質和成本
在基於品質和成本的方法中,成本也是用於選擇賣方的一個考慮因素。一般而言,如果專案的風險和(或)不確定性較高,相對於成本而言,品質應該是關鍵因素。
獨有來源
買方要求特定賣方準備技術和財務建議書,然後針對建議書進行談判。由於沒有競爭,因此僅在有適當理由時才可採用此方法,而且應視為特殊情況。
固定預算
固定預算法要求在建議邀請書中向受邀的賣方揭露可用預算,然後在此預算內選擇技術建議書得分最高的賣方。因為有成本限制,所以賣方會在建議書中調整工作的範圍和質量,以適應該預算。買方應該確保固定預算與工作說明書相符,且賣方能夠在該預算內完成相關任務。此方法僅適用於工作說明書定義精確、預期不會發生變更,且預算固定且不得超出的情況。
會議
輸出
採購管理計劃
採購管理計畫包含採購過程中要進行的各種活動。它應該記錄是否要進行國際競爭性招標、國內競爭性招標、當地招標等。如果專案由外部資助,資金的來源和可用性應符合採購管理計畫和專案進度計畫的規定。
採購管理計劃可包括以下內容:
如何協調採購與專案的其他工作,例如,專案進度計畫制定與控制
進行重要採購活動的時間表
用於管理合約的採購測量指標
與採購有關的相關方角色和職責如果執行組織有採購部,專案團隊擁有的職權和受到的限制
可能影響採購工作的限制因素和假設條件
司法管轄權和付款貨幣
是否需要編制獨立估算,以及是否應作為評價標準
風險管理事項,包括履約保函或保險合約的要求,以減輕某些專案風險
擬使用的預審合格的賣方(如果有)
根據每個項目的需要,採購管理計劃可以是正式或非正式的,非常詳細或高度概括的。
採購策略
一旦完成自製或外購分析,並決定從專案外部管道採購,就應制定一套採購策略。採購策略中應該規定專案交付方法、具有法律約束力的協議類型,以及如何在採購階段推動採購進度。
交付方法
對專業服務項目和建築施工項目,應採用不同的交付方法。
專業服務項目的交付方法包括:買方或服務提供者不得分包、買方或服務提供者可以分包、買方和服務提供者設立合資企業、買方或服務提供者僅充當代表。
而工業或商業施工專案的交付方法包括(但不限於):交鑰匙式、設計-建造(DB)、設計-招標-建造(DBB)、設計-建造-營運(DBO)、建造-擁有-運營-轉讓(BOOT),及其他。
合約支付類型
合約支付類型與專案交付方法無關,需要與採購組織的內部財務系統相協調。它們包括(但不限於)以下合約類型及其變種:總價、固定總價、成本加獎勵費用、成本加激勵費用、工料、目標成本及其他。
採購階段
採購策略也可以包括與採購階段有關的信息,這種信息可能包括:採購工作的順序安排或階段劃分,每個階段的描述,以及每個階段的具體目標等。
招標文件
招標文件用於向潛在賣方徵求建議書。如果主要依據價格來選擇賣方(如購買商業或標準產品時),通常就使用標書、投標或報價等術語;如果其他考慮因素(如技術能力或技術方法)至關重要,則通常使用建議書之類的術語。具體使用的採購術語也可能因行業或採購地點而異。
取決於所需的貨物或服務,招標文件可以是資訊邀請書、報價邀請書、建議邀請書,或其他適當的採購文件。
使用不同文件的條件如下
資訊邀請書(RF)
如果需要賣方提供關於擬採購貨物和服務的更多信息,就使用資訊邀請書。隨後一般也會使用報價邀請書或建議邀請書。
報價邀請書(RFQ)
如果需要供應商提供關於將如何滿足需求和(或)將需要多少成本的更多信息,就使用報價邀請書。
建議邀請書(RFP)
如果專案中出現問題且解決方法難以確定,就使用建議邀請書。這是最正式的「邀請書」文件,需要遵守與內容、時間表,以及賣方應答有關的嚴格的採購規則。
買方擬定的採購文件不僅應便於潛在賣方做出準確、完整的應答,還要便於買方對賣方應答進行評價。採購文件會包括規定的應答格式、相關的採購工作說明書,以及所需的合約條款。
採購工作說明書
依據專案範圍基準,為每次採購編制工作說明書(SOW),僅對將要包含在相關合約中的那一部分項目範圍進行定義。工作說明書會充分詳細地描述擬採購的產品、服務或成果,以便潛在賣方確定是否有能力提供此類產品、服務或成果。根據採購品的性質、買方的需求,或擬採用的合約形式,工作說明書的詳細程度會有較大不同。工作說明書的內容包括:規格、所需數量、品質水準、績效數據、履約期間、工作地點和其他要求。
採購工作說明書應力求清晰、完整、簡練。它需要說明所需的附加服務,例如,報告績效,或對採購品的後續營運支援。在採購過程中,應根據需要對工作說明書進行修訂,直到它成為所簽協議的一部分。
對於服務採購,可能會用「工作大綱(TOR)」這個術語。
與採購工作說明書類似,工作大綱通常包括以下內容
承包商需要執行的任務,以及所需的協調工作
承包商必須達到的適用標準
需要提交批准的數據
由買方提供給承包商的,將用於合約履行的全部資料和服務的詳細清單(若適用)
關於初始成果提交和審查(或審批)的進度計劃
供方選擇標準
在確定評估標準時,買方要努力確保選出的建議書將提供最佳品質的所需服務。
供方選擇標準可包括(但不限於)
能力和潛能
產品成本及生命週期成本等
自製或外購決策
透過自製或外購分析,做出某項特定工作最好由項頁目團隊自行完成,還是需要從外部管道購買的決策。
獨立成本估算
對於大型的採購,採購組織可以自行準備獨立估算,或聘用外部專業估算師做出成本估算,並將其作為評估賣方報價的對照基準。如果二者之間存在明用顯差異,則可能表示採購工作說明書有缺陷或模糊,或潛在賣方誤解了或未能完全回應採購工作說明書。
變更請求
專案文件更新
經驗教訓登記冊
里程碑清單
需求文件
需求追蹤矩陣
風險登記冊
相關方登記冊
組織過程資產更新
實施採購
實施採購是取得賣方應答、選擇賣方並授予合約的過程。本過程的主要作用是,選定合格賣方並簽署關於貨物或服務交付的法律協議。本過程的最後成果是簽訂的協議,包括正式合約。
ITTO
輸入
專案管理計劃
範圍管理計劃
需求管理計劃
溝通管理計劃
風險管理計劃
採購管理計劃
配置管理計劃
成本基準
專案文件
經驗教訓登記冊
專案進度計劃
需求文件
風險登記冊
相關方登記冊
採購文件
採購文件是用於達成法律協議的各種書面文件,其中可能包括當前專案啟動之前的較舊文件。
採購文件可包括
招標文件
招標文件包括發給賣方的資訊邀請書、建議邀請書、報價邀請書,或其他文件,以便賣方編制應答文件。
採購工作說明書
採購工作說明書(SOW)清楚地向賣方說明目標、需求及成果,以便賣方據此做出量化回應。
獨立成本估算
獨立成本估算可由內部或外部人員編制,用於評估投標者提交的建議書的合理性。
供方選擇標準
此類標準描述如何評估投標人的建議書,包括評估標準和權重。為了減輕風險,買方可能決定與多個賣方簽署協議,以便在單一賣方出問題並影響整體專案時,降低由此導致的損失。
賣方建議書
賣方為回應採購文件包而編制的建議書,其中包含的基本資訊將被評估團隊用於選定一個或多個投標人(賣方)。如果賣方將提交價格建議書,最好要求他們將價格建議書與技術建議分開。評估團隊會根據供者選擇標準審查每份建議書,然後選出最能滿足採購組織需求的賣方。
事業環境因素
組織過程資產
工具與技術
專家判斷
廣告
廣告是就產品、服務或成果與使用者或潛在使用者進行的溝通。在大眾出版物(如指定的報紙)或專門行業出版物上刊登廣告,往往可以擴充現有的潛在賣方名單單。大多數政府機構都要求公開發布採購廣告,或在網路上公佈擬簽署的政府合約的資訊。
投標人會議
投標人會議(又稱承包商會議、供應商會議或投標前會議)是在賣方提交建議書之前,在買方和潛在賣方之間召開的會議,其目的是確保所有潛在投標人對採購要求都有清楚且一致的理解,並確保沒有任何投標者會得到特別優待。
數據分析
建議書評價
對建議書進行評估,確定它們是否對包含在招標文件包中的招標文件、採購工作說明書、供方選擇標準和其他文件,都做出了完整且充分的回應。
人際關係與團隊技能
談判
談判是為達成協議而進行的討論。採購談判是指在合約簽署之前,對合約的結構、各方的權利和義務,以及其他條款加以澄清,以便雙方達成共識。最終的文件措詞應該反映雙方達成的全部一致意見。談判以簽署買方和賣方均可執行的合約文件或其他正式協議而結束。
談判應由採購團隊中擁有合約簽署職權的成員主導。專案經理和專案管理團隊的其他成員可以參與談判並提供必要的協助。
輸出
選定的賣方
選定的賣方是在建議書評估或投標評估中被判斷為最有競爭力的投標者。對於較複雜、高價值和高風險的採購,在授予合約前,要把選定的賣方報給組織高高階主管審批。
協定
合約是對雙方都有約束力的協議。它強制賣方提供規定的產品、服務或成果,強制買方向賣方支付相應的報酬。
合約建立了受法律保護的買賣雙方的關係協議文本的主要內容會有所不同,可包括(但不限於)
採購工作說明書或主要的可交付成果
進度計畫、里程碑,或進度計畫中規定的日期
績效報告
定價和支付條款
檢查、品質和驗收標準
擔保和後續產品支持
激勵和懲罰
保險和履約保函
下屬分包商核准
一般條款和條件
變更請求處理
終止條款和替代爭議解決方法
變更請求
專案管理計畫更新
需求管理計劃
品質管理計劃
溝通管理計劃
風險管理計劃
採購管理計劃
範圍基準
進度基準
成本基準
專案文件更新
經驗教訓登記冊
需求文件
需求追蹤矩陣
資源日曆
風險登記冊
相關方登記冊
組織過程資產更新
控制採購
控制採購是管理採購關係,監督合約績效,實施必要的變更和糾偏,以及關閉合約的過程。本過程的主要作用是,確保買賣雙方履行法律協議,滿足專案需求。
買方和賣方都出於相似的目的來管理採購合同,每方都必須確保雙方履行合同義務,確保各自的合法權利得到保護。合約關係的法律性質,要求專案管理團隊必須了解在控制採購期間所採取的任何行動的法律後果。對於有多個供應商的較大項目,合約管理的一個重要面向是管理各個供應商之間的溝通。
鑑於其法律意義,許多組織都將合約管理視為獨立於專案的一種組織職能。雖然採購管理員可以是專案團隊成員,但通常也會向另一部門的經理報告。
在控制採購過程中,需要進行財務管理工作,包括監督向賣方付款。這是要確保合約中的支付條款得到遵循,確保依合約規定,把付款與賣方的工作進度連結起來。需要重點關注的一點是,確保向賣方的付款與賣方實際已經完成的工作量之間有密切的關係。如果合約規定了基於專案產出及可交付成果來付款,而不是基於專案輸入(如工時),那麼就可以更有效地進行採購控制。
在合約收尾前,若雙方達成共識,可以根據協議中的變更控制條款,隨時對協議進行修改。通常要書面記錄協議的修改。
ITTO
輸入
專案管理計劃
需求管理計劃
風險管理計劃
採購管理計劃
變更管理計劃
進度基準
專案文件
假設日誌
經驗教訓登記冊
里程碑清單
品質報告
需求文件
需求追蹤矩陣
風險登記冊
相關方登記冊
協定
協議是雙方之間達成的諒解,包括對各方義務的一致理解。對照相關協議,確認其中的條款和條件的遵守。
採購文件
採購文件包含用於管理採購過程的完整支援性記錄,包括工作說明書、付款資訊、承包商工作績效資訊、計畫、圖面和其他往來函件。
批准的變更請求
核准的變更請求可能包括合約條款和條件的修改,例如,修改採購工作說明書、定價,以及產品、服務或成果的描述。與採購相關的任何變更,在透過控制採購程序實施之前,都需要以書面形式正式記錄,並取得正式批准。在複雜的專案和專案集中,變更請求可能由參與專案的賣方提出,並對參與專案的其他賣方造成影響。專案團隊應該有能力去識別、溝通和解決會影響多個賣方的工作的變更。
工作績效數據
工作績效數據包含與專案狀態相關的賣方數據,例如,技術績效,已啟動、進展中或已結束的活動,已產生或投入的成本。工作績效數據也可能包括已向賣方付款的情況。
事業環境因素
組織過程資產
工具與技術
專家判斷
索賠管理
如果買賣雙方無法就變更補償達成一致意見,或對變更是否發生存在分歧,那麼被要求的變更就成為有爭議的變更或潛在的推定變更。此類有爭議的變更稱為索賠。如果無法妥善解決,它們會成為爭議並最終引發申訴。在整個合約生命週期中,通常會按照合約條款對索賠進行記錄、處理、監督和管理。如果合約雙方無法自行解決索賠問題,則可能必須依照合約中規定的程序,以替代爭議解決方法(ADR)去處理。談判是解決所有索賠和爭議的首選方法。
數據分析
績效審查
對照協議,對品質、資源、進度和成本績效進行測量、比較和分析,以審查合約工作的績效。其中包括確定工作包提前或落後於進度計劃、超出或低於預算,以及是否有資源或品質問題。
掙值分析
掙值分析(EVA)計算進度和成本偏差,以及進度和成本績效指數,以確定偏離目標的程度。
趨勢分析
趨勢分析可用於編制關於成本績效的完工估算(EAC),以確定績效是正在改善還是惡化。關於完工估算方法的詳細信息
檢查
檢查是指對承包商正在執行的工作進行結構化審查,可能涉及對可交付成果的簡單審查,或對工作本身的實地審查。在施工、工程和基礎設施建設項目中,檢查包括買方和承包商聯合巡檢現場,以確保雙方對正在進行的工作有共同的認識。
審計
審計是對採購過程的結構化審查。採購合約中應明確規定與審計有關的權利和義務。買方的專案經理和賣方的專案經理都應該專注於審計結果,以便對專案進行必要調整。
採購審計是指對從規劃採購管理過程到控制採購過程的所有採購過程進行結構化審查。其目的是找出合約準備或管理方面的成功經驗與失敗教訓,供本專案其他採購合約或執行組織內其他專案的採購合約借鏡。
輸出
結束的採購
採購關閉,買方通常透過其授權的採購管理員,向賣方發出合約已經完成的正式書面通知。關於正式關閉採購的要求,通常已在合約條款和條件中規定,並包括在採購管理計劃中。一般而言,這些要求包括:已按時按質依技術要求交付全部可交付成果,沒有未決索賠或發票,全部最終款項已付清。專案管理團隊應該在關閉採購之前批准所有的可交付成果。
工作績效訊息
工作績效資訊是賣方正在履行的工作的績效情況,包括與合約要求相比較的可交付成果完成情況和技術績效達成情況,以及與SOW預算相比較的已完工作的成本產生和認可情況。
採購文檔更新
採購文件更新可包括用於支援合約的全部進度計劃、已提出但未批准的合約變更,以及已批准的變更請求。採購文件還包括由賣方編制的技術文件,以及其他工作績效信息,例如,可交付成果的狀況、賣方績效報告和擔保、財務文件(包括發票和支付記錄),以及與合約相關的檢查結果。
變更請求
專案管理計畫更新
風險管理計劃
採購管理計劃
進度基準
成本基準
專案文件更新
經驗教訓登記冊
資源需求
需求追蹤矩陣
風險登記冊
相關方登記冊
組織過程資產更新
作為控制採購過程的結果,需要更新的組織流程資產包括(但不限於)
支付計劃和請求
所有支付都應按合約條款和條件進行。
賣方績效評估文件
賣方績效評估文件由買方準備,用於記錄賣方繼續執行當前合約工作的能力,說明是否允許賣方承接未來的項目,或對賣方現在的項目執行工作或過去的執行工作進行評級。
預審合格賣方清單更新
預審合格賣方清單是先前已經通過資格審查(獲得批准)的潛在賣方的清單。因為賣方可能因績效不佳而被取消資格並從清單中刪除,所以應該根據控制採購流程的結果來更新這個清單。
經驗教訓知識庫
經驗教訓應該歸檔到經驗教訓知識庫中,以改善未來專案的採購工作。在合約執行終了時,應把採購的實際成果與原始採購管理計畫中的預期成果進行比較。應該在經驗教訓中說明專案目標是否達成;若未達成,則說明原因。
採購檔案
應該準備好帶有索引的全套合約文檔,包括已關閉的合同,並將其納入最終的專案檔案。
專案相關方管理
概述說明
相關方滿意度應作為專案目標加以識別和管理。有效引導相淚關方參與的關鍵是重視與所有相關方保持持續溝通(包括團隊成員),以理解他們的需求和期望處理所發生的問題、管理利益衝突,並促進相關方參與專案決策和活動。
在敏捷或適應環境中需要考慮的因素
高度變化的項目更需要專案相關方的有效互動和參與。為了進行及時且有效率的討論及決策,適應型團隊會直接與相關方互動,而不是透過層層的管理層級。客戶、使用者和開發人員在動態的共創過程中交換訊息,通常能實現更高的相關方參與和滿意程度。在整個專案期間保持與相關方社群的互動,有利於降低風險、建立信任和儘早做出專案調整,從而節省成本,提高專案成功的可能性。
為加快組織內部和組織之間的資訊分享,敏捷型方法提倡高度透明。例如,邀請所有相關方參與專案會議和審查,或將專案工件發佈到公共空間,其目的在於讓各方之間的不一致和依賴關係,或與不斷變化的專案有關的其他問題,都盡快浮現。
識別相關方
識別相關方是定期識別專案相關方,分析和記錄他們的利益、參與、相互依賴性、影響力和對專案成功的潛在影響的過程。本過程的主要作用是,使專案團隊能夠建立對每個相關方或相關方群體的適度關注。
本過程通常在編制和批准專案章程之前或同時首次進行。本過程需在必要時重複進行,至少應在每個階段開始時,以及專案或組織出現重大變更時重複進行。每次重複進行本過程,應透過查閱專案管理計畫組件及專案文件,來識別相關的專案相關方。
ITTO
輸入
專案章程
專案章程會列出關鍵相關方清單,也可能包含與相關方職責相關的資訊。
商業文件
商業論證
商業論證確定專案目標,以及受專案影響的相關方的最初清單。
效益管理計劃
收益管理計劃描述如何實現商業論證中所述收益。它可能指出將從專案成果交付中獲益並因此被視為相關方的個人及群體。
專案管理計劃
溝通管理計劃
相關方參與計劃
專案文件
變更日誌
問題日誌
需求文件
協定
協議的各方都是專案相關方,還可涉及其他相關方。
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
問卷調查
問捲和調查可以包括一對一調查、焦點小組討論,或其他大規模資訊收集技術。
腦力激盪
腦力激盪
一種通用的資料收集和創意技術,用於向小組徵求意見,如團隊成員或主題專家。
頭腦寫作
腦力激盪的改良形式,讓個人參與者有時間在小組創意討論開始前單獨思考問題。
只需每個人把想法寫下來,然後以匿名的方式進行傳遞,並添加修改。
適合團隊中內向性格的成員多。
數據分析
相關方分析
相關方分析會產生相關方清單和關於相關方的各種信息,例如,在組織內的位置、在專案中的角色、與專案的利害關係、期望、態度(對專案的支持程度),以及對項目資訊的興趣。
相關方的利害關係可包括(但不限於)以下各條的組合
興趣
個人或群體會受與專案相關的決策或成果的影響。
權利(合法權利或道德權利)
國家的法律框架可能已就相關方的合法權利做出規定,如職業健康和安全。道德權利可能涉及保護歷史遺跡或環境的可持續性。
所有權
人員或群體對資產或財產擁有的法定所有權。
知識
專業知識有助於更有效地達成專案目標和組織成果,或有助於了解組織的權力結構,從而有益於專案。
貢獻
提供資金或其他資源,包括人力資源,或以無形方式為專案提供支持,例如,宣傳專案目標,或在專案與組織權力結構及政治之間扮演緩衝角色。
補充:相關方分析產出
相關方清單
相關方資訊
組織位置
專案角色
利害關係
興趣
受到影響
專案決策
專案成果
權利
合法權利
道德權利
所有權
知識
貢獻
期望
態度
對資訊興趣
文件分析
評估現有專案文件及以往專案的經驗教訓,以識別相關方和其他支持性資訊。
數據表現
相關方映射分析/表現
相關方映射分析和表現是一種利用不同方法對相關方進行分類的方法。對相關方進行分類有助於團隊與已識別的專案相關方建立關係。
常見的分類方法包括
權力利益方格、權力影響方格,或作用影響方格
基於相關方的職權等級(權力)、對專案成果的關心程度(利益)、對專案成果的影響能力(影響),或改變專案計畫或執行的能力,每一種方格都可用於對相關方進行分類。對於小型項目、相關方與項目的關係很簡單的項目,或相關方之間的關係很簡單的項目,這些分類模型非常實用。
相關方立方體
這是上述方格模型的改良形式。本立方體把上述方格中的要素組合成三維模型,專案經理和團隊可據此分析相關方並引導相關方參與專案。作為一個多維模型,它將相關方視為一個多維實體,更好地加以分析,從而有助於溝通策略的發展。
凸顯模型
透過評估相關方的權力(職權層級或對專案成果的影響能力)、緊迫性(因時間約束或相關方對專案成果有重大利益訴求而導致需立即加以關注)和合法性(參與的適當性)將相關方進行分類。在凸顯模型中,也可以用鄰近性取代合法性,以便檢視相關方參與專案工作的程度。這種凸顯模型適用於複雜的相關方大型社區,或在相關方社區內部存在複雜的關係網絡。凸顯模型可用於確定已識別相關方的相對重要性。
分類標準
權力(職權層級或對專案成果的影響能力)
緊迫性(因時間約束或相關方對計畫成果有重大利益訴求而導致需立即加以關注)
合法性(參與的適當性)
適用條件
複雜的相關方大型社區
相關方社群內部存在著複雜的關係網絡
主要作用
確定已識別相關方的相對重要性
因應措施
A)Core(確定型):這些是關鍵的項目相關方。身為一個專案經理,你需要集中關注這些相關方。
B)Dominant(支配型):這樣的專案相關方有權力和合法性,但沒有緊迫感。你應該關注他們的期望,但總是沒有太多的緊迫性。
C)Dependent(依賴型):根據顯著性模型,這些項目相關方對專案沒有真正的權力。然而,他們需要被管理,因為他們可以輕鬆選擇與其他專案相關方結盟,從而影響您的專案。
D)Dangerous(危險型):適當命名的分類,這些利害關係人有權力和緊迫性,但沒有合法性。想像一下,一個非常資深的人試圖將她的觀點強加給你的專案結果,而不是真正參與其中!專案經理需要使這些幹係人適當地參與或滿意。
E)Latent(潛伏型):可能是計畫幹係人的最佳類別。這些幹係人只有在專案出現嚴重問題時才會進入專案。與他們過度溝通微觀層面的細節也不是一件好事。
F)Demanding(苛求型):在突出模型中,這樣的利害關係人似乎總是認為他們的工作需要你的立即關注。如果您在這些涉眾身上花費了太多的時間和精力,那麼您實際上不會獲得太多的專案里程。還有其他更重要的人要合作。
G)Discretionary(自住型):專案利害關係人的另一個很好的分類。定期更新他們的狀態,他們會很高興的。
H)Non-stakeholders(非相關方):這些人不是專案的利害關係人。在這樣的人身上投入時間和精力無論如何都不會幫助你塑造專案的結果。
影響方向
可以根據相關方對專案工作或專案團隊本身的影響方向,對相關方進行分類。
可以把相關方分類為
向上(執行組織或客戶組織、發起人和指導委員會的高階主管)
向下(臨時貢獻知識或技能的團隊或專家)
向外(專案團隊外的相關方群體及其代表,如供應商、政府部門、公眾、最終使用者和監管部門)
橫向(專案經理的同級人員,如其他專案經理或中階管理人員,他們與專案經理競爭稀缺專案資源或合作分享資源或資訊)
優先排序
如果專案有大量相關方、相關方社群的成員頻繁變化,相關方和專案團隊之間或相關方社群內部的關係複雜,可能有必要對相關方進行優先排序。
會議
輸出
相關方登記冊
變更請求
專案管理計畫更新
需求管理計劃
溝通管理計劃
風險管理計劃
相關方參與計劃
專案文件更新
假設日誌
問題日誌
風險登記冊
規劃相關方參與
規劃相關方參與是根據相關方的需求、期望、利益和對專案的潛在影響,制定專案相關方參與專案的方法的過程。此過程的主要角色是,提供與相關方進行有效互動的可行計劃。
ITTO
輸入
專案章程
專案管理計劃
資源管理計劃
溝通管理計劃
風險管理計劃
專案文件
假設日誌
假設日誌中關於假設條件和限制因素的信息,可能與特定相關方相關聯。
變更日誌
變更日誌記錄了原始專案範圍的變更。變更通常與具體相關方相關聯,因為相關方可能是:變更請求的提出者,變更請求的審批者,或受變更實施影響者。
問題日誌
為了管理和解決問題日誌中的問題,需要與受影響的相關方進行額外溝通。
專案進度計劃
進度計畫中的活動可能需要與具體相關方相關聯,即把特定相關方指定為活動責任人或執行者。
風險登記冊
風險登記冊包含項目的已識別風險,它通常會把這些風險與具體相關方相關聯,即把特定相關方指定為風險責任人或受風險影響者。
相關方登記冊
相關方登記冊提供項目相關方的清單,以及分類情況和其他資訊。
協定
事業環境因素
組織過程資產
工具與技術
專家判斷
數據收集
標竿對照
數據分析
假設條件與限制分析
可能需要分析目前的假設條件和限制因素,以合理剪裁相關方參與策略。
根本原因分析
進行根本原因分析,識別是什麼根本s原因導致了相關方對專案的某種支持水平,以便選擇適當策略來改進其參與水平。
決策
優先排序/分級
應該對相關方需求以及相關方本身進行優先排序或分級。具有最大利益和最高影響的相關方,通常應該排在優先清單的最前面。
數據表現
心智圖
心智圖用於對相關方資訊、相互關係以及他們與組織的關係進行視覺化整理。
相關方參與度評估矩陣
相關方參與度評估矩陣。相關方參與度評估矩陣用於將相關方目前參與程度與期望參與程度進行比較。對相關方參與程度進行分類的方式之一。
相關方參與程度可分為如下
不了解型
不知道項目及其潛在影響。
抵制型
知道專案及其潛在影響,但抵制專案工作或成果可能引發的任何變更。此類相關方不會支援專案工作或專案成果。
中立型
了解項目,但既不支持,也不反對。
支持型
了解專案及其潛在影響,並將支持專案工作及其成果。
領導型
了解專案及其潛在影響,並積極參與以確保專案成功。
在圖中,C代表每個相關方的當前參與水平,而D是專案團隊評估出來的、為確保專案成功所必不可少的參與水平(期望的)。應根據每個相關方的當前與期望參與程度的差距,進行必要的溝通,並有效引導相關方參與專案。彌合當前與期望參與程度的差距是監督相關方參與中的一項基本工作。
會議
輸出
相關方參與計劃
相關方參與計劃是專案管理計劃的組成部分。它確定用於促進相關方有效參與決策和執行的策略和行動。基於專案的需要和相關方的期望,相關方參與計劃可以是正式或非正式的,非常詳細或高度概括的。
相關方參與計劃可包括(但不限於)調動個人或相關方參與的特定策略或方法。
利害關係人管理計劃
利害關係人管理計畫是專案管理計畫的組成部分,為有效調動利害關係人參與而規定所需的管理策略。根據專案的需要,利害關係人管理計畫可以是正式或非正式的,非常詳細或高度概括的。
除了利害關係人登記冊中的資料,利害關係人管理計畫通常還包括
關鍵幹係人的所需參與程度和當前參與程度
利害關係人變更的範圍和影響
幹係人之間的相互關係與潛在交叉
專案現階段的利害關係人溝通需求
需要分發給幹係人的訊息,包括語言、格式、內容和詳細程度
分發相關資訊的理由,以及可能對利害關係人參與所產生的影響
向幹係人分發所需資訊的時限和頻率
隨著專案的進展,更新和優化利害關係人管理計劃的方法
專案經理應該意識到利害關係人管理計畫的敏感性,並採取適當的預防措施。例如,有關那些抵制項目的干係人的信息,可能具有潛在的破壞作用,因此對於這類信息的發布必須特別謹慎。更新幹係人管理計畫時,應審查所依據的假設條件的有效性,以確保該計畫的準確性和相關性。
管理相關方參與
管理相關方參與是與相關方進行溝通和協作以滿足其需求與期望、處理問題,並促進相關方合理參與的過程。這個過程的主要作用是,讓專案經理提高相關方的支持,並盡可能降低相關方的抵制。
在管理相關方參與過程中,需要進行多項活動
在適當的專案階段引導相關方參與,以便獲取、確認或維持他們對專案成功的持續承諾
透過談判和溝通管理相關方期望
處理與相關方管理相關的任何風險或潛在關注點,預測相關方可能在未來引發的問題
澄清和解決已識別的問題
管理相關方參與有助於確保相關方明確了解專案目的、目標、效益和風險,以及他們的貢獻將如何促進專案成功。
ITTO
輸入
專案管理計劃
溝通管理計劃
溝通管理計劃描述與相關方溝通的方法、形式和技術。
風險管理計劃
風險管理計劃描述了風險類別、風險偏好和報告格式。這些內容都可用於管理相關方參與。
相關方參與計劃
相關方參與計畫為管理相關方期望提供指導和資訊。
變更管理計劃
變更管理計劃描述了提交、評估和執行專案變更的過程。
專案文件
變更日誌
變更日誌會記錄變更要求及其狀態,並將其傳遞給適當的相關方。
問題日誌
問題日誌會記錄專案或相關方的關注點,以及關於處理問題的行動方案。
經驗教訓登記冊
在專案早期取得的與管理相關方參與相關的經驗教訓,可用於專案後期階段,以提高此流程的效率和效果。
相關方登記冊
相關方登記冊提供專案相關方清單,以及執行相關方參與計畫所需的任何資訊。
事業環境因素
組織過程資產
工具與技術
專家判斷
溝通技能
回饋
在進行管理相關方參與過程時,應根據溝通管理計劃,針對每個相關方採取相應的溝通方法。專案管理團隊應該使用回饋機制,來了解相關方對各種專案管理活動和關鍵決策的反應。
人際關係與團隊技能
衝突管理
專案經理應確保及時解決衝突。
文化意識
文化意識有助於專案經理和團隊透過考慮文化差異和相關方需求,來實現有效溝通。
談判
談判用於獲得支持或達成關於支持專案工作或成果的協議,並解決團隊內部或團隊與其他相關方之間的衝突。
觀察/交談
透過觀察和交談,隨時了解專案團隊成員和其他相關方的工作和態度。
政治意識
透過了解計畫內外的權力關係,建立政治意識。
基本規則
根據團隊章程中定義的基本規則,來明確專案團隊成員和其他相關方應該採取什麼行為去引導相關方參與。
會議
會議用於討論和處理任何與相關方參與有關的問題或關注點。
在本過程中需要召開的會議類型包括(但不限於)
決策
問題解決
經驗教訓與回顧總結
專案開工
迭代規劃
狀態更新
輸出
變更請求
專案管理計畫更新
溝通管理計劃
需要更新溝通管理計劃,以反映新的或已變更的相關方需求。
相關方參與計劃
需要更新相關方參與計劃,以反映為有效引導相關方參與所需的新的或更改的管理策略。
專案文件更新
變更日誌
根據變更請求更新變更日誌。
問題日誌
可能需要更新問題日誌,以反映問題日誌條目的更新或新增。
經驗教訓登記冊
更新經驗教訓登記冊記錄管理相關方參與的有效或無效方法,以供目前或未來專案參考。
相關方登記冊
監督相關方參與
監督相關方參與是監督專案相關方關係,並透過修訂參與策略和計劃來引導相關方合理參與專案的過程。此過程的主要作用是,隨著專案進展和環境變化,維持或提升相關方參與活動的效率和效果。
ITTO
輸入
專案管理計劃
資源管理計劃
溝通管理計劃
相關方參與計劃
專案文件
問題日誌
問題日誌記錄了所有與專案和相關方有關的已知問題。
經驗教訓登記冊
在專案早期所獲得的經驗教訓,可用於專案後期階段,以提高引導相關方參與的效率和效果。
專案溝通記錄
根據溝通管理計劃和相關方參與計劃而與相關方開展的專案溝通,都已包括在專案溝通記錄中。
風險登記冊
風險登記冊記錄了與相關方參與及互動有關的風險,它們的分類,以及潛在的應對措施。
相關方登記冊
相關方登記冊記錄了各種相關方信息,包括(但不限於):相關方名單、評估結果和分類情況。
工作績效數據
事業環境因素
組織過程資產
工具與技術
數據分析
備選方案分析
當相關方參與效果未達到期望要求時,應進行備選方案分析,評估應對偏差的各種備選方案。
根本原因分析
進行根本原因分析,確定相關方參與未達預期效果的根本原因。
相關方分析
進行相關方分析,確定相關方群體和個人在專案任何特定時間的狀態。
決策
多標準決策分析
對考察相關方參與的成功程度的多種標準進行優先排序和加權,識別出最適當的選項。
投票
透過投票,選出應對相關方參與程度偏差的最佳方案。
數據表現
相關方參與度評估矩陣
使用相關方參與度評估矩陣,來追蹤每個相關方參與程度的變化,並對相關方參與加以監督。
溝通技能
回饋
回饋用於確保發送給相關方的訊息被接收和理解。
示範
演示為相關方提供清晰的資訊。
人際關係與團隊技能
積極傾聽
透過積極傾聽,減少理解錯誤和溝通錯誤。
文化意識
文化意識和文化敏感度有助於專案經理依據相關方和團隊成員的文化差異和文化需求來規劃溝通。
領導力
成功的相關方參與,需要強有力的領導技能,以傳遞願景並激勵相關方支持專案工作和成果。
人際交往
透過人際互動了解相關方參與程度的資訊。
政治意識
政治意識有助於理解組織策略,理解誰能行使權力和施加影響,以及培養與這些相關方溝通的能力。
會議
輸出
工作績效訊息
變更請求
變更請求可能包括用於改善相關方目前參與程度的糾正及預防措施。應該透過實施整體變更控管流程對變更請求進行審查和處理。
專案管理計畫更新
資源管理計劃
可能需要更新團隊對引導相關方參與的職責。
溝通管理計劃
可能需要更新專案的溝通策略。
相關方參與計劃
可能需要更新關於專案相關方社群的資訊。
專案文件更新
問題日誌
經驗教訓登記冊
風險登記冊
相關方登記冊
敏捷部分
基礎內容
敏捷宣言
2001年,軟體產業思想領袖共同發表《敏捷宣言》,正式宣告敏捷開發運動的開始。我們正在透過親自開發和幫助他人開發,發現開發軟體的更好方法。
透過這項工作,我們開始更重視《敏捷宣言》四大價值:
個體以及互動而非過程與工具
要讓每個自組織團隊都選擇最適合他們的湯匙工具。
各種敏捷工具、方法論和流程的選擇非常多,你應該盡力做到都嘗試一次。
工具和流程可是很棒很有用的東西,但必須放對地方,要讓使用者來掌控它們。流程和工具必須是為人服務的,而不是反過來。
可用的軟體而不是完整的文檔
大多數產品來說,使用者文件都是很有價值的組成部分。但如果關注焦點不再是產品本身,而變成了流程文檔,那就有問題了。
如果在開發流程剛開始的時候,你對前期詳盡文件太過投入,那就會錯失檢驗和適應的良機,無法做到不斷地從錯誤中學習並調整流程和需求。
人們普遍誤以為敏捷團隊是不寫文件不做計劃劉的,但實際上,敏捷團隊為規劃和文件工作所花費的時間、精力]遠多於傳統團隊,因為計劃需要不斷地進行細化和更新。
客戶合作而不是合約談判
承包商的出價通常就是份賭注:,賭他們能夠在一定時間內完成工作,而利潤則取決於他們能否多快好省地滿足客戶最低要求,招標合約只能承載溫和的對立關係。
敏捷宣言的作者最終得出結論,基於合約的專案側重方向不對。他們更喜歡採用時間材料模式,相關各方就像是一群合夥人,齊心協力在規定時間和預算範圍內努力建立最有價值的系統。降低客戶風險,不是靠前期擔保方式轉嫁風險給承包商,而是依靠流程中客戶的持續參與,以及敏捷團隊定期交付可工作軟體增量的能力。
應對變更而不是遵循計劃
計畫驅動型組織通常都有「變化控制」流程,設計的初衷很美好,預防使命蔓延、特性蔓延以及其他各種形式的超支和延的寸影響目。
軟體開發的世界裡,變化就像海上的天氣一樣不可避免,因而理所當然的,認為變化是好事的流程就是最好的流程。
軟體專案的規劃必須是流動而非固定的,這是為了團隊好,但主要是為了產品的好,最終是為了客戶的好。因而你需要為變化做計劃,也要改變你的計劃。
敏捷實踐者樂於指出,傳統軟體開發方法是計畫驅動,敏捷專案是規劃驅動的區別。
源自這些價值的十二大原則
1、我們最重要的目標,是透過持續不斷地及早交付有價值的軟體使客戶滿意。
重點關注:客戶滿意
實務重點:持續交付儘早交付
2.歡迎需求變化,即使在開發後期也一樣。善於掌控空變化,幫助客戶獲得競爭優勢。
重點關注:幫助客戶獲得競爭優勢
實踐重點:擁抱變化實現軟體靈活性良好設計及實踐
3.經常地交付可工作的軟體,相隔幾星期或幾個月傾向於採取較短的周期。
重點關注:經常交付
實務重點:頻繁交付快速交付時間越短越好
4、專案過程中,業務人員和開發人員必須每天一起工作。
重點關注:客戶協作
實作要點:現場客戶頻繁溝通
5.要善於激發專案人員,給他們所需的環境和支持,並相信他們能夠達成目標。
重點關注:激勵團隊
實務重點:提供環境提供支持充分信任
6.在團隊內部,傳遞訊息效果最有效率的方式是面對面的交談。
重點關注:面對面溝通
實務要點:盡可能面對面分散式團隊可利用線上技術
7.可工作的軟體是進度的首要度量標準。
重點關注:進度度量
實務要點:可工作的軟體而非已完成的程式碼量
8.敏捷流程倡導永續開發。責任人、開發人員和使用者應該能夠維持恆久穩定的進展速度。
重點關注:永續開發穩定的步調
實務重點:不透支精力是基於平均速率
9.對技術精益求精,對設計不斷完善,將提升敏捷能力。
重點關注:技術精益求精設計不斷完善
實作重點:技術卓越良好設計保持程式碼簡潔重構
10.要做到簡潔,即要盡量減少不必要的工作,這是一門藝術。
重點關注:簡潔最小化工作
實務重點:工作圍繞客戶需求開展不建構華而不實功能
11、最好的架構、需求和設計出自於自組織的團隊。
重點關注:自組織
實務重點:團隊自主共同責任相互協作漸進方式
12.團隊定期反省如何能提高成效,並由此調整團隊的行為。
重點關注:定期反省作出調整
實務重點:定期回顧驗證與適應持續改善
也就是說,右欄的項目固然有價值,但我們更重視左欄的物品。
專案生命週期
預測型生命週期
預測型生命週期預計將從高確定性的明確的需求、穩定的團隊和低風險中獲益。團隊需要詳細的計劃,了解要交付什麼以及如何交付。當其他潛在變更受到限制時,這些項目就會成功。
團隊領導的目標是盡可能減少預測型專案的變更。當團隊在專案開始時創建詳細的需求和計劃時,他們可以闡明各種限制。然後,團隊可以利用這些限制來管理風險和成本。進而,團隊在實施詳細計畫時,他們會監督並控制可能影響範圍、進度計畫或預算的變更。
預測型專案強調根據部門劃分的、有效的、順序的工作,並且通常不會在專案結束前交付商業價值。如果遇到變更或需求分歧,或者技術解決方案變得不再簡單明了,預測型專案目就會產生意想不到的成本。
迭代
迭代型生命週期,迭代方法是透過一系列重複的循環活動來開發產品。
迭代型生命週期透過連續的原型或概念驗證來改進產品或成果。每一個新的原型都能帶來新的相關方新的回饋和團隊見解。然後,團隊在下一週期重複一個或多個專案活動,在其中納入新的資訊。團隊可能會在長達數週時間的一個特定迭代中使用時間盒,集中各種見解,然後根據這些見解對活動進行返工。這樣,迭代有利於識別和減少專案的不確定性。
當專案複雜性高、變更頻繁或當專案範圍受到相關方對所需最終產品的不同觀點的支配時,採用迭代型生命週期會有優勢。迭代型生命週期可能需要更長的時間,因為它是為學習而優化,而不是為交付速度而優化。
增量
增量型生命週期是透過在預定的時間區間內漸進增加產品功能的一系列迭代。來產出可交付成果。
有些專案優化是為了加快交貨速度。許多企業和專案無法等待所有的事情全部完成;在這種情況下,客戶願意接受整個解決方案的一個部分。這種少量可交付成果的頻繁交付稱為增量型生命週期。
與一次交付一個最終產品相比,增量型生命週期將經常優化為專案發起人或客戶交付價值的工作。在開始工作之前,團隊就規劃了最初的可交付成果,他們也會盡快開始第一次交付的工作。
例如,在繼續建造大樓的其餘部分之前,施工人員可能希望先展示一間已完成的房間或一層樓。這種情況下,在繼續建造大樓的下一層前,他們可能會為已完成的樓層佈置家具、刷漆等。客戶可以查看和批准有關樣式、顏色和其他細節,以便在進一步投入時間和金錢之前做出相應的調整。這樣做將減少潛在的返工和/或客戶的不滿。
適應型
適應型生命週期(也稱為變更驅動或敏捷方法),其目的在於應對大量變更,並獲得相關方的持續參與。適應型生命週期也包含迭代和漸進的概念,但不同之處在於,迭代很快(通常2-4週迭代一次),所需時間和資源是固定的。
需要因應快速變化的環境
需求和範圍難以確定
能夠以有利於相關方的方式定義較小的漸進式改進
敏捷(適應)
在敏捷環境中,團隊預料需求會發生變更。迭代和增量方法能夠提供回饋,以便改善專案下一部分的計劃。不過,在敏捷專案中,增量交付會發現隱藏或誤解的需求。
在基於迭代的敏捷中,團隊以迭代(相等持續時間的時間盒)形式交付完整的功能。團隊集中在最重要的功能,作為一個團隊合作完成其工作。然後,團隊再集中在下一項最重要的功能,並合作完成其工作。團隊可決定一次進行若干功能的開發工作,但團隊不會同時完成所有的迭代工作(即團隊不會在完成全部分析等工作後再解決所有需求)。
四種生命週期的特點
不確定性和複雜性模型
混合生命週期
對於整個項目,沒有必要使用單一的方法。為達到特定的目標,專案經常要結合不同的生命週期要素。預測、迭代、增量和/或敏捷方法的組合就是一種混合方法。
針對不同項目類型的基本的、單一的方法,它們結合起來就形成一種混合模型。早期流程採用了一個敏捷開發生命週期,之後往往是一個預測型的發布階段。當專案可以從敏捷方法中受益並且專案的開發部分中存在不確定性、複雜性和風險時,可以使用這種方法,然後是一個明確的、可重複的發布階段,該階段適合採用預測方法進行,可能由不同的團隊實施。這種方法的一個例子是,開發某種新的高科技產品,然後針對成千上萬的用戶推出,並對他們進行培訓。
以預測法為主、敏捷法為輔的方法
以預測法為主的專案中一個小的敏捷要素。在這種情況下,以敏捷方法處理具有不確定性、複雜性或範圍蔓延機會專案的一部分,而使用預測法管理專案的其餘部分。這種方法的一個例子是,某工程公司正在使用一個新的組件來建造一個設施。
雖然大部分的項目可能是常規、可預測的,就像組織實施的許多其它的設施項目一樣,但這個項目包含了一種新的屋頂材料。承包商可能會計劃先在地面上進行一些小規模的安裝試驗,以確定最佳的安裝方法,並在有足夠時間解決問題時儘早發現問題,隨後透過試驗和調整,增量地改進流程。
以敏捷方法為主、預測法為輔的方法
以敏捷方法為主、預測法為輔的方法。當某個特定要素不可協商,或使用敏捷方法不可執行時,可能會使用此方法。這種情況的例子包括,整合由不同供應商開發的外部組件,這些外部組件不能或不會以協作或增量方式合作。在組件交付之後,需要單獨整合。
符合目的的混合生命週期
專案團隊可能基於專案風險設計一個混合生命週期。例如,某校園建設工程可能會有多個建築需要改善和建造。增量方法會將資源集中,使某些建築比其他建築更早完工,從而加快投資回報。眾所周知,每個建築的獨自交付都能得益於該建築獨自採用預測型生命週期。
專案管理的目標是在給定的當前環境下盡可能以最好的方式創造商業價值。專案採用敏捷方法亦或預測法,都無關緊要。要提出的問題是:“我們怎麼做才能最成功?”
當團隊創造價值時,是否需要回饋?如果需要,增量方法將會有所幫助。在探討各種想法時,是否需要管理風險?如果需要,迭代方法或敏捷方法將會有所幫助。
當組織無法交付中間價值時,敏捷方法可能不是很有用。這樣沒有問題,但為了敏捷而敏捷並不是目標。關鍵在於,要選擇一個對專案、風險和文化管理有用的生命週期或生命週期的組合。
敏捷關乎頻繁交付給客戶。而這種交付要帶給團隊回饋。團隊利用上述回饋規劃並重新規劃下一部分的工作。
舉例
某政府部門有一個信貸保險申請開發案。這個多年期專案使用新的、響應能力更強的使用者介面和系統整合來取代其過時的保險體系。專案的大部分使用敏捷方法實施,並伴隨持續的業務輸入。
保險費率是根據經濟合作暨發展組織(OECD)下發的一個200頁的規範進行計算。計算步驟解釋非常清楚,幾乎不會有混淆機會(也幾乎沒有中間結果需要企業確認),計算步驟的編碼是由一個獨立團隊完成。兩個團隊合作計算所需的輸入變量,以及如何使用和顯示輸出值,但除此之外,計算團隊在很大程度上以預測的方式工作。
混合型生命週期作為過渡策略
許多團隊無法在一夜之間切換到敏捷工作方式。對於那些已經習慣預測型環境、並在其中獲得成功的人士,敏捷技術的觀感截然不同。組織越大,活動部件越多,轉換所需的時間就越長。因此,計劃一個漸進的過渡是有意義的。
漸進的過渡涉及要增加更多的迭代技術,以便改善學習,加強團隊和相關方的一致性。之後,也要考慮增加更多的增量技術,以加快對發起人的價值和投資回報。上述各種方法的組合被視為一種混合方法。
可以先在一個風險不大、具有中低程度不確定性的專案中嘗試這些新技術。在組織成功地使用混合方法後,再嘗試更複雜的項目,這些項目需要增加更多的技術。這是一種根據組織的情況、特定的風險,以及團隊適應並接受變革的就緒情況而調整的漸進式混合過渡。
混合敏捷方法
敏捷團隊很少將其實踐局限於一種敏捷方法。每個專案背景都有其各自的獨特性,例如團隊成員技能和背景的不同組合;開發中的產品的各個組成部分;以及工作環境中的年齡、規模、關鍵性、複雜性和監管制約因素等。敏捷框架並不是針對團隊訂製的。為了定期交付價值,團隊可能需要對實踐進行裁剪。通常,團隊都會實踐各自特殊的敏捷組合,即便他們使用一個特定的框架作為起點也不例外。
協調方法:裁剪敏捷框架的一個例子是,一個廣泛使用的常見協調方法涉及協調使用Scrum框架、看板方法和極限程式設計(XP)方法的要素。 Scrum為產品待辦事項清單、產品負責人、Scrum主管以及跨職能開發團隊的使用提供指導,包括衝刺計畫、每日例會、衝刺評審和衝刺回顧會議。看板面板幫助團隊進一步提高效率,方法是將工作流程視覺化、使障礙更容易被察覺,以及透過調整在製品限制來實現流程管理。此外,受極限編程啟發的工程實踐,如使用故事卡、持續整合、重構、自動化測試和測試驅動開發,將進一步提高敏捷團隊的效力。總之,與孤立採用各種實踐相比,協調這些不同來源的實踐將產生更好的協同成果。
影響裁剪的項目因素
典型敏捷流程
可行性階段
主要完成專案願景和商業論證。
專案願景
我們為什麼要做這個專案?這是專案願景。
商業論證
商業論證開發是敏捷專案管理中重要的起點。商業論證是對專案的構想、目標、達到目的策略、重大事件、所需投資和預期回收所做的簡明概要文件。商業論證向客戶闡明了該項目為什麼以及如何帶來價值。對於商業項目,價值通常使用如投資報酬率(ROI)、內部報酬率(IRR)、淨現值(NPV)和回收期來評估。
啟動階段
主要完成專案章程,建立待辦事項、高階估算,產品路線圖。
專案章程
輕量級。
待辦事項列表
需求項是以使用者故事的形式來表達的。
高階估算
又親和估算,使用T恤衫尺寸(如S、M、L、XL、XXL等)或咖啡杯尺寸(如小杯、中盃、大杯、超大杯等)來表示某個需求項的相對工作量大小。
產品路線圖
利用故事地圖來創建。使用者故事地圖展示產品路線圖
優先評價
要根據業務價值決定優先級,確定新能力的開發活動優先順序時必須考慮的4個因素。
獲得這些功能所帶來的經濟價值。
開發(可能還包含支援)新功能所需的成本。
開發新功能所產生的學習和知識的量及重要性。
開發這些功能所減少的風險。
由於大多數專案是為了節約開支或賺錢,因此前兩個因素常常在優先討論中占主導地位。然而,如果想最優地確定優先級,對學習和風險的適當考慮也是很重要的。
確定經濟優先級
淨現值
內部報酬率
回收期
折現回收期
確定合意性優先順序(替代價值估計法)
Kano分析
驚喜屬性
有時候稱為魅力屬性。這些特性的交付是客戶未預料到的、與眾不同的或可以帶來高價值的好處,可能為客戶帶來競爭力和高滿意度。
滿意屬性
作為滿意的特性,越多越好。這些特性會為顧客帶來價值、創造競爭優勢,大部分的競爭都聚焦在這個屬性的領域。
不滿意屬性
這些特性必須具備,如果這些特性不具備,客戶就不會喜歡這個產品,但即使這些特性存在,也不會提升顧客的滿意度。
無關緊要屬性
這些特性無論從哪方面來說對顧客都沒有影響。因為客戶對其根本不關心,我們應該嘗試消除、最小化或延遲交付這些特性,例如一個外觀很漂亮的電腦硬碟。
相對權重
MoSCoW方法
MoSCoW技術把使用者故事以降序方式進行優先順序排列
M-must have,即必須有的;「必須有的」需求和特性是系統的必需組成部分,是對開發很重要的產品特徵,沒有這些系統將不能正常工作或不能增加價值。
S-should have,即應該有的;「應該有的內」特性也非常重要,對開發不是很重要但有重要商業價值的產品特性。如果缺少這些特性,解決方法會變得煩瑣或昂貴。
C-couldhave,即可能有的;「可能有的」特性能增加一些商業價值的產品特性。
W-won't have this time,即希望有的,這次不會有;「希望有的,這次不會有」的特性指的是這個功能雖然不錯,但不是必需的需求,帶有一點商業價值的產品特性。
風險
應該先發展髙價值、髙風險的功能。這些功能可以提供最髙的價值,而對它們的處理可以消除顯著的風險。
接下來是高價值、低風險的功能。這些功能提供了和第一個功能集相當的價值,但是風險較低。
接下來是低價值、低風險的功能。它們被排在第三位,因為放棄它們對產品的總價值產生的影響較小,它們的風險也很低。
最後,對那些提供低價值,但具有高風險的功能,最好是避免開發。
發布階段
主要完成故事切片,故事估算,建立發布計劃。
故事切片
史詩-特性-使用者故事。
故事估算
估算技術有計畫撲克或寬頻德爾菲,計畫撲克用到菲波那契數列(0、1、2、3、5、8等)
發布計劃
Release Plan,又稱版本計劃
創建敏捷環境
僕人式領導
專案經理被定義為「由執行組織委派,領導團隊實現專案目標的個人」。許多專案經理已經習慣於作為專案的協調中心,負責追蹤團隊的狀態,並向組織中的其他成員反映。當項目被分解為孤立的功能時,這種方法沒有問題。
然而,對於高不確定性項目,專案的複雜性是一個人所無法管理的。而跨職能團隊既能協調自身的工作,也能與業務代表(產品負責人)合作。
從事敏捷專案工作時,專案經理的角色就會從團隊的中心轉變為團隊和管理人員提供服務。在敏捷環境中,專案經理充當僕人式領導,其工作重點轉變為引導需要幫助的人,促進團隊的合作,保持與相關方的需要一致。身為僕人式領導,專案經理要鼓勵將責任分配給團隊成員,分配給那些掌握完成任務所需知識的人。
當專案經理成為僕人式領導時,工作重點就會從「管理協調」轉向「促進合作」。
僕人式領導為團隊賦權
敏捷方法強調,僕人式領導是一種為團隊賦權的方法。僕人式領導是透過對團隊服務來領導團隊的實踐,它注重理解和關注團隊成員的需要和發展,旨在使團隊盡可能達到最高績效。
僕人式領導的角色是促進團隊發現和定義敏捷。僕人式領導實踐並傳播敏捷。
僕人式領導依照以下順序從事專案工作
目的
與團隊一起定義「為什麼」或目的,以便他們能圍繞專案目標進行合作互動。整個團隊在專案層面而不是在人員層面優化。
人員
目標確立後,鼓勵團隊創造人都能成功的環境。要求每個團隊成員在專案工作上做出貢獻。
流程
不要計劃遵循「完美」的敏捷流程,而是要注重結果。如果跨職能團隊能夠常常交付完成的價值並反思產品和流程,團隊就是敏捷的。團隊將其過程稱作什麼並不重要。
僕人領導的職責
僕人式領導透過管理關係,在團隊內和組織中建立溝通與協作。這些關係可以幫助領導者在組織中得心應手地為團隊提供支援。這種支持有助於消除障礙,促進團隊理順過程。由於僕人式領導了解敏捷,在應用具體方法時實踐敏捷,因而他們能幫助滿足團隊的需要。
僕人領導可能有很多頭銜,但最重要的是他們所做的工作。
教育相關方,使其了解為什麼要敏捷以及如何敏捷。根據優先順序說明商業價值的好處,對被賦權團隊加強問責,提高工作效率,並透過更頻繁的評審來改善品質。
透過指導、鼓勵和幫助為團隊提供支持。倡導團隊成員的培訓和職業發展。 “我們以支持的方式領導團隊”,這句話說的是領導在發展其團隊成員時所扮演的角色。透過支持、鼓勵和專業發展,團隊成員將獲得信心,承擔更多的職責,並在組織中做出了更大的貢獻。僕人式領導的一個關鍵作用是,培養和發展團隊成員,幫助他們超越自身當前的角色,即使團隊將失去他們也正在所不惜。
透過技術專案管理活動,如量化風險分析來幫助團隊。有時團隊成員可能不具備在某些角色或功能上的知識或經驗。對相關技能有更多接觸、或接受過相關培訓的僕人式領導可以透過提供培訓或進行這些活動來為團隊提供支援。
慶祝團隊的成功,為團隊與外部團隊合作提供支持,並發揮橋樑作用。創造相互欣賞的正面氛圍,建立加強合作的良好意願。
僕人式領導的促進作用
當專案經理成為僕人式領導時,工作重點就會從「管理協調」轉向「促進合作」。促進者將幫助每個人盡所能思考和工作。促進者鼓勵團隊參與、理解,並對團隊產出共同負責。促進者幫助團隊創建可接受的解決方案。
僕人式領導促進團隊內部與團隊之間的合作與對話。例如,僕人式領導在團隊內部和團隊之間幫助發現瓶頸問題,並進行相應溝通。然後,團隊將解決這些瓶頸問題。
此外,促進者也鼓勵大家透過互動式會議、非正式對話和知識分享展開協作。僕人式領導要透過成為公正的搭橋者和教練來做到這一點,而不是取代他責任人做出決策。
僕人式領導消除組織障礙
《敏捷宣言》的第一個價值關乎個人與過程、工具的互動。對僕人式領導而言,更好的職責是認真檢視那些阻礙團隊敏捷或組織敏捷的過程,並努力使其合理化。例如,如果一個部門需要大量文檔,僕人式領導的角色就能發揮作用,他們可以與部門合作審查所需的文檔,就敏捷交付如何滿足這些需求達成共識提供協助,並對所需的文檔數量進行評估,從而使團隊能夠將時間更多地用於提供有價值的產品,而不是創建詳盡的文件。
僕人式領導也應該關注其他冗長的流程,這些流程往往造成瓶頸問題,阻礙團隊或組織的敏捷性。可能需要處理的過程或部門的例子包括,財務部門、變更控制委員會或審計部門。僕人式領導可以與他人攜手合作,共同質疑和審核他們的過程,為敏捷團隊和領導提供支持。例如,對團隊而言,每兩週交付一個工作產品僅僅是為了讓產品進入隊列或過程,而冗長的發布過程卻可能需要6週或更長時間,這樣做有什麼好處呢?太多的組織都有這些「瓶頸」過程,正是它們阻礙了團隊快速交付有價值的產品或服務。僕人式領導有能力改變或消除這些組織障礙,為交付團隊提供支援。
團隊組成
《敏捷宣言》的價值和原則的一個核心宗旨是強調個人和互動的重要性。敏捷優化了價值流,強調了向客戶快速交付功能,而不是如何「用」人。
敏捷團隊專注於快速開發產品,以便能獲得回饋。在實踐中,最有效的敏捷團隊往往由三到九個成員組成。理想情況下,敏捷團隊應該集中在一個團隊工作場所工作。團隊成員100%為專職成員。敏捷鼓勵自我管理團隊,由團隊成員決定誰執行下一階段定義的範圍內的工作。敏捷團隊與僕人領導一起茁壯成長。領導支持團隊的工作方法。
跨職能敏捷團隊頻繁創造功能性產品增量。這是因為團隊集體對工作負責並共同擁有完成工作所需的所有必要技能。
無論整體的敏捷方法是什麼,團隊越是限制其在製品,團隊成員就越有可能透過合作來加速整個團隊的工作。在成功的敏捷團隊中,團隊成員在工作中以各種方式合作(如結對、群集、群體開發),因而,他們會協同工作,而不會落入迷你瀑布的陷阱中。團隊在給定時間解決所有的需求,然後試圖完成所有的設計,然後去完成所有的構建,就會發生迷你瀑布的情況。使用這個場景,在建置中或建置後測試中的某個時刻,團隊可能會意識到,原先的假設已經不再有效。在這種情況下,團隊解決所有的需求根本是浪費時間。相反,當團隊成員合作打造全部功能中的少量功能時,隨著工作的進展和交付少量已完成的功能,他們也在不斷學習。
成功敏捷團隊的屬性
自組織團隊
自組織
團隊成員自組織決定實現衝刺目標的最佳方式。沒有專案經理或其他經理告訴團隊怎麼開展工作(Scrum Master也不該冒昧這樣做)。自組織是系統自下而上、自發的屬性一沒有外部的統治力量採用傳統的自上而下、命令與控制的管理方式。
自組織團隊
自組織團隊也叫做自管理團隊、或被授權的團隊。團隊被授權自己管理他們的工作流程和進度、團隊決定如何完成工作。
自組織團隊是敏捷軟體開發最基本的要求。
決定如何完成迭代/衝刺代辦事項的方式並實現他們。團隊被賦能成為自發性組織和自我指導的團隊。
自發性組織關注如何完成工作的方式。
自我指導關注團隊成員如何協調工作。
原則11“最好的架構、需求和設計是出於自組織團隊”
敏捷的角色
敏捷團隊中有三種常見的角色
跨職能團隊成員
產品負責人
團隊促進者
中心主題