CIO接不接手半截項目

1、CIO:接不接手半截項目案例背景“接不接這個半截項目？”幾天來，小李一直在琢磨著這個問題。在 IT圈兒里，接手半截項目的事情時有發(fā)生，因為成功率不高，因此這種事情一 般讓接手人談虎色變。小李是一個新任命不久的IT公司項目經(jīng)理，被部門經(jīng)理劉總派去接手一個 已經(jīng)完成一半的項目，原來的項目經(jīng)理小張由于公司安排，調(diào)到其他項目中了。 部門經(jīng)理劉總表明，目前項目大部分功能已經(jīng)開發(fā)完成， 單元測試和集成測試已 經(jīng)完成，因為用戶新提出的需求，尚有少部分模塊需要進行重新開發(fā)。按照部門經(jīng)理的介紹，重點針對需要修改的模塊，小李制定了一個較為明確 的項目計劃，在不修改其它模塊的基礎(chǔ)上，只需要 30天就可以完成項目，并

2、提 交給了部門經(jīng)理劉總。但是接手項目不久后，小李發(fā)現(xiàn)事實遠不像項目經(jīng)理劉總說的那樣，除了明確要修改的模塊以外，由于原來的測試人員水平和負責態(tài)度很差， 其他模塊其實 存在大量的問題，整個項目模塊都需要修改。而且，由于原來的項目經(jīng)理水平有 限，沒有留下什么文檔，小李和項目組其他成員只能按照銷售經(jīng)理的口頭需求和 以前的程序，一點點地修改所有的程序，項目的范圍變大了很多。小李找部門經(jīng)理劉總說明了情況，劉總才發(fā)現(xiàn)他也被原來的項目經(jīng)理小張欺 騙了，于是他相應(yīng)地給小李增加了一些資源， 但是小李認為現(xiàn)有的資源還是不足 以按時完成項目。而且，目前的項目情況和當時部門經(jīng)理劉總的許諾差距太大， 所以小李產(chǎn)生了一定的

3、情緒。項目由于范圍擴大，而且期間又有客戶的新需求，所以延期了一個月的時間 才完成。事后，小李被公司的CEO找去，批評他缺乏預(yù)見風險的能力以及項目延期的 事情。小李認為部門經(jīng)理劉總當初沒有了解清楚項目狀況并誤導(dǎo)了他，再說項目的范圍擴大了很多，延期一個月完成已經(jīng)是不錯了。小李認為自己當了部門經(jīng)理 劉總的替罪羊。小李、劉總，小張這幾個人都犯了什么錯誤，小李應(yīng)該如何做才能做好一個 “半截”的項目，并得到領(lǐng)導(dǎo)的承認呢 ？最大的錯來自企業(yè)高層昆山泓森信息科技管理顧問有限公司執(zhí)行總裁黃紹良:IT部門也缺乏一套完善的開發(fā)體系和管理體系，只從個別的進度匯報來衡 量項目的進度，未能從交付和用戶確認的監(jiān)控手段來證實

4、匯報的真實結(jié)果。一個項目發(fā)生超支，延誤導(dǎo)致未能如期交付的時候便需要有人負責， 任何錯 誤及罪過都直接指向當時負責該項目的項目經(jīng)理。 所以我常常勸告那些老是抱怨 公司未賦予足夠權(quán)力的項目經(jīng)理， 這是他們的“福氣”。在這個案例中CE（不指 責劉總，不指責被調(diào)職的項目經(jīng)理，單單批評小李便是最好的說明。其實最大的“錯”來自企業(yè)的高層管理人員（包括CEO和部門經(jīng)理劉總。這個案例說明國內(nèi)一個常見的IT企業(yè)通病，就是企業(yè)管理層對IT部門缺乏一個 明確的績效衡量和管理方法，同時IT部門也缺乏一套完善的開發(fā)體系和管理體 系，只從個別的進度匯報來衡量項目的進度， 未能從交付和用戶確認的監(jiān)控手段 來證實匯報的真實結(jié)

