PMBOK,專案管理/專案管理 - 技術
跳至內容

PMBOK,項目管理/項目管理

專案管理協會(PMI)是一個試圖建立專案管理標準秩序和標準的組織。

廣告

為此,PMI 維護了專案管理知識手冊 (PMBOK),其中建立了每個專案經理都應該了解和應用的一整套工具和良好實踐。

與其他方法論(例如 Scrum 等敏捷方法論)相比,PMBOK 面向預測性專案管理。 PMBOK 以線性方式呈現專案的幾個階段(一旦克服一個階段,就無法返回),其中需要/解決方案、範圍和規劃(例如,每個任務的成本和持續時間)執行)是在初始階段建立的(這就是為什麼它被稱為預測管理)。

因此,我們可以認為 PMBOK 屬於專案管理的更經典分支(以及在英國流行的補充 PRINCE2 標準)。然而,這一事實並不意味著它提供的某些工具不能與其他更敏捷和靈活的方法結合使用。

在進入正題之前,有必要根據PMBOK建立專案的定義和特徵:

  • 專案試圖解決問題(滿足需求)。
  • 這是暫時的
  • 它在時間上是唯一的,在相同的情況下是不可重複的。
  • 帶有不確定性
  • 消耗資源:時間、金錢、材料和勞力。

專案有自己的生命週期,分為以下幾個階段:

  • 開始:需求已確定,問題是是否可以實施該專案。
  • 規劃:
    • 更詳細地制定了解決方案。
    • 定義任務、日曆。
    • 時間和金錢的成本估算。
    • 問題又是該項目是否可行。
  • 執行:監控和調整規劃。
  • 結束:驗證專案是否滿足解決需求

所有這些階段都意味著以下一般過程:

  • 確定問題或機會
  • 識別並定義理想的解決方案
  • 確定所需的任務和資源。
  • 準備時間表並取得資源
  • 估算專案成本並準備預算
  • 分析風險並與利害關係人(任何對專案有直接或間接利益的人)建立關係:定期風險管理
  • 在執行過程中保持適當程度的控制和溝通:定期召開會議以檢測和溝通偏差
  • 管理成功的結束
    • 待辦事項清單:完成專案的任務清單。
    • 當專案即將結束時,團隊成員往往會分散開來。

然而,一個項目可以從其他角度來看,例如從人際關係的角度:

  • 激勵團隊:創造合適的氛圍
    • 花時間解釋每個角色如何為專案做出貢獻
    • 在會議上投入時間來強調成員的正向貢獻。
    • 信任委派的工作
    • 將目標分配給個人並讓他們選擇路徑。
    • 認可超出要求的努力。
    • 以身作則
  • 管理多樣性
    • 確定可能的個人目標,將其最小化或轉化為團體目標。
    • 尋求群體凝聚力(協調習俗、文化等)。

反過來,除了內部專案管理和人際關係流程之外,專案還在組織範圍內開發和執行。目前,我們可以找到主要業務是專案執行的公司,例如諮詢和審計領域的公司。這是最積極的情況,因為整個組織都專注於專案管理。

然而,大多數公司都有一個由不同職能的部門和執行特定任務的員工組成的等級結構,其流動性往往相當分散。在這種類型的場景中,與內部協作者執行專案(按照既定的情況,是臨時的)會帶來更難以管理的場景(這就是為什麼專案經常承包給外部顧問和審計師的原因之一)。

第二種情況可能會為員工帶來“筒倉心態”,即人們的目標與他們的職能領域相關,而不是與他們所分配的項目相關;他們可能並不關心專案的成功,而更願意履行其穩定的部門單位義務。這個問題會阻礙工作團隊的合作(橫向思考)。

簡而言之,組織的成熟程度和已建立的內部程序可以影響專案的成功或失敗:

  • 如果組織通常從事項目,那麼已經有明確的指導方針。
  • 正式的溝通管道:如果過於僵化,就會阻礙工作
  • 非正式溝通管道(朋友、熟人等):如果過於頻繁,可能會產生錯誤訊息

最後,PMBOK 規定,要認為專案成功,必須滿足以下期望:

  • 第一級:實現專案目標
  • 二級。專案效率。
    • 對客戶工作的干擾程度。
    • 資源利用效率
    • 團隊成員數量的成長
    • 管理衝突
  • 三級。最終用戶/客戶端的實用程式。
    • 最初的問題解決了嗎?
    • 福利是否增加了或是否真正節省了?
    • 用戶目前正在使用該產品嗎?
  • 四級。組織改進:從經驗中學習

專案負責人

專案經理或專案經理有以下職責:

  • 項目:成本、日曆、功能和品質目標。
    • 組織機構
    • 投資報酬率.
  • 資訊流:主動提供,如果主管對某些資訊感到驚訝,則表示我們沒有正確告知。
  • 團隊:提供回饋和認可。
  • 關於你自己:個人成長。

