在不賠上職涯的情況下取消專案

本文是「從馬西斯」集合的一部分。 其中描述辨識何時應該停止專案的最佳做法、這樣做的優點,以及取消專案時需要考慮的考慮。

若要下載本文的 Word 版本,請參閱 取消專案 (而不取消您的職涯) : (Project Server 2010 的白皮書)

若要查看更多文章,請參閱 白皮書

取消專案 (而不取消您的職涯)

身為專案經理,我們無權結束。 人員誰輕鬆地結束某個專案,完全找不到專案經理的角色。 專案經理本質上是開放式的。 我們就是以結果為導向、挑戰動機、永不說話、實現、看出半滿的人。 畢竟,當專案處於起始狀態時,沒有任何專案可顯示,但最好,專案經理會利用這些專案來實現已完成專案的願景。 她是專案完成的傳播者。

即使現在,您也不會閱讀這篇文章,並思考「我希望他會告訴我如何儲存我真的不想取消的專案」?

您不會單獨。

專案經理是一種文化特性,是自然的困擾者。 我不知道您,但是當我觀看電影《完美 Storm》時,當船直接上水牆時,我無訊息地叫用「C'mon。」。 您將進行此作業。」驚訝? (Er Alert: 這條船沒有成功,我在電影開始之前就知道了。它不會阻止我) 。

有時候,是時候停止

