Glossary

Kris專案管理流程手冊 > 3.5 專業術語

▓ 作者：賴志宏 博士   出處：Kris專案管理顧問   日期：2019/3/6

有關本手冊內容所使用的專業術語之定義，請參考下表。

章節	術語	英文	定義
1.2	作業	Operations	由各別功能單位來負責的「例行性及重複性」工作。這些工作通常具有固定的工作流程及產出結果。「作業」的主要目的在從事「維繫公司業務功能正常運作」的「服務、生產、維運」等相關的例行性工作。
	專案	Project	一個暫時性(temporary)的任務、根據特定(specific)需求和目標，由一個暫時性的團隊，在一段事先規劃的期間內來完成，以交付事先定義的獨特(unique)產品、服務或結果。
	群組專案	Program	組織為了實現策略投資最大的利益和獲得最佳的控管效率，通常會把一群互相關聯的專案集中在一起管理，以方便統一來指揮調度及溝通協調，這些被集中管理方的專案群組稱為「群組專案」，有時也會被稱做「多重專案 (multiple projects)。
	投資組合專案	Portfolio	企業為了實現策略目標，透過規劃和執行各種投資標的組合(investment portfolio，簡稱投資組合)，來追求整體投資的最大利益，進而達成組織的策略目標。每個投資標的都有個別的利益目標，並由一個專案或一群具有共同利益及互動關係的專案(program，簡稱群組專案)來予以實現。這樣的策略投資專案組合被稱為投資組合專案(Portfolio)。
1.3	專案管理	Project management	專案管理就是運用領導、組織、用人、計畫、控管及各種管理領域的知識、方法、技術和工具，於專案管理的活動上，來解決專案的問題，並達成專案的目標和需求
1.4	專案管理流程	Project management process	在專案的生命週期各階段中，由不同專案管理階層人員，所共同從事的管理活動之程序或步驟。
2.1.1	問題	Problem	指實際狀況和理想或正常狀況之間有差異(variance)的情況。
	需求	Need	指為了達成期望的目的，必須滿足的狀況或條件。
	目標	Objectives	指為了滿足需求，所設定的具體量化標準。
2.1.2	可能解決方案	Possible solution	用以滿足所有問題解決需求及目標之所有可能的行動方案。
	備選方案	Option	問題通常會有許多「可能的解決方案」。在經過初步構想及篩選後，於眾多的「可能的解決方案」中，少數幾個被選出來做為最終篩選的候選解決方案。
	最佳解決方案	Optimal solution	在所有備選的解決方案中，最終被篩選出的解決方案。
2.1.3	商業案例報告	Business case	用以判斷某個問題解決方案或專案是否值得投資的所有必要彙整資料，內容主要說明該問題解決方案或專案是否是想要的(考量成本、效益及風險之間的平衡)、是否可行(方法是否可行及產出是否可交付)、是否可達成(效益是否可達成)等。
2.2.1	專案核准文件	Project charter/mandate	在專案正式開始前，由專案贊助者或專案起始者所撰寫的一份用以證實專案被正式成立的文件。同時也用以正式授權專案經理使用組織預算及資源來從事專案的活動。
2.2.2	專案擁有者	Project owner	為負責專案最終成敗的高層主管，提供專案順利完成所有必要的資源及指導。
	專案委員會	Project committee/board	專案委員會成員通常由企業高層主管選派出，此為負責最終決策的團體，以確保專案最終將順利完成。須包含一名專案委員會主席及專案贊助者，及重要的利害關係人代表。
	專案贊助者	Project sponsor	代表經營團隊，負責監督專案的高層主管，協助確保專案能夠滿足顧客和公司的需求。專案贊助者負責專案政策的解釋及落實，同時協助專案管理團隊對上層經營者溝通與報告，及協調外部顧客之事宜。
	專案稽核者	Project auditor	為獨立運作的專案稽核人員。協助專案贊助者，從事專案執行狀況、問題及改善結果之監督、查核及報告工作等。
