確定ITIL項目期望的四個關鍵挑戰

為了成功，任何項目的工作組必須設定和運用期望--這方面ITIL項目并無它異。在ITIL項目中需要掌控的最大期望也就是能夠像管理其他項目一樣管理它。下面是四個不同點，它們會在項目章程大綱制定會議期間做各種決定時起作用，還會貫穿于項目的整個生存周期中。

1、ITIL項目實施需要多年

據此，要看到企業的ITIL項目的各個目標是在整體之外某階段起作用，這一點至關重要。據個例子來說，當執行配置管理方案時，會定義一個配置管理數據庫(CMDB)來儲存所有配置項(CI)的信息。在單個項目循環周期中，應該盡力首先配置最重要的類型的配置項。通過創建方案實施時間表來明確特定的配置項類型何時加入CMDB的做法會得到一致同意。各個利益相關人員可能不喜歡在該列表上排最后，但他們還是會支持該項目，他們知道他們并沒有被忘記或忽略。記住這一點，共同的培訓經驗讓每個人都能平等協商。

2、管理ITIL的各個項目應有程序規劃

大多數企圖實施ITIL的公司都能形成執行各個項目的方法，但卻極少有機制來管理若干年內的互相關聯的一組項目。考慮到ITIL實施需要若干年而單個項目的持續時間較短，可以成立一個成員組，這個成員組不以單個項目的存在時間為限--而是一個宏觀規劃的組。該組的職責在于保證整個計劃安排的客觀連續性，以及仲裁平行運行的項目間產生的沖突。

可以上面談到的CMDB的例子進一步說明，可以注意到被如此描述的CMDB是一個精確的，保持最新的CI信息庫。而且該庫的存在并不虛無。它需要信息變更管理以維持數據保持最新狀態(項目1)。信息存儲完備后，就可以通過事件管理來改善服務調用應答而使用了(項目2)。問題管理能把校對整理事件通知單以獲得問題通知單(即找出問題的根由)(項目3)。闡明研究CI之間的關系(項目4)來改善當計劃做一些系統調整時各個部分相互影響的分析，不斷提升應用程序可用性和減少不在計劃內的停工期。這些都需要宏觀規劃組來監視。如果你還沒有這么一個組，那得趕快組建一個。

3、是構建一個框架而非安裝一個產品

一般來說，產品安裝比起框架構建要顯得簡單。大多數主要的軟件銷售商經常抱怨他們的產品在多個公司安裝的過程。然而，當準備構建ITIL框架時，就會突然面臨決策問題，即怎樣才能使現存的網絡處理模型適應欲構建的ITIL項目。因為現存的處理過程包含于現存的應用程序中，把這些程序有機的組合是一大挑戰。

不要期盼找到一個簡單的最佳解決方案。你不得不使用你培訓所得的技能，權衡不同的處理方法，另外，基于ITIL的一些方案的自動化需用到的許多工具有固有的局限性，不得不同時作權衡，通過權衡做出明確的有機組合的方案。可能最重要的是，需要促使利益所涉人員積極的作出各種決定。因為ITIL不要求人們只以一種方式工作，但人們可能想保留選擇權而遲遲不做出決定。如果遇到的正是這種情況，提醒各相關人員每個項目只不過是整個征途上的一小步而已。在將來的某個階段可以重審這個決定。

4、在工程進行過程中會損失資源

在項目審查會議上，能發現項目計劃的一個最常見的假設(或不如說是危險)是假設資金、時間和人員在項目結束前能保持連貫恒定。根據單個項目的持續時間，可能能夠數出從項目開始到結束都在的人員。然而，對于一個歷時幾年的ITIL工程，懷疑每個人都能自始自終和你在一起。

在工程中制定保障措施以管理人員的變換--對那些較高級的職員也得提防。有兩個緩和措施可以采取：第一，確定候補人員，而且該候補人員是適合越多的項目越好。無需給與正式的職位，但要盡量使更多的人了解單個項目的關鍵元素。很明顯，實時狀態的文件和狀況報告能幫上忙，應避免只送單個人員去培訓。如果根據預算只能培訓單個人員，應該設法把培訓知識傳遞到組內成員之間。第二，做出培訓計劃以使項目組新成員快速的進入項目狀態。作為一個小組的新成員，但沒有制定好的措施使其快速跟上并快速發揮作用，那狀況要多糟糕就有多糟糕。