还记得微软公司的Project产品吗？还有Gantt charts？为期一周的涉众评审呢？在80年代90年代，甚至在过去十年的早期，成功的IT项目管理与今天的定义完全是两个概念。可悲的是，那些技术不仅过时，而且不再是成功的IT项目管理模式。这是为什么呢？传统的项目管理方法变得有点过时，我认为有两个主要原因。

　　首先，IT项目的界限不再像五年前或者十年前那样明确。“完成”项目到底意味着什么呢？项目通常需要有某种类型的结论，其中所有涉众都要认为该项目已经达到了令人满意的状态。十年前，如果程序部署了并且有CIO的用户使用了，那么构建内部应用程序的流程就完成了，也就是说：安装、运行，然后就结束了。

　　而现在对“完成”的概念定义非常模糊。考虑一下你的客户关系管理（CRM）系统吧。Web应用曾经完成过吗？你会经常修补，做一些小的发布，修复一些错误的功能而没有重新使用出厂副本，还会征求最终用户对应用的反馈。对于CRM或者Web应用，怎么样才算真正“完成”了呢？我们要透过重重浓雾才能命中项目——甚至这对于非常成功的IT项目管理团队都是很大的挑战。

　　第二，CIO的业务环境完全发生了变化。项目管理者过去要交付项目可靠的结果并使项目走上正轨，就算没有几年时间的话，起码也有几个月的时间。他们对一些意料之外的延误还有回旋余地，他们的项目团队不会在未来的日子里以150%的负荷运营。而且，他们可能对把项目从一个里程碑推进到下一个里程碑的不连续的下一步行动特别关注。剩下的工作很容易看到（然而，未必容易执行），因此估算完成工作需要的时间也相对简单些。

　　今天的CIO们处在不同的环境中，主要的一项差异就是时间极大地压缩了。你服务的消费者们——不管是与你在一条业务线应用上工作的内部客户，还是从你这里获取服务的外部客户——他们都期望快速的周转和更新。成功的IT项目管理团队需要在一半时间有时甚至是一小半时间内提交稳定的成果。此外，你项目团队的工作可能会立即部署给用户。这就使得问题和故障响应也变得更具挑战了。

　　我们面对现实吧：旧式学院项目管理技术已经不再适用了。你团队成员的态度已经发生了变化，你涉众的预期也发生了变化。在当今的经济形势下，CIO不能再负担得起像1999年那样的管理了。

　　那么我们有什么解决办法呢？信不信由你，解决办法就是给予一定自由。当今的IT开发人员和设计者们，如果能得到更多自主的条件和定义松散的工作空间，他们可以工作得更好。作为CIO，你有责任设定项目愿景和预期。你的项目经理们应该定义好各种里程碑，然后就流程开发需要的时间征求开发人员和设计人员的意见。但是，比较有趣的是，允许那些人规划自己的路线，而无需给他们规定步骤。这种自底向上的方法可以使开发人员和设计人员有发挥创造性的自由，使他们的工作可以在压缩的时间内完成，同时这样也保证了CIO清晰定义成功项目预期的职能。

更多请见明日文章：成功IT项目管理三步指南