鉴于项目的高失败率，你也许会认为，即便在项目完成时仅取得某种程度的成功公司也会很高兴了。事实并非如此。尽管困难重重，组织总期望着项目能完成得更好、更快、更省。达成这些目标的唯一方法只有运用高效项目管理过程和技术。本清单概括了管理一个项目的主要阶段，并探讨了每个阶段的关键步骤。

计划

1:利用项目定义文档做好工作计划

IT基础设施项目现在有种缩短计划过程的趋势，强调马上动手开始工作。这是错误的。花些时间进行适当的规划可降低成本、缩短时间并提高项目生命周期内的质量。项目定义是计划过程很主要的成果，从较高的层次阐述了项目的林林总总。一旦经过了客户和直接利益相关者的认可，它就成了要实施工作的基础。举个例子，在进行Exchange迁移时，项目定义应包含以下东西：

· 项目概况:为什么要进行Exchange的迁移？业务驱动力是什么？商业利益是什么？

· 目标: 迁移将实现哪些东西？你希望取得哪些成果？

· 范围: 要实现Exchange的哪些特性？哪个部门将要进行转换？哪些事情是超出范围的？

· 前提和风险: 哪些事情是前提条件，哪些事情是你关心的？相关硬件和基础设施是否已到位？存储容量和网络性能足够了吗？

· 方案: 迁移项目应如何开展和进行？

· 组织: 列出项目的重要角色。确定项目经理不难，但担保人呢？像这类项目有可能是CIO。项目团队成员呢？所有直接利益相关者是否都列进来了？

· 签字页: 请担保人和关键利益攸关者认可本文档，签字确认此计划。

· 初期效果、成本及现状评估: 应该从很好的猜测评估开始，那后进行修正，有必要的话工作计划完成就马上开始。

项目工作计划

2: 创建规划周期

在项目定义准备就绪后就可以建立工作计划了。工作计划为项目可交付成果的构建及项目管理提供了分步向导。如果有的话，你应当利用一个类似项目的旧工作计划作为模型。如果没有，可以利用工作分解结构和网络图等传统方式做一个出来。

创建一个详细的工作计划，包括分配好资源，在自己感觉舒服的前提下尽可能长远地测算工作。这就是你的规划周期。规划周期完成后，进行高层次项目设计，考虑所增加的不确定性。规划周期会随项目过程迁移。随着时间安排的日益临近，开始时不明确的高层次的活动需要进行更为详细的定义。

项目管理过程

3: 预先定义项目管理过程

项目管理过程概括了管理项目所需的资源。包括团队应如何管理问题、范围变更、风险、质量及沟通等。项目能进行严格和具有前瞻性的管理是十分重要的，确保项目团队成员和所有利益攸关者在项目是如何进行管理方面达成共识亦然。如果你的组织已经建立起了一般程序，那么在你的项目里运用就是了。

4: 管理工作计划，监视调度预算

一旦项目已做好充分的计划，工作的执行即可开始。理论上，既然你们已经对项目定义达成协议，而且工作计划和项目管理过程已经就绪，剩下的唯一挑战就只有正确地执行你的计划和过程了。当然，没有一个项目会完全依照估计和计划那样进行的。我们的挑战就是积极准确地将必要的严格和纪律运用到你的项目管理技巧上。

· 定期回顾工作计划，以便对照进度和预算了解自己的进展情况。如果项目规模小的话，可能需要每周进行一次。对于大一点的项目，频率可改为每两周一次。

· 识别出前一段时间已经完成的工作，然后更新工作计划，把它们列为已完成。找出是否存在应完成而未完成的工作。在更新了工作计划后，判断项目是否可按期保质不超预算地完成。若否，找出关键路径，并寻找到加速执行相关工作的办法以便能让你重回正轨。

· 预算监控。看看项目的实际支出总额，根据已完成工作判断自己的实际支出是否超出了原来预估。如果是的话要提前处理好。要么与团队一道协商出按照原来预算完成剩余工作的办法，要么就得担上超支风险。

5: 寻找告警信号

找出项目可能有麻烦的信号。包括如下：

