要實施ITIL必須管理好期望

威廉，莎士比亞的名言說道：“期望是一切悲痛的源頭?！彼\懇地用喜劇化語言告訴我們，當你負責領(lǐng)導某項業(yè)務的時候，你必須為了項目能夠順利進行而設(shè)定目標。所以我不得不對這位偉大的詩人說抱歉了，因為我要將他的名言改為：“不合理的期望是一切悲痛的源頭?！?

期望——我怎么知道什么是合理的
無論你是否具有系統(tǒng)開發(fā)、項目管理、商業(yè)分析或者其他的專業(yè)領(lǐng)域的背景，都應該聽說過設(shè)定目標的重要性。但是如果每個人都知道它的重要性，為什么每個項目都不能達到預期的目標呢？也許最相關(guān)的問題是你應該如何合理的設(shè)定預期目標。

期望依賴于建立合理的目標。根據(jù)本文的主題，我們規(guī)定目標的含義是股東們對于某個項目成果的共識。清楚的目標是最好的，因為它們最容易被衡量。顯然，這是股東們定義項目成功的標準，但是如果項目沒有達到預期目標，股東也是最容易失望的人。

為了將項目風險最小化，首先應該有一份完整的股東名單，并確保每位股東都包括其中。如果你發(fā)現(xiàn)某位股東不愿意參與此事，你有三種選擇。你可以勸說他們參與，也可以請高級管理人員幫助你勸說股東參與，如果前面兩種方法都不可行，你可以記錄下來哪些股東沒有參與該項目，并將其列為一大風險。因為如果你的項目結(jié)果不盡如人意的話，那么股東是最有可能對此表示不滿的，無論這是不是他們的本意。其次，一定要盡可能地減少那些不確定的決策。當然，你在作決定之前沒有先見之明，怎么降低風險呢？

彌補差距——我應該如何開始
絕大部分項目都有開始階段。這個階段中需要確定股東，起草項目文檔，明確項目目標，詳述債務來源及總數(shù)，明確項目小組成員和組織者，明確項目進程中的里程碑和交付時間。所有這些內(nèi)容都應該包含在項目計劃文檔之中。

不幸的是，絕大部分項目都在開始階段結(jié)束之后才開始進行人員培訓，那個時候項目中重要的計劃文檔通常都已經(jīng)完成了。你可能需要在項目開始之前就對項目中的關(guān)鍵人員進行培訓。在項目的開始階段，公司開始同廠商接觸，了解能夠幫助實施ITIL解決方案的工具。你必須在接觸廠商之前就形成內(nèi)部的專家意見，這樣才能夠和廠商位于同等地位。至少股東和團隊成員應該上一堂ITIL基礎(chǔ)課。

即使你還沒有確定廠商，早期的培訓也能幫助你的項目小組成員形成共同語言，幫助他們快速準確地討論如何實現(xiàn)這一構(gòu)架。很多項目小組都會在事后追悔莫及“我們不知道我們當時所不了解的是什么”。及早培訓能夠避免這種情況的出現(xiàn)。

ITIL計劃中四個重要的問題
為了確保項目取得成功，所有的項目小組都必須管理期望——ITIL計劃也不例外。ITIL計劃中，你需要管理的最大的期望就是——你希望可以象管理所有其他項目一樣管理它。下面是ITIL計劃同普通項目之間的四大差別，這將影響你決定項目會議和整個項目周期。

1、你的ITIL計劃可能會持續(xù)幾年的時間
確保每個獨立的項目目標符合整個企業(yè)的ITIL目標，且每個項目都對整體目標都有價值，是非常重要的。例如，你在實施Configuration Management（配置管理）項目的時候，規(guī)定使用Configuration Management Database（CMDB，配置管理數(shù)據(jù)庫）來保存所有的CI（Configuration Items，配置項）信息。從這個項目本身的價值考慮，你必須優(yōu)先處理最重要的CI類型。選擇的這些CI類型可能會引起沖突。你可以按照一個時間進度給大家提供一個清晰的說明，告訴他們哪些CI類型會被存放到CMDB中。你的股東可不希望出現(xiàn)在你的列表中的第20名，如果他們知道自己沒有被忽略或忘記，那么他們將更有可能支持你的項目。記住，共同的培訓經(jīng)歷將會讓人們有一個平等討論基礎(chǔ)。

