專案管理小案例

2021-03-18 01:17:11 字數 4938 閱讀 6843

、專案啟動會

劉某被任命為***專案的專案經理,被告知一周後要去客戶現場召開專案啟動會,需要準備乙個實施方案的***報告。劉某在與技術人員溝通後,寫了乙個專案整體推進方案,並設定了三個階段目標。但到了現場以後才發現,客戶要求的並不是乙個整體推進方案,客戶希望了解軟體系統長什麼樣?

如何在3個月內將現有老系統切換下來,其他的都不想交流,最終這次交流的效果可想而知,劉某寫的***根本沒派上用場。

問題一:這次現場啟動會,目標不明確,背景不了解,溝通不到位,準備不對口。首先需要明確的是我們為什麼要開這個會?

我們要達到什麼樣的目的和期望?通常情況下,專案啟動會是乙個動員會、誓師會,達到鼓舞士氣的作用。也可以理解為是乙個**會、引導會,達到引導干係人理解專案建設思路和規劃的目的,從而獲得專案干係人的理解和支援,使之積極參與專案的建設和推進。

問題二:專案啟動會的策劃缺乏溝通和準備。在專案啟動會召開前,作為啟動會策劃者、組織者的甲乙雙方專案經理的溝通顯得至關重要。

甲乙雙方領導人的關注點和意圖,需要通過甲乙雙方的專案經理整合。專案啟動會參與的干係人及他們的行程安排,需要提前溝通,並考慮不能按時參加的風險,安排必要的應急措施。會議地點、時間、發言人及發言內容設計,所需要的橫幅、投影、語音裝置等需要提前準備,會議通知需要提前1-2天下發。

專案經理張某沒有與銷售經理、客戶資訊科長溝通,就不可能了解專案的背景、期望,不可能了解客戶的想法和意願,因此也就談不上準備了,其效果也是很差的。

、專案策劃

a專案是乙個大型、複雜的專案,規劃有55個子系統,醫院計畫用三年時間完成此專案的建設。但醫院不知道該如何入手、如何推進專案,只是初步計畫用半年時間將原有老系統替換下來,即8月開工,12月完成切換。公司面臨的問題是資源短缺,現有人員對系統還不是很熟悉,his實施的4個人中乙個是專案經理,乙個是專案軟體經理,兩個入職不到半年的新員工;而lis、pacs、電子病歷實施的人員還沒著落。

當前資源只能滿足培訓,開發資源也非常缺,需要先做現場需求調研,進行離岸式開發,這樣開發團隊才能兼顧多個專案。客戶中心機房需要搬遷,伺服器、儲存、網路都需要重新做整合,硬體建設的工作量比較大,客戶期望在12月完成上線也有硬體工期的考慮。

針對這些情況,專案經理根據歷史經驗,在與部門相關人員討論後,決定:

1.階段規劃,系統切換方案及上線時間:如果定在12月份上線,系統上線後通常需要穩定3個月左右,這時候面臨跨年的問題。醫保存在年終結轉,加之操作員不熟悉,問題可能會比較多,專案組可能年都過不好。

根據資源情況,專案組將專案劃分為三個階段,第一階段的目標定位為替換原有系統,同時為了達到效果,加上電子病歷、lis和pacs。同時在第一階段中又分為兩個小階段,第乙個小階段對原系統進行點對點切換,同時上電子病歷,時間定在10月1號;第二個小階段推進lis、pacs的實施,開始時間定在11月1號。這樣系統有希望在1月份春節前穩定,並在次年4月份驗收。

為了減少因系統切換對病人、醫院帶來的不利影響,根據上線時間緊、資源前期投入不充分的情況,專案組決定採用新、老並行的切換方式。這樣不用醫院跟醫保協調修改資料的問題,對病人和科室來講,相對平滑,操作員也有乙個熟悉的過程,同時系統切換也有保險,即便新系統推進不了,老系統仍是乙個較好的應急備份。

2. 取消現場需求調研,培訓與需求調研相結合:如果先進行現場需求調研,然後離岸式開發,勢必會影響到這個上線計畫,10月1號是不可能完成上線準備的。

於是專案組決定立即開展培訓,在培訓中邊輔導、邊進行需求調研,以及需求的應對。

以第一小階段點對點替換老系統為目標,將需求的擴充套件控制在最低限度,同時以較少的開發資源在現場進行快速響。在乙個月左右的時間,專案組做到了資料準備、系統培訓、本地化需求及問題的響應和修改三大塊工作的並行推進。

