---

    某出版集团于2006年启动了“书刊信息化”工程，项目投资规模近3000万元，建设周期为两年，由国家发改委批准立项。书刊信息化工程旨在利用最新的科技手段，全面提升集团下属各出版社、期刊社的信息化水平。项目最终要实现三个目标：一是搭建统一的内容资源共享平台；二是实现出版社、期刊社的业务流程数字化管理，规范编辑、出版、发行、物流等业务流程；三是将50万图片和多年的历史期刊资料数字化并标引入库，完成资源加工工作。集团下属的信息技术中心具体负责该项目的组织实施工作，由于中心不可能具备相应的技术开发人才，所以项目基本是以招标方式委托承建单位组织实施的。

    本人以前一直在IT公司工作，多以乙方的角色参与项目，这次以甲方项目管理者的身份参与项目，是一次重要的角色转变。由于项目比较大，涵盖的内容繁杂，需要进行分解并逐步实施，事实上我成了甲方的大项目经理。

    经过两年来的努力，项目经过四批十余包的招投标和实施过程，所有子项目均已完成了初验工作，基本实现了预定目标，正准备相关验收文档，上报发改委申请项目终验。在整个项目的推进过程中，项目整体管理的思路、方法和工具起了很大作用。在集成商、监理公司、承建单位、最终用户等多方协作的环境中，真正做到了充分调动各方积极力量，协调各种冲突和矛盾，平衡好各方关切，加强项目管理，确保项目的顺利开展。

    项目整体管理是项目经理最重要的工作之一，通过多种知识和方法的综合运用，协调项目干系人不一致甚至是矛盾的需要和期望，解决项目中遇到的问题和冲突，从而让项目能按照预定的轨迹达成目标。项目整体管理包括项目启动、项目整体计划编制、指导和管理项目实施、监控项目绩效、整体变更控制、项目收尾等过程，实际上贯穿了启动、计划、执行、监控、收尾各个项目生命周期阶段，是九大知识领域中唯一覆盖五个过程组的知识领域。就管理具体项目而言，整体管理就是决定在什么时间把工作量分配到相应的资源上，判断项目是否还在可控范围内，有哪些潜在的问题并在其变糟之前积极处理，以及协调各项任务安排使得项目整体上取得一个好的结果。在具体实践中，结合甲方项目管理的特点，本人重点进行了如下一些工作：

---

    每个子项目在签订合同后，我都要求必须开一个正式的项目启动会议，包括集成商、监理单位、承建单位项目经理和领导以及项目骨干都需要参加。启动会议是一个项目的正式开始，除了这个形式上的意义之外，更重要的是合作各方在项目业务需求、项目目标、合作方式、项目范围、主要交付品及交付方式、关键项目阶段及里程碑等方面达成共识，这种共识为项目进展过程中的沟通协调奠定了基础。事实证明，大部分乙方项目经理最初都不能清晰地阐述上述内容，需要在启动会议前进行多次沟通和筹备。项目经理们有时会强调产品功能和忽视项目范围，有时项目阶段划分和实际根本不符，有时对过程交付品和最终交付品界定不清，更常见的是不清楚业务需要，对最终用户需要通过系统解决什么问题、系统能为提升业务带来哪些帮助缺少认识。所以这些，通过项目启动会议并提交项目范围说明书（初步）的方式得到了很好的解决。

    项目整体计划是指导项目实施的路线图，是进行管理和监控的基础。很多号称过了CMM3甚至更高级别的IT公司，在具体操作项目时往往缺少掌控能力，常遇到如下几种情况：

    （1） 计划制定后就束之高阁，既不用来指导日常工作，也不在发生变化的时候对基准计划进行调整。事实上，计划的制定应该是“滚动式的”，在不同阶段都需要对计划进行不同程度的细化和调整，这也体现了项目的“渐进明细”特征。

    （2） 计划的完整性、可行性差。一方面体现在只有进度计划，对范围管理、质量管理、风险管理、沟通管理等领域缺少规划；另一方面，在进度计划中，也存在阶段划分不合理、WBS分解不全面、交付品遗漏、缺少任务管理、没有进行资源分配和资源平衡等问题。这样的一份计划就纯粹成了形式，对指导日常工作没有任何意义。我的项目管理经验此时就发挥了重要作用，经常需要与承建方、监理单位一道共同审核项目计划，从范围和产品的区别、WBS的制定、活动定义、活动排序、活动资源估算、历时估算等环节给予指导和帮助，作者落实一份可以执行的项目计划。

