(承前文) 故事繼續之前，我們先來聊聊到底是怎麼讓事情變成這樣的吧。

到底誰是壞人呢…
是Eric嗎？

Well, 雖然Eric因為沒有誠實面對造成一些問題 - 從一開始他因為恐懼所說的小謊(跟老闆說很容易就能解決)，讓他之後騎虎難下而沒辦法坦然面對真像。 不斷的繼續做假，才造成整個狀況惡化至此。 這部分當然是有他的責任，但卻不是我最想要談的東西。

一來，我並不打算從道德的角度來看這件事情，畢竟若故事講了半天只是宣導人要誠實，也未免太八股太無趣了吧? 我還不如直接貼華盛頓砍櫻桃樹的故事，最少不用自己寫的累得要死。

再來, 誠不誠實其實也不是關鍵。 誠實當然可以讓問題簡單些，讓大家早點可以開始導正。 但他的粉飾太平卻不是最根源的問題。 說到底，這件事情無論他誠實也好不誠實也好，其實都不能改變「問題已經發生了」這點 (別忘了，問題已經發生了，他的不面對只是讓問題加劇罷了)。
 

聽起來像是某種詭辯嗎？ 實際上我要說的是：今天不管是誠實的Frank來帶這案子也好，或是比較膽小的Eric來帶這案子，結果可能不會有所不同；相同的問題都會面對，唯一差別只在於「誰能提早救火」。 可是，提早救火始終不是我們喜歡的狀況啊！ 如果可以，我們希望火最好根本別燒起來。

所以若回歸原始的話，始作俑者其實是那位「認真上進又謙卑的年輕工程師」(更糟的是，他可能根本沒想過他做了甚麼有問題的事情)。 但是的，他才是罪魁禍首….

只是，我們在此責怪一位認真上進又謙卑的年輕人是對的嗎？
唔，這是個好問題。 但我的答案是：「對、也不對」。

先來談對的部分。 

若我們把同樣的故事架構換個情境，看看大家看法是否會不同。 假設這位年輕人今天並沒有自己發現規格上的錯誤。 但他曾經因為聯誼或甚麼活動認識了客戶端撰寫合約的一位小姐。 專案開始了後的某天，這位約過會的小姐打了電話給他：「怎麼辦，我某個規格數據Key錯了，結果都沒人發現。 糟糕的是，合約都簽了，萬一東西有問題老闆會罵死我的。」 接下來就在電話另一端哭的是梨花帶雨讓人好不心疼。 而這位年輕人單純又浪漫，哪裡能忍受美女的眼淚呢；於是一瞬間心中湧起了某種激動，大聲的告訴她說：「別哭了！ 我會想辦法把規格參數改過來，沒人會知道的。」 改好後，為了避免佳人被罵，他沒告訴別人 - 包含其他工程師、包含Eric、以及所有其他部門。

 

OK，理由不同了，但做法還是相同，最後也產生了同樣的結果；這樣有稍微讓整件事情沒這麼正義了吧？

 

好吧，好吧。 如果還是有人因為剛剛的情節存有某種浪漫性，覺得為了愛情的名義是可以原諒、深信真愛無敵的，那我再改改故事的架構如何？ 如果他認識的客戶端人員僅僅是他同學、是他親戚，打了電話請託叫他改，他就便宜行事的改了呢?

 

好吧，那再極端些。 如果是因為自己不會做所以亂改設計；或是因為收了甚麼賄絡而協助私下改了規格呢？ 或是他是產業間諜故意要搗亂的？

 

當然，這次他是因為一片好心所以做了一些調整，但是從結果論而言，他的行為是非常嚴重的。 可以試著想像，一個大型的專案(如NASA發展太空船)，包含的人將非常的廣。 如果大家都不按照原本規劃的方向、做法、合約、規格走，自己聽到了一些甚麼風聲，自己感覺到哪裡錯了，就私自改了。 改了也不告訴別人，也不留下記錄。 這樣搞下去，最後做出來的東西要是整合的起來，太空船要能起飛，恐怕才有鬼吧？

 

這叫Scope Creep (之前有聊過)。 Scope Creep其實是非常非常可怕的東西，因為在這次的故事中，大家也不是不認真做、沒人偷懶、也不是因為問題或是意外而Delay。 但偏偏東西做出來就是完全不合乎合約要求，這不是很慘嗎?? 所以這位年輕人自然是有責任的；但等等，我前面也有提，也不能完全責怪這位年輕人。

 