3. 在正式伺服器、網路環境中培訓:培訓、測試環境與正式環境很多時候是分開的,即我們的軟體開發、測試、培訓在乙個單獨的伺服器、網路環境中進行,系統上線時再切換到正式伺服器及網路環境上。

很多時候切過去才發現正式伺服器及網路存在很多不完善的地方,對上線影響非常大。於是專案組決定協調整合小組在最短的時間內完成中心機房伺服器、儲存、中心交換機的整合,培訓直接採用正式伺服器、儲存及網路。這樣能在培訓階段發現正式環境的缺陷和不足,在將近乙個月的培訓過程中,確實檢查出了很多網路問題,這為後來系統上線做好了基礎準備。

4. 監督網路佈線、pc採購供貨、終端除錯的第三方承建商工程進度:網路環境及終端裝置是系統10月1號上線的基礎、前提條件,因此這一塊的工作雖然不是我們公司承建,但必須跟進、監督,以保證能按計畫上線。

專案經理協調資訊科長,要求第三方公司列出詳細的工程進度計畫,以最大的投入、最快的速度推進,在1個月內完成網路佈線及終端裝置的採購、整合、安裝、除錯等工作。制度每週例會溝通機制,每週檢查軟、硬體推進情況,分析其中存在的風險,解決其中存在的問題,以確保按計畫上線。

專案最終按計畫完成第一階段上線切換,同時也按計畫開始了lis、pacs的實施推進工作。

、專案需求調研

a專案是乙個戰略性專案,合同額度低、客戶要求高。在經過前期長時間的溝通後,專案組決定先進行調研,然後進行集中式開發。

專案組在調研前並未與當時的院長、主管副院長深入溝通,領導說你們直接找下面科室溝通吧。直接面對科室調研的最大問題是科室對資訊化建設的全域性理解不夠,各自為政,各自為自己部門的利益考慮,很多時候他們的需求相互衝突。

專案組在每個科室調研時,更多的時間用在了與操作員的溝通上,結果調研來的需求侷限於細節上的內容,而對流程和管理上的內容操作員是沒有決定權的。在一系列的反覆和開會之後,專案的進度一再延遲。

在經過將近7個月的調研的,主管副院長、門診部主任換人了,幾乎所有的需求又跟領導重新確認了一遍,而新任領導對前任領導規劃的態度模稜兩可,很多問題懸而未決。

結果需求調研及評審用了10個月,所得到的結果是一堆需求規格說明書及評審檔案,在系統上線後乙個月修改的需求和問題大於前期調研所做的開發工作量。需求調研週期過長導致前期調研的需求到後期因為各種原因有了很大的變化。而醫院職能部門負責人的調整,其對資訊化建設的理解差異,對系統的上線推進產生的致命的影響。

可以說,這個專案的失控就在於前期沒有策劃好需求調研。

現場需求調研、集中式開發,需要注意三個方面的工作:

1.調研的目標要明確,內容要盡量少,週期要盡量短。其實施內容不能過多,從調研到上線,最好不要超過三個月,期間最好不能跨年。實施內容過多,在資源投入不夠的情況下,很容易導致調研開發周期過長,而影響到上線時間。

跨年的影響一方面是節假綜合症,影響專案推進效率;另一方面是醫院容易人事變動,領導的變化對專案的影響是致命的。

2. 需求調研最關鍵的是領導層。系統的規劃是出於領導的思想、想法,是全域性的整體考慮。

售前諮詢與領導溝通到位還遠遠不夠,還需要策劃醫院領導對各科室中下層員工進行溝通,將思想統一,理念和思路明確。這樣在各科室具體調研時才不會偏離中心思想。而在各科室調研中,調研的物件應該是科室領導,而不是操作員。

很多時候我們會遇到這樣的科室領導:你找某某了解吧,即使扭轉不過來,跟他指定的某某調研結果必須得到他的確認。要注意,在醫院是領導說了算,領導才是關鍵。

3. 現場需求調研最重要的是白紙黑字。需求談話紀要、需求會議紀要、需求文稿、需求規格說明,這些文件是非常重要的。

需求是否漫延?需求是否擴充套件?需求是否模糊?

需求是否反覆?一切都需要白紙黑字來說明才行。需求溝通更多的是靠嘴,口頭語言的溝通很容易產生偏差和失真,因為溝通的內容受講話人的態度、情緒、眼神等外界因素的干擾,唯獨文字語言、圖表等是相對客觀的,可以上溝通資訊接收人有時間、空間餘地去思考,受人為因素干擾較少,其對溝通資訊的理解和判斷也就相對客觀。

我們經常會碰到老是扭著的客戶,很多原因因人而異,或許換個人去跟他溝通,問題就沒那麼嚴重了,這就是非文字語言溝通的弊端。