---

    大部分项目问题都与需求有关，需求变更与控制对项目成功至关重要。当项目出现问题时，最常听到的是承建方会抱怨“用户需求变化太多了”，果真如此吗？

    所谓项目管理，是把各种知识、技能、手段和工具应用到项目活动中，从而满足项目干系人的要求与期望。那么，什么是需求呢？需求实际上包括项目需求和产品需求两个方面。项目需求是项目包含哪些工作，达到什么目标，满足什么业务需求，交付什么成果等方面的综合；产品需求则是传统的需求分析要界定的内容，包括功能性和非功能性需求等方面，刻画了主要交付成果的特征。项目需求通过项目范围来体现和管理，产品需求通过软件需求规格书来界定。我接触的项目经理大多以产品需求作为主体，而且往往只强调功能点和模块划分，对用例、流程涉足不多。用户很难想象最后使用系统时的场景，更难判断对日常业务工作会带来哪些改变，所以对需求的确认也就成了形式，当开发成型后发现不符合预期时，提出变更也就在所难免了。

    为了有效避免需求频繁变更问题，我一般采用如下方法：

    （1） 强化需求定义。从业务需求、用户需求、产品需求三个层次进行分析和界定，并且要保持彼此间的管理和追溯能力。这里需求跟踪矩阵式一个很好的工具，但在实践中还没有看到承建方真正使用过。

    （2） 提高需求规格说明书的质量。强调用例分析，场景模拟和业务流程，不单依靠功能点描述的单一形式。当然，非功能性需求也要详细说明。

    （3） 充分利用界面原型刻画需求。最好是快速实现业务系统的界面原型，让最终用户直观地看到系统的“模样”，从而提高判断力，避免分歧。

    （4） 把握住项目范围和业务需求。

     产品功能的组合满足了用户需求，用户可以通过多个产品功能开展自己的业务。用户需求的整体满足又支持了企业的发展战略，提升了效率，规范了流程，也就是实现了业务需求。

    大部分需求变更来自于设计和实现不能满足用户需求，业务需求没有发生变化，项目范围也没有发生变化，在这种情况下，用户的意见肯定是很重要的，应该以接受为主。

    当然也有因用户方变化带来的需求变更，比如业务模式调整，部门机构调整等。在书刊信息化工程中，其中一家出版社率先实行了大编辑部制，打破了原有的工作模式，系统需要很多改变。这就需要变更控制系统发挥作用，在实践中，我们通过补充协议进行了范围变更。

    综上所述，把握住需求的本质是控制需求的最有效手段。在此基础上，利用原型法界定需求，通过评审机制确认需求，通过变更控制系统管理需求变更才能发挥更好的作用。

---

    信息技术中心不是最终系统使用者，是项目的组织实施者，沟通界面众多，包括集成商、监理单位、承建方、用户、主管领导等，对沟通的要求较高。在本项目中，我主要采用了如下一些做法：

    （1） 强调沟通理念。在启动会及相关项目会议上，我都会强调一个观点：甲乙双方拥有共同的目标，是合作关系。进度出现问题，整个工程进展就会受到影响，商务上必然也会受到影响。各方都需要为一个目标而努力，只是角色分工不同而已。另外就是鼓励沟通，很多承建方项目经理只在开项目例会时才露面，一周的问题攒在一起说，对项目进展十分不利，是不被提倡的。

    （2） 制定沟通计划。这个过程确定了所有的正式沟通需求，定义了何时、以何种方式向谁发送何种信息，由谁负责整理这些信息，当然也包括项目会议的组织，进展报告的编写等内容。有了沟通计划，信息传递的效率提升了，项目问题就可以及早暴露并得以解决。

    （3） 加强非正式沟通。非正式沟通是获取项目真实情况的有效途径，有些潜在风险会在非正式沟通中得以发现。非正式沟通不仅用来获取信息，更有助于建立信任关系。关于非正式沟通，有多种方法和技巧，这里不再赘述。

---

    在项目实施中，仍然存在一些需要完善的地方。一是需求跟踪没有仔细去做，导致经常会为了并不特别需要的功能浪费很多精力，甚至有些功能根本用不到；二是没有搭建一整套的项目管理系统，让项目各方在一个统一的平台的进行交流和互动，把配置管理、缺陷跟踪甚至问题记录等都可以纳入进来，从而对项目进行集中管理；三是风险管理不到位，部分项目出现延迟现象。今后要整理分析相关经验，制定风险评估模板，强化风险识别和应对计划编制工作，让风险可控。