品保人的部落格

將重要的名詞解釋整理如下:

整合管理
    最終產品,服務或成果轉移
        此階段的工作:正式驗收與移交專案最終產品,服務或成果
        驗收包含收到正式說明書,說明已滿足專案成果驗收的規格

    組織流程資產更新
        專案檔案:專案活動的產出文件,如:專案管理計畫書,範疇,成本,時程及品質的基準與專案文件
        專案或階段結案文件:表示專案已完成的文件,專案結案文件包含正式結案的文件(在驗證範疇經發起人簽收),專案產出的結果已順利移交維護單位的文件.若專案終止也應記錄終止的原因,並依結案程序將已完成及未完成的交付標的移交他人
         歷史資訊:歷史資訊及經驗學習進入知識庫供未來的專案參考應用

    專案結案(行政程序結案)
        專案結案方法論,有三點
            (1) 滿足專案或退場準則所需的行動及活動
            (2) 將專案產出轉移到下一階段(專案,維護或生產)所需的行動及活動
            (3)  蒐集專案的記錄,稽核專案,匯整 Lesson Learned 及建檔專案資訊, 供組織未來參考使用
     
    結束專案或階段
        產生內外部專案結案程序來驗收專案,產品或服務並做 lesson learned
        結束專案流程對照專案範疇聲明來審查專案結案與否
        建立程序以驗收專案文件及檢驗已接受的交付標的,用來與客戶或發起人協調及互動.
        將經驗學習有系統的保留下來
        當所有的合約都完成結束後,專案才能結束
        中途停止(terminated)之專案,對於已完成之專案範疇及程度亦應建立程序,以調查原因及記錄

    專案團隊面對變更管理原則
        PM的職責是主動(預防)管理影響變更的因素(先辨識變更因素)
        確認所提出的變更後,應將欲變更的項目與內容記錄至變更紀要(Change Log)
        變更送核定前(緊急狀況是採追認)要先評估變更的衝擊,以口頭或書面告知客戶或發起人擬採取之變更
        提出變更影響評估報告(陳述對專案各方面的影響)給變更控制系統來審核
        評估是否有其他的替代方案,同時可量調整變更所造成的其他應調整事項(如:成本,風險,品質及人員)
        核准機制應依照變更控制系統所定義的審批層級
        若是專案時程育逾期,在保留時程內之專案時程逾期由PM負責作調整,不應先做變更時程或變更基準
        由CCB審核後,若是變更不影響最終產出及日期,仍應檢視其他可能造成之衝擊因素
        若專案變更是關鍵或重大變更,由發起人決定
        由變更控制委員會核准或否決變更申請
        無論批准或否決,都要將變更的結果更新至變更紀要中
        將變更知會利害關係者
        依新的專案管理計畫書來管理專案
        追蹤變更衝擊及實施

    變更控制委員會(CRB)
        很多專案的變更是無法單獨由專案經理來審核的,而是需要一群專業人士來審核變更對專案的影響.專案經理的角色是協助變更的決策
        委員會有義務審視變更需求,看額外的功能修正是否有其他影響
        委員會可以包含:專案經理,客戶,發起人或組織的其他專家(不一定要在專案團隊)
        不同的核准階層可以由不同委員會成員的組成來核准,主要是以變更管理計畫書所定義的權責為主
        所有變更應由變更控制系統的定義來提交給對應的應審核委員會審核

    構型管理系統(Configuration management System)
        用於(1)提交變更申請(2)追蹤核准後的變更 (3)確定變更的的批准層級及 (4)核准變更的方法
        構型管理系統涵蓋變更控制系統,是PMIS的一部份
        發生在專案的生命週期的變更都要被監控

    變更控制會議
        變更控制系統(CCS)是正式的,制式程序,文件表單,追蹤系統及不同階層審核變更的定義
        在不同的領域下有不同的變更控制系統,如:範疇,時程,風險...等

    執行整合變更控制
        呈變更管理委員會CCB審核
        整合變更控制的實施是從專案開始到專案結束
        變更計畫有可能會影響成本估算,活動順序,行程日期,資源需求,及選擇的風險對策
        核准變更的內容需更新至專案管理計畫書,專案範疇聲明及其他專案交付標的.必要時,需更新專案基準

    缺點改正
        當專案交付標的沒有滿足客戶需求時對交付標的重新修正或製作,又稱重工
        交付標的缺陷是在品質管理流程發現的,並在控制階段提出變更(重工)申請,在整合變更控制核准或否決

    專案基準
        一個好的專案管理計畫書需有BARF特性(Bought into,Approved, Realistic and Formal)
        專案管理計畫書被發起人核准後,其相關的基準也被確認下來
        標準的基準有三種: (1)範疇 (2)時程 (3)成本績效基準
        一個好的專案其績效應常滿足其基準
        範疇基準是指: (1)專案範疇聲明 (2)WBS (3) WBS說明表

    變更申請
        專案的目的是為了達到專案的目標,故要時時量測專案指標的績效,若是有差異則需提出矯正措施.
        常見差異分析後的變更申請:(1)矯正措施 (2)預防行動 (3)缺點改正
        (風險管理的措施可直接付諸執行,不必經過變更申請)

    實獲值技術
        績效報告包含:(1) 工作績效資訊 (2)工作績效衡量值,(3)預測 (4)議題 (5)及需改善事項
        實獲值技術從專案的開始到結束的過程中進行專案績效的量測
        實獲值管理方法可以依據過去的績效提供未來績效的預測

    績效報告
        績效報告包含:(1) 工作績效資訊 (2)工作績效衡量值,(3)預測 (4)議題 (5)及需改善事項
        預測包含:估計或預測未來的情形或事件;依據過去的資訊及知識來估算或預測
        預測是根據專案執行時提供的工作績效資訊來進行未來的工作績效預測的更新與發佈.如:完工成本估算BAC

    專案文件更新
        專案管理計畫書包含各知識領域的子計畫和基準
        專案文件是用來協助專案經理管理專案的各類文件,並不屬於專案管理計畫書
        在專案生命週期的產出只要不屬於專案管理計畫書的文件,就是專案文件
    
    工作績效資訊
        提供成員的績效訊息
        在監控專案工作子流程,不斷檢視績效與基準的偏差並提出矯正措施
       
    交付標的
        具體的,可被驗收的及包含於專案管理計畫書的產出
        指專案過程的中間產物或專案最終產品
        產出可能是產品,成果,或提供的服務
        驗收規格記錄在:(1) 專案範疇聲明 (2) WBS說明表
        在驗證範疇與執行品質管制子流程驗收教交付標的

    組織流程資產
        流程,程序及政策
        知識庫
        歷史資料
        經驗學習

    企業環境因素
        包含:組織的制度,系統,市場條件,組織文化

    專家判斷
        (1)執行組織的平行單位 (2) 客戶及發起人 (3)  專案管理辦公室 (4)主題專家 (5) 顧問 (6) 技術協會 (7) 工會 (8) PM與專案團隊

    專案範疇聲明
        承接高層與客戶須需求,加以界定工作範疇;列舉了專案的工作項目及工作的方法
        (1)範疇基準的一部份 (2)專案產品的驗收規格 (3)達成專案目標的作法
        內容包含:1.產品範疇聲明2.排除事項 3. 交付標的 4.驗收規格 5.限制條件 6.假設事項
        專案範疇聲明是手段

    專案章程
        (1)專案目的 (2)目標 (3)高階需求 (4)高階專案描述 (5) 初步里程碑 (6)預算 (7) 風險(8)專案核准需求  (9) 專案經理  (10)專案經理責任及權限 (11)發起人

    專案工作條款
        包含商業需求,產品範疇描述,策略規劃
        對內部而言:由發起人依營運企劃,產品或服務的需求提供說明; 對外部而言:由客戶提供的合約內容即包含專案工作條款

