象大多數(shù)的故事一樣，這個故事也發(fā)生在很早以前。但是當我談起它的時候，傷疤依然疼痛。我曾經在一個軟件開發(fā)團隊工作過，這個團隊拼命的想生產一個產品，或者是只要能使用的任何東西。由于過去項目的失敗，這個團隊盡管許多基礎建設已經到位了，但是卻缺乏成功的向導和跡象。你可以說這個團隊存在，但是缺乏清楚的組織結構和許多達到成功的必要的商業(yè)要素。這個團隊的使命和眼界被一個受過良好教育，可是很可能沒有經驗的新領導人弄得墨成一團。
至于商業(yè)需要，它們一直在那兒。幸運的是，操作系統(tǒng)滿足了穩(wěn)定的最小需要。但是同樣遺憾的是，這些系統(tǒng)并不能適應快速改變的環(huán)境，而且在許多年后，也超過了它們的平均壽命。為了替換這些老化的主機，執(zhí)行者提出了一系列的 “改進創(chuàng)新”。執(zhí)行這些創(chuàng)新對開發(fā)團隊而言，幾乎不需要優(yōu)先級考慮并且甚至只需花費更少的錢。
許多內部的項目不過是在重復著勞動和競爭?！百I一套ERP軟件，定制它來滿足我們的需要”，“為什么我們要重新發(fā)明輪子呢”。那些是來自團隊內的經常的喊聲，也是一個來自企業(yè)失敗項目的教訓。經過了與巧舌如簧的銷售人員一道玩若干回高爾夫和共進幾次兩小時的午餐的結果就是為一套ERP軟件投資幾百萬美元。但是那只不過是買License的花費。
模型、標準和認證
“我喜歡用老軟件，為什么我一定要改變？”，用戶、軟件開發(fā)人員、需求分析師、項目經理和股東都面臨著對即將到來的變化的相互間的抵制。
明顯的，需要正規(guī)的項目管理。而執(zhí)行管理層選擇了CMM作為銀彈工具?！爸灰@樣一個基礎組織就位，所有的項目就可以成功的、一致的完成。我們需要工作組在6個月之內達到CMM2認證?！逼鹣?，這些指令都被忽略或者輕視，但是執(zhí)行管理層通過中層管理者的獎金來施壓。
通過和一個成熟的開發(fā)團隊的比較來提高自己看起來比填寫一個空白的過程文檔更容易。復制他們的制度和過程看起來也是一條可以達到CMM檢查表的捷徑?！白屛覀兏淖冞@些文檔的頁眉、頁腳，拿來為我所用?！庇捎趫?zhí)行者又要實施另一種模型ISO9001,所以這個策略并沒有起到作用。從這個前提出發(fā)，“文檔化你所做的，并根據(jù)你的文檔去做事”，一條粗線被畫在了文本流程和實際操作之間。
在運用了CMM差距分析檢查表后，這些結論發(fā)展成為了一個CMM項目計劃。因此什么是這個團隊應該建造的呢，過程或者產品？項目計劃和項目跟蹤與監(jiān)控的關鍵過程域的執(zhí)行逐步演化成了現(xiàn)存的項目辦公室。但是卻遺失了執(zhí)行這些過程的技巧。
咨詢的角色
組織了解了越多的成功的開發(fā)團隊，他們就需要越多的啟發(fā)，使他們能夠看到“隧道的盡頭”。他們不得不補充工作團隊的技能?！扒竽愀嬖V我們?yōu)槭裁次覀兊男『⑦@么丑陋。但是如果我們放棄了，我們要回到項目的混亂狀態(tài)去?！庇谑撬麄兓ㄙM很大的價錢請咨詢機構來調查。在預算被耗盡的幾個星期之后，他們拿出了一個報告，描述了他們需要什么樣的過程和技能。但是如果沒有一個有悟性的講解員去把這些咨詢報告翻譯成簡單的操作，那么這份報告就好像講給聾子聽了。
為了增加復雜度的層次，不斷變化的公司戰(zhàn)略和新的創(chuàng)意壓迫著全方位的預算。當這個團隊對增加一點又減少一點這樣反反復復的投資提供感到氣急敗壞的時候，他曾尋找過促進項目管理知識交流的更劃算的方法。有一個方法就是去補充合同制的雇員。這個策略持續(xù)了一段時間，大量的知識在領導、項目管理專業(yè)人員和以前公司的雇員間交流。這個方法看起來能滿足目標。但是在大多數(shù)的團隊里，個人沖突是屢見不鮮的，并且很可能這個項目的領導被要求離開。在招聘某個替代職位的過程中注意到一些個人的特點將會得到一個更能與團隊協(xié)調的候選人，但是雇傭期會比較短暫。當預