業界內廣為流傳的關於專案管理的通俗講解(2)(轉)
對於基準,我象舉個例子。
我們在沒有結婚之前,你腳踩幾隻船?
我們說法律允許但道德不允許,但你可以腳踩N只船:)
但當有一天你和你的朋友進了一個小黑屋子,然後帶了兩個蓋章的本本的時候,你還可以腳踩N只船嗎?
我們說此時就不允許了,因為你過了一個基準線(BASELINE)
如果你還想腳踩N只船就需要重新回小黑屋子再蓋兩個章就可以了。
那我們的專案要越軌怎麼辦,也就是專案變更?
我們說對這樣的專案變更會影響各要素比如時間,成本,質量等
我們應該統一由專案管理辦公室來進行控制,如果你要變更基準,必須要進行嚴格的限制。
在客戶提出變更請求時,要建立變更申請登記表和變更申請 表,並讓客戶簽字。
有時候一些不是非常關鍵的模組PM也不至於一點不講情面,該賣面子的時候還是要賣,尤其是當著對方領導的面,千萬要 賣面子,但是也別賣的太乾脆,不要讓他們得到的太容易。
PM在變更管理中需要做的是分析變更請求,評估變更可能帶來的風險和修改基準檔案。
如果一個專案進行過程中,比如現在的點心的3G專案,你發現如果再多花一點時間就可以編寫出對以後非常有用處的程式,但這個程式不在本專案範圍之內,你要不要做?
對,我們說不能做,你可以重新起一個專案來做,但不能在這個專案裡做,這樣會是我們的專案成本超出,風險增加,而且和其他的專案缺少比對性和參照的價值。
這也是我們說現在有大約80%以上的專案失敗的原因,我們說專案失敗並不是專案進行不下去了,徹底破產,在PMI有明確的定義,凡是專案的成本超出預算,質量沒有得到保證,時間超過預計等等都在失敗的範圍之內。
這個在華為做的很好,華為有個有名的增量開發的名聲。
只用20%的功能先滿足你80%的需求,其他的功能我可以開發升級的版本,於是就在小數點後平明的增加數字,於是就是了V1,V1.1,V1.11....等版本
它從來不一下子滿足你所有的需求,我們大家想想,誰沒有事情拿出自己的手機把所有的PING碼都試用一下,我們說沒有,我們大部分的需求是在打電話,發訊息,打打遊戲,對不對?
這點在專案管理中非常重要,請大家結合資料好好研究。
專案干係人是什麼東東,誰給我舉一個例子?
對,包括專案人員的老婆孩子,正確
我們說有的專案需要的時間很緊張,如果你的專案成功了,但專案的程式設計師們都成了光棍,那專案還是非常失敗,至少不是喪心病狂的PM這麼想。
合理解決專案干係人的衝突是個很累的問題,其中還包括你的只能經理們,你的董事長,你的客戶,等等,等等,有的說沒用?
好,如果你的專案進展不下去,你該怎麼辦?
對,開會,把你的高層找一個坐到會議室,不用他說話,只讓他曖昧的看著大家,大家一定會想,這個傢伙一定和領導有關係,我們還是好好的做這個專案,下一個專案再給他使拌子吧:)
所以為了不累死好好分析一下你的專案干係人吧
我們上次講了一些基礎的知識,包括什麼是專案管理,專案管理包括什麼?
你說專案管理有幾個知識領域?
你說專案管理有幾個過程組?
讓我們想起了泡MM的例子是不是?
還有老母親做QA的比喻
幾天我們著重強調的是
專案是什麼?人們常用“時間”,“資源(或缺乏資源)”,“某種工作努力”,“交付物或者產品”,“綜合工程”,“缺乏凌駕其他班組的職權”,以及“預算”來給它下定義。實際上,專案是一種獨特的工作努力,即遵照某種規範及應用標準去匯入或生產某種新產品或某項新服務。這種工作努力應在限定的時間、成本費用、人力資源及資財等專案引數內完成。?
首先給大家一個專案的定義,到底什麼是專案?
根據PMPBOK的定義,專案是在一段時間內為完成某一獨特的產品或提供獨特的服務所進行努力的過程。
這個過程受到時間、人力、資源、成本、質量上的限制
專案有幾個特徵:1.臨時性 2.獨特性 3.一次性
下面大家告訴我下面哪個是專案:A惠普與康柏機構重組惠普與康柏機構重組。B建造一座新工廠 C改建道路 D工程材料採購 E開發軟體包 F結婚典禮 G尋找拉登
有人說是尋找拉登,大家說尋找拉登有明確的結束時間嗎?
當然我們可以假設尋找拉登50年如果找不到,專案就結束是不是?
所以說我們今天不討論哪個到底是專案,所有的問題都要放到具體的環境下,否則沒有意義。
下面大家可以開始提問了。
什麼是WBS呢?
WBS是工作分解結構,就象一張道路交通圖,它能夠指引你如何從當前位置到達想去的地方。沒有它,你可能就要迷路了。
怎樣來做一個好的WBS呢?
有時候在接受新專案時前無例子可借鑑感覺分解時真困難, 因為每個人的解決問題思路不同,同一個專案不同的人有很多種分類, 因為可以按照工作的流程分解,也可以按照系統論的方法進行結構上的分解, 但我覺得有一條很重要的原則應該注意,那就是麥肯錫的精髓,他們在分解工作時非常強調的就是MECE, muturally exclusive, collectively exhaustive, 即相互獨立,完全窮盡的原則, 也就是現在較流行的說法"橫向到底,縱向到邊" , 如果分解時堅持了這個原則, 我想一定會有Perfect 的WBS, 其實WBS並非是PMI的"真傳", 只是被PMI起名為WBS, 有時候工作中我們也會用類似的方法解決問題無非是沒有提升到理論高度, 但WBS確實是做事的核心步驟。
做一個WBS需要注意一些什麼問題呢?
·第一級通常與專案生命週期相同(如需求分析,設計,採購,施工……)
·第一級應在專案進一步分解前完成
·WBS的每一級都是其上一級的片斷(Segment)
·一個工作單元只與一個上層單元相關
·上層單元的工作內容應該等於其所有直接下層工作單元的總和
·一個工作單元由一個人負責
·在整個WBS中使用同一種定義,在整個組織中亦然
·透過將人員包括進WBS來激勵他去完成計劃
什麼是甘特圖呢?
1.以圖形或表格的形式顯示活動。
2.現在是一種通用的顯示進度的方法。
3.構造時應包括實際日曆天和持續時間。不要將週末和節假日算在進度之內
什麼是風險呢?
首先問一個問題
你們說在一個專案中,初始階段和結束階段哪個時候專案的風險大?
對,是開始的時候,因為在開始的時候我無數的不可控制的因素。
那什麼階段的損失大呢?
對,在結束的時候,所以說兩者是相反的/
所以說在專案的啟動階段成功的可能性最小,風險發生的機率也就最高,但是這時候一旦預計的風險發生了,損失是最小的。
想想廣州和深圳很多爛尾樓?損失會有多少???!!!!!
另外我們要明確幾個定義:
1是確定性。具有明顯的可能性,比如中國和韓國對抗賽,勝負是很明顯的:)
2是風險。韓國隊能贏中國隊幾個球是一種風險的預測。
3是未知性。中國和美國比賽門球那就是未知的:)[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-958337/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 業界內廣為流傳的關於專案管理的通俗講解(1)(轉)專案管理
- 專案管理軟體與IT業界專案經理人的關係(2)(轉)專案管理
- 專案管理軟體與IT業界專案經理人的關係(3)(轉)專案管理
- 企業中的專案管理2(轉)專案管理
- 企業的專案化管理(2)(轉)
- 關於專案管理中的公共關係資源管理(轉)專案管理
- 關於公關專案管理的基礎意識(轉)專案管理
- 專案管理:業績為上(轉)專案管理
- 專案管理業績為上(轉)專案管理
- 關於專案管理的一點體會-轉載專案管理
- 知識型企業中的專案管理2(轉)專案管理
- 基於戰略視角的企業專案管理模式研究(2)(轉)專案管理模式
- 專案管理與企業智商2(轉)專案管理
- 有關專案管理的詞彙(轉)專案管理
- ERP的專案管理(2)(轉)專案管理
- 將傳統的專案管理方法應用於全面的企業運作(轉)專案管理
- 企業的專案化管理(轉)
- 解讀專案管理計劃(2)(轉)專案管理
- 關於專案管理的知識點專案管理
- 關於專案內模組引用的問題
- 我在專案管理中關於需求分析的總結(轉)專案管理
- 有關專案管理詞彙的用法(轉)專案管理
- 談談專案的成本管理2 (轉)
- IT產品管理與專案管理的關係(轉)專案管理
- 關於專案經理的職業發展的對話(轉)
- 企業中的專案管理1(轉)專案管理
- 企業中的專案管理3(轉)專案管理
- 企業中的專案管理4(轉)專案管理
- 企業中的專案管理5(轉)專案管理
- 企業的專案化管理(1)(轉)
- 企業的專案化管理(3)(轉)
- 關於專案公司文化的思考(轉)
- 關於專案管理的一點體會專案管理
- 貝葉斯公式的通俗講解公式
- Android Touch事件傳遞機制通俗講解Android事件
- 專案質量管理的主要內容(轉載)
- 專案管理理論中關於軟體專案外包採購管理的探討(轉)專案管理
- 區域網內基於WEB的檔案傳輸解決方案詳解 (轉)Web