範疇管理
    產品範疇:定義專案所應產出的產品,服務或結果的特徵與功能
    專案範疇:產出符合產品範疇所定義出的特色與功能的產品,服務或成果所必須完成之所有工作

    利害關係者登錄表
        利用利害關係者登錄表來辨識利害關係者( 能提供詳細的專案和產品需求)
        辨識利害關係者後的產出,需包含:
            個人基本資料(姓名,職稱,專案角色,聯絡資訊)
            評估資訊:主要需求,主要期許,懟專案的潛在影響,專案生命週期最聚焦之處
            利害關係者分類:內外部,支持者/中立者/抗拒者

    焦點團體(Focus Group)
        是一種共識討論,召集預審合格(prequalified)的利害關係者和主題專家一起進行,藉以得到他們對於專案應產出的產品,服務或成果的期望與態度(看法)
        經由培訓合格的主持人引導大家面談討論來確定需求,比一對一面談更能激盪出更多的火花

    促進研習會(Facilitated Workshops)
        一種深度交流的會議,與關鍵的跨功能別的利害關係者一起來定義專案的產品需求
        由於互動的方式,可快速調和不同利害關係者與跨功能的需求,進而建立利害關係者彼此的信任,緊密的關係及改善溝通,可快速促進利害關係者的共識
        在軟體工業稱之為聯合應用發展JAD(Joint Application Development)召集軟體使用者和開發團隊來共同改善軟體開發的流程
        在製造業稱為品質機能展開 QFD(Quality Function Deployment). QFD用來蒐集客戶的聲音VOC(Voice of Customer),有助於新產品開發時決定產品的關鍵特性

    集體決策技術
        集體決策技術是指在多數選擇方案中找出一個未來行動的期望結果，用以產生、分類和排序產品的需求，方法有
            一致性(Unanimity,全數同意)
            過半數(Majority,共識決)
            最高票(Plurality,多數決)
            獨裁(Dictatorship)

        共識決是PMP最典型的方式
            優點：安全、最佳解、群體支持及接納
            缺點：無法快速地達成協議、主事者推卸責任的說辭
  
    需求文件
        需求必須清晰(可衡量及測試).可追蹤,完整地,前後一致且被利害關係者接受.批准後就形成基準
        格式包含將所有需求依照利害關係者及優先順序進行分類,以及有執行摘要,詳細敘述和附註的詳細格式
        內容包含(但不限於):可獲得的營運需求,機會,可追蹤的商業和專案目標,功能性需求,非功能性需求(如服務及安全水平等),品質需求,允收準則,商業規則,其他組織因素帶來的衝擊,支援和訓練需求,需求假設與限制等資訊.
    
    需求追溯矩陣
        一份結合需求的原始動機,並在整個專案生命週期中,用來追蹤需求的表格
        可確保每個需求都會對公司營運和專案目標增加許多的企業商業價值,也確保在專案結束時,在需求文件中所有經批准的需求都能交付實現.
        提供一管理商品範疇變更的架構
        不限於對營運需求,機會,目的及目標,專案目標,專案範疇或WBS交付標的.產品設計,產品開發,測試策略及情境,測試方案,高階甚至更詳細需求的需求追蹤
        記錄每一個需求的特徵,用以定義每個需求的主要資訊,包含唯一的辨識碼(Unique identifier),需求內容說明,理由原因,負責人,來源,優先等級,版本,現況(包含進行中,刪除,延期,新增,已批准),完成日期,額外包含保 證利害關係者對需求滿意的穩定性,複雜性和允收準則!
 
   專案範疇聲明(Projeect Scope Statement)
        提供專案交付標的及完成這些成果所需要的工作
            提供專案團隊更詳細規劃的依據
            提供專案的基準做為變更及評估績效的依據
        讓專案利害關係者對專案有共通的瞭解,包含:
            產品範疇聲明
            專案交付標的
            產品使用者驗證規格
            專案排除事項
            專案限制條件
            專案假設事項

    範疇管理的分解術
        Decomposition分解術:將主要交付標的分解成較小單位以便於管理(規劃,執行和控制)
        一般是將專案交付標的分解至適當工作大小(時間,成本等均能可靠的予以估算和管理)

    工作分解結構(Work BreakDown Structure)
        是專案最基礎的文件,用以估計人力,時程,成本及評估風險等,以交付標的為導向
        可用組織圖,魚骨圖及大綱式等方式呈現,足以涵蓋專案所有的範疇及產出物
        與專案利害關係者用來溝通的文件
        可用湧浪規劃法來發展,可以當作是日後的專案範本

    WBS展開原則
        最上面是專案的產品,結果或服務
        分解後的第一層是專案的生命週期(有順序性的展開)
        第二層(含)以下的產出物為第一層的展開,若無法展開到如80小時以內的交付標的,需要繼續往下展開,直到符合80小時以內的交付標的產生,即產出工作包(Work package)
        WBS包含客戶要的交付標的,產品範疇,專案範疇及專案管理的成果
        最終在建立工作包的管制帳戶(control account)及單一的工作代碼(code of account),並獲得一獨特的識別碼(identifier)後,WBS即正式完成
        管制帳戶是整合範疇,時程和成本的管理控制點,並與實獲值相比較.每個管制帳戶可包含一個或多個工作包.但每一個工作包只能對應一個管制帳戶

    工作包Work Package
        工作包是WBS最底層的交付標的
     
    工作分解結構說明表WBS Dictionary
        與WBS搭配的文件,對WBS各組成部份詳加說明
        避免計畫的產出物發散
        防止範疇潛變(Scope creep)
        增加專案團隊對任務的了解
        WBS說明表內容至少需包含交付標的的目的及重點才行
        對於每個工作分解結構組成部分,工作分解結構說明表都相對應一個工作代碼,一份工作條款,負責的組織,一份進度里程碑清單,有關的預劃活動,所需資源,成本估算,品質要求,驗證規格,技術參考文獻以及合約資訊

    範疇基準
        範疇基準來自於專案範疇聲明,WBS及WBS說明表
        批准的專案範疇聲明與對應的工作分解結構和工作分解結構說明表都是專案的範疇基準
        將定期的WBS的工作包對應產出數目畫出來就是典型的範疇基準

    變異分析Variance Analysis
        專案績效衡量值用來評估基準跟實際績效的差異
        專案範疇控制重要因素包含原因確立及偏離範疇基準的程度,是否需要矯正措施或預防行動

    工作績效衡量值Work Performance Measurement
        衡量值可以包含規劃與實際的技術績效或其他範疇績效量測
        績效資訊應被文件化並主動與利害關係者溝通

