确定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的一些方案的自动化需用到的许多工具有固有i局限性，不得不同时作权衡，通过权衡做出明确的有机组合的方案。可能最重要的是，需要促使利益所涉人员积极的作出各种决定。因为ITIL不要求人们只以一种方式工作，但人们可能想保留选择权而迟迟不做出决定。如果遇到的正是这种情况，提醒各相关人员每个项目只不过是整个征途的一小步而已。在将来的某个阶段可以重审这个决定。

i　4、在工程进行过程中会损失资源

　　在项目审查会议上，能发现项目计划的一个最常见的假设(或不如说是危险)是假设资金、时间和人员在项目结束前能保持连贯恒定。

　　在工程中制定保障措施以管理人员的变换--对那些较高级的职员也得提防。有两个缓和措施可以采取：第一，确定候补人员，而且该候补人员是适合越多的项目越好。无需给与正式的职位，但要尽量使更多的人了解单个项目的关键元素。很明显，实时状态的文件和状况报告能帮上忙，应避免只送单个人员去培训。如果根据预算只能培训单个人员，应该设法把培训知识传递到组内成员之间。第二，做出培训计划以使项目组新成员快速的进入项目状态。