2.2.3	專案利害關係人	Project stakeholder	凡是對專案的進行過程及結果具有興趣或影響力的相關人士。
2.2.4	專案需求	Project requirement	專案在執行及完成接收時，必須達成的目標、遵守的規定及滿足的條件。包含事業的需求、利害關係人溝通需求、產出的需求、專案管理的需求等。
	專案實現方法	Project approach	為了滿足專案需求，所發展的專案實現策略、方法及上層(high-level)管理及產出之主要階段及活動等。上階(high-level)代表初階的、非細部的。
2.2.5	產品範疇	Product Scope	專案最終之交付產出 (如產品、結果或服務)，及其應有的特微，、功能及效能需求等。詳載於『產品需求文件』(Product Requirements Document)。
	工作範疇	Work Scope	為完成專案最終交付產出應從事的所有工作項目及規定條件，詳載於『工作說明書』(SOW, statement of work)。
	專案範疇	Project Scope	包含專案的產品範疇、工作範疇、專案目標、專案假設、專案限制、達成方法、專案組織、專案界限及專案控管方法等相關資料。
2.2.7	啟動會議	Kick-off meeting	在進入計劃階段之前，一個正式的會議，用來讓所有重要專案利害關係人，清楚及認同整個專案的背景需求、角色責任、實現方法、範疇、管理需求、利害關係人溝通需求及最終的接收條件等。
2.3.2	專案產出	Project deliverable	指專案完成後，必需交付給內部或外部顧客之有形(tangible)的產品(product)或無形(intangible)的服務(service)或結果(result)。專案產出的規格是根據內部或/外部顧客的需求所制定的。
	產品	Product	指那些具有功能性及可操作性專案的最終產出，例如建築物、電子產品、家具、資訊系統、軟體或電影等。有形產品的價值取決於顧客對產品功能和品質的滿意程度。
	服務	Service	指那些以執行過程來創造價值的活動。通常，無形的服務在提供專業知識、技術、勞務，以完成顧客所需要的無形結果。例如，教育訓練、表演活動、顧問服務、金融服務、運輸服務、清潔服務、設備維修等。
	結果	Result	指一種期望的狀態、成果或效益。無形服務的價值取決於顧客對服務過程與結果的滿意程度。
	功能需求	Functional requirements	功能需求：指一個產品或服務應該具有的操作行為或動作。「功能需求」描述一個產品或服務應該可以做什麼，例如，一個杯子的功能需求就是裝水。
	非功能需求	Non-functional requirements	非功能需求：指一個產品或服務所需功能應達到的品質要求。例如性能、效率、美觀、安全、可靠、經濟、環境、支援、維護等需求。「非功能需求」描述一個產品或服務的操作功能應該要做到什麼程度。
	產出需求文件	Product requirements document	產出需求文件：用來描述所有產出需求的文件，通常根據產出的類型，可被稱為產品需求文件(product requirements document)、軟體/系統需求規格書(software/systems requirements specification)、或服務需求文件(service requirements document)。一個專案可能同時包含以上的三種產出需求文件。
2.33	工作分解架構	Work breakdown structure (WBS)	一種階層式的工作組織架構，用來將整個專案任務分解成更細的工作群組及個別工作，以做為定義專案工作範疇及發展專案計畫的依據。
	工作分包	Work package	用以完成工作分解中最低階交付產出的工作群組，可以由一位獨立的工作小組來負責完成。工作分包是一個獨立區隔的工作群組，可以被進一步來被分解成更細的工作步驟及任務。
2.3.4	品質保證	Quality assurance	為了確保專案的工作按計畫的方法、程序或標準進行，所從事的工作流程審查、檢討及矯正的品質管理活動。
	品質控管	Quality control	為了確保專案工作的產出達到驗收的標準，所從事的產出檢驗、檢討及矯正的品質管理活動。
	品質稽核	Quality audit	為確保工作小組有落實工作計畫及品質計畫的規定，所進行的查核、檢討及矯正的品質管理活動。品質稽核的活動通常只用於大型的專案，中小型的專案則視實際的狀況來決定是否需要。