時間管理
     定義活動
        定義該作的事情以完成可交付成果
        定義專案的各項活動, 包含確認計畫應完成(執行)的工作並記載在文件
        將工作包分解成更小單元,稱為活動(Activity)
        確認WBS最低階工作包(Work Package)之交付標的(Deliverable)應完成的活動
        前提是要滿足專案的目標

    時間管理的分解術
        將工作包分解成更小更好管理的單位,叫活動(Activity)
        建立工作分解結構的結果:交付標的 vs 定義活動的結果:活動
        WBS,WBS說明表及活動清單(activity list)可依序完成,也可同時並行
        WBS, WBS說明表是活動清單發展之基礎
        分解工作及定義活動一般是由負責該工作包的專案團隊成員負責

    湧浪規劃法Rolling Wave Planning
        大型專案一開始要把專案計畫的活動細節規劃的很清楚是很困難的,故可採逐步規劃,一方面進行專案,一方面規劃更詳細的活動細節
        湧浪規劃法是一種逐步完善的規劃手法
            使用WBS較低階成果來規劃近期的活動
            使用較高的WBS階層成果來規劃晚期的活動
            當晚期活動快到時,再以WBS較低階層成果來規劃活動
        在早期專案規劃資訊不足的情況下,先以里程碑的形式表示

    活動清單Activity List
        提供專案所計劃應完成之所有活動,任何非專案範疇內之活動,皆不應包含在活動清單內
        活動內容要具體化與量化,能讓專案成員清楚理解並執行
        應有活動識別碼(activity identifier)及活動內容描述(Scope of work description)
        以時程進度的型態表示
        活動(activity)為組成專案時程之展開元件(discrete components), 但不算是WBS之組成元件.活動跟工作包是過程跟結果關係

    里程碑Milestone
        里程碑本身不是活動,故沒有工期,所以期程為"0"
        里程碑舉例:接受之交付標的,完成雛型,系統測試,簽訂合約
        通常用以定義主要交付標的之應完成日期;或定義外部介面(outside interface) 工作之完成日期
        策略規劃(Strategic planning)階段,因資訊不足,故常使用里程碑做時程規劃
        是專案的顯著部份(A significant point or event in the project);是專案管理之限制條件(Constraints)
        可定義在章程,專案範疇聲明的限制及WBS說明表
        可由客戶或發起人定義里程碑及完成日期,專案活動應配合里程碑來排程
 
    順序圖示法PDM(Precedence Diagramming Method)
        使用節點(node)來表示活動,使用箭線來表示依存關係;節點可以是方形或矩形
        又叫節點圖示法AON(Activity on Node)

    箭線繪圖法ADM(Arrow Diagramming Method)
        使用節點(node)來表示依存關係,使用箭線來表示活動
        又叫活動箭線表示法AOA(Activity on Arrow;or Activity on line)
       
    要徑(Critical Path)
        使用網圖找出最長路徑的完成時程.這個時程就是完成專案至少需要的時間.
        找出要徑的方法是將所有可能的路徑列出,分別算出各路徑之累加天數,最長的那一條就是要徑
        Float浮時等於"0"
        若要徑上的活動被延誤,則浮時為負值
        要徑法(Critical Path Method; CPM)是以單一值估算工期的方法
    
    浮時或時差Float or Slack
         浮時(Float),時差或待工(Slack)是在不會影響專案的最終完成日期條件下,活動所容許的時間彈性,可以為正值,"0" 或負值.
            要徑的浮時為"0"
            若要徑上的活動被延誤, 其浮時為負值.
      
    相依關係判定
        強制相依關係Manadatory dependencies
            硬邏輯關係(Hard Logic)
            工作性質固有的相依關係,通常涉及實際的限制
        刻意相依關係Discretinoary dependencies
            軟邏輯關係(Soft Logic),優先選用邏輯關係(Preferred logic),優先邏輯關係(Preferential logic)
            前後順序可以由專案團隊之喜好或需要來決定
            可依照先前成功的經驗來排序,又稱最佳實務(Best practuce)
        外部相依關係External dependencies
            涉及專案活動與外部活動(非專案活動)的關係.

    資源行事曆Resource calendars
        關於可利用的資源的資訊
            有沒有資源可以使用?
            資源的能力如何?
            有多少資源可以使用?
            資源來源的地理位置
            資源所需具備的專案要求條件
        資源行事曆在兩個子流程產出
            人力資源管理的獲得專案團隊
            採購管理的執行採購

    活動資源需求Activity Resource Requirements
        估算活動資源過程的產出,明確在每個活動行程指出需要何種資源與多少資源
        發展時程把何時需要資源的時程訂定出來
        將所需要的個別資源量加總起來,就是專案所需資源總和

    類比估算法Analogous estimating
            又叫由上而下估算法
            使用過去相同性質的專案活動期程來估算
            在初期資訊有限時使用
            使用歷史資訊及專家判斷

   參數估算法Parametric estimating
            適合可以等比例估算的方式
            可以是線性縮放,也可以非線性縮放(主要考慮是否有交互作用)

    三點估算法Three Point Estimates
        三點估算法是把風險考量進去,會有比較接近實際的估算值, 取此三個值的平均值
            最可能估算值(most likely)
            樂觀估算值(optimistic)
            悲觀估算值(pessimistic)
        與PERT估算的值不同,PERT是取三個值的加權平均值

    計畫評核術PERT(Program Evaluation and Review Technique)
        每個活動有三個估計值
            悲觀估算值(pessimistic):P
            樂觀估算值(optimistic):O
            最可能估算值(most likely):M
        亦可用來估算期程或成本
        強調符合時程,讓成本保持彈性
        比CPM的單點估算及三點估算法來得精確
        公式:PERT=(P+4M+O)/6
      
    時程網圖分析Schedule Network Analysis
        綜合不同分析工具,如要徑法(CPM),關鍵鏈法(critical chain method),若-情境分析法(What-If scenario analysis),資源撫平(Resource leveling)及計算未完成專案活動的最早及最晚之開始和完成日期
        主要目的是找出網圖中有那些活動是路徑的匯集或分歧點以做為時程壓縮的分析之用
 
   要徑法(Critical Path Method)
        要徑法使用單一數值估算時程,常使用可能估算值
        要徑法沿著專案時程網圖進行前推法與後推法(見發展時程的Time workshop)
        算出所有活動的最早開始與完成日期,最遲開始與完成日期
        強調成本控制Cost Controlling,讓時程保持彈性Schedule flexible.可撫平非要徑資源以控制成本
        在專案歷史資訊很少時使用
        忽略任何資源的使用限制

    關鍵鏈法Critical Chain Method
        針對專案受限制的資源(resource constrained)做管理,非只對傳統的要徑做管理
        受資源限制的要徑稱關鍵鏈
        關鍵鏈法增加緩衝時程(duration buffers),這些時程也是屬於專案的活動之一
        置於關鍵鏈末端的緩衝,報護專案完成日期在關鍵鏈上不會延誤,稱為專案緩衝
        匯流緩衝feeding buffer:額外的緩衝置於不在關鍵鏈上的一系列相依任務鏈匯入關鍵鏈的進入點上,在於保護關鍵鏈以免受到匯流鏈延誤的影響
         
    資源撫平Resource Leveling
        是發展時程也是控制時程的"工具與技術(TT),應用在已使用要徑法進行分析的時程
        資源撫平使用的情境有兩種
            時程中某資源的使用量有限時:要將專案各活動在彈性時間(即總浮時)內調動.希望盡可能不要影響專案的期程,使資源在不同時期的使用量更加平均和穩定
            時程中某資源被過度分配(over-allocated):  某個共用或關鍵的資源本身的數量有限,或是限定只能在特定的時段使用,因此必須調整專案時程來遷就該項資源
        資源撫平常會造成原本要徑的改變

    若-情境分析法What-If Scenario Analysis
         對什麼情境出現時,該如何處理?假設不一樣,時程也跟著改變
        進度網路分析利用進度模型,計算各種情境
        例:材料延誤一週進廠,準備的人力呆滯一週,可以做其他的什麼活動?
        計算變更的效應最常使用的是蒙地卡羅分析,可分析出分佈在整個專案期程可能結果的機率分佈

    時程壓縮Schedule Compression
        縮程法Crashing:(1)不一定會增加成本,或(2)以最小的成本增加,達到最大時程的壓縮.投資報酬率最大
        快速跟進Fast tracking:(1)將有順序(前後)關係的活動同時進行(2)常會造成重工和增加風險
        縮程法 vs 快速跟進法

    專案時程基準
            經專案管理團隊接受並核准的專案時程稱為時程基準(Schedule baseline)
            是量測及報告時程績效的基準

   績效審查Performance Reviews
        衡量,比較及分析時程績效,如:
            實際開始與結束日期,完成百分比,EAC
            實獲值管理(EVM)的時程變異SV及時程績效指標SPI
        決定時程變更是否需要採取!矯正措施
        若使用關鍵鏈排程法,則以剩餘緩衝量及保護交付日的緩衝量決定是否需採取矯正措施

    變異分析Variance Analysis
        變異分析是時程的差異分析,使用時程變異及時程績效指標,用以評估原時程基準與實際時程的差異
        總浮時的差異分析也是變異分析的重要標的
        判定,分析造成時程基準偏差的原因及程度及決定是否需要矯正措施或預防行動

(資料參考來源:長宏專案管理顧問公司教材)