5.1.3.1的Requirements Documentation是否流入4.2Develop Project Management Plan?

近來有一位朋友問了很多有關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)!但肥蝦以為針對這些在你的邏輯架構屬於例外的部份就特別記一下就好了!(一本書由多人所作,因此有些前後稍微衝突的地方在所難免!)

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

誠信才是永遠的!-"誠信"漂流記讀後感

今日收到一位好友寄來一封聽說是對岸那邊聯考的作文─"誠信”漂流記

內容如下：
----------------------------------------------------------------------------
話說誠信被那個“聰明”的年輕人投棄到水裡以後，他拼命地游著，最後來到了一個小島上。“誠信”就躺在沙灘上休息，心裡計劃著等待哪位路過的朋友允許他搭船，救他一命。

突然，“誠信”聽到遠處傳來一陣陣歡樂輕鬆的音樂。他於是馬上站起來，向著音樂傳來的方向望去：他看見一隻小船正向這邊駛來。船上有面小旗，上面寫著“快樂”二字，原來是快樂的小船。

“誠信”忙喊道：“快樂快樂，我是誠信，你拉我回岸可以嗎 ？ “

“快樂”一聽，笑著對“誠信”說：“不行不行，我一有了誠信就不快樂了，你看這社會上有多少人因為說實話而不快樂，對不起，我無能為力。”說罷，“快樂”走了。

過了一會兒，“地位”又來了，誠信忙喊到：“地位地位，我是誠信，我想搭你的船回家可以嗎？”

“地位”忙把船劃遠了，回頭對“誠信”說：“不行不行，誠信可不能搭我的船，我的地位來之不易啊！有了你這個誠信我豈不倒霉，並且連地位也難以保住啊！”

誠信很失望地看著“地位”的背影，眼裡充滿了不解和疑惑，他又接著等。

隨著一片有節奏的卻不和諧的聲音傳來，“競爭”們乘著小船來了，“誠信”喊道：“競爭，競爭，我能不能搭你的小船一程？”競爭們問道：“你是誰，你能給我們多少好處？ ”

“誠信 ”不想 說，怕說了又沒人理，但“誠信”畢竟是誠信，他說：“我是誠信……”
“你是誠信啊，你這不存心給我們添麻煩嗎？如今競爭這麼激烈，我們‘不正當競爭’怎麼敢要你誠信？”言罷，揚長而去。

正當誠信感到 近乎絕望的時候，一個慈祥的聲音從遠處傳來：“孩子，上船吧!”，一個白髮蒼蒼的老者在船上掌著舵道：“我是時間老人。”“那您為什麼要救我呢？”誠信問道。 老人微笑著說：“只有時間才知道誠信有多麼重要！”

在回去的路上，時間老人指著因翻船而落水的“快樂”、“地位”、“競爭”，意味深長地說道：“沒有『誠信』，快樂不長久，地位是虛假的，競爭也是失敗的。”
-----------------------------------------------------------------------------

這篇文章肥蝦以為可以作為一個專案經理在做利害關係人溝通管理之時的註腳!

一個專案當然專案經理要設法建立公司,專案團隊在利害關係人心中的credit!唯有credit才能使得利害關係人對專案有信心,對你-專案經理有信心!

任何手法都是一時的!最重要的是一旦您的或專案團隊的credit失去,你將一無所有!

就順序上來說,肥蝦個人的作法如下:

利用公司的credit接下案子->建立PM的credit->建立專案團隊的credit->建立公司在這個專案的credit!

如果利害關係人已經認為公司是騙人的,你一定要設法保住您專案經理的credit!否則此專案必敗無疑!

因讀到此篇文章心也所感,肥蝦特與各位一同分享!