· 进度或预算的差异开始变大，尤其在项目早期的时候。你总倾向于认为自己能摆平，但这已经是一个告警信号了。如果这种倾向未能迅速获得纠正，影响将是无法挽回的。

· 你发现自己认为已经完成的工作实际上尚未完成。比如说，哪些你认为已经迁移到新平台上的用户仍未迁移。

· 你需要非预设的加班时间在很后期限到来前完成工作，尤其在项目早期是就已经不得不如此的时候。

· 团队士气开始下降。

· 可交付成果或服务质量开始恶化。比如说，用户开始抱怨其转换过来的电子邮件文件夹没有正确运行。

· 质量控制步骤、测试活动以及项目管理时间开始被削减。类似Exchange迁移之类的大项目会影响到组织中的每一个人。不要削减哪些能确保工作正确完成的活动的时间。

如果上述情况发生了，要通过风险管理提高其可见性，然后制定整体计划积极地确保项目回归正轨。如果你不能成功地解决这些问题，要把它们作为问题提出来。

管理范围

6: 确保资助人认可范围变更请求

做完计划管理的基础工作后，范围管理就成为控制项目很为重要的活动。许多项目失败并非由于评估的问题，也不是因为项目团队的技能不够，而是由于项目团队工作的主要或次要的可交付成果，并非原始项目定义或业务需求之内。甚至即使你的范围管理到位了，有2个主要的范围管理领域需要得到深刻理解才能保证项目成功：理解客户是谁以及需求渐变。

一般而言，项目发起人是为项目提供资金的人。对于像Exchange迁移之类的基础设施项目，发起人可能是CIOh或CFO。尽管通常只有一个发起人，大项目会有许多利益攸关者，或者是受此项目影响的人。范围变更请求通常由利益攸关者发起 — 他们中的许多人可能是有自己权限的经理。这些经理有的可能会要求给他/她的管辖范围内开放聊天服务，有的可能会要求放宽自己邮箱的大小限制。对于利益攸关者而言，变更是不是重要的并没有关系，他们不能做出范围变更的决定，他们也无法批准你的团队去做出变更。在正确的范围管理中，由于资助人是唯一能追加资金来进行变更并评估项目影响是否可接受的人，他们（或其指定的人）必须做出批复。

7: 防止需求渐变

许多项目经理知道，在被要求给项目增加一项主要的新功能或可交付成果时要援引范围变更管理过程。然而，有时候项目经理并不知道小的范围变更时不时会被追加进来。需求渐变是一个术语，用以定义在未经范围变更管理过程而进行的针对项目的一系列小型的范围变更。在需求渐变中，一系列小型的变更 — 虽任何一个都不会独立地影响到项目 — 会累积起来很终导致对项目产生显著影响。许多项目失败的原因正是因为需求渐变，而项目经理需要勤快些，对此加以防范。

风险管理

8: 事先识别风险

当计划的工作在进行中时，项目团队需识别出所有已知的风险。对于每个风险，他们都应判断出风险发生的概率及其对项目潜在的影响。那些标示为高风险的事件应当有特定的计划来加以缓解，以便避免其实际产生。中等程度的风险需加以评估，以便看看是否需积极管理。(低风险事件可标示为假设。也就是说，存在潜在风险的可能，但你“假设”正面结果更有可能产生)。部分风险继承自影响到公司里的每个人的复杂项目。其他的风险可能包括专业技能不足，对技术不熟悉，以及未能平滑地与已有的产品和设备集成。

 

9: 持续评估项目中的潜在风险

 

一旦项目开始后，阶段性地执行风险评估来决定是否有新的风险浮出水面，需要加以管理。

 

10: 尽快解决问题

 

Issue指重大的问题。比如说，在Exchange迁移里面，你订购的Exchange服务器未能按时配置好。或者可能一大堆桌面机器的Windows系统没有配置正确，需要重新设计。项目经理应积极地管理开放问题，来确保其得到解决。如果问题并非急需解决，或者问题已经出现了一段时间，这也许不是大问题。也许是潜在的问题（风险），或者可能是在后面某个时候需要加以解决的一个行动项。真正的大问题，天生是需要尽快解决的。