專案品質管理包含專案和專案產品的管理。產品品質度量和技術或許會因專案產品的特定類型而異，不過無論專案產品性質如何，專案品質管理適用於所有專案。雖然軟體產品和蓋核電廠的品質管理做法和度量大不相同，但是專案品質管理卻對兩者都適用。
長久以來品質一直被視為顧客主觀的滿意度，「如期、如質、如預算」是每一個專案經理人揮不去的夢魘，就像孫悟空頭上戴的緊箍咒，只要顧客（唐三藏）不滿意，專案經理人（孫悟空）就頭痛，無法結案，甚至犧牲了時間和成本的基準，一味討好顧客，造成進度落後與成本超支。
品質管理應該從品質規劃開始。品質規劃包含品質政策、規定、政府法規、程序、範圍說明等等，透過績效度量基準（即範圍基準、時程基準、成本績效基準），以及關係人登記簿和風險登記簿這兩個資料庫，去擬定品質標準和品質管理計畫。
專案只要符合範圍基準、時程基準、成本績效基準的要求，就算是符合專案品質標準，也就是符合專案管理計畫；此時即使顧客不滿意，專案經理人也必須設法與顧客溝通，讓顧客接受專案的成果。
品質持續改善之所以能夠提高生產力，主要原因是可以減少重工（Rework）。只要符合績效度量基準，專案團隊成員就不必擔心被顧客要求重工，把浪費在不良品質的成本節省下來，就可以降低成本並提高生產力。專案的績效度量基準（PMB）是由範圍基準、時程基準、成本績效基準所構成。範圍基準、時程基準和成本績效基準，都是專案管理計畫的一部分。
範圍基準（Scope Baseline）包含專案範圍說明（PSS）、工作分解結構（WBS）、工作分解結構辭典（WBSD）三部分。其中，專案範圍說明包含：
(1) 產品範圍說明—如產品的功能與特性。
(2) 專案交付項目—如完整產品驗收的流程和準則。
(3) 產品驗收準則—如完成產品範圍所要做的工作。
(4) 專案界限—包括專案範圍的正面表列和負面表列。
(5) 專案制約—記載於合約之預設的時程（里程碑）和預算。
(6) 專案假設—指和專案範圍相關的專案假設。
至於工作分解結構則是將交付項目進行階層式的分解，以利專案團隊執行。WBS階層的最底層稱為工作包（Work Package），相關的工作包可以整合為統制帳戶（Control Account），兩者都有獨特的識別碼，用以估計成本、人力、時間以及評估風險。統制帳戶的範圍、成本和時程會整合起來，並與作為績效度量的實獲值進行分析比較。
針對每一個WBS組件（工作包和統制帳戶），都必須提供一頁詳細的技術資訊說明，匯集所有的說明後，就構成工作分解結構辭典。
時程基準（Schedule Baseline）是根據時程網路分析所提出的專案時程特定版本。在專案管理團隊認可與核准之後，標明基準開始日期和基準完成日期的時程，就可當作時程基準使用。
成本績效基準（Cost Performance Baseline）是按時間分段的預算，作為度量和監控專案整體成本績效的基礎。它按時段匯總已估算成本，通常以S曲線的形式表示。
經理人應該了解專案的績效度量基準（PMB）是由範圍基準、時程基準、成本績效基準所構成，而這三個基準根本就是專案管理計畫的一部分，因此專案只要符合範圍基準、時程基準、成本績效基準的要求，就算是符合專案品質標準。
看你寫專案管理已經很多篇了.
雖然這不是我研究的主要項目.
但就軟體工程而言專案管理也是很重要的.
但就以我目前的環境.我們主要的工程師或主管都具CMMI Lavel ?的認證.
但管理專案的能力還是?
能否講講你的故事和實務,不是那種理論性的.而且比較接近事實的.
比如說:
時間跟成本和品質..你如何取捨,決定..
如:剩一個月專案需完成,你遇到開發問題,但你有三個解決方案.
1.獨自開發,但品質較難掌握.
2.買元件,但成本會超過預算.
3.多請一個員工協助開發,但找人的素質跟進度都無法明確掌控..
你如何去決定跟處理?
.我們主要的工程師或主管都具CMMI Lavel ?的認證
我所熟悉的CMU/SEI所制定的CMMI是不對個人做認證的
Level ? 是對組織的評鑑 分為 CL 和 ML
CL共有6個 Level
ML共有5個 Level
國內大都走ML，不過號稱ML5的公司的專案管理還是一蹋糊塗
基本上你談的根本不是專案管理的實務問題，比較像益智問答
範圍、時間、成本是決定品質的三要素
專案管理視為一樣重要，不會有取捨問題
為何獨自開發,品質會較難掌握?
為何買元件,成本會超過預算?
為何多請一個員工協助開發,找人的素質跟進度都無法明確掌控?
這些假設性的問題都應該在規劃階段就做好風險管理,定出風險回應策略
而不是頭痛醫頭腳痛醫腳臨時抱佛腳
我不知是實務問題,也不知是否是益智問答?
我只知道這是我在IT界多年來一直出現的問題.
1.為何獨自開發,品質會較難掌握?這是必然的,你要開發東西,關鍵點,關鍵技術加上一些因素,就品質上有風險.對你專案師角色你當然不認為是風險.因為很多管理者都認為你程設師就是可以把量跟質做好.
2.為何買元件,成本會超過預算?我以前就遇到阿呆專案經理,去跟客戶談一個案子,那個案子才幾十萬而已.但他那案子有用到別家公司的元件(他以為那是自己研發的),元件要60萬.當系分師告訴他時,眼淚都快流出來.
買元件要考量的東西並不是那麼簡單.
3.為何多請一個員工協助開發,找人的素質跟進度都無法明確掌控?
你以為請人有那麼容易?技術上,態度上,融合上...有時找一個人要好幾個月.這個專案結束後,這個人要怎麼定位?
這些都不是假設性的問題.比如說專案執行間有成員離職!有成員出去不小心被雷踢到..這些要隨機應變的.
風險（Risk）就是尚未發生的問題，是指事件發生與否的不確定性。
風險有三種等級：(1)已知(2)已知未知(3)未知未知
(1)已知（Known）：經理人深知該項目會影響專案，卻無計可施。例如：客戶要求提前3個月完工就是已知風險。
(2)已知未知（Known-unknown）：經理人深知該項目會影響專案，但是卻無法預測是在何時或是到底會造成多大影響。例如八八水災和H1N1都是已知未知風險。
(3)未知未知（Unknown-unknown）：風險超出經理人能力，無法預知可不可能發生。例如電影《2012》描述，在2009年時科學菁英團隊向美國總統證實，地球即將在2012年毀滅……，然而這畢竟只是電影情節，即使地球有可能在2012毀滅，我們也無法預知。因此，世界末日的到來就是未知未知風險。
除了未知未知風險，在IT界多年來一直碰到的問題，其實都是已知未知或已知風險。在問題還沒出現之前(尚未發生的問題就是風險)，其實都可以透過風險管理來預防，並在規劃階段就未雨綢繆定好風險回應策略。
專案管理遇到系統整合，自己的經驗是「沒人理會。」
sunallen提到：
專案管理遇到系統整合，自己的經驗是「沒人理會。」
能收到錢就好...工程師累死是工程師自己時間分配的問題...
tecksin提到：
能收到錢就好...工程師累死是工程師自己時間分配的問題
不要被時間管理了...
說明一下我的背景
當了30年的IT人，由於輔導許多SI公司導入CMMI
發現連 ML2 的專案管理都做不好 卻想一步登天 ML5
最近五年才從CMMI中專攻專案管理，認真地學PMBOK
發現國內絕大部份的IT人都有很豐富的專案執行經驗
但是談到專案管理卻都是土法煉鋼自以為是
frankmclin提到：
發現連 ML2 的專案管理都做不好 卻想一步登天 ML5
這不是要照順序來嗎?? 能夠一次就到ML5嗎??還是我搞錯了....
光從評鑑角度來看這是可行的
ML5評鑑範圍包含ML4，ML4包含ML3，ML3包含ML2。
ML2重點在專案管理，ML3等於專案管理 + (軟硬體)工程，ML4還要再加上量化，ML5則再加上創新與流程改善。組織並不需要每個ML都去做評鑑 (很貴的)。只要符合評鑑要求，一次到位並不違背評鑑遊戲規則。
真正問題是顧問與業者聯合做假....
建議還是從ML2的專案管理開始按部就班做好紮根工作
frankmclin提到：
真正問題是顧問與業者聯合做假....
+1
自以為是的說不定正是你自己喔!
先別生氣, 我來陳述我的理由....
PMP/CMMI都是前人的Good Practice/Best Practice, 用了PMP/CMMI,也沒有保證專案一定成功, 不用PMP/CMMI, 也不一定專案就會不成功, 這些前人的經驗, 都只是讓我們在專案管理知識領域摸索的過程中, 可以找到捷徑, 可以了解可以怎麼做, 或是怎麼做比較好而已.
往往各位看到失敗的專案, 都是以為沒有照PMP/CMMI的心法, 這當然太容易推論了, CMMI是重量級的方法論, 那請問用SCRUM開發專案會不會成功? 誰說專案一定要用瀑布模式, 寫這麼多文件? 如果相關主客觀環境配合得好, 可不可以不寫文件, 專案照樣成功?
成功, 沒有一定的法則, 複製別人成功的經驗, 固然是一種作法, 但是不代表不這樣做, 一定不回成功. 品質管理強調的找Root Cause, 請問在這個推論下, 專案是否成功, 是否有沒有做CMMI/PMP是Root Cause呢? 各位可以再思考看看.
在我看來, 許多公司RUN CMMI會失敗的原因, 都是只學到了CMMI的皮, 沒有遵循CMMI的骨, 各位說的CMMI導入只是為了拿評鑑, 這的確是原因之一, 我看到的問題通常則是在每個流程領域, 大家太過強調了SG(特定目標)與SP(特定執行方法), 常常卻忽略了每個流程領域都會出現的GG(一般目標)與GP(一般執行方法), 反而成為失敗的Root Cause.
GG跟GP在說甚麼? 最常見的, 就是要評估是不是有執行這個流程的資源(人力), 能力, 規劃, 教育訓練等等, 基本功都沒打好, 怎麼遑論要使用CMMI成功?
我覺得最可笑的是, CMMI雖然強調是組織能力的成熟度, 但往往很多人是因為組織導入了CMMI, 個人學習到了一些執行工作的技巧, 就以為自己懂了CMMI, 然後抱怨組織不瞭解CMMI. 於是, CMMI最大的效用, 反倒是建立了個人的能力, 對組織能力幫助反而有限!?
如同前po所說, CMMI是重量級的方法論, 要run CMMI, 前提就是要有做很多工作(尤其是paperwork)的心理準備, 人員不成熟, 人力不夠, 想玩CMMI成功, 難度本來就很高. CMMI會不會變成台灣軟體界的笑話, 很值得期待喔!
iThome鐵人賽
看影片追技術