5、果。接不接手半截項目除非我們離職，否則我們不能拒絕半截的項目。其實在實際的情況下，大部 分的項目經(jīng)理都沒有選擇的權(quán)利，但是在沒有選擇的權(quán)利下還是有選擇的能力，例如利用足夠的數(shù)據(jù)說明你手上的項目已經(jīng)讓你喘不過氣來， 再向領(lǐng)導(dǎo)說明新增 加的項目對現(xiàn)項目的沖擊，影響和風險，建議其他可行的方法，讓領(lǐng)導(dǎo)去決定是 否應(yīng)該把這個半截的項目讓你負責。往往這些動作不會影響最終的決定， 就是需要接受這個半截的項目，但總可 以把其他手上的項目往后推延，讓你有足夠的時間來對這半截項目進行評估和計 劃。接手一個半截項目在20多年的項目管理生涯中，我的經(jīng)驗讓我深切理解，不要相信任何人告 訴你的項目一切內(nèi)容，必須確認、確認

6、再確認，來認證那些信息和結(jié)果。從這個 案例的描述中可以想象到，該項目缺乏一套完善的開發(fā)體系和管理體系，開發(fā)過程中很多行政交付（包括范圍變動管理、風險管理、項目計劃和進度報告等）和 技術(shù)交付（包括系統(tǒng)架構(gòu)設(shè)計、模塊功能規(guī)格、原代碼和測試報告等）都沒有到 位。作為一個項目經(jīng)理，依賴部門經(jīng)理對項目的了解來繼續(xù)執(zhí)行項目的開發(fā)是小 李犯的錯誤。小李的處境是相當?shù)湫偷睦?，國?nèi)外都有相同的情況發(fā)生。我過 去在接手一個半截項目的時候，首要是把項目的現(xiàn)狀和對項目范圍的理解與最終 用戶確認。因為只有最終用戶才知道他們最終的需求。在確認的過程中，可能讓 客戶有計劃增加項目的范圍，這些不明確的范圍便需要與被調(diào)走的項

7、目經(jīng)理確認 （這個案例說前項目經(jīng)理被調(diào)派去管理另一個項目， 所以還有機會跟原項目經(jīng)理 核對整個項目的范圍），如果前項目經(jīng)理的理解與最終用戶的最終需求發(fā)生沖突 的時候，便需馬上提升這些爭議到管理層， 對爭議進行仲裁和做出決定。 而不是 等事情發(fā)生后才匯報劉總爭取資源和時間。一個項目經(jīng)理接手一個半截項目與接手一個新項目沒有任何不同，只是一部分技術(shù)工作可能已經(jīng)完成。接手一個半截項目不代表項目經(jīng)理不需要考慮建立項 目范圍，考慮項目交付方法、項目風險和管理方法。做好項目經(jīng)理的工作前項目經(jīng)理對項目范圍的理解和最終用戶對項目的交付需求讓高層決議后， 便成為這個半截項目的范圍，對這范圍建立新的基線、計劃、質(zhì)量

8、指標、溝通計 劃、工作分派和執(zhí)行風險和進度管理。在過程中更需要有效地監(jiān)控范圍變動，爭 議，溝通，風險和進度。任何對項目發(fā)生影響的情況，需要馬上與有關(guān)人員進行溝通、協(xié)調(diào)和達成協(xié)議。要是未能達成共識，便需馬上提升讓管理層知道。這樣 可以有效地讓管理層投入項目中， 幫助你解決項目中地困難，同時讓管理層也擔 上一部分的責任。保護你自己除了讓管理層投入項目中，項目經(jīng)理更需要嚴謹記錄及執(zhí)行范圍變動， 風險 評估及應(yīng)變方法、資源及進度管理?？v然在項目完成后，負責的劉總離職，你還 有足夠的記錄和證據(jù)讓CEO!解項目的延誤“錯不在你”。項目管理知識體系除了告訴大家一個項目該如何管理外， 每一個模塊的行政 交付都

