個人資料保護顧問的旗艦店

專案需求變更時到底應該要從哪幾個部份進行分析

專案需求變更時到底應該要從哪幾個部份進行分析是個有爭論的議題, 從PMI規範PMP的內容來看, 是從Scope, Cost, Time, 以及Quality四個點來分析.

在PMP一直提到, 專案Scope若有異動, 需要透過一個"Integrated Change Control Process"進行審議, 方能決定是否要進行Scope的異動. 當然, 有一個名為"Integrated Change Control Board"小組會進行此一連串的審議作業. 其在審議的依據, 需要靠PM提供該Scope異動所造成的Impact, 以及相關的Solutions.

最近在上課時, 同學提了一個問題, 需求在經過Integrated Change Control Process審議後, 如果決定不異動Project Scope, 那是要先通知當初提需求的人? 還是先通知主管? 說實話, 這個問題我個人是覺得很難回答, 雖然在那個時間點, 我硬掰了一些答案. 先通知誰有那麼重要嗎? 是的, 真的很重要. 以這個例子來看, 如果主管認為提出需求的人是很重要的, 不論有什麼樣的需求都必須儘量滿足, 那在Integrated Change Control Process完成後, 就需要先通知主管, 因為主管可能會作出翻盤的決定, 可是, 如果有這種情況發生, 只能說這個公司的專案管理制度是有問題的, 因為經由Integrated Change Control Process所作出的決定就已是最後的決議, 不管背後有再多的政治因素, 都應該已在Integrated Change Control Process進行過程中被充分討論, 而不是在決議已出後再推翻決議. 當然, 有人會說, 主管並未表達他的意見, 是的, 那這個問題就出在Integrated Change Control Board的組成份子. 如果企業內認為主管的意見真的很重要, 則當初在建立Integrated Change Control Board時, 意就應邀請主管加入, 畢竟主管也是組織中的資深同仁, 是有資格參與運作. 但如果一開始未加入Integrated Change Control Board的運作, 理論上, 透過此小組所作出的決議就不再有任何可能被推翻, 當然, 除非以新的需求變更來還原已被異動過的Scope.

Negotiation, 談判, 會出現在眾多場合中, 本文將就採購欲進行談判前的準備工作作一個簡單的說明:

1.釐清到底該次談判的主題到底為何?

在一般的Project中, 最常遇到的就是客戶對專案時程的要求比PM所預估的更緊, 對於一般的PM(東方)來說, 不外乎就下列幾種作法:

1. 加班

Earned Value, EV: 一般會翻譯成[實獲值], 實際已獲得之數值

這種技術一般用在專案管理中, 用以衡量專案的執行績效. 當然, 要衡量就需要有一個衡量的基準, 這個基準就是俗稱的Baseline.

Cost Center:成本中心, 也就是在企業中, 每個部門的預算使用都歸屬於某個中心, 這個中心就是所謂的成本中心. 在實施成本中心的企業內, 每個單位在使用預算會十分小心. 舉個例子, 在未實施成本中心的企業中, 資材單位提出要建置一個資訊系統, 此資訊系統的所有建置成本會計算在資訊單位頭上, 資材單位不痛不癢. 但在實施成本中心的企業中, 所有建置成本就會歸屬到資材單位. 實施Cost Center的企業會讓組織內每個單位在使用預算時較為小心謹慎, 因每單位的支出會在Cost Center中顯示, 同時被Review

本文章之參考資料來源為:

1. PMI PMBOK 3rd
2. 2005 Rita Mulcahy PMP EXAM PREP

這是一個老掉牙的老梗了，本來也不太想拿出來講的，不過在講課時，跟同學談到這個問題，也是眾口紛芸。想談這個問題，是想從比較實際面來看，如果要看從理論下手的，JavaWorld聊天版的那個Thread:『有沒有不會寫程式卻在作系統分析師』已經有破八百的超強人氣，很是可以參考看看，不過，真的看看就好，裡面有一些是真的很火爆。

站在一個PMP Certified的立場而言，PM可以是一個臨時抓來的路人甲，對於Project的Domain know how本來是可以選擇當作失憶，完全不懂，...等等，看到這，也許有人不認同，ㄟ，Please wait a moment，請再看下去。要作到PM可以是隨便找來的路人甲，其中這個PM得身具很多特異功能，包括他(她)必須能找到有Domain know how的staffs，這些staffs會代替PM來watch PM所不熟悉的那一塊，以及協助評估整個Project所需要使用之Resources以及相關的Risk，當然，這時候PM所站的角度是在最後決策的那一個關卡，看到這裡，大概又有人要問: PM不了解Domain know how，怎麼去作最後的決策? 是的，這就要帶出第二個重要的點，這些協助PM的staffs就必須是PM可以完全trust的，這些staffs要就各種情況以及問題提出各種構面的分析以及建議，當然，這些資訊需要充足到能讓完全不了解Domain的PM可以有作出決策的判斷。但，人就是人，再怎麼值得信賴的staffs，也很少有不為自己著想，即便不為自己著想，也要為所帶的team members著想，就算不為team members著想，team members也會逼著staffs或PM要為他們留後路。所以就會在各種需要決策的問題點上，多少會為自己留下一點後路，舉個例子: 在評估所需之執行時間，大部分的人會多留一點buffer，以避免開天窗，但這往往與客戶的要求背道而馳，這時候，staffs所提供的schedule estimation往往就在預留buffer的情況下失真，那PM該不該相信staffs所提出的評估報告呢? 如果PM有足夠的Domain know how，那PM可以就此退回此份schedule estimation嗎? 這是一個立場性的問題，即便是PM有能力作出判斷，但schedule的壓縮所必須擔負的風險是產出品質不佳，而PM正是在未來要背負這種品質控管不好罵名的那個人，所以，PM也會有PM的堅持，而這些往往並不與PM是否有專業know how沒有決對上的關係。當然，如果staffs所提出的數據過於離譜，又無法提出合理的解釋，那PM根本就可以直接作出判斷。所以，在這種論點之下，PM是否需要是該Project領域內的專家，其實並不那麼重要，這就是: 『一隻狼帶著一百頭羊打的仗好，還是一頭羊帶著一百隻狼打的仗好』，這是一個各有立場的問題。

本文章之參考資料來源為:

1. PMI PMBOK 3rd
2. 2005 Rita Mulcahy PMP EXAM PREP

看來要先澄清PMP的考試規定:

1.應考前需有35PDU, 且需PMI認可之訓練單位核發