2.3.5	資源分解架構	Resource breakdown structure	為一階層式的資源組織架構，用來細分專案所需的資源類型及次要類型，以做為資源需求計畫及成本科目分類的參考依據。
2.3.6	里程碑	Milestone	專案生命週期流程中的某個重要事件及其必須發生的限制時間點。也就是那些必須開始於(must start on)、必須完成於(must finish on)某個時間點的活動。
	里程碑限制時間	Milestone constraint	里程碑活動的限制時間可能是不能更改，也可能是根據某種假設暫時決定的。主要包含：專案開始及結束時間點、重要階段的完成時間點、重要產出的交付時間點、重要工作的檢核時間點、重要的會議時間點、重要的儀式活動時間點等。
	工時	Working Hour	完成一件工作的所有資源必須使用的時間，通常以小時/單位來做為計算。工時主要用來計算工作所需資源的使用時間，進而可用來計算跟工時相關的成本。例如，一件工作需要5個技術人員，每個人要做8個小時，那麼總工時為5人x8小時/人=40小時。
	工期	Duration	一件工作從開始到完成所需要的時間長度，不管同時使用多少資源。工期主要用來計算工作的完成時間。例如，一件工作需要用5個技術人員，每個人要做8個小時，其總工時為=40小時。若每人一天工作8個小時，且同時一起開始工作，那麼只要花一天的時間就可完成。此時工期為8小時。如果每人一天工作4個小時，且同時一起開始工作，那麼要花2天的時間就可完成。此時工期為16小時。
	使用率	Resource usage rate	一個資源指派給一件工作，可使用正常工時的最大比率值，例如，一位程式設計師每天正常工作8小時，那麼如果他被指派去做工作A，且一天只能做4小時。那麼他的時間使用率為50%。相對地，如果他每天需要12小時，那麼他的時間使用率為150%，亦即他必須使用加班時間。
	工期為導向的專案	Duration-driven project	以固定工期來做任務排程的專案。這類專案以控管工期為第一優先考量，因為它的完成時間有重要的限制需求。通常，它在資源的使用數量及方式上，限制程度比較少。
	工時為導向的專案	Effort-driven project	以資源使用工時來做任務排程的專案。這類專案以控管工時為第一優先考量，因為它在資源使用數量及方式上，限制程度很大。
	預留工期	Reserved Duration	通常，為了應付不確定因素所造成的時間延遲風險，所增加的緩衝(Buffer)時間。風險程度愈高，預留工期愈長。決定預留工期的多寡前，專案經理及工作小組組長應共同檢視風險背後所有的假設條件及不確定因素，以確定預留工期的合理數量。
	要徑法	Critical path method (CPM)	依照專案所需工期及活動相互先後依存關係製成網狀圖，再將網狀圖的各種流程之中需要最多工期的選為要徑，根據此要徑推算及調整其他活動項目的排程，作為一個專案完成的最佳路徑。
	網狀圖	Networking diagram	將活動依照先後依存關係，以網狀圖示的方式呈現。
	資源撫平	Resource leveling	資源撫平是將專案中各活動必要資源過度使用的狀況，予以平衡成更平緩的程序，其目的在使專案全程的資源需求都能維持在合理分派的基準上(低於資源最大使用量) ，其排程係以資源的可用度及可管理程度來決定。
	基準值	Baseline	即專案活動、資源及成本相關設定數量及限制條件標準值，可於專案開始及任何階段進行中予以設定或更新，用以作為專案階段實際進度之差異分析、績效評估及變更行動之決策比較基礎。
2.3.8	成本分解架構	Cost breakdown structure (CBS)	一種階層式的成本組織架構，用來將整個專案的成本項目分解成更細的成本細目，以做為定義預算科目的依據。
	成本科目	Cost account	是指成本的類型，用以做為成本估算的分類依據。
	預算科目	Budget account	是指預算編列所使用的會計科目，用以做為預算分類的依據。「成本科目」和「預算科目」基本上是一樣的，只是使用時間點不同而已。也可以稱為「會計科目」或「費用科目」。
	控管帳戶	Control account	為指派給特定工作小組，來完成WBS中最低階交付產出的工作分包(單一或多個)之成本帳戶。其用途在做為累計工作分包費用，以做為工作分包費用及預算控管的依據。