9、是保護項目經(jīng)理本身利益的最有效武器，尤其是風險管理。一個成功的項目經(jīng)理不是他本身的職責賦予多少行政權(quán)力， 是如何利用他本 身的能力來影響高層及一切資源，來達到你交付的目標。每個人都有責任肯曼管理顧問有限公司高級顧問黃曉剛:從這個案例分析來看，這個IT公司是一個很明顯的職能性組織的公司。IT 項目隸屬于部門管理，部門經(jīng)理有很大的決策權(quán)。另外一點，該公司并沒有建立一套科學(xué)有效的 IT項目管理的規(guī)范和制度。 比如：小張離開項目組，沒有任何交接手續(xù)，沒有文檔資料。在這個問題上，小 張、劉總、小李都應(yīng)該負有不同程度的責任。首先分析小張的問題。小張作為前任項目經(jīng)理，有責任在項目啟動初期，根 據(jù)公司現(xiàn)有的I

10、T項目管理水平，對上級提出建議，建立和完善適合本公司需要 的、或者本項目需要的IT項目管理方法或制度。這個案例中明顯反映了該公司在范圍管理（比如變更管理）、人力資源管理（比如團隊建設(shè)）、質(zhì)量管理（比 如程序質(zhì)量、文檔產(chǎn)品管理等）、風險管理（比如范圍變動、人員變動、進度變 化等）存在很多的問題。另外項目后期更換項目經(jīng)理是不多見的，是否更換需要提前進行風險分析, 決定更換后需要向項目管理委員會或上級提出變更申請，進行變更處理程序。其次分析劉總的問題。劉總作為部門經(jīng)理，在新的項目經(jīng)理沒有到來之前， 有兩種交接形式。一種是：如果劉總不具備項目管理知識基礎(chǔ)， 可以在小張離開 之前，提示小張必須在新崗位工

11、作期間， 為項目交接工作保留一定的時間，重返 該項目完成交接。另一種是：如果劉總具備一定的項目管理經(jīng)驗和背景， 可以要 求小張完成該項目狀態(tài)的工作總結(jié)報告，同時將項目暫時移交給他或項目核心骨 干或項目助理，等到新的項目經(jīng)理到位時，再進行轉(zhuǎn)交。劉總還犯了一個錯誤，就是在項目交接變更過程中缺少和 CEO勺溝通，導(dǎo)致 后來CEC責備小李。嚴格意義上講，在大多數(shù)的職能型組織中，CEOS接指責項目經(jīng)理是不妥當?shù)?。只有在一種情形下這種指責是成立的。 那就是該公司具備自 己的項目管理委員會，并且項目經(jīng)理需要定期向項目管理委員會溝通的，同時 CEC是項目管理委員會的成員。最后分析小李的問題。小李如果項目管理經(jīng)

12、驗豐富，在接受“半拉子項目” 前，應(yīng)該首先對該項目進行是否接受的摸底調(diào)研工作，全方位了解項目現(xiàn)狀、項目范圍、進度、團隊、產(chǎn)品質(zhì)量、溝通機制、存在的風險，然后基于調(diào)查的資料 和數(shù)據(jù)，制定未來的項目計劃。第二步才是向劉總進行溝通匯報，并且闡述如果接受這樣的“半拉子項 目”，自己作為項目經(jīng)理的職業(yè)原則和操作方法，為什么要制定這樣的計劃，為什么需要補充人力資源，如何控制范圍，如何控制進度，如何滿足項目質(zhì)量等等。 同時別忘了提醒劉總需要向項目管理委員會或 CEC報告。自己也需要向用戶進行 溝通，解釋項目管理方式和未來的項目計劃， 并且告知客戶在項目后期提出范圍 變更對雙方存在的風險。第三步才能在上級或項

13、目管理委員會簽字授權(quán)情況下，正式接受這個項目。為了保證完成這個“半截”項目，接下來小李需要注意以下幾個重點。要快速建立一套簡單有效的項目管理機制，并且通報項目團隊新老成員。一定要控制項目范圍，在項目后期進行范圍變更，或者客戶提出大的需求更 改，一般是不可取的。盡量用一些替代辦法來滿足需求的變更， 從而使項目進度 不至于延期。要檢查項目質(zhì)量，與客戶需求中提出的質(zhì)量要求進行核對。 盡量控制滿足項 目質(zhì)量而不是超越，從而也能為進度控制帶來好處。要加強溝通。對項目新老團隊成員要進行融合；對部門經(jīng)理劉總要做到多種 形式的匯報、建議和反饋；對客戶要溝通的不僅僅是需求上的把握理解，還要進 行項目管理方法和知

