專案管理_轉載
專案管理是決定ISO20000專案核心的一個因素,如果按重要次序排列,它應置於第一位,它比你懂不懂ISO20000更重要,專案管理在企業管理與工作之中所佔據的位置會越來越重要,一個優秀的現代工作者應該具備起碼的專案管理意識,一個優秀的管理者應該是一個合格的專案經理,為了交流的便利,這裡對專案管理的基本概念做一個介紹:
u 什麼是專案
專案是為完成一個或多個特定的目標而進行一次性的任務。專案有明確的起點與終點,它是一次性的,它的目標是特定的,它的結果是不可逆轉的,它是有成本約束的。所以按這種定義,我們日常工作與生活中許多事務可以定義成專案,比如完成一次培訓,讓學員理解接受此次培訓課程的內容,這是目標,但是不是理解這難以量化,所以我們採用考試測驗的方法,設計一套考核試卷,目標即可定義為考核及格率為100%,為了做這個培訓,需要做許多子任務,比如要做培訓教材,要做培訓試卷,要尋找培訓場地,找培訓講師,組織所有學員培訓,最後組織考核與做培訓滿意度調查,這些都是專案的活動,需要有一個計劃把它組織起來,按一定的邏輯次序進行進間安排,比如培訓教材沒有設計出來之前,不可能做培訓試卷,培訓講師沒有確定之前,不可能組織培訓,要尋找不同活動之間的邏輯關聯,按時間把它們安排好,這就是專案計劃,專案計劃非常重要,以這個例子而言,如果做得比較嚴謹的話,培訓場點的裝置測試(投影儀、電腦、擴音投備、網路連線)這些活動都要考慮好,甚至要考慮到某個裝置如果作業時環了,怎麼辦,等等這些,每個子任務要明確由誰負責,整個培訓的任務由誰負責,這就形成了一個專案體制。按照這種理念,一次婚禮的舉辦、一個公司的開業、一次旅行、一場音樂會、一場戰爭這些都是一個專案,如果我們想有質量有保障的完成這些事情,一定會用的專案管理的某些方法,有人可能說,我不懂什麼專案管理,但這些事情一樣可以做得好,其實你認真去分析做這些事情的過程,它一定契合專案管理的一些方法,只是我們沒有意識專案管理這個名詞罷了,這有些象金剛經中所說的“所言一切法者,即非一切法,是故名一切法”的道理。一個任務分解越多、時程越長、涉及人員越多的專案越需要專案管理,這二者成正比。
u 什麼是專案管理
專案管理是在有限的資源約束下,對專案範圍內的全部工作進行有效地組織,以保障其達成專案目標的一系列方法與理論。專案管理的活動是非生產性的,它包括對生產性事務的管理、質量的管理、風險的管理、計劃的管理、配置的管理、績效的管理等等,這是按管理屬性進行大致分類,專案管理主要由專案經理負責,當專案極其複雜時,可能將專案經理可能會設立一些專案管理角色將某些專案管理活動分擔下去,甚至有可能將一個大專案分拆成若干個小專案,進行分頭管理,說到底,所以專案管理並沒有一個硬性的模式,當前有許多專案管理的書籍與課程在介紹這方面的知識,這些知識只是一個一個的工具而已,如何去採用哪幾種工具或組裝不同的工具在一起為專案所用,這需要專案經理的智慧,當前的網路發展,各式各樣的知識資訊隨手可取,對以前的人類而言,資訊的獲取最為困難的,需要花費巨大的時間去記憶記錄,而現在的人類最為困難是資訊的分析與應用,由於搜尋引擎的越來越先進,網路接入方式越來越便利,這對人類的學習模式與大腦運作機制帶來根本的影響,博學已經沒有太多意義,你再博學也不會超過1GB的硬碟,當機器佔領了這個領域,人類將永遠退居二線,在各種自相矛盾的管理邏輯之內,找到適於此時此景的解決之道,這需要智慧,一個當前世界頂尖的專案管理方法的理論專家可能管理不好一個小專案,一個完全不知專案管理為物的26歲的拿破崙可以攻克義大利,所以不能脫離人與場景的情況下去唯方法論,一個優秀的管理者必定在管理一個專案時更有得心應手,一個優秀的專案管理者必定在管理時也更有心得,專案管理與管理的本質是大部份是同通的,但在我們大多數人並不是天才的情況下,熟知一些基本的專案管理方法與知識,有益無害,會讓我們真正從事專案管理或做其它事務時更加效率。
對於ISO20000這種專案而言,專案經理的挑選至關重要,我的觀點是,對於一個ISO20000的專案經理而言,專案管理意識與經驗比ISO20000的知識更為重要,以下的是我認為幾個比較重要的素質要求:
找一個聰明些的腦袋比什麼都重要,它會讓許多複雜的事情變得簡單而容易,雖然現在的工作者基本上是受過正統的教育與檢驗的,但在你跟周圍的人的每一次交流、會議、報告、工作接觸、材料閱讀中,你還是會發現有一些人比其它人更能展示出清晰的思路和某種敏銳,它可能是先天也可能是後天的,發掘出來這種人出來,讓他做更多的事情,承擔更多的責任,會省很多事,這也是為什麼一些IT公司尋找最聰明的人的原因,這裡指的聰明不是指IQ或學歷的最終結果,而是對事物能迅速、靈活、正確地理解和解決的能力,即趨於智慧。在專案過程中需要不斷的學習新東西,理解、分析、判斷當前的情況,做出合理的干預措施,包括以下所說的各種要求,無一不是以一個聰慧的大腦緊密相關的,不夠聰明的大腦容易做出糟糕的決策,糟糕的決策容易把專案拖入不可控制的困境,要讓有利條件最大化,才能讓成功機率最大化中,才能讓專案成本最小化。
管理過專案的人有一種心理經驗,從專案開始團隊初成的情緒高漲、到開始慢慢的問題越來越多,心中開始產生焦慮,然後會出現比較嚴重的困難,似乎已無力掙脫泥潭,此時整個專案位於最低點也最關鍵點,內部的專案成員位於情緒的最低點,各種負面情緒接連而至,懷疑的聲音越來越多,最後來自到專案外圍的領導層的壓力也越來越大,然後專案經理焦頭爛額的想辦法化解,漸漸豁然開朗,到專案後期時,一切又越來越趨於控制之內,各方的情緒又隨之拔高,到最後專案結束的喜悅時,大多數甚至不記得在專案最困難時的那種負面的情緒了,而專案經理在想起以前某個專案時,第一反應更多是做那個專案時那種心理起伏的感覺。性格的特質對於專案經理也特別重要,專案某種層面就是一堆接著一堆的問題的集合,或者說那就是一團亂纏在一起的網線,不是網路的網,而魚網的網,專案經理要做的就是解開它。一個性格不強健的人容易在困難出現的時候陷入消極應對,在遭受指責與批評時進行無謂的對抗,這都會置專案於不利的地步,進取型的人的目標性較強,這使得過程中的困難、障礙、矛盾不會成為太大的干擾,專案經理就得把專案扛在肩上,連爬帶滾的衝向終點,而不是碰到困境時,把沙包丟掉自己先逃或推卸責任由別人頂包,要有迎面問題的進取心。
一個廣義的管理能力定義基本包括前後所說的所有要素了,這裡說的管理能力只是相對狹義的,更多是指方法與技巧層面的,對於管理能力的定義很多:比如在國家的通用標準中是指四個模組:自我發展管理,團隊建設管理,資源使用管理,運營績效管理。針對具體的方法技能則是指:
n 設計能力:制訂組織架構、流程、規則、方法、產出的能力
n 組織能力:將資源(人、物資、資金、時間)進行分配、組合、以使其按預期既定的模式運作的能力。
n 計劃能力:對一個複雜的任務進行無遺漏的邏輯分解、並在時間上進行前後排序作業設計的能力。
n 控制能力:圍繞已有的計劃、目標、約束對作業程式進行檢查、調整、改進施加影響的能力。
n 授權分工能力:根據任務的屬性以及成員的屬性,對兩者進行最優組合的能力
分析能力是根據資訊對客體的正確判斷的能力,決策能力是指在合適的時間完成合理的決定的能力。管理的核心在於分析與控制,沒有分析就沒有決策,沒有決策就沒有控制,分析能力確定當前的方位,能夠指出透過最終目的可能路線,決策能力需要挑選出一個最佳路線,一個管理者沒有良好的分析能力就如一個司機沒有方向感,這樣就沒有辦法到達目的地,或者沒有辦法效率的達到目的地,缺乏良好的分析能力將使一切變得艱難,無法對當前的情況做出正確的判斷,甚至不知道要進行判斷,這樣就容易造成在最需要的時機沒有做進行干預或沒有進行正確的干預。談到分析能力人們第一反應就浮現一大堆的資料包表,這是對分析能力的侷限,大多數場景是沒有資料這樣明確量化的參考的,當我們看一張漂亮的臉孔時,這其實就是一種分析,我們在很短的時間就分析認為這張臉是漂亮的,只是分析動作太快了我們就不覺得它是分析,當我們覺得現在公司管理情況很不好時,這其實也是一種分析,只是這個分析過程非常內在化,這兩個例子中我們一下子沒有辦法去理解這個分析的模型而已,所以某種程度上這些其實也是一種運算,當一個運算非常複雜而迅速時,我們會覺得它很“自然”,它是“人性”的,它不是機械式的,而是天然存在的,這時我們理解不了也覺察不到它的運算分析過程,如果我們哪一天可以理解了,那麼人工智慧的時代將會到來,這種瞬間的分析能力是人類最大的進化結果。
從更抽象的層而來說,分析能力的優劣則是每個人的計算模型與速度造就的,而每個人內在的模型是隨著後天進行不斷的調整的,從出生甚至在母胎中時一個模型就開始建立,而後隨著對外圍的感知模型開始複雜,漸漸分裂成多個子模型,然後又各自發展,出現矛盾、又不斷進行調和,當一個區域性的子模型發展越複雜時,往往意味著這個人某方面的能力會越強,在這個巨大的相互關係的體系中,內在層面我們一直傾向建立一個統一的、不矛盾的模型,當我們的內在模型實現統一時,我們會感到內心和諧,這與認知與痛苦有緊密的關係,我們對世界與自己的看法隨著這個程式慢慢的在改變,自我就在這經年累月中形成,所以按照這種推理,自我未來必然可以被複制,自我也是可以被摧毀的。
一個管理者的大部份工作時間會在溝通表達上面,與上級與下屬交談,會議、報告、培訓,大部份表達是依附於口頭,也有相當的比重依附於文件,溝通表達的目的無非是希望在充分說明情況下,得到別人的支援、配合、理解。這意味著這方面能力會影響面很大,當你需要向上級索要資源與決策支援時,你需要它,當你需要向下屬下達任務與作業要求時,你需要它,當你需要向一個團體推銷一個方案時,你需要它,對於別人來說,絕大多數的能力體現都是透過你每一句話、每一份文件去感知的,這如水桶理論一樣,你其它方面的能力再強,溝通表達能力不足,也只能發揮與溝通表達能力相等的績效,它會一直決定你的最短板,而且它會影響你的人際關係與個人形象,大多數人第一直覺很難相信一個文件做得糟糕無比的人會是一個有能力、思路清晰的管理者,也很難相信在一個非受迫的環境下無法清楚表達自己想法的管理者,可以很好的帶一個團隊完成任務,這些情況雖然不是一定理智的,但這是合理的現實,除非你是非常高層的領導,不然大都數時候,仍然需要自己做文件、自己想清楚怎麼講話,這些基礎的技能一個合格的管理者應該要紮實掌握,這並不是鼓勵誇誇其談,也不是鼓勵文件花哨,現在社會帶有較強的趨銷售模式,不能指望領導、同事、下屬的全能全知,管理者自己要能充分表達自己的思想,文件也應該展現適當的工整與美感。
的理解能力
對於一個專案經理來說,ISO20000是一種業務知識,對業務知識的理解與掌握會有利於專案經理的工作,雖然我認為它不是專案經理必備的知識,但這只是在任命專案經理的時候的判斷,一旦開始專案後,專案經理必須要掌握一定程度必要的業務知識,這樣會更有效率,也會避免一些業務的特性不能很好識別,而造成專案過程中的錯誤作業,所以我的建議是ITIL foundation級別的知識還是要具備的,當專案規模越小時,越對專案經理的業務知識掌握提出更高的要求,專案規模越大時,專案經理的業務知識掌握要求反而可以降低,這兩者成反比。業務知識的掌握與理解在上述的能力具備條件時,是多多益善的,但把它拔高到第一個順位則是本末倒置了,這是很多公司在挑選專案經理的一個很大的誤區,
專案經理的素質要求,以上只是選擇性的說明了幾個比較重要的幾個項次,它並不全面,這是其一,其二素質的評判並不是0和1之分,每一項素質都是或多或少的問題,就上面而言,如果第1、2要項匹配得很好,但其它要項很差,或者第3、4、5項要項很好,其它要項很差怎麼辦。每個人都或多或少具備這些能力,要考量釋出的特點與專案要求是否匹配,甚至要考慮到缺點的分佈,是否此人的缺點與專案要求有嚴重衝突,如果一個人上述的能力都OK,但是他與專案幾個關鍵成員以前因為工作產生了嚴重的矛盾不和,讓他負責專案能很好完成專案嗎?。其三除去素質外,每個公司的環境不一樣,需要考慮的因素更多,比如時間因素與權力因素,一個具備以上素質要求的人員,他從事重要的生產職能管理,不可能脫身從事ISO20000專案管理事務,或者這名人員在公司處於底層作業,讓他擔負專案經理,是否有可能真正掌握權力去調配比較職位高几個層次的人員作業,這些都是很現實的因素,需要針對每個公司不同的情況做不同的考量,找到那個最有可能把專案做成功的人員來擔任專案經理很重要,高層領導做的人員任命決定是非常有影響力與破壞力的。
7) 在
目前國內有不少公司有ISO20000諮詢業務,尋找一家有實力、專業、負責任的諮詢公司很重要,目前通常的做法,首先圈定備選的諮詢公司名單,圈定的原則基本是搜尋諮詢公司有哪一些,然後查詢一些這些公司的資料,一般公司網站上會有介紹,看這些公司的開業歷史、業務範圍、業務規模、專案經驗,一個業務範圍廣、規模不大的公司基本是不大可能專業的,專案經驗少的也不太可能專業、一個成立不久的公司同樣不太可能專業,一般而言尋找做過有跟自己公司業務相近的專案的諮詢公司是相對好的選擇,這些再查詢看一些對這些公司的評論資訊,基本可以擬定一個備選名單。
有了一個備選名單後,可進行業務聯絡,經過第一輪的接觸,即諮詢公司的自我推薦,會剔除一部份不合格的,保留3家左右的諮詢公司進行最後選擇,後面更多是對諮詢方案的評價,與諮詢顧問的評論,要牢牢把握一個重點,選諮詢公司最終其實對顧問的選擇,一個看似有實力的諮詢公司可能派出不合格的諮詢顧問服務,以目前的ISO20000諮詢情況而言,尤其如此,所以在諮詢公司講解諮詢方案時,要求由諮詢公司的專案擔當顧問進行講解,以加強了解,而不是由諮詢公司安排所謂的專家來講解,諮詢公司的售前階段,多數會派比較有實力的顧問與專家來應對,最後拿下合同後,再派一個其它的顧問來作業,那些售前階段的專家顧問多是不參與具體專案的,或者只是掛個名,偶爾來轉轉,要特別注意這個環節的把關,一定要在未籤合同時,充分與真正負責專案操作的諮詢顧問交流,以做到適當的瞭解,因為中國真正合格的管理諮詢顧問非常非常少,尤其以ISO20000這種相對新生的國際標準,情況更甚之。大多數相對成熟的諮詢公司的諮詢方案基本形成了固定的模版了,只需在裡面把客戶的名字與標識改一改即可,這樣的方案他們講過無數次,不懂行的人難以看觀破綻,所以要準備更多的問題,包括專案操作、理論、業務的問題來進行測試,這種互動性質的交流比較容易驗證出諮詢顧問的認知與能力。不建議負責專案操作的諮詢顧問人數過多,除非公司業務地理非常分散而且規模很大,不然以一個顧問為佳(如要是二個人,一定要搞清楚共分工),參與專案的諮詢顧問多,往往意味著諮詢顧問的實力不濟需要多人合作,或者諮詢顧問的時間不能保證,需要幾個顧問拼湊時間,也有可能是有新入職顧問需要試驗品來學習,以ISO20000這種標準而言,許多人的理解不一,不要以為諮詢公司的顧問是一致的,多數諮詢公司的人是找來的成品顧問,這些顧問都是基於過去自己的經驗理解,幾個認識不同的人一起給你治病,可以想象其中的風險,尤其ISO20000各流程的介面關聯甚多,這樣體系非常容易出現問題。另一個經驗是,要注意那些動則在售前階段諮詢公司的老總來參與的情況,看視對方重視客戶,實際上可能與這個公司的實力有關係。
選擇諮詢公司沒有一個定性的方法,多瞭解,多準備問題,多互動交流,多直接與專案擔當顧問提前瞭解,都是降低選擇風險的方法,以ISO20000諮詢業務來看,國內目前還難以成長比較有實力的專業諮詢公司,這個市場很快會象ISO9000一樣進行惡性的競價,最終諮詢公司為了生存會加快專案操作,以證書為第一考慮,客戶最後口碑差,價值感越發低,如此形成一個惡性的迴圈,這是中國諮詢業的悲哀也是中國企業的悲哀。
諮詢公司選定後,商務合同需要進行擬定,基本上ISO20000的服務級別管理是同樣適用於此的,象服務日曆、服務目錄、服務級別、服務報告這些要素同樣需要考慮,比較關鍵的在於服務目錄的部份,在明確甲乙雙方的分工與責任,要清楚界定諮詢公司的到底做什麼,不做什麼,比如提供多少規模的什麼樣的培訓服務,在專案過程中是否擔任專案管理職能,還是隻提供純粹的諮詢意見即可,諮詢公司是否參與檔案編制,或者是否提供哪一些案例參考,在服務過程中提供哪一些報告與產出,顧問在現場的服務時間是多少,遠端服務時的響應時間是多少,這些能明確的部份要寫入合同,如有可能把參與專案參與的顧問人員也寫入合同,並明確寫明諮詢公司不得中途更換諮詢顧問人員。合同驗收條件要進行明確,不建議在合同中寫入過多不可量化的、不切實際的要求,比如一些類似合同寫著要明顯提高甲方的服務質量與客戶滿意度等等,這種要求本身期望於在專案中進行解決是不現實的,如果嚴格進行測算,需要設計一套明確的測量方法與計算方法,不然根本無從知道現在以及專案結束後的服務質量是多少。在合同簽訂時乙方大多數時候會為了贏得合同答應這些條件,碰到較真的甲方,最後就容易發生糾紛,不滿意是由於心理預期與實際感知的落差造成的,甲方應理智的對待專案與合同,要真正把自己的專案需求梳理好,進行一個優次排列,這樣真正明白哪一個是真正重要,哪一些是可以放棄的,覺得花了錢不多做些好象吃了虧,事實上在一直想抱著一堆目標作業時,最後會發現連最重要的目標也保障也出現了困難,這都是在對專案寄於了過高的期望,乙方也應該有技巧的引導、調整甲方的心理預期,畢竟這方面乙方的認知是相對理智與有經驗的。
尤其注意的是付款的條件,要針對性的進行設計,把握好其中關鍵的里程碑,考慮雙方的利益問題,合適的付款條件會對甲乙雙方形成壓力,對甲方而言,當然是款項越後面支付越有利,但如此諮詢公司的成本支出就顯得不公平並帶有很大的風險,對乙方而言越早付的款項越多,就對自己越有利,但如此甲方的利益就缺乏最有力的保障,一般而言合同簽訂會付一部份,培訓完成後付一部份,體系檔案完成編制後付一部份,體系正常執行一段時間後付一部份,認證完成後付一部份,最後判定驗收條件全部後再付最後的部份,這樣子切分成多個部份,諮詢公司會期更大的動力去追逐作業程式,同時每一個階段開始前,諮詢公司都提前得到了收益,不會成本預支的問題,而對於甲方而言,因為錢已經付出,必然要得到服務並對服務質量進行評判,雙方形成一個良性的博弈,對專案的成功形成正面的動力。
專案目標的定義多數情況並沒有得到重視,如果一個專案是軟體開發型的專案,這時目標會顯得相對顯而易見,但當是一種管理諮詢類專案時,對它的目標定義就存在一定難度,但目標又是如此重要,沒有它的指引,任務無法生成、作業沒有方向,結果無法判定,對於ISO20000這種專案而言,每個公司在專案初期都宏圖大志,證書反而是最不考慮的,但隨著專案的進展後,會放棄越來越多的目標,最後唯證書論了,這裡做為公司的領導,最需要清醒的是,在週期以半年或一年計的時間裡,你花錢做這個專案想幹嘛,到底想幹嘛,要想清楚,用常識也會知道,在半年或一年的時間內,建設一整套設計優秀的制度這本身是很困難的,何況是要讓一整套制度進行運作起來,而且要拿到一個國際認證,這些要實現其實是很難的,真正把按月把時間切分一下,你會發現,一般設計一整套覆蓋全公司的流程制度要有2-3個月內完成,考慮到編制、評審、修訂,而且參與人員的文件能力與設計能力,這是很難的,最後會為了趕進度而犧牲設計質量,要理智的看到在短短時間我們能做什麼,把最難的事情給做了,把離開諮詢顧問做不了的事情給做了。注意專案目標包括時間的目標,即賦予這個專案多久的時間來實現目標,不建議採用低於半年的時間目標,也不建議採用超過一年的時間目標。
一個ISO20000專案,最重要的是得到一整套設計合理的流程制度,也即是一個好的管理體系,其次這個管理體系要得到外部的檢驗,即一個國際標準認證,再次之是培養一批理解ISO20000的ITSM核心的中層管理者,讓組織得到一個持續監控、維護、改進管理體系的方法。有了四點(一個體系、一個認證、一個隊伍、一個方法)這個專案才會不斷的開花結果,未來服務質量的提升才更有保障,這樣才不會專案一結束,體系就死亡,這四點都可以進行具體的檢驗判定,而且這四點甲方難以在沒外力的情況下進行作業,能做好這四點就非常非常完美了。大膽放棄一些具體的業務指標,比如成本下降多少、質量提高多少、效率提高多少、滿意度提高多少,這些指標的決定的因素與條件是非常複雜的,管理體系只是其中一個要素而已,這些指標的提升需要更長的週期,更全面、更系統化的改善,不能把這些亂壓在專案中,不然會非常容易出現問題。
有了專案目標,接下就要設計一個專案體制去實現它,體制中最關鍵的一點就是專案經理的權責定義,不要搞那些流於形式的專案經理制,中國大多數的公司的風格是什麼專案都會讓職務最高的領導來擔任專案經理,但實際上專案操作這些高層領導不可能負責,這些就造成一個嚴重的問題,真正負責專案管理的人員沒有對應的專案經理的權力,真正有專案經理權力的人不負責專案管理,負責專案的人員做事名不正言不順,反而會經常受到高層領導的專案事務干預,無法按自己的思想去做專案操作,最後誰都負責也誰都不負責,造成一系列的困境,一個清楚的組織架構比什麼都重要,一定要切分清楚專案經理的權力邊界與職責邊界,要明確什麼事情專案經理說了算,什麼事情需要由高層領導決策,要明確專案經理做什麼,專案經理是一個角色,體制的第一層是定義好有哪一些小組,哪一些角色,這些角色分別的權責是什麼,第二層是然後是分別是誰擔任什麼角色,這樣才能形成一個真正可以指導作業的專案體制。
ISO20000專案的體制,建議的職能組可分為:決策領導、專案經理、專案助理組、諮詢組、培訓組、流程設計組、流程評審組、體系實施組、軟體工具組、認證稽核組。
u 決策領導:階段性的瞭解專案進度,對重大決策進行決議,提供資源支援,授權專案經理的專案權力。
u 專案經理:擁有專案內事務的最終發言權,制訂與控制專案計劃、策略、協調、檢查各小組的任務,對專案成員進行考核,工作對決策領導負責。
u 專案助理:為專案成員服務,提供後勤支援,負責會議管理、文件、模版管理、計劃跟催、檢查反饋。
u 諮詢組:對專案作業中的問題提供諮詢建議與解決方案。
u 培訓組:負責整個專案的所有培訓組織、管理、記錄。
u 流程設計組:負責程式檔案的設計、編制、修訂、解釋。
u 流程評審組:負責程式檔案的評審。
u 體系實施組:負責程式檔案的釋出、執行落實、執行檢查與反饋。
u 軟體工具組:負責體系執行的工具技術支援。
u 認證稽核組:負責外部稽核的組織、準備、配合
以上只是根據公司的專案規模可進行職能合併與重組,小組建制越多,職能越明確,但小組間的任務互動就越複雜,專案經理整合任務與資訊的能力就要越強,小組建制越少,職能越不清楚,但小組間的資訊互動也就越少,作業管理難度也相對較小,具體的取捨要根據具體的情況來定。上面介紹的職能是很粗略的,在真正設計專案體制時,需要具體畫出組織架構,並做職能文字說明,專案體制一定要明確對所有專案成員進行公佈,以所有成員清楚各自的權力與職責,避免出現不必要的解釋糾份,影響專案工作,在可能的情況在公司內部的資訊系統上進行公告,以擴大影響。
明確專案體制後,專案經理需要編制專案計劃,專案計劃建議進行分層控制,以便於進行管理,將專案的計劃分為三層:
u 第一層是專案一級計劃,它只定義關鍵的里程碑,這裡是指把整個專案按時間程式分解成幾個主任務,比如專案啟動是一個里程碑,然後第二個主任務是理論培訓,理論培完成的點就是里程碑,然後第三個主任務是流程設計、第四個主任務是流程評審,第五六七個主任務是流程實施、內部稽核、外部稽核,這樣最粗線條把專案分解成若干個主任務,定義出每一個任務完成的時點,列成計劃,這個就是戰略計劃,它必須得到決策領導的審批,這個戰略計劃一旦要變更,需要決策領導進行審批,所以一般而言一級計劃是嚴攻死守的,它一旦打破就意味著專案面臨基本目標可能喪失的問題。
u 第二層是二級計劃,一般是按月進行編制,或者按主任務編制,按月編制是不管屬於哪一個主任務的子任務分解,統一按月份來做計劃管理,一個月就一個計劃,一個任務只要落在某個月份就進行羅列排序,這樣的好處是所有的事務會在一個檢視中提現出來,利於統一跟蹤檢查,按主任務編制是指根據一級計劃的主任務分解,對每一個主任務進行再分解並進行單獨的計劃管理,這樣的好處是每個主任務分解很清楚,但當幾個主任務並行時,計劃管理較為困難。也可以將月計劃與主任務計劃同時進行,先編制主任務,然後再逐月制訂月計劃。二級計劃是戰術計劃,它是完成一級計劃的基礎。一級計劃與二級計劃都應該由專案經理進行制訂與管理。
u 第三層是三級計劃,一般是按周進行編制,即每一個周是一個計劃單元,周計劃來自對月計劃的再分解,最終是依靠每週的計劃推動來實現專案目標,周計劃就是執行計劃或作業計劃,它是可以落實到人的,在有必要而管理力度可以達到的情況下,日計劃的出現也是可能的,這取決於任務分解的可行性與必要性,一般而言周計劃基本上是可以滿足管控的目的了。周計劃可能由專案經理制訂,也可以考慮分組由組長進行制訂,即一個周計劃或分組多個周計劃管理,這個取決於實際的情況與環境。
計劃編制時考慮的要素是任務的內容是什麼、責任人是誰、參與者是誰、產出是什麼,什麼時候開始、什麼時候結束,擁這些要素,計劃才成為計劃。在編制計劃時要考慮適度的冗餘,在作業時一定會有各種因素打破既定的預期,尤其當專案的參與者大多是身兼多職時,更是如此,時間的冗餘設計同樣可以分層,在一級計劃時就預留10%左右的時間進行緩衝,即這10%的時間是不在計劃之內的,留著做最惡劣的時候來使用,二級計劃也做適度的冗餘,二級計劃不建議一開始就制訂出來,而是按階段按月進行編制,因為做過久的未來的比較詳細的計劃不切實際,只需做到適度的提前即可,計劃的目的是為了指導作業,有了一級計劃,每個月末根據當時的情況制訂好下一個月的計劃,這樣更有效一些許多細節的事務,不到那個階段時,是意想不到的。三級計劃因為是周計劃,同時有周末的時間可以緩衝,所以計劃可以排定得比較緊湊與精確。對於一些可以估算精確的任務要計劃嚴格些,如一個培訓一個評審,這種時間可以做好估算,這種計劃就得設計得嚴格些,但一個檔案的編制,則比較難估算,這時計劃就得留有一定的富餘。
計劃是否具備較高的執行性與操作性,取決於任務分解的精度,如果任務分解有遺漏,則很有可能導致計劃缺失,所以計劃的制訂需要非常重視,一級計劃比較容易制訂,二級計劃制度就有一定難度了,如果在二級計劃就出現缺失,會帶來不小麻煩,三級計劃缺失,還很有可能具體的作業人員會發現並提醒,但二級計劃這種戰術層面多數由專案經理一人控制,就非常依賴其個人能力,任務的分解首要對任務有清楚全面的理解,一般首先考慮這個任務是不是可以拆分成若干個子任務,當不能再拆分時,就考慮這個任務的作業步驟,如果作業步驟不能再拆分時,就考慮這個任務需要依賴什麼要素,按照三層邏輯去迴圈分解分一個任務基本上是可以成功分解,計劃分解到最精細時,就會成為一個作業指導,比如一個培訓,能不能拆分成幾個子培訓,不能拆就考慮它的步驟,培訓一般要先做培訓教材、然後是培訓展開,最後是培訓考核,這樣就可以拆分成三個子任務,然再分析每一個子任務,比如培訓教材製作,按同樣的邏輯再進行分解,先要做一個培訓教材的模版,然後收集培訓資料,再進行培訓教材的編制,然後再做稽核,然後列印,這樣可以分解得比較清楚,而且不容易出現紕漏;再分析培訓展開這個子任務,已經不能再分解子任務了,也沒有什麼步驟可言,這時可以考慮它的依賴要素有哪一些,要做培訓,需要有場地、裝置、講師、學員等等,這時就又可以分解出,確定場地,裝置的除錯等一系列的活動出來,如此不斷分析下去,就可以做出一個具有很高執行性的培訓計劃出來。
對於計劃的追求不宜過於偏執,基本上是不存在非常精確的計劃的,每一個專案結束時,你總會發現是有些情況你無法預計的。有些公司的領導會為了計劃而計劃,最後形成一堆沒有核心的流於形式的計劃文件,而忘記了計劃的根本作用。一定要把握計劃的意義所在,計劃是為了實現目標而讓大家清楚在什麼時候要做什麼事情,我非常強調專案經理去制訂計劃,是因為在制訂計劃的過程是一個建立專案地圖的過程,也是自我程式梳理的過程,它會幫助專案經理非常清楚的把握現在與未來的狀況,專案經理應該非常清楚專案的進展狀況,非常清楚哪一塊的計劃是存在風險與問題的。計劃要形象的在專案經理的腦內,如果專案經理的制訂計劃能力不強,應該組織進行計劃評審,以便大家的一個正確的作業指導依據,計劃制訂完成後,要進行正式的渠道公佈。
大部份人在有足夠的動力或擔心受到懲罰時,工作效能會更高。對於ISO20000這種專案,絕大多數的專案成員都不可能是專職的,所以專案的事務是本職工作額外多出的事情,而且這些人員多數還是管理人員,依靠什麼能讓一批管理人員長時間的額外做一些不是本職工作的事情,並且要按質按時的完成呢?領導這些管理者做事情的還不是他們的上司,大多數管理人員還是很忙碌的,所以這些額外的工作勢必會佔用他的日常工作時間,經常引發時間安排的衝突。這時去談職業精神與領導者的人格魅力,可能能在一週甚至一個月內讓這些人一直專案要求作業,但一年的話就很困難了,把專案的成功寄望於每個人的自律性與主動性,這是不現實的,所以必須要設計一個有效的績效模式,去解決這種做事的動力問題,說到底就是獎罰,每一個專案成員承諾一筆專案獎金,會解決一些問題,每一個專案成員如果沒有沒有做好,就罰去一筆錢,也會解決一些問題,不願意加班就發放加班費,這樣子說,可能每一個老闆會哭,每一個工作者會笑,這只是基本的道理與規律問題,實際獎多少罰多少,這取決於老闆的價值判斷與每一個工作者的價值判斷,如果這個專案的所有成員都擁非常高的職業精神,又這個專案的專案經理有著強大的威攝力,是不需要支出這種成本的,專案成員本著統一目標,不要一分錢的加班加點幹好專案,甚至說不準可以創收一些額外罰款收益,但這樣的公司與這樣的員工又真的沒有那麼多,大多數人還是現實的動物,而且每個人又可以很聰明的用各種方式與理由去解釋每一次沒有按時安質完成任務,所以績效策略還是相當必要的,如果要更有保障完成專案目標的話。
績效的設計的第一考慮是要有足夠的動力去約束激勵專案成員,包括專案經理在內,第二考慮是要讓專案經理掌握績效考核的權力,以便能有效領導與管理專案團隊,第三考慮是要有足夠有效的措施去約束每一個人具體的作業行為,專案最終其實就是成百上千件任務組成,專案的成功依賴每一件任務的按時按質完成,所以績效模型的設計要合理,對專案成員的績效設計,要從三個方面考慮:質量、任務量、行為,質量代表著分配給他的工作是不是按時按質完成,任務量是他投入了多少時間,行為是團隊意識與作業態度,三者佔有權重各不相同,而且要對每一個方面再進行更詳細的定義分解,以便有更明確的指導意義,績效要做日常記錄並在月例會上進行說明,績效的作用要發揮於當下,當專案結束時,再說績效考評,這樣的績效起不到多少作用,績效的設計要由專案經理負責,由決策領導進行審批,透過後應在專案啟動會議上進行正式公佈,要把績效納入日常管理,績效的資料是在作業過程中產生的,要融入例會制度之中進行報告,這樣才能最大效能的發揮作用。
專案目標、專案體制、專案計劃等等都是假設性的,它是專案的規劃設計,它只是空想的結果,其基礎是專案策劃者的分析能力與預知能力,這些假設是不是正確的是一個問題,專案會不會按料想的假設那樣發展也是一個問題,如何保證結果跟我們計劃的一樣呢?這就需要對過程進行控制,過程沒有控制,結果就沒有保障,控制二字的核心涵義,從字面可以如此理解,“控”意味著監控、觀察、知曉物件的情況,“制”意味著駕馭、制服、影響物件,綜合一處的意義為透過一種或多種方法瞭解某個或多個物件的情況,然後利用手段使物件符合按自己的預期或要求。專案過程控制主要是針對進度、質量、成本三這個方面,專案過程的控制是法無定式的,要根據具體的專案情況具體設計,以下是針對ISO20000這個專案的過程控制的幾個建議:
最重要的要讓專案有一個自我反饋、調整改進的機制,這個頻率要相對較高且有規律性,這樣才有機會及時干預控制,並形成慣性,設計一個定期的會議制度是一個比較好的選擇,會議非常耗費成本,但它的資訊擴散也非常有效率,會議制度可以進行分層,月例會:整個專案進展情況說明、上個月的計劃完成情況檢查報告、下個月計劃的分佈說明、專案問題跟進報告,月例會可以邀請決策領導層參加,以月例會為的專案資訊釋出渠道,同時專案經理提出超出其許可權範圍的協調事項的渠道;周例會:上週計劃完成情況說明,下週計劃公佈,專案內事務協調;根據具體的情況,有時在專案的某些階段,也需要設計日例會,尤其是檔案編制的階段,很容易一週的時間過去了,但沒有任何進度,這時就需要加強監控手段,或者要求任務者編制自己的子計劃,以加強管理。會議制度得到良好的執行,會形成專案的生產節拍,這也是專案的心跳,每個專案組成員心裡都會有統一的工作節奏,大家的資訊與對專案的感知也比較一致,會減少許多不必要的問題。有時會議制度久後,會形成一種管僚化,大家覺沒有什麼內容就放棄了對會議制度的堅持,這是很不好的,當制度都可以放棄打破時,沒有什麼是不能被打破的,這是帶給大家的一種資訊,對制度的堅持比制度本身更重要,它會帶來一種文化,它也會傳遞一種所有人都要毫無折扣的按制度行事,專案如果執行力的意識遭到破壞,會帶來一系列的惡果。專案經理要牢記不能讓那種渙散、敷衍的習氣在專案組內蔓延。會議制度一個是定期很重要,而會議的內容則更加重要,要定義清楚月度會議要做什麼,週會議要做什麼,把內容圈定在會議材料中,形成模版,會議時間無須過長,會議的形式可以是由專案經理若專案助理針對計劃進行檢查,任務負責人回答,也可以是由任務負責人或組長進行本週期完成的工作有哪一些。
檢查主要是側重於進度或側重於質量,進度的檢查要以“時”來檢查,即規律性的檢查,與會議制度相配合,比如每週五下午檢查本週的計劃完成情況,這種措施可以由專案助理或專案經理來負責。質量的檢查要以“事”來檢查,即把檢查措施放在任務計劃本身去,質量檢查可能會帶有較強的專業性,需要考慮檢查人的專業能力,比如象體系檔案編制是不是合格,對它的檢查專案助理與專案經理有可能沒有這種專業能力,這時可以安排專門的人員檢查,或者讓幾個負責檔案編制的人交叉檢查,這個檢查的動作設計到計劃本身去,這樣才能避免遺漏。檢查要側重於產出物,儘量避免依靠口頭確認,所以在製作計劃時,要考慮到每一個任務的產出物是什麼,當產出物檢查合格後,要上交到專案助理處管理起來,所以當專案助理看計劃只要到了交產出物的時間,就會要求交貨,而且他不是向作業者要求交貨,他是向檢查者要求交貨,這樣分層進行跟催檢查,可以讓作業者相對規範的完成任務。對於一些關鍵性事務的質量檢查,可以考慮做專題會議性質的評審,比如一個流程檔案編制完成要進行定版時,就需要組織人員進行評審。
專案經理在制訂計劃時,凡是有產出物的部份要考慮是不是要設計文件模版,設計一個合理實用的模版,會減輕作業人員的工作量,同時能約束產出結果,統一大家的作業規範。像體系檔案的編制,肯定是模版的,還有一些象計劃的模版,計劃檢查記錄的模版、會議材料的模版、體系檔案評審的模版、會議記錄的模版、培訓記錄的模版、日常績效記錄的模版,這些大大小小的模版會很多,專案助理要負責模版的管理與發行,文件模版要做好版本管理控制。
變更管理是指專案體制、專案目標、專案計劃、專案文件已確定的東西需要進行調整時,需要做變更控制,這裡強調變更,主要是兩點,一是要有授權,即誰有權力批准改變,比如一級專案計劃要改,專案經理不能決定,需要決策領導審批,再如一個定版的體系檔案要修改,需要專案經理審批等等,二是要有通知,改變了什麼需要告訴哪一些人,甚至會引發哪一些相關聯的事情發生,比如文件模版要改,會影響其它的哪一些檔案,要通知哪一些人員,專案經理要有變更控制的意識,避免引發混亂。
配置管理主要是指專案過程中文件管理,每一份計劃、模版、記錄、報表、報告需要統一管理起來,最好的方式建立一個檔案伺服器並利用專門的軟體進行管理,這樣大家調閱與修改都可以留下記錄,最需要關注是體系檔案的配置管理,由於一群人編制,隨著檢查與評審的過程,會不斷有新的版本產生,需要進行嚴格的邏輯與物理管理。另外一系紙質的檔案需要好保管歸檔,分門別類進行管理,最終專案結束時,從頭到尾的所以產出是可以查閱的,最終的專案成果也是工整清楚的。
1.10. 專案結束的管理
一個好的開始跟一個好的結束會讓你工作事半功倍,專案的啟動與結束要儀式化,非常正式的去操作,這會讓上至領導層下至專案成員,去嚴肅正視專案,長遠的對大家的意識產生影響,要利用專案啟動會那個時刻去樹立專案經理的權威,要利用專案總結會議去為專案成員爭取成績。一般談專案管理比較少重視專案結束的方法與過程,事實上結束與開始同樣重要,要找到一種符合公司情況的最有效的方式來結束專案。
首先要把專案目標做一次全面回顧,當目標達到時,專案才能結束,再回頭看專案初期定的目標,是否全部做到了對應,達到了判定完成的條件。其次是把專案成果進行整理,清查一次專案的所有文件,做一個分門別類的統計,看看專案團隊取得了一些成績,這些專案文件是一個公司的歷史與財富,在專案過程就要有這種意識做好記錄。接著要對專案過程進行總結,專案經理需要靜下心來,回顧一下整個專案過程,分析一下哪一些地方出了問題,為什麼?以後類似的問題是否可以避免?哪一地方做得比較好,為什麼?是否可以供日後的專案複製?整個計劃的達成情況要做深入的回顧總結。過程總結完後,需要把專案過程中發現的未解決的問題梳理出來,以便於公司日後有人跟進改善。以上說的這些要形成一個工整的專案報告,這個專案報告很重要,要全面而深入,專案在編制之前,專案經理可以組織一次專案成員進行一次小型會議以收集更多大家的意見,當專案總結報告完成後,組織一次正規的專案總結會議,儘可能邀請整個專案體制的成員參加,專案經理在會議上報告專案目標完成情況、專案過程介紹、專案問題總結、專案成果總結。然後專案體制的各個小組分別進行發言,最後由決策領導對專案是否結束進行最終判定,並宣佈專案體制解散。一般而言一個專案結束時一定遺留一些問題或未完事項的,需要確定這些問題或事項的對應負責人員,以保障專案過程中的瑕疵得到處理,同時也利於鞏固專案成果。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23630258/viewspace-1032634/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- (轉載)手工搭建webpack+vue專案WebVue
- 下載Project 2021專業版專案管理軟體Project專案管理
- 傳統專案管理VS敏捷專案管理專案管理敏捷
- 技術轉向專案管理的心得筆記專案管理筆記
- 專案管理專案管理
- CORNERSTONE:用專案管理助推企業轉型升級專案管理
- 什麼是專案管理,如何做好專案管理?專案管理
- 專案整合管理
- 敏捷專案管理?敏捷專案管理
- IT專案開發團隊建設與管理總結(轉)
- 專案管理--PMBOK 讀書筆記(4)【專案整合管理】專案管理筆記
- 專案管理之風險管理案例-專案交付風險專案管理
- 專案專案管理包括哪些內容專案管理
- (轉)OC專案轉Swift指南Swift
- [原創] 我的專案管理之路--9、如何從技術向管理轉身專案管理
- maven 專案轉化成 gradle 專案實踐MavenGradle
- [原創] 我的專案管理之路--2、認知專案管理專案管理
- 專案管理基本流程介紹,讓你輕鬆管理專案專案管理
- 什麼是專案成本管理?如何做好專案成本管理?
- 運維專案管理用什麼專案管理軟體好?運維專案管理
- 前端專案如何管理前端
- 專案管理隨筆專案管理
- 最近專案管理感悟專案管理
- 專案資源管理
- 專案進度管理
- HDU 4858 專案管理專案管理
- 一.專案整合管理
- 專案風險管理
- 專案質量管理
- 關於一些爬蟲專案教程的整理(轉載)爬蟲
- 專題 | 專案管理知識、方法論、工具NO.3:事事皆為專案,人人都要懂專案管理...專案管理
- 《系統整合專案管理》第九章 專案成本管理專案管理
- 資訊系統專案管理系列之三:專案管理過程專案管理
- 資訊系統專案管理系列之五:專案整體管理專案管理
- 資訊系統專案管理系列之六:專案範圍管理專案管理
- CRM中的專案管理:搭建CRM與專案一體化管理專案管理
- 專案管理都管理哪些內容?專案管理
- 忽略特殊檔案(轉載)
- 專案控制管理:如何避免專案不達標?