2、你應該把相關(guān)的ITIL項目作為一個整體程序進行管理
絕大部分希望利用ITIL管理項目的公司都會創(chuàng)建一套項目執(zhí)行的方法。但很多公司都缺乏能夠在幾年的時間里，統(tǒng)一管理相關(guān)項目的機制。

如果ITIL計劃實施的周期橫跨幾個年度，而項目的周期通常較短的話，你可以成立一個比較長期的小組，該小組存在的時間會超過單個項目周期，稱之為程序組。程序組的職責是在整個執(zhí)行過程中確保整體一致性，并在與并行項目發(fā)生沖突的時候，做出協(xié)調(diào)和判斷。

還是回到我們上面舉的CMDB的例子，你可能注意到我們將CMDB描述成一個精確、實時更新的CI信息管理庫。但是這個庫并不是憑空產(chǎn)生的。它要求Change Management（變化管理）工作來保證數(shù)據(jù)的更新（項目1）。等數(shù)據(jù)到位以后，Incident Management（事件管理）開始使用這些數(shù)據(jù)改善服務響應（項目2）。Problem Management（問題管理）可以將事件和問題聯(lián)系起來（項目3）。在CI之間建立起完整的聯(lián)系（項目4）能夠改進影響力分析，幫助改善變化規(guī)劃，提高應用效能，減少無計劃的停工。從總體上檢查這些獨立的項目是程序組的職責。如果目前你沒有這樣一個小組，就應該考慮成立一個。

3、你在建設(shè)的是構(gòu)架而不僅僅是產(chǎn)品
總的來說，產(chǎn)品比構(gòu)架更容易實施，因為絕大部分主流的軟件廠商都已經(jīng)在大量的企業(yè)用戶身上積累了豐富的經(jīng)驗，并將軟件產(chǎn)品打造得比較完善了。但是，如果你要建設(shè)的是ITIL構(gòu)架，就突然要做很多決定，決定如何在ITIL的世界里重塑現(xiàn)有的方法。如果你目前的方法已經(jīng)存在于當前的應用之中，那么就需要將這些方法關(guān)聯(lián)起來。

不要試圖去尋找單一的最佳答案。你必須在各種不同的方法之間權(quán)衡，并限制可以使用的基于ITIL進程的自動化工具。但是最重要的是，你必須讓股東做出他們的決定。因為ITIL不是告訴人們做事情的唯一方法，人們可以盡可能地展現(xiàn)他們的想法。如果你發(fā)現(xiàn)自己身處這樣的處境之中，就一定要提醒股東，所有的項目都僅僅是漫漫長路中的一步。你可以在將來重新考慮這個決定。

4、在計劃實施過程中你可能會逐漸失去一些資源、
我在回顧項目會議的時候發(fā)現(xiàn)最普遍的項目計劃/風險之一是假設(shè)完成項目所需要的金錢、時間和人力資源都是穩(wěn)定而持續(xù)的。對于持續(xù)時間不長的單個項目來說，你可以指望某個人從項目的開始到結(jié)束都能參與。但是我很懷疑參與ITIL計劃的每個人都能從現(xiàn)在開始陪你走過未來的幾年。

如果你同意我的觀點，那么就應該在你的項目中采取一些安全措施來應對人員變動和交接的情況——甚至可能是高層人員。有兩種方法能夠減少影響：第一，盡可能多地為項目中的職位準備好接替的人員。你不需要設(shè)置一些正式的職位，你只要確保每個項目中都有不只一個人理解單項工程的關(guān)鍵因素就可以了。顯然，實時更新的文檔和狀態(tài)報告對此非常有幫助，但是如果條件允許的話，你應該盡量避免只派一名成員參加培訓課程。如果預算有限，只能培訓一名成員的話，你就應該想辦法讓團隊成員能夠盡快共享這些知識。第二，為新加入項目的團隊成員制訂培訓計劃，這樣能夠幫助他們快速上手。最糟糕的情況莫過于讓一名新人加入項目團隊，但卻沒有系統(tǒng)化的辦法讓他快速進入狀態(tài)。