14、識方面的溝通， 從而為項目的順利完工創(chuàng)造條件。 當然，還 要注意保持與項目管理委員會或 CEO勺恰當形式的溝通。我認為，有了以上這些控制要點，小李在項目后期的工作就會變得更加順利， “半截”工程也不是什么難事。最終，項目的進度也會控制得很好，即使延期一 些，也會得到客戶、上級領(lǐng)導(dǎo)和團隊成員的理解。管理制度存在重大缺陷項目管理咨詢專家周名:項目是復(fù)雜的，IT項目更為復(fù)雜，沒有完善的文檔記錄，后續(xù)工作根本沒 法高效的繼續(xù)。該公司的項目管理相關(guān)制度需要完善。該項目問題較多，除去原項目經(jīng)理小張，新任項目經(jīng)理小李，部門經(jīng)理劉總 的工作出現(xiàn)問題外，該公司的項目管理制度和流程也有重大缺陷。首先來分析較為直觀

15、的各個責任人的問題。每個人都難辭其咎原項目經(jīng)理小張的項目管理較為糟糕。 項目管理文檔缺乏，對項目小組成員 的工作監(jiān)督考核不到位，向上級反映情況時較為草率，項目在未完成的情況下調(diào) 任其他項目時，不顧及繼任者可能遇到的巨大問題而提供建議報告等問題，反映出小張還不是一名合格的負責任的項目經(jīng)理。新任項目經(jīng)理小李經(jīng)驗不足，也存在很多的問題，集中體現(xiàn)在如下方面：輕 易接受上級關(guān)于項目的介紹，不做細致的調(diào)查了解；急于求成，大致獲取項目狀 況便著手制訂計劃；由于工作問題產(chǎn)生情緒；計劃中忽略模塊之間的耦合性。不過小李對工作的負責態(tài)度是值得肯定的， 而且，雖然由于接受了不準確的 信息而產(chǎn)生認識和實際的巨大偏差導(dǎo)致

16、自己計劃失策引起了較大的情緒，但是還是堅持了“先解決問題，后追究原因”的工作原則，難能可貴。部門經(jīng)理劉總問題較大，難辭其咎。首先，沒有嚴格要求下屬項目經(jīng)理做好 項目文檔管理工作；其次，輕信下屬的工作匯報，不對其進行校驗確認；最重要 的是，其在所管項目出現(xiàn)項目經(jīng)理調(diào)換情況時， 工作嚴重不到位，組織新舊項目 經(jīng)理進行項目交接應(yīng)屬于其本職工作，但卻沒有做導(dǎo)致項目的嚴重問題。這些責任人工作出現(xiàn)問題不只是由于其本人的能力和責任感問題，更重要的是由于該公司的項目管理制度和流程存在較為嚴重的問題。小李接手項目后，發(fā)現(xiàn)項目沒有留下什么文檔，只能通過銷售經(jīng)理的口頭需 求和以前的程序來進行工作。項目管理文檔缺乏甚

17、至沒有，不只是原項目經(jīng)理小 張的問題，更重要的原因可能是，該公司的項目管理制度中沒有對項目管理文檔 的要求，或者要求不清晰明確，或者沒有相應(yīng)的考評審核機制。項目是復(fù)雜的，IT項目更為復(fù)雜，沒有完善的文檔記錄，后續(xù)工作根本沒 法高效的繼續(xù)。該公司的項目管理相關(guān)制度需要完善。小李接手項目時，不是和原項目經(jīng)理小張進行項目交接， 而是從部門經(jīng)理劉 總處獲取資訊?，F(xiàn)在通訊技術(shù)如此發(fā)達，即使小張已經(jīng)被派往國外，小李也可以 通過電話或者Email與小張進行項目交接。即使項目沒什么文檔，那么部門經(jīng)理劉總可能通過小張的匯報了解項目的大 致情況，但是對于項目的具體狀況以及存在的問題可能不是很了解，這就需要新任項目

