專案管理方法不是最重要的,成功完成專案真正需要什麼?
當今專案管理的兩個方向正在發展:瀑布式和敏捷式。這兩種方法都有優點和缺點,下面將介紹流行和適用的方法。
瀑布式
這種方法的主要代表是PRINCE2,該模型基於這樣一個事實,即我們從一開始就知道我們想要生產什麼,並且我們能夠確定此類專案的預算。
階段沒有時間限制,團隊規模也沒有限制(或實踐)。方法論由主題和過程組成,一切都建立在作為方法論核心的原則的基礎上。
該框架包括商業案例的定義(用於專案驗證),並透過定義角色和責任支援專案的組織。它顯示瞭如何管理風險、質量、進度和變化,並支援規劃。PRINCE2既適用於需要大量檔案備份的企業,也適用於對檔案需求減少、人數較少的小型團隊。
如果你忽視了這些原則,這個方法論就會失敗。這是使用所謂PRINCE的最常見的原因。關鍵在於:
● 保持持續的商業案例,以及在專案不再存在時取消專案的能力,
● 界定角色和責任,
● 專注於產品,
● 經驗的基礎,
● 寬容管理,
● 階段管理
● 適應特定環境下的專案
PRINCE為專案的幾乎所有方面提供了一個複雜的框架,並提供了關於如何執行專案和需要注意的事項的完整技術,常被用於IT專案,以及建築、活動和其他專案。
SCRUM
這個名字起源於美式橄欖球隊使用的球員陣型。整個方法論,純粹的敏捷性,是為了給專案提供動力,減少檔案和管理業務變更,使交付的產品在當前的業務情況下是有用的。
規則很簡單:
● 最多 10 人的團隊,
● 衝刺時間不超過4周,
● 系統的衝刺回顧,
● 透過日常會議進行專案控制,
● 產品所有者是管理優先事項的人,
● Scrum主管負責監督該方法的正確應用,
● 輕鬆對專案進行更改。
所有這些都伴隨著回顧會議,以消除瓶頸併成為一種 "經驗教訓"。
SCRUM更像是一種生產方法論,通常有助於控制工人/創造者。它引入了嚴格的規則和事件,使團隊保持自覺和紀律性。在敏捷方法論中,控制預算並不容易,所以如果雙方不同意一定的敏捷性和信任,SCRUM往往會變成瀑布,只剩下衝刺和其他一些敏捷的元素。
敏捷方法論,不僅適用於IT行業,只要是相對較小的專案,它們也可以用於其他專案。如果想管理大型專案,或者把維護當成一個專案,那麼敏捷方法可能是致命的。
看板
看板表是列的集合,它反映了生產過程的各個階段,任務沿著這些階段轉移。得益於此,我們很容易看到哪些工作還沒有開始,哪些是我們目前正在做的,哪些處於測試階段,哪些已經準備好了(這是一個列配置的例子)。
看板本身在維護專案中可以發揮很大的作用,我們不生產特定的產品,但我們的工作是處理事件和變化,我們必須能夠有效地處理這些問題。
專案計劃——良好做法
選擇正確的方法或做法是很重要的,因為它定義了整個專案的框架,決定了行動的方向。然而,良好的專案計劃是將失敗或停工的風險降到最低的方法。
根據專案的執行方式,我們要麼為下一個衝刺階段規劃工作,要麼規劃整個專案,只更多地關注下一個階段的細節。雖然效果相似,但作為結果,我們可以看到整體的輪廓。
當然,在一個專案中,從來沒有發生過所有計劃中的任務都 "準備好 "的情況,但關鍵是不要把這樣的任務列入下一個迭代或階段。這種計劃方法在某種程度上可以使我們避免因任務受阻而無法實施專案計劃。
在正確層次的方法論管理
即使你選擇了最適合的方法論,你仍然需要應用四眼原則來確保專案的底層活動或可交付狀態是真實的。因為資料會對專案的結果產生重大影響。專案執行若沒有準確的實時資料, 無論用什麼方法論,都極有可能失敗, 因為是閉眼駕駛, 不出意外只是僥倖。
市場上能夠提供實時準確資料的專案管理工具不多, 8Manage PM 就是其中之—。新一代8Manage PM專案管理系統支援多種專案管理方法論,是一個實時更新的業務管理、專案計劃、執行、協同與交付平臺。它可以幫助你在正確的層次上避免專案資訊的扭曲,最大化自動化和資料的完整性。
• 維持單一事實來源
8Manage PM專案管理系統將專案資訊統一儲存在集中的資料庫中。每個專案干係人看到的專案資訊都來自同一個資料庫,並實時顯示或重新整理。當專案干係人變更任務資訊時,這次變更將實時錄入資料庫。
• 垃圾進垃圾出
即使有單一事實來源,這也不代表人們不能做“ 垃圾進,垃圾出” 的事。例如,你是設計規範可交付成果的輸入人,並聲稱它已經100% 完成。除非計劃的核對人(通常是可交付程度的交付物件)審查並接受可交付成果,否則 8Manage PM專案管理系統不會接受它已經 100% 完成。這被稱為四眼原則或輸入/核對控制,通常用於金融服務行業的資訊系統。
• 完工率
除了使用輸入/核對等策略來控制工作分解結構 (WBS) 中活動層級(父層級)的完工率外,8Manage PM專案管理系統不允許使用者直接在非父節點輸入完工率。系統會根據子活動的完工率自動計算每個非父節點的完工率,從而避免高層級的謊言。
• 變更和重新審批
根據預設的企業規則,規則之外的專案變更將觸發重新審批。這是為了避免在不讓干係人知道的情況下變更專案計劃。
• 基線
每次審批或重新審批專案計劃和執行時,都會為專案計劃和執行設定基線。專案干係人始終可以將當前的專案計劃和執行與以前的基線進行比較,從而檢視差異。
• 審計跟蹤
對於專案計劃和執行的每一次變更,8Manage PM 專案管理系統都會維護不可刪除的審計跟蹤記錄。自動化的審計跟蹤捕捉人們在專案中的行為,讓整個環境更加透明。
總結
使用任何方法論,無論其利弊,我們都能有效地結束專案,並在客戶完全滿意的情況下完成合同,這是怎麼做到的?答案很簡單:能夠提供實時準確專案資料的系統工具,以及讓客戶成為我們團隊的平等成員,參與所有活動、檢查點和審查會議。這就是為什麼我們很容易識別所有的早期警告,並在質量、預算和合同規定的任何一種差異上開展工作。
單純談論哪種方法更好是沒有意義的。作為專案經理,你必須為特定的專案選擇合適方法和
,並系統地執行。請記住,團隊的力量在於你管理的人員和你為之創造創新產品的客戶。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31550487/viewspace-2944210/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 什麼樣的專案才算是成功
- 企業需要成功的專案(轉)
- TRIZ專案成功的關鍵是什麼?
- 軟體專案管理實踐:專案成功的關鍵是什麼?專案管理
- Java專案是不是分散式,真有那麼重要嗎?Java分散式
- 承諾-專案成功的重要因素薦
- 成功的MES專案,前期都做了些什麼?
- 中國的專案管理最缺什麼?(轉)專案管理
- 真正成功的SOA專案5個裡才1個
- 專案的成功
- 一個成功的專案 需要大家多包容
- 完整的設計一個專案需要什麼?
- 古代最成功的專案管理-西遊記(轉)專案管理
- 資訊化為什麼需要專案管理?(轉)專案管理
- 管理多個專案:專案管理真正的挑戰專案管理
- 成功的專案管理需要做好哪些方面?專案管理
- 西遊記 古代最成功的專案管理案例(轉)專案管理
- 專案里程碑是什麼?為何如此重要?
- 為什麼成本管理在專案管理中很重要專案管理
- SAP專案管理方法論(轉)專案管理
- 軟體專案量化管理方法
- [譯]專案什麼時候需要React框架呢?React框架
- [譯] 專案什麼時候需要 React 框架呢?React框架
- 專案的真正結束(轉)
- 【案例】成功完成天網千帆開源專案的感受
- GitHub專案大多不是開源專案Github
- 在Linux中,GNU專案的重要性是什麼?Linux
- 專案成功關鍵要素和專案成功關鍵要素
- 成功接專案需要注意的幾個要點
- 科學的專案管理方法有哪些?專案管理
- 專案經理之什麼是專案管理專案管理
- 成功的專案歸功於成功的專案管理,它幫你踏上成功之旅!專案管理
- 做IT整合類大專案,真正成功交付並盈利的少之又少
- 客戶成功管理用什麼專案管理軟體好?專案管理
- ERP專案管理方法分析(轉)專案管理
- 科研專案管理方法探討(轉)專案管理
- 適度變更,專案更加成功的重要途徑(轉)
- 什麼是專案管理?專案管理