、專案計畫編制

a專案是乙個100萬的專案,專案組5人,專案實施內容為傳統his的核心。專案經理計畫實施週期為8個月,平均每月投入5人,5個人相對固定,流動性不大。在編制專案計畫時,專案經理根據歷史經驗,將8個月的工作計畫全部列出,然後在專案周例會上與大家一一確認,所有人都點頭同意。

結果這個專案的計畫變更有24次。

b專案是乙個400多萬的專案,專案組9人,專案實施內容為his、lis、pacs和電子病歷。專案計畫實施週期為30個月,平均每投入9人,其中4人相對固定,其他**動性大。在編制專案計畫時,專案經理根據歷史經驗,將專案規劃為三個階段,制訂每個階段的實施目標和實施內容。

然後在每個階段專案經理組織專案組制訂月度推進計畫,每週再進行周計畫,並在每週例會上檢查上週計畫執行結果。這個專案的計畫只變更過1次。

c專案是乙個3000萬的36個縣的區域性實施專案,專案組40人左右,專案實施內容為his、lis、pacs。專案計畫實施週期為10個月,平均投入40人,其中60%人員是流動的、不確定的,並且很多成員是新員工或剛畢業無工作經驗的。專案經理在編制專案計畫時,首先將36個縣分成三個階段推進,並將專案分成三個區域,設區域負責人,在每個區域的各個縣,設縣負責人;縣負責人報計畫組區域負責人,區域負責人報計畫給專案經理,由專案經理進行整合。

每週例會定周計畫和檢查上週計畫執**況。這個專案的計畫變更過3次。

通過a、b、c三個專案計畫的大體情況,我們可以看出:專案計畫的編制是非常有挑戰的,並且因專案情況而異,並沒有一成不變的模式,專案計畫的目的在於識別出專案風險,降低不利風險對專案最終結果的負面影響,並發揮、提高有利風險的發生,使之對專案的推進有益。

總體來講,專案計畫編制需要注意三個方面:

1. 里程碑計畫和詳細工作計畫:通常情況下專案的計畫可分為三層,第一層是合同回款里程碑,或根據專案背景情況制訂的較適宜的階段,之所以按合同回款約定定里程碑,是更容易考核專案績效;第二層是階段內的里程碑,階段內的里程碑可視為專案推進過程中乙個乙個的小目標,有明確的交付物和階段成果;第三層是詳細的工作任務計畫,即我們通常所說的什麼樣的事情?

由誰來負責?多長時間?交付成果為何物?

通常情況下,專案計畫的變更管理有不同的級別或層次,複雜的專案,不確定性因素很多,計畫的變更宜管理到第一層即可,簡單一些的專案變更可管理到第二層里程碑計畫。計畫編制及變更管理也是需要成本的,計畫越細,對制約因素、限制條件的分析要求越高。所以a專案的計畫變更過高很大程度上也是因為計畫過細,編制全週期的專案計畫幾乎是不可能的。

特別是對於大型三甲醫院的專案,週期較長,專案後期有很多不確定的因素在左右專案進度。因此,這類專案最好是明確制訂

一、二級里程碑計畫,詳細工作計畫則按月滾動編制。

班級管理小案例

藍菲點頭。菲兒主動說 老是,我們違反了紀律,您該怎麼懲罰,便怎麼懲罰吧,我們都接受的。我卻不打算懲罰她們,姑且讓她倆欠著我這份 人情 目的還是那乙個 當別的同學和藍菲對我通知家長不滿時,作為當事人的她們,好替我說句公道話。其實,我這樣做實在算不得科學的民主管理,但我們班目前尚沒有班規 最後,藍菲遲疑...

現場管理小案例

class txt 6s管理小案例 近年來,現場管理一直是企業界和管理界關注的焦點之一,各種先進的管理理念和模式不斷湧現出來,企業怎樣緊扣實際去選擇和匯入?xx車輛廠備料車間的做法給人以啟示。xx車輛廠備料車間是工廠鐵路貨車生產的前沿工序,擔負著工廠各種板材 型鋼及貨車部件的生產,僅敞車 棚車兩種主...

專案管理案例

曼聯足球俱樂部 妮克蕾特 拉森在和她的丈夫凱文一起裝卸洗碗機,告訴他關於曼聯 manchester united 聯賽組織委員會的第一次會議的一些事情。拉森自認為是乙個 足球媽媽 被選舉為聯賽主管,負責組織俱樂部的第乙個夏季錦標賽。曼聯足球俱樂部 musc 位於新漢普郡的曼切斯特,成立於1992年,...