另一方面,專案經理不斷面臨挑戰,我們可以發現以下挑戰:

  • 責任VS責任缺乏權威
    • 高度的責任感。
    • 我與我沒有直接權力的人一起工作。
  • 不切實際的目標
    • 這是最常見的問題之一。
    • 強化正確分析和規劃專案範圍的想法。
  • 功能定位
    • 人們會傾向於關注他們的知識功能領域。
    • 鑑於其時間性,其功能區域比專案更重要。
  • 不確定性的根本衝突
    • 用很少的資訊快速做出決定。
    • 範圍估計(例如成本)
    • 盡量讓上司和團隊成員理解估算的困難。

為了成功應對專案管理帶來的責任和挑戰,專案經理必須不斷提升以下技能:

  • 專案管理:規劃和監控的工具。
  • 人際關係
    • 領導、談判和授權技巧。
    • 口頭和書面溝通技巧
    • 解決衝突。
    • 培養導師(輔導)角色的技能
  • 技術知識
    • 產業和技術領域的知識
    • 產品和/或流程的知識
    • 設計技巧
  • 個人技能
    • 誠實、正直
    • 放眼全球
    • 對不確定性和模糊性具有高度容忍度
    • 有說服力和自信
    • 開放且可訪問
    • 決定性
    • 商業的。能夠推銷想法或項目的優點。
    • 老師。向團隊成員傳授知識。

專案定義

專案定義由以下階段組成:

  • 第一階段:了解問題或機會。
  • 第二階段。確定最佳解決方案
  • 第三階段。制定解決方案並製定計劃
  • 第四階段。專案啟動

第一階段:了解問題或機會。

確定專案想要滿足的真正需求至關重要。將根據是否令人滿意地滿足這一需求來評估工作。

首先,有必要區分需求和解決方案。

必要性:

  • 向客戶描述目標
  • 明確目的和目標
  • 留下如何做的問題。
  • 為什麼這樣做的答案應該指向商業理由。

相反,一個解決方案:

  • 描述團隊的手段
  • 指定實現目標的策略和想法。
  • 指定如何做。
  • 為什麼這樣做的答案應該指向客戶的需求。
  • 要求確定真正的需求可能會讓第三方感到不舒服,因為他們不相信您的標準。

基於這些定義,此階段應該產生專案需求文件作為其輸出,該文件不提供解決方案,而僅描述需求。本文檔必須包含以下部分:

  • 問題或機會的描述
  • 問題的影響或影響
  • 確定誰或什麼受到問題的影響
  • 忽視問題的影響
  • 期望的情況
  • 與實現所需情況相關的好處
  • 與組織的策略保持一致
  • 與組織其他領域的相容性衝突
  • 不確定性
  • 主要假設
  • 解決方案的局限性
  • 環境考慮
  • 歷史支持訊息

收集完所有這些資訊後,需要重新評估問題是否值得解決,並確定是否有潛在的解決方案。

第二階段。確定最佳解決方案

要確定滿足已確定需求的解決方案,可以遵循以下流程:

  • 與未來的工作團隊成員或利害關係人進行集體腦力激盪。
  • 檢查他們滿足項目需求文件中的陳述的程度。
  • 選擇 2 到 5 個候選解決方案。

對於選定的候選解決方案,必須進行詳細分析,以確定哪一種最適合所涵蓋的需求,且成本可負擔。

財務分析(成本 x 收益):

為了驗證專案的財務可行性,有必要確定專案可以產生的現金流入,例如,從專案實施中獲得的收益(增加銷售額、降低成本等)以及專案所產生的費用。啟動代表專案進度和管理。

因此,透過估算不同現金流量的大小併計算4個基本指標,我們可以確定哪個項目為我們提供了更大的財務獲利能力。

至少應研究以下指標:

  • 淨現值(NPV)。 考慮資金的時間價值,確定專案將產生多少錢。
  • 內部報酬率 (IRR) 。確定投資報酬率。
  • 時期 返回。確定何時收回投資(NPV = 0)。
  • 錢洞 。確定所需的最大投資。

非財務分析(加權因子評分模型 - 決策矩陣)

使用加權因子評分模型(「決策矩陣」)進行分析首先要準備要評估的屬性清單。為每個解決方案建立一個權重,並分配分數來表示每個候選解決方案的符合程度:

優勢:

  • 允許使用各種數據,包括財務數據。
  • 允許管理階層參與和敏感度分析。

缺點:

  • 高度主觀的過程。
  • 它顯示了該項目的吸引力,但並不代表商業理由。

除了財務或矩陣分析之外,最終決定選擇哪種解決方案可以基於其他工具的使用:

  • 市場研究
  • 試點測試。在有限的區域進行測試。
  • 原型製作。建設項目的一小部分來驗證正確的預測。
  • 計算機模擬。

簡而言之,所進行的分析不僅有助於選擇解決方案,而且還使我們能夠確定解決方案是否可行以及該專案是否值得繼續進行。