象大多數的故事一樣，這個故事也發生在很早以前。但是當我談起它的時候，傷疤依然疼痛。我曾經在一個軟體開發團隊工作過，這個團隊拼命的想生產一個產品，或者是隻要能使用的任何東西。由於過去專案的失敗，這個團隊儘管許多基礎建設已經到位了，但是卻缺乏成功的嚮導和跡象。你可以說這個團隊存在，但是缺乏清楚的組織結構和許多達到成功的必要的商業要素。這個團隊的使命和眼界被一個受過良好教育，可是很可能沒有經驗的新領導人弄得墨成一團。

至於商業需要，它們一直在那兒。幸運的是，作業系統滿足了穩定的最小需要。但是同樣遺憾的是，這些系統並不能適應快速改變的環境，而且在許多年後，也超過了它們的平均壽命。為了替換這些老化的主機，執行者提出了一系列的 “改進創新”。執行這些創新對開發團隊而言，幾乎不需要優先順序考慮並且甚至只需花費更少的錢。

許多內部的專案不過是在重複著勞動和競爭。“買一套ERP軟體，定製它來滿足我們的需要”，“為什麼我們要重新發明輪子呢”。那些是來自團隊內的經常的喊聲，也是一個來自企業失敗專案的教訓。經過了與巧舌如簧的銷售人員一道玩若干回高爾夫和共進幾次兩小時的午餐的結果就是為一套ERP軟體投資幾百萬美元。但是那隻不過是買License的花費。

模型、標準和認證

“我喜歡用老軟體，為什麼我一定要改變？”，使用者、軟體開發人員、需求分析師、專案經理和股東都面臨著對即將到來的變化的相互間的抵制。

明顯的，需要正規的專案管理。而執行管理層選擇了CMM作為銀彈工具。“只要這樣一個基礎組織就位，所有的專案就可以成功的、一致的完成。我們需要工作組在6個月之內達到CMM2認證。”起先，這些指令都被忽略或者輕視，但是執行管理層透過中層管理者的獎金來施壓。

透過和一個成熟的開發團隊的比較來提高自己看起來比填寫一個空白的過程文件更容易。複製他們的制度和過程看起來也是一條可以達到CMM檢查表的捷徑。“讓我們改變這些文件的頁首、頁尾，拿來為我所用。”由於執行者又要實施另一種模型ISO9001,所以這個策略並沒有起到作用。從這個前提出發，“文件化你所做的，並根據你的文件去做事”，一條粗線被畫在了文字流程和實際操作之間。

在運用了CMM差距分析檢查表後，這些結論發展成為了一個CMM專案計劃。因此什麼是這個團隊應該建造的呢，過程或者產品？專案計劃和專案跟蹤與監控的關鍵過程域的執行逐步演化成了現存的專案辦公室。但是卻遺失了執行這些過程的技巧。

組織瞭解了越多的成功的開發團隊，他們就需要越多的啟發，使他們能夠看到“隧道的盡頭”。他們不得不補充工作團隊的技能。“求你告訴我們為什麼我們的小孩這麼醜陋。但是如果我們放棄了，我們要回到專案的混亂狀態去。”於是他們花費很大的價錢請諮詢機構來調查。在預算被耗盡的幾個星期之後，他們拿出了一個報告，描述了他們需要什麼樣的過程和技能。但是如果沒有一個有悟性的講解員去把這些諮詢報告翻譯成簡單的操作，那麼這份報告就好像講給聾子聽了。

為了增加複雜度的層次，不斷變化的公司戰略和新的創意壓迫著全方位的預算。當這個團隊對增加一點又減少一點這樣反反覆覆的投資提供感到氣急敗壞的時候，他曾尋找過促進專案管理知識交流的更划算的方法。有一個方法就是去補充合同制的僱員。這個策略持續了一段時間，大量的知識在領導、專案管理專業人員和以前公司的僱員間交流。這個方法看起來能滿足目標。但是在大多數的團隊裡，個人衝突是屢見不鮮的，並且很可能這個專案的領導被要求離開。在招聘某個替代職位的過程中注意到一些個人的特點將會得到一個更能與團隊協調的候選人，但是僱傭期會比較短暫。當預算同市場的薪酬等級相比，不具有競爭力時，“別處的牧場更綠”。更多的嘗試提供了更多的回報，並且知識交流還在繼續。

自我與策略

很多執行主動性與指示或與一般理解互相沖突。這種衝突之一可以是當專案過程需要資金和人員支援時，發現追加預算和人員已被凍結。在此例中，“起伏波計劃編制”允許“現實主動性”超出現有專案的預算。同樣，許多軟體解決方案至少在伺服器結構上受限於共同的“摒棄微軟哲學”。在那時，今天亦如是，軟體商銷售中間產品，資料庫軟體升級到視窗系統，而很久以前則是把應用程式介面到不同品位的UNIX。關於微軟伺服器在共同結構上的使用，“通用技術結構總署”強制推行美國產業工會聯合會標準的認可程式。

悅耳的講座

一個關鍵專案與專案部的發起人離開了，使推進要素停止執行了一段時間。替補執行者帶來了很好的經驗財富，如同一個出色的發起人一樣。但是，進行了一年以後，法人層又進行了改組，那位經驗豐富的人選成了一位賭金保管員，而不再是主管。在一個新的組織結構和執行環境下，開發小組發現他們服務於同樣的客戶，而且更多了。這導致了執行委員會成員的變化，關鍵優先權置實體於變化控制程式。期間，此屬於“企業資源計劃”的公司與同組織一個大的公司結合，並改變了聯絡和方向。這種結合將涉及一個導致大部分結構重新設設計的工程

今天的基線

組織結構是一個脆弱的矩陣，由職能經理構成，他們保持預算並使前景複雜化。雖然專案節奏一直在變化，但它持續地受到專案管理小組監督並在需要時向任何一位彙報。該小組當前全部由法人和合同專業人員組成，他們為客戶提供產品的檔案。有著如下領域：變更，風險，範圍管理的專案管理機構，小組正在由專案向客戶需要的交付專案轉變。但缺少了什麼呢？

何去何從

今天，專案部嚴格地關注於專案。日常變化例如“企業資源計劃”軟體結構影響了許多專案和大量的產品釋出。小組正緩慢地朝著部門領導靠攏，但專案內部依存的概念卻相去甚遠。這種觀點將為專案部的管理者提供一個清晰的理解本部門內部所有專案變化帶來的的影響

自從關鍵人物掌握了許多專案所需的能力，人力資源混亂是經常發生的。交叉訓練，合同資源以及任務思考的主動性正在進行但卻未列入進度表。

如果這個軟體開發團隊要穩定發展，他們的成功依賴於高效的資訊傳遞和領導能力。這一點的確重要，因為這個團對已經是銷售、市場和資訊服務行業中的一分子了。新的企業領導來源於市場槓桿的調解。一些人預言研發小組要能按市場需求，適時地生產高品質的產品。然而那是矛盾的嗎？

一位具有14年的管理經驗的專案經理，涉足領域包括航空、銀行、諮詢、政府、保險、後勤、非營利專案以及垂直運輸等方面。他在如下方面提供諮詢：計劃與配置管理，過程改進，系統結構，e網知識，客戶需求以及管理諮詢等。
[@more@]

專案團隊管理的失敗經驗（轉）

相關文章