18、經(jīng)理和原項目經(jīng)理花費足夠的精力做好交接工作。另外，劉總許諾大部分功能開發(fā)完成，并通過了單元測試和集成測試，小李 接手后卻發(fā)現(xiàn)這些模塊存在大量的問題。 為什么上級負責人獲取的信息和實際差 距如此之大呢？這也是公司關(guān)于單元測試和集成測試的管理不到位的表現(xiàn)，工作沒有考評，沒有審核，就好像一個黑匣子，導(dǎo)致項目風險甚大。對于IT項目來說，項目經(jīng)理的水平和態(tài)度也很大程度上決定了項目的成功 和失敗，部門經(jīng)理的決策也對項目出現(xiàn)重大變故時能否妥善正確處理有重大影 響。因此，由于部門經(jīng)理和項目經(jīng)理同時出現(xiàn)較為嚴重的問題，項目失敗也在情理之中。如何做半截項目“半截”項目和普通項目相比，涉及問題更多，更為嚴重，項目成

19、功與失敗 不僅受制于新任項目經(jīng)理的能力， 而且受制于前任項目經(jīng)理的項目管理狀況， 及兩任項目經(jīng)理的交接情況。筆者也剛中途接手一個對日大項目的一個階段子項目，可謂“半截”項目，下面就以此為例，談?wù)劰P者對于“半截”項目管理的一些體會。筆者接手的那個半截項目主要工作是進行 UT測試（單元測試）。該項目是 一個設(shè)計為四層結(jié)構(gòu)（P層-C層-F層-D層）的復(fù)雜的JAVA項目。UT測試分為 兩部分：一部分是用JUNIT工具進行單層測試，另一部分是對單一模塊進行功能 測試。單層測試需要首先按照日方要求設(shè)計 PCL（測試式樣書）。成員們對設(shè)計PCL 不熟悉，對JUNIT工具應(yīng)用也不熟悉，對如何使用JUNIT工具

20、實施PCL中的測試 案例更不熟悉。項目極為緊張，工作量巨大，日方時間逼得很緊（嚴守納期是對日外包項目 的一大特點，納期即工期），而很長一段時間十幾個人的項目組工作似乎沒有什 么進展，公司領(lǐng)導(dǎo)焦頭爛額。在此情況下，筆者剛結(jié)束另一項目，正好被安排來 接手此項目。很顯然這是一個苦差使。項目出現(xiàn)了技術(shù)瓶頸，組員筋疲力盡，工作熱情不 高，領(lǐng)導(dǎo)不斷施壓，情況比案例更為糟糕。所幸筆者在做另一個項目時也曾跟蹤 過這個項目的進展，對使用的技術(shù)也有一定的理解。首先，筆者請示上級安排和前任管理者進行工作交接。 筆者擬定了一個交接 談話提綱，內(nèi)容包括當前組內(nèi)成員的狀況，包括前任管理者及項目組中對PCL和JUNIT了解

21、最深刻的組員對這兩種技術(shù)的認識，包括當前每個功能模塊的單元 測試狀況等等。時間緊急，在接受工作的當天晚上，筆者加班和前任管理者就此 在會議室進行了長達5個小時的交流。最終，交接完成，技術(shù)上達成了共識，不 僅可以把我的理解加入進去，而且可以很好的保留現(xiàn)有的一些工作成果， 一切都 較為明朗了。其次，筆者設(shè)計了一個簡易的調(diào)查表格，主要是對于技術(shù)的認識以及對當前 項目狀況的認識，當然還包括收集對策和建議的內(nèi)容。第二天上午發(fā)給了各個組 員，然后召集大家開會討論。會議持續(xù)了很久，最后大家都統(tǒng)一了認識，特別是 對技術(shù)的認識，在工作熱情方面也有明顯的改善，筆者基本掌握了每個組員的具 體情況。然后，筆者安排了解最為深入的組員和筆者一起設(shè)計 PCL模版，并整理出一 份對PCL質(zhì)量的檢查表，然后使用JUNIT工具模擬了測試，整理了工作流程。筆 者也綜合各個組員的具體情況