有的项目在刚开始的时候，看起来都充满了希望。但不幸的是，不是每个项目都能发挥其所有的潜能。那么你应该如何开始你的ITIL计划，并保证能量水平与所关心的ITIL要求之间的运转正常呢？

威廉，莎士比亚的名言说道：“期望是一切悲痛的源头。”他诚恳地用喜剧化语言告诉我们，当你负责领导某项业务的时候，你必须为了项目能够顺利进行而设定目标。所以我不得不对这位伟大的诗人说抱歉了，因为我要将他的名言改为：“不合理的期望是一切悲痛的源头。”

期望——我怎么知道什么是合理的

无论你是否具有系统开发、项目管理、商业分析或者其他的专业领域的背景，都应该听说过设定目标的重要性。但是如果每个人都知道它的重要性，为什么每个项目都不能达到预期的目标呢？也许最相关的问题是你应该如何合理的设定预期目标。

期望依赖于建立合理的目标。根据本文的主题，我们规定目标的含义是股东们对于某个项目成果的共识。清楚的目标是最好的，因为它们最容易被衡量。显然，这是股东们定义项目成功的标准，但是如果项目没有达到预期目标，股东也是最容易失望的人。

为了将项目风险最小化，首先应该有一份完整的股东名单，并确保每位股东都包括其中。如果你发现某位股东不愿意参与此事，你有三种选择。你可以劝说他们参与，也可以请高级管理人员帮助你劝说股东参与，如果前面两种方法都不可行，你可以记录下来哪些股东没有参与该项目，并将其列为一大风险。因为如果你的项目结果不尽如人意的话，那么股东是最有可能对此表示不满的，无论这是不是他们的本意。其次，一定要尽可能地减少那些不确定的决策。当然，你在作决定之前没有先见之明，怎么降低风险呢？

弥补差距——我应该如何开始

绝大部分项目都有开始阶段。这个阶段中需要确定股东，起草项目文档，明确项目目标，详述债务来源及总数，明确项目小组成员和组织者，明确项目进程中的里程碑和交付时间。所有这些内容都应该包含在项目计划文档之中。

不幸的是，绝大部分项目都在开始阶段结束之后才开始进行人员培训，那个时候项目中重要的计划文档通常都已经完成了。你可能需要在项目开始之前就对项目中的关键人员进行培训。在项目的开始阶段，公司开始同厂商接触，了解能够帮助实施ITIL解决方案的工具。你必须在接触厂商之前就形成内部的专家意见，这样才能够和厂商位于同等地位。至少股东和团队成员应该上一堂ITIL基础课。

即使你还没有确定厂商，早期的培训也能帮助你的项目小组成员形成共同语言，帮助他们快速准确地讨论如何实现这一构架。很多项目小组都会在事后追悔莫及“我们不知道我们当时所不了解的是什么”。及早培训能够避免这种情况的出现。

ITIL计划中四个重要的问题

为了确保项目取得成功，所有的项目小组都必须管理期望——ITIL计划也不例外。ITIL计划中，你需要管理的最大的期望就是——你希望可以象管理所有其他项目一样管理它。下面是ITIL计划同普通项目之间的四大差别，这将影响你决定项目会议和整个项目周期。

1、你的ITIL计划可能会持续几年的时间

确保每个独立的项目目标符合整个企业的ITIL目标，且每个项目都对整体目标都有价值，是非常重要的。例如，你在实施Configuration Management（配置管理）项目的时候，规定使用Configuration Management Database（CMDB，配置管理数据库）来保存所有的CI（Configuration Items，配置项）信息。从这个项目本身的价值考虑，你必须优先处理最重要的CI类型。选择的这些CI类型可能会引起冲突。你可以按照一个时间进度给大家提供一个清晰的说明，告诉他们哪些CI类型会被存放到CMDB中。你的股东可不希望出现在你的列表中的第20名，如果他们知道自己没有被忽略或忘记，那么他们将更有可能支持你的项目。记住，共同的培训经历将会让人们有一个平等讨论基础。

2、你应该把相关的ITIL项目作为一个整体程序进行管理

绝大部分希望利用ITIL管理项目的公司都会创建一套项目执行的方法。但很多公司都缺乏能够在几年的时间里，统一管理相关项目的机制。

如果ITIL计划实施的周期横跨几个年度，而项目的周期通常较短的话，你可以成立一个比较长期的小组，该小组存在的时间会超过单个项目周期，称之为程序组。程序组的职责是在整个执行过程中确保整体一致性，并在与并行项目发生冲突的时候，做出协调和判断。

还是回到我们上面举的CMDB的例子，你可能注意到我们将CMDB描述成一个精确、实时更新的CI信息管理库。但是这个库并不是凭空产生的。它要求Change Management（变化管理）工作来保证数据的更新（项目1）。等数据到位以后，Incident Management（事件管理）开始使用这些数据改善服务响应（项目2）。Problem Management（问题管理）可以将事件和问题联系起来（项目3）。在CI之间建立起完整的联系（项目4）能够改进影响力分析，帮助改善变化规划，提高应用效能，减少无计划的停工。从总体上检查这些独立的项目是程序组的职责。如果目前你没有这样一个小组，就应该考虑成立一个。

3、你在建设的是构架而不仅仅是产品

总的来说，产品比构架更容易实施，因为绝大部分主流的软件厂商都已经在大量的企业用户身上积累了丰富的经验，并将软件产品打造得比较完善了。但是，如果你要建设的是ITIL构架，就突然要做很多决定，决定如何在ITIL的世界里重塑现有的方法。如果你目前的方法已经存在于当前的应用之中，那么就需要将这些方法关联起来。

不要试图去寻找单一的最佳答案。你必须在各种不同的方法之间权衡，并限制可以使用的基于ITIL进程的自动化工具。但是最重要的是，你必须让股东做出他们的决定。因为ITIL不是告诉人们做事情的唯一方法，人们可以尽可能地展现他们的想法。如果你发现自己身处这样的处境之中，就一定要提醒股东，所有的项目都仅仅是漫漫长路中的一步。你可以在将来重新考虑这个决定。

4、在计划实施过程中你可能会逐渐失去一些资源

我在回顾项目会议的时候发现最普遍的项目计划/风险之一是假设完成项目所需要的金钱、时间和人力资源都是稳定而持续的。对于持续时间不长的单个项目来说，你可以指望某个人从项目的开始到结束都能参与。但是我很怀疑参与ITIL计划的每个人都能从现在开始陪你走过未来的几年。

如果你同意我的观点，那么就应该在你的项目中采取一些安全措施来应对人员变动和交接的情况——甚至可能是高层人员。有两种方法能够减少影响：第一，尽可能多地为项目中的职位准备好接替的人员。你不需要设置一些正式的职位，你只要确保每个项目中都有不只一个人理解单项工程的关键因素就可以了。显然，实时更新的文档和状态报告对此非常有帮助，但是如果条件允许的话，你应该尽量避免只派一名成员参加培训课程。如果预算有限，只能培训一名成员的话，你就应该想办法让团队成员能够尽快共享这些知识。第二，为新加入项目的团队成员制订培训计划，这样能够帮助他们快速上手。最糟糕的情况莫过于让一名新人加入项目团队，但却没有系统化的办法让他快速进入状态。

管理一个ITIL项目和管理其他项目有所不同。如果你按照本文中提到的要点去做的话，在结束的时候，每个人都会得到自己想要的东西。