2.3.9	風險	Risk	指未來可能發生的好或不好的事情，會造成正面或負面的衝擊。
	風險分解架構	Risk breakdown structure (RBS)	階層式的風險分解架構，用來將整個專案的風險類型及次要類型予以分解，以做為辨識及定義風險的依據。
	風險發生機率	Probability	指估算風險可能發生的或然率。
	風險衝擊程度	Impact	評估風險對專案4大目標：範疇、時間、成本及品質所產生之影響程度。
	風險優先指數	Risk priority number (RPN)	由風險的發生機率（Probability）及衝擊程度（Impact）兩者相乘之數值，以供風險排序及後續行動之依據。
	風險嚴重性等級	Degree of risk severity	指根據風險優先指數分布的範圍，介定高、中、低風險程度，用以做為風險處理及控管之優先順序決定。
	風險回應策略	Risk response strategy	為防範及減少專案執行時可能遭遇到的突發狀況或危機處理事件，所採取的應變行動目標及方法。
2.3.11	專案控管	Project control	從事「專案管理標的」之「追蹤紀錄(量測)」、「分析差異(分析)」、「檢討績效(評估)」及「更正行動(調整)」等四大活動。
	控管辦法	Control methods	指「追蹤紀錄」、「分析差異」、「檢討績效」及「更正行動」的作業流程、負責人員、產出表單及方法工具的說明。
	專案現況	Project status	包含專案的產出、工作、時程、成本、資源、品質、議題、變更、風險等項目之實際及預期發生之狀況。
	專案管理標的	Project management areas	指「產出、工作、品質、時程、資源、採購、合約、費用、議題、變更、風險、溝通」等專案必須計畫及控管的面向。
	現況差異	Status variance	專案實際產出結果與計畫基準值之間的差異。
	績效	Project performance	專案實際產出結果值與計畫基準值間的比值，如時程績效、成本績效、品質績效等。
	更正行動	Corrective action	為了避免或解決專案風險、議題、變更或造成專案實際執行結果偏離原先計畫之衝突，所採取的必要改善行動。
2.5.1.1	進度	Progress	指工作進行的實際達成程度。
2.5.2.1	議題	Issue	指那些被人關心、討論或爭論的重要話題(topic)或問題。在專案管理中，議題特別是指那些「未被解決的問題、未被調解的爭議、或未被討論的重要事件等」。
2.5.2.2	變更	Change	指那些會改變「產出範疇、工作範疇、專案計畫及合約內容」的議題事件。變更會對專案產生正向或負向的衝擊，同時會改變相關的專案計畫、文件或合約內容。
2.6.3	完工移交工作	Completion handover work	將已完成完工驗收的專案或工作分包，交由接收方接管之相關作業。
	完工移交項目	Completion handover item	通常包含「專案完成後應交付的軟體、硬體、設施及文件。同時，也可能包含這些軟體、硬體、設施之操作及維護人員的能力(如知識、技術及經驗)等」。
	完工移交對象	Completion handover receiver	指負責接收完工移交項目的人員或單位。完工移交工作包含負責「工作分包」的工作小組組長向專案經理來進行完工移交的工作，或專案經理向接收單位來進行完工移交的工作。
	完工移交策略	Completion handover strategy	完工移交的策略有「階段式移交」或「一次式移交」等兩種。「階段式移交」是在專案進行的過程中，分階段來進行移交的工作。「一次式移交」則僅在結案時才來進行。
2.6.4	合約行政結案工作時間	Contract administrative closing time	各別合約廠商根據實際完工驗收及移交的時間，來進行此工作。因此，不需要等到整個專案完成後才來辦理。

　

(單元結束)

Top