為何不完全能責怪這位年輕人呢。 因為這是專案負責人自己，也就是Eric在專案開始前，沒有思考到這部分的規劃；他沒有提出任何「變更管理的機制」 (Change control management)。 他才是最該責怪也最該負責任的人。

 

但甚麼是變更管理呢?

 

我們都知道，專案進行中，一定會有大事小事的變動發生。

最大的可能是客戶要停止專案。

次一些的可能是客戶想變更產品的功能、或是改變交付標地等。

中一點的可能是我們發現更好的技術或是材料想要改變做法降低成本。

小一點的則可能是我們要調整專案的實際執行順序、改變工作的人員等。

也可能是工程師發現合約或是規格有甚麼錯誤。

 

但不管是甚麼理由而需要改變，並不是自己覺得好就好；並非大家自以為是「為了專案好」就都該率性的執行下去。 大部分的改變可能牽連甚廣，有時候不是一兩個人就可以評斷的。  所以這些可能造成專案大幅變異的事情，都應該通知專案的負責人，甚至技術相關的專家或主管；甚至更嚴重的應該要讓更上面的高階決策者或客戶知道。 此外，一個案子可能做個三年五年，但好心的年輕人可能中途離職了。 所以也可能最後有問題時大家卻完全沒人知道當時發生了甚麼事。

 

所以如何追蹤變更、評估變更、審核變更、執行變更、並記錄變更是一整套應該要預先定義的遊戲規則。 而做為一個PM，專案開始前要做一些預防的規劃。 Project Charter是一個，Change control management plan是另一個。

 

寫流程可能大家覺得無聊，所以我直接用狀態來做形容。

專案必然會碰到一些變更。 這些變更，首先要確保技術主管、以及專案負責人要能被知會。 (舉例來說，年輕的工程師應該要先回報他的發現)

 

只有他回報後，了解變更可能影響性的人才能評估該不該做變更。 (舉例來說，由更資深的工程師來評估這位年輕工程師的發現是不是為真。 甚至在這情形下，若我們懷疑是客戶規格開錯，我們也該知會客戶這個發現。)

 

再來，如果確定這變更是有必要的，那我們要再來評估，變更後可能造成甚麼影響？ 是不是會造成後面工作的Delay、Delay多少? 或是造成人員無法調度、或是造成大幅成本超支這類的問題。 (舉例來說，改設計那件事或許只是簡單的調幾個數值，但可能會造成後面的東西全部要重新設計與開發。 那就得思索這變更是否值得。)

 

當評估完成後，還要有人來真正做決定，告訴大家是不是真的該變異(做Approve的動作)。 (評估完後，該跟客戶報告說合約有這些問題。 我們可以怎麼幫忙解決，可是影響性可能會是怎麼樣。 客戶要自己評估到底甚麼是他要的？ 是那個合約上似乎不正確的規格、還是要改成業界的標準？ 這是很重要的，我們是絕不該也不能代替客戶做決定，畢竟我們又怎麼知道客戶不是有特殊的目的才把規格定這樣的？)

 

再來可能要談合約調整。

(舉例來說，客戶接受調整規格，可是後面時程的延誤，甚至成本的增加那是不是要重新議約來提供我方補償或是甚麼其他優惠。)

(再舉一個例子，如果合約執行了三年，若三年後驗收的人根本不知道來龍去脈。 你跟他說：「Hey這是因為當年的變更才變的跟合約不同的啊」。 他說：「我不管，一切照著合約走。 你交個我跟合約一致的東西出來吧!!」 那不就尷尬了..)

 

再來，專案負責人或是PM要來根據改變的內容來調整執行計畫。

(如此，後面的人才知道變了甚麼東西、新的Schedule是甚麼、自己哪些工作被影響了，也才知道哪些數據才是正確該用的。)

 

然後才是有人把變更執行。

(這時候，我們這位年輕正直有上進心的工程師才該去執行他的發現)

 

最後則還要記錄變了甚麼，目前狀態如何。 這樣日後才能追蹤、才能檢視、才能了解到底專案進行中根據不同的理由與原因我們做了哪些改變。

(舉例來說，某天心血來潮，很可能某個完全不瞭解專案的高階主管發現怎麼比原始合約完成日期晚了一大段時間還沒做好，問說：「怎麼DELAY這麼嚴重？」 我們總要能證明是因為什麼原因DELAY吧。 甚至可能還要證明，變更後，根據新的Baseline，我們其實比修正的時間表還來的進度超前都不一定。)