本文章之參考資料來源為:
- PMI PMBOK 3rd
- 2005 Rita Mulcahy PMP EXAM PREP
在Project進行過程中, 需求的變更是不可避免的事情, 而PM的職責也不是在阻止這些變更需求的出現, 而是如何確保當變更需求出現時, 保護原本就已在進行中的Project, 並使新提出之變更需求得已合理地加入Project中:
1.釐清需求變更內容
PM需先與需求變更提出者進行討論, 以釐清變更需求的目的以及內容, 藉由此步驟, 可以過濾與原Project不相關之需求
2.評估變更需求所帶來的衝擊(Impact)
若依PMBOK 3rd所提到的, 需要就Scope, Cost, Time, Quality四個重要構面進行評估. 因為需求的變更往往需要新的Resources來配合, 更可能的, 會影響原先進行中Project的schedule, 而且, 若為了維持原承諾的schedule, 可能會犧牲部分的Quality, 故PM需就Scope, Cost, Time, Quality四個重要構面進行評估, 以確定所有衍生的衝擊
在2005 Rita一書中, 提到要考慮的, 包括Scope, Cost, Time, Quality, Risk, Customer Satisfaction六個構面. 個人也贊成再加入Risk以及Customer Satisfaction.
- 一般需求的變更將帶出更多不在原先考量以及已識別的風險, 甚至原來不構成風險的因素卻因需求變更而成為風險, 所以PM需要與Project Team就整體Project Risk重新進行評估.
- 而整個PMP一再強調的, 是需要把所有相關的Stakeholders的意見納入考量, 所以某個Stakeholder所提出的需求變更, 可能其他的Stakeholder並不願意該變更納入該Project的scope, 所以, PM需要就此需求變更所可能引起的Stakeholder反應進行評估, 一旦評估可能會影響客戶驗收的意願時, PM就必須小心行事
※若被提出之變更需求與原Project無任何關係, PM應該要作的, 是另外kick-off一個新的Project來進行, 而非將之加入原進行中的Project, 畢竟此新的變更需求與原Project無關係, 所以也不適宜使用原Project之resources
3.找出各種解決的方案
需求變更造成的最大衝擊有可能是Schedule被迫異動, 以及所需的Resource需要追加. 此時, PM需要就各種可能的解決方案進行沙盤推演, 如果客戶堅持Schedule不變, 則PM就需要提出各種方案來安置此變更的需求(可以是加入更多的Resources, 或是把需要循序進行的Tasks改成同時進行的方式, ...).
4.將變更需求的相關資訊提交Integrated Change Control System進行討論
在第二步驟中所有被找出的各種解決方案需要提交Integrated Change Control System進行討論. 此流程會就各種可能的衝擊以及可能的解決方案進行討論, 當然, 討論的結果不一定會是接收此需求變更, 也可能認為此變更需求的影響層面過大, 或不符原Project的目的而作出退回的決議.
若是Integrated Change Control System決議退回, 則PM需妥善回應給原變更提出者. 若確定要將此變更納入Project, 則PM就需將相關的後續處理方案移轉給Project Team
5.取得內部Stakeholders的同意
PM將需求變更的決定以及可能的解決方案向Project Team進行announce, 並取得Project Team的共識. Project Team的反彈亦是PM需要妥善處理的, 因為需求的變更往往代表的是已完成的工作需要重作或是需要更多的投入, 而這些都可能造成Project Team士氣的低落, 故PM需要特別注意需求變更所帶來的負面衝擊
6.取得外部Stakeholders的同意
再者, 如前述所言, 整個Project的Stakeholders並不僅提出需求變更的一方, 可能會有其他的Stakeholders不樂見到需求的變更, 此時, 就需要PM進行協調; 此外, Integrated Change Control System所作出之同意變更有時其作法不見得完全符合變更提出者的想法, 故PM仍需就未來因應變更的作法與原提出者達成共識
7.開始進行需求變更
留言列表
