PMP達人-專案管理經驗成長與學習 IT肥蝦個人的專案管理經驗與心得記事與分享。

67愛的鼓勵 2訂閱站台

        近來有一位朋友問了很多有關4.2 inputs的問題,肥蝦我個人建議他看一下PMBOK page 49的Figure 4.5!但4.2.1.2的說明跟Figure 4.5有一個衝突點：即是Requirements Documentation是否流入4.2Develop Project Management Plan.
      
        基本上,4.2.1.2的Outputs from Planning Processes基本上主要是三個baselines跟十二個子計畫(可從PMBOK 4.2.1.2的說明可知),但如參考Figure 4.5可以發現5.1除了 Requirement management plan流入4.2外又多一個requirements documentation也流入4.2.1.2! 這requirements documentation是有點爭議性的!

        以肥蝦個人的理解,就從整個PMBOK的角度,可以把4.2看成是做完各個領域的規劃後進行彙總的過程:
(1)所以首要的是先確認專案的存在與業務(Business)的要求(=>project charter).
(2)再來是彙總所有規劃程序主要產出的子計劃跟baseline,追求其間的一致性,總不能子計劃之間彼此打架吧!(=>Outputs from Planning Processes).
(3)另外因為是我們的組織要在現有的環境下去執行它,所以現有週遭環境法令的限制,公司的組織與資源,以及以往公司或外界相關的經驗,都可以拿來作參考或調整的依據.(=>Enterprise Environmental Factors;Organizational Process Assets)

        由於此處的工作主要是進行彙整,最重要是需要專家的能力進行處理(Expert Judgment),而產出當然就是在專案執行,監控,結案所要依據的規範了(Project Management Plan)!

        因此你可以想成如果其他規劃流程的產出是為了完成相關的子計劃或baseline,基本上就不會再流入4.2了.因為4.2要的是所有領域規劃的最終可納入專案後續作業依據的產出!

        只有requirements documentation要特別留意一下!就規劃的流程,你可發現:5.1的output:Requirements Documentation會留入5.2產生Project scope statement(還有project document updates=>當然就是指Requirements Documentation);以及5.3配合Project Scope Statement一起產生WBS,WBS Dictionary(還有project document updates=>當然就是指Requirements Documentation).以及12.1去判斷那些需要外購,進而有Procurement Management Plan與Procurement Documents!

        因此基本上5.3的產出Scope Baseline,在規劃的產出而言,已能大體上包含了Requirements Documentation的要求!因此就PMBOK的文字說明僅寫了Outputs from Planning Processes是代表baseline and subsidiary plans. 可是在Figure 4.5又特別把requirements documentation列為4.2的input!當然也是可以把他想成requirements documentation是客戶/USER的原始要求,因此需要在彙整Project Management Plan時需要再特別的考量(在Project Scope Statement中有所謂Project exclusions)!但肥蝦以為針對這些在你的邏輯架構屬於例外的部份就特別記一下就好了!(一本書由多人所作,因此有些前後稍微衝突的地方在所難免!)

        以上是肥蝦個人的淺見跟說明,還請   參考!