他的印度人有句語:「如果馬死,卸載。」專案經理會想要執行任何動作,但不做。 不要離開死馬... er,專案、專案經理比較可能會變更專案經理) (,請將兩個不正確 ( (專案) 在一起,以查看他們是否以小組身分更快地提取購物車。 我們想要重新命名馬,傳送馬車以進行更多訓練、將資金新增至馬,或只等候它之上的等候,希望沒有人注意到它不是正在等待,並避免宣告每個人都已經知道的內容。 馬不再往前轉。

然而,在現代化的專案管理世界中,我們的焦點可能會延伸到單一專案之外,並延伸到產品群組管理,而且當專案必須競爭相同的資源時,有時候取消專案是整個組織的最佳前進路徑。

停止專案會從識別不適當的繼續事實開始。 這可能不明顯。 某些組織已在其專案組合管理環境中採用階段控制程式。 階段控制會設定專案每個階段之間的正式檢閱,並確保專案已就緒且值得繼續進行。 然而,即使在這個結構中,仍有停止專案的抗拒。 尋找已定義和實作的階段控制環境並完全不尋常,但也發現一旦專案啟動,就沒有任何政治方式可以停止專案。 有階段控制,但所有閘道都已開啟。

如果您無法讓專案變慢、暫停或取消,則階段控制沒有多大價值。

專案不應該繼續的原因可能不是任何人的錯誤。 有無限數量的可能原因。 也許專案的經濟效益已經改變。 預期的投資報酬率現在顯然不會發生,因為我們認為已完成產品的價格不再可行。 或許經濟本身已經改變。 在不再可銷售商品的區域中,商品的商品專案或許沒有位置。 或許競爭對手已藉由在您預期之前和準備就緒之前發行競爭產品來變更環境。 也許您遺失了一些關鍵人員,他們具備專案成功所需的重要知識和專業知識;或者,專案可能已超過預算、排程、風險、品質或複雜度閾值,使得繼續進行變得有問題。

專案已經啟動,那麼我們要如何停止它?

不論您是使用正式階段控制程式或臨機操作商務檢閱程式,都有一些方法可判斷專案不應該繼續進行。

第一個且最明顯的是執行商務案例「重新整理」。 您在專案啟動時所使用的任何商務驅動程式計量都應該經過檢閱。 專案是否仍有機會提供預期的投資報酬率? 專案中的交付專案是否仍然需要? 使用您在專案開始之前用來評估專案的相同結構,可讓您比較目前的情況。

另一個可能的方法是使用專案管理層級 PM 知識主體的 10 個知識領域:評估每個區域的專案狀態,並將該評估與您在專案開頭的預期進行比較:

  1. 專案整合管理

  2. 專案範圍管理

  3. 專案時間管理

  4. 專案成本管理

  5. 專案品質管制

  6. 專案人力資源管理

  7. Project Communications Management

  8. 專案風險管理

  9. 專案採購管理

  10. 專案專案專案關係人管理

讓我們以第 8 號風險管理為例。 專案第一天的風險應該最高。 這會是您最「未知」的時候。 在過去一天,風險應該是零,因為您剛才傳遞專案。 您現在知道結果。您自然會預期,隨著專案的進行,風險量會降低。 是嗎? 如果風險持續增加,這可能是需要重新流覽專案範圍的徵兆。

如果您執行投資報酬率 (ROI) 分析 (當您暫停專案以進行商務檢閱) 時,請務必考慮,別忘了投資中的 「I」 不是零。 您已花費一些金錢,因此您必須考慮的投資是剩餘的資源和完成專案所需的成本。 如果您取消專案,則 「R」 可能為零,但至少 「I」 不會變大。

當您進行商務檢閱時,考慮商機成本也是不錯的事。 如果您未再花在這個專案上,而且您的資源並未系結于這個專案上,他們是否會對另一個專案執行一些有價值的動作,以克服此處遺失的投資?

以滑鼠右鍵結束

如果您必須取消專案,請務必先取消專案。 只要在情緒圖示中結束專案,可能會造成比繼續進行更多的損害。

請確定您負責處理即將取消專案的小組成員。 過度溝通,並確定員工有機會在商務檢閱期間提供意見反應。 或許它們有您尚未考慮的觀點,而且目前可能歡迎所有輸入。

採用一些重要的專案結尾最佳做法,並確定在此情況下加以套用。 它們可能包括:

  • 請與員工開會,以檢閱可從進行中的工作中擷取哪些專案。 您甚至不知道自己有一些重大優點。

  • 在這裡,不要受到責備是不錯的主意。 不過,自責通常沒有用處,但著重于誰應該受到責備,而不是該怎麼做,可能會讓您無法從這個原本令人不快的結果中取得正面結果。

    執行總結會議以關閉專案,並感謝所有小組成員參與。 請確定已記錄並封存所學到的任何課程和其他專案檔案,以及任何工作產品。

  • 請確定專案有最終的會計,以便計算實際成本與權益。 也請務必不要忘記您的子約聘人員。 請確定所有未處理的發票都已解決,而且您的廠商不會有任何未處理的發票,例如長期訂閱。 畢竟,您可能很快就會在下一個專案上再次使用它們。

立即停止專案的優點

這並非全都是好消息。 在您的商務檢閱中,專案到目前為止的投資可能會有一些值得指出的回報。

第一個最明顯的好處是專案小組成員的全新可用性。 如果他們未處理此專案,它們會立即可供其他專案使用。

接下來是回收。 人們通常會意外地發現有多少進行中的工作可以調整為其他用途。 在某些情況下,這可能是完整的 (,但更簡要) 產品。 在其他情況下,可能會有可復原的模組在其他專案上立即具有價值。 擲回已完成的所有專案通常是一大錯誤。 包含在您已預先付費的硬體、軟體、訂用帳戶和服務等思念事項中。 也許組織的另一個部分可以使用這些授權來提升生產力。

軟性優勢幾乎一律是改善的鬥志。 幾乎所有處理需要停止之專案的人員,都知道它應該在發生之前停止。 問題幾乎一律有一種開放而非不確定的問題,而且知道專案的結束並不代表其雇用的結束,對於現在可以處理更具生產力之工作的員工來說,通常是個好消息。

我的職涯呢? 我現在是否與失敗相關聯?

在 2005 年,KPMG 執行了全域 IT 管理問卷。 在其中,他們討論了必須停止的專案,其中一位人士說:「取消不太可能提供預期權益的專案應該不會被視為失敗 — 無法取消這類專案應該是」。這非常合理。 如果您是不應該繼續的專案,則您只是問題的一部分,而不是解決方案。

經歷這個非預期的專案結束程式的一個側面優點是,您會成為「正則訊息代理程式」。 您一直願意支援並分享好消息,因此您對管理的可信度幾乎一定會增加。 如果您已完成關閉專案的不錯工作,您也有許多資料和優點可提供。 有已獲回收之專案的會計,以及投資和報酬率的實際會計。 您也應指出組織其餘部分的優點,因為您希望管理知道取消專案不一定是災難。 畢竟,釋放小組成員的可用性,讓其他專案更可能成功。

沒有專案經理想要結束專案。 這不是我們的本質。 但它自然是專案經理的一部分,也是每個專案經理都需要準備好面對的一部分。

關於作者

Chris Vandersluis 是 Microsoft 認證合作夥伴、加拿大 HMS Software 的副總裁和建立者。 他擁有 McGill University 的經濟效益學位,以及超過 30 年的專案控制系統自動化經驗。 他長期隸屬于 Project Management Institute (PMI) ,並協助您找到 Microsoft Project Users Group (MPUG) 的多倫多、多倫多和魁北克章節。 Chris 所撰寫的發行集包括《星號》、《重度建構新聞》、《計算加拿大》雜誌和 PMI 的 PMNetwork,而他也是 Project Times 的一般常客。 他教授 McGill University 的進階專案管理,並經常在北美洲全球各地的專案管理關聯函式上進行討論。 HMS Software 是 TimeControl 專案導向的計時系統發行者,自 1995 年起一直都是 Microsoft Project Solution Partner。

您可以透過電子郵件連絡 Chris Vandersluis:: chris.vandersluis@hms.ca

如果您想要閱讀 Chris Vandersluis 的更多 EPM 相關文章,請參閱 HMS 的 EPM 指引網站 (https://www.epmguidance.com/?page_id=39) 。