最后期限——BOSS工程项目的管理(转)

写在前面的废话

管理这个东西，看起来好像很”高级“，其实“弱智”得很，适用面往往很窄，所采用的方法、经验甚至于理论，都常常只适用于特定的环境、文化和团队素质等等。越具体的管理经验，越是如此！所以，我这里要罗里罗嗦的预先做一些限制，以尽可能的为自己的”谬论“开脱，呵呵！见笑见笑！

——这里，顺便插一句：在遇到具体的管理方面的问题时，切不可相信或期望有那所谓的灵丹妙药。因为真正适用你的东西往往不具体，而具体的东西又往往并不适用。管理，是太受”人“本身这个因素的影响啦！俺这里所说的，权作为一种交流吧。。。。。废话少提，下面言归正传：

对所谓的“BOSS工程项目”，我们来做一个明确的定义。

这里要突出的，是“工程”这个词。这是个与“研发”相对的概念。其特定的限制，指得是已经完成BOSS系统软件的大部分设计、代码编写，已经有了一个至少是基础版本的BOSS软件系统；现在工程阶段，虽然也会做一些软件的开发工作（一般来说主要集中于做一些客户化定制，满足一些特殊的需求和业务限制等），但是主要的工作内容，还是在于客户协调、设备安装调测、数据倒换、系统测试、割接等等”实施性质“的工作。

离了这个基本前提，”BOSS项目“就变成了一个”软件开发项目“，而不是具有特定要求和含义的”工程“项目了。可以这么说：BOSS工程实施的操作步骤、方法等，往往大同小异，积累出来的经验，主要受客户环境、系统本身的特性等方面影响，在不同企业或项目之间具有较强的可通用性；而软件开发项目的操作步骤、方法等，与所操作企业本身的企业文化，员工技能水平，软件产品的定位等等，有着非常强的关联性，从而在不同的企业之间，甚至同一企业的不同项目之间，都很难具有实际操作上的通用性。

下面对”BOSS工程项目“做一个相对量化的界定：

1、实施得是与中移动BOSS系统（业务运营支撑系统）类似的国内电信运营支撑系统。

2、采用的基本工作模式，是运营商提出系统建设需求，集成商负责实施的方式。这其中集成商的负责实施，不包括从零开发一个完整的BOSS系统，而是已经有了一个成熟或至少核心的BOSS软件版本（这实际上是软件产品商，而不是集成商的职责）。这里说一下个人的观点：这种在一个成熟或基础核心版本上进行集成的系统建设模式，应该会是至少近几年内的趋势，甚至会成为以后运营商能够认同的成熟工作模式。一家之言，权当参考。

3、项目周期，指得是从集成商项目组进场，到整个项目结束的”售后“阶段。一般包括这几个典型的项目阶段：需求分析、客户化定制配置和开发、系统用户测试、系统割接、系统初验、系统终验。这里不包括项目的售前招投标，和后期的纯维护阶段。

与大部分影视节目的开头俗似，俺这里也要来一段：这里所讲述的故事，纯属个人通过对一些实际工作经验的总结，将其理解虚拟为故事表达出来的，其中如有任何情节与某个实际工程中的场景“貌似”，纯属巧合。

最后，这里罗列一下下文中将要适用的字体和图示（后面会随时补充完善）：

1、大标题、小标题，这太明显了，就不罗嗦了；

2、红色字体。建议不要违反或疏忽的东西，如果违反将会对项目产生致命的、或长远的伤害；

3、黄色字体。警告，不要范这样的愚蠢错误。

4、蓝色字体。重要提示和技巧，其中大号蓝色字体表示重要经验、感悟的总结。对于管理来说，其实感悟，尤其是自身对人性、管理技巧等方面的感悟非常有价值的，这才是管理的真正积累。

〇、引子

孙乙， S 公司的一名工程师，曾经写过2年左右的代码，也曾经在BOSS系统的某个模块担当过1年多的负责人，有一些技术业务方面的积累。因为表现一贯比较“骚包”，喜欢总结团队方面的工作经验，尤其在安排多人的工作任务和协调同事之间的关系上，喜欢一群人而不仅仅是自己一个人把事情做好的感觉，也喜欢和别人讨论各方面的工作问题，为此而得到了某些领导的“赏识”。

为了考验孙乙，某领导曾经让这位仁兄先尝试负责过一些小项目，经过“三关六难”的考验，孙乙同志已经逐步形成了自己相对以往项目经理而言更为“精细”的管理风格——这应该是技术人员转向管理岗位的优势吧！领导们也认为孙乙同志已经具备一名项目经理的基本素质，可以考虑给予其更多的机会，让他开始尝试完整的BOSS工程实施。

刚好，S 公司近期完成了一个BOSS软件版本的研发，该软件系统在结合S 公司多年所积累的BOSS建设经验基础上，做了一些整合、调整和发展，尤其是在架构、系统性能等方面，做了一些设计上的优化；更采纳和考虑了eTOM最新理论，融合了很多国际化的先进理念。。。。（这里省略1000字）。采用这种“核心版本”＋“客户化定制”的模式，也是 S 公司希望将来成为固定工作模式的方式，经过和客户和业界人士各方面的多次接触和沟通，再加上吸取近期炒得比较火得竞争对手A公司得所谓“统一版本”泡泡经验， S 公司的领导认为这种方式值得尝试一下。从而系统不久的将来，也就是在1、2年之后吧，彻底的改变本公司的工作模式。

因为这种方式一旦成功，S 公司的管理层认为本公司就在BOSS软件的产品化方面打下了一个基础，而软件产品化是一个必然的趋势。为此，对于这个新研发的BOSS软件，S 公司将其命名为“XXP-BOSS”。因为领导们的意思，是希望这个产品，将会为客户带来“终极终极的体验”。 并且，该产品的版本号，从2.0开始。也就是目前研发的版本，是XXP-BOSS 2.0。因为，领导们又听说，一个软件，往往是1.0版本还凑合，2.0版本就特别烂，到3.0才稳定，为了打破这个狗屁理论，也为了避那个忌讳，就决定直接从2.0版本开始了！

到目前为止，应该说，XXP-BOSS 1.0——哦，不！XXP-BOSS 2.0 经完成了核心版本的研发，已经在严格按照经过深思熟虑、各位首席架构师和业务专家们历经百多个日日夜夜的争吵、而得出来的完美架构要求上，开发出来了！

经过各专家组的多方评测、研究、分析和在一个基本运行模拟环境下的测试（虽然 S 公司没有多少钱，无法搭建一个500万用户量行环境，但搭建一个500用户量的环境还是非常有把握的），各方面感觉，基本已经达到了预定的设计目标。现在所苦的，就是没有真实的运营环境对这个XXP-BOSS 2.0 进行实际运营的生产测试了。

此时，非常幸运的，在销售部门的积极配合下，更主要是在集团公司的一声令下的基础上，某省运营商 T 公司，已经和 S 公司签订了建设新系统的合同， 打算让 S 公司一展自己 XXP-BOSS 2.0 的风采。

考虑到以往的很多 BOSS 工程实施中，项目控制的过于粗放，从而导致项目出现很多进度、质量、成本方面的问题，而孙乙同志经过这2年领导的刻意锻炼，已经形成了鲜明的“精细”风格，为此，领导们经过讨论，觉得可以让孙乙在这个项目中一展身手啦！

考虑到 T 省公司给予的这次 BOSS 工程项目非常关键，它不但是首次验证 XPP-BOSS 2.0 的成功， 而且还将成为后续客户的推广依据。为此， S 公司的高层对此也非常非常的重视，打算严格按照新近认证通过的 CMM 要求，来实施项目的管理。

首先，S 公司的领导小组经过讨论，首先任命技术副总 李丁 来作为项目总监，对整个项目进行负责，并正式任命 孙乙 作为项目经理，这已经通过书面材料的方式，下达给李丁和孙乙两位。

然后，在孙乙同志收到通知后激动得还没有醒过神的第二天，李丁找来了孙乙，与其进行了一次沟通。一方面对其以往的工作给予了肯定，一方面传达了公司高层对该项目的期望，和要求孙乙同志必须实现的明确目标，最后还好好鼓励了一下。。。。。（这里省略2000字）最后还带孙乙同志一起喝了不下8瓶左右的二锅头。孙乙同志怀着激越的心情，和一种原本不太把握得住但喝过酒后就腿脚又特别有力量的感觉，很牛比的打了一辆大奔，回到了自己的蜗居。

孙乙同志在入睡前，心里头还一直乱哄哄的在想象着明天该如何召开项目启动会，找哪些伙计来参加这个项目等等。。。。。。

一、项目启动

（一） 公司内部的项目启动

项目总监和项目经理确定后，现在就要正式启动项目了。让项目尽早的进入正轨，是每个正常项目都希望的。于是，第三天一大早上班，孙乙就再次找到了李丁，就项目启动相关事宜进行了一个简单的讨论。两人都一致认同当天下午13：30召开项目启动会议，并初步确定了需要参加项目启动会的人员名单。具体包括的人员大致有如下范围：

1、技术负责人。由于公司高层在制定项目经理的同时，也基本确定了本项目的技术负责人，那就是一名叫 牛技的技术大拿。牛技其实也是在XPP-BOSS2.0产品研发的架构设计师之一，而且具备8年以上的BOSS技术经验。所以牛技的参加是必不可少的。

2、七大模块负责人。由于项目规模比较大，需要分多个模块来负责。于是两人又按照XPP-BOSS2.0的模块划分，和公司以往同类项目的惯例，共确定了 七个模块的负责人。这些模块负责人一方面是本模块的技术专家，另一方面将作为“子项目经理”，协助项目经理进行本小组成员的管理工作。由于项目组到高峰时期，人数将超过50人以上，所以这是非常有必要的。这七个模块技术兼管理负责人，也必须参加项目启动会的。

3、项目7大模块所涉及技术部门的经理。由于公司采用矩阵式管理，由于今后项目组将陆续加入的更多工程师来自于这些部门，为了今后能够“名正言顺”的和这些部门经理协调人力资源，这些部门的经理（在PMBOK中，这被称为直线经理）必须参加。

4、公司相应领域的专家。这些专家，将不一定会作为项目组的正式成员，但由于他们曾经在本项目所涉及领域的丰富经验，将会为本项目的开展提供必要的帮助。包括一些技术、商务、管理等方面的建议，以及参加后期项目开展过程中的一些技术评审等。所以，能够请到他们参加，也会对项目有所帮助。

5、项目的售前代表。由于项目所涉及领域，是公司目前的主营业务，大家都比较熟悉，就不进行单独的售前售后交接了，通过项目启动会一并进行。

6、公司采购、工程管理等非技术部门的代表。不可小看了这些部门，他们的工作，虽然对像类似BOSS这一类的项目没有突出的贡献，但他们具备“合法伤害权”，所以能够让他们参加，对于大型项目能够让他们的经理直接参加，并让公司高层直接告诉他们需要给予本项目什么样的优先处理等级，将会非常重要。看过《潜规则:中国历史中的真实游戏 》的同志将非常认同这一点。

7、最后。当然，不能少的，就是代表公司高层意志的相应领导。除了项目总监李丁同志必须参加，并作为项目启动会的正式发起人外，对于BOSS这种重大项目，至少还应该让1名以上公司的实权高层人物参加。公司高层对于项目启动会的成功召开，起到至关重要的作用。

在确定人员名单后，孙乙还考虑了一下会议方式和地点。地点就定在公司12楼大会议室（公司最好会议室，体现项目重要性）；而会议方式，由于销售代表、技术负责人牛技、个把领域专家都在外地，考虑开一个电话会议。

孙乙发完会议通知后，忽然发现自己遗漏了一个重要角色：根据公司CMM 过程的要求，需要QA全程跟踪本项目。于是，孙乙又来到李丁办公室。李丁嘿嘿一笑：还算自觉嘛，我已经安排啦！否则我哪有那么多空闲，天天盯着你啊？

接下来，要确定的是会议议程和会议目标。

对于项目启动会议来说，一定要达到相应的工作目标，切不可成为“过堂会”，否则浪费时间不说，还会因为没有“真正召开”项目启动会而导致后续的很多项目协调工作上存在许多障碍。这是很可悲的！

结合本项目的实际情况，已经考虑孙乙是第一次从事这类项目的项目经理，李丁和孙乙一起，为项目启动会制定了如下目标：

1、介绍项目售前背景，明确项目目标和范围。

2、明确公司对于项目的要求，该项目对于公司运营的意义。

3、正式授权项目经理。

4、明确提出各技术部门、非技术部门对于本项目的响应级别和要求，并要求各部门经理给出承诺。

5、正式成立项目组，并当场确定项目组第一批进入成员名单，和得到各成员对进入项目工作的认可。

为了确保会议目标的顺利实现，孙乙拟定了如下的会议议程，并和李丁讨论确认通过：

0、会议主持人为李丁，整个会议自始至终由李丁负责引导。

1、李丁启动会议，做简单说明，并请公司领导讲话。李丁经过和相关领导联系，确定让另外一名公司实力外副总王富来负责。主要内容是介绍大致的项目背景，公司对项目的要求，以及明确项目总监（李丁）、项目经理（孙乙）、技术负责人（牛技）的任命和职责等。限时30分钟。

2、让销售代表做一次口头的售前售后交接。主要将项目的销售情况，客户期望，售前的相关方案和承诺等，做一次说明。并明确说明本项目在售前阶段和客户共同确定的粗略目标和规划。这个议程，可以允许大家发问，并进行相关讨论，尽可能避免含混不清之处，但需要控制讨论发散到后续的项目实施中问题上去。限时1小时。

3、李丁正式向所有人员传达正式任命孙乙为项目经理，并就任命孙乙的情况做一简要说明，表明公司高层是经过慎重考虑和选择的，并表态公司将强力支持孙乙的工作。然后，重要的是，李丁要引导孙乙开始工作：让他介绍对项目的理解，以及对项目工作安排的大致说明，和可能需要各技术部门、非技术部门提供的配合要求等进行说明。限时10分钟。

4、孙乙开始工作，对项目可能需要各部门配合的情况和主要风险等进行简要介绍。在这里，孙乙认识到自己需要注意自己的方式方法：不能操之过急，也不能过于软弱，要尽可能客观和留有余地的阐明项目对资源的需求，和做一些必要的说明，要表现得自己考虑得的确比较全面而重点突出。

为了达到这个目的，孙乙实际上在一知道自己要承担这个项目开始，就要做相应得准备工作，甚至包括向前面提到得领域专家进行一些咨询，不能显得没有太多准备和考虑。否则会大大降低启动会的工作效果。

5、项目经理就重点资源配合问题和各部门经理进行原则性确认。对于BOSS项目来说，尤其是工程师的人力资源问题，需要在李丁的主持下，让孙乙和各部门经理做一个初步讨论，在李丁的协调下，能够让孙乙和各技术部门、非技术部门经理得到原则上的认可即可，无须过分细节的确定。

尤其需要注意的是：项目组马上需要进入的人员，主要是各模块负责人，以及其它的特殊技能人员、核心工程师等，也需要孙乙立即宣布，并同各技术部门经理当场敲定下来。

关于非技术部门的确认，特别的，由于往往这些部门管理上相对独立，可能需要王富参与协调，明确公司对他们的要求，从而尽可能消除今后发生协调冲突的隐患。

本议程和上一议程可以混合进行，限时1~1.5小时。

6、就项目的主要风险进行技术性讨论。这需要公司高层、销售代表、项目技术负责人、各模块负责人、项目外领域专家等一起参与讨论，让大家就自己认为的项目最重要的风险进行讨论。这一方面，可以让大家对项目的难度有更感性的认识；另一方面，让孙乙在接下来的项目计划过程中，充分考虑这些因素。

这个地方，就是牛技发挥其大拿位置的场合了，他作为技术负责人，需要拿出自己的观点和建议，并力主引导大家朝一致的方向努力。

这里需要提示的是：不要过多的陷入细节讨论，也不要就谁是谁非进行争论，孙乙要做到的是将所有人的不同观点都记录下来，作为自己考虑的素材。在讨论过程中，孙乙也要向大家传达这一原则，不要让会议变得过分冗长。

该议程限时1～1.5小时。

7、最后，领导总结性发言，再次明确公司的希望、态度、要求，等等。

从会议的议程可以看出，项目启动会议的内容非常丰富，时间要非常好的控制。所以需要孙乙做不少的准备工作。

在考虑清楚这些后，孙乙向相应人员发布了会议通知，并通过公司相应管理部门开通了下午1:30~5:30的电话会议，和预约了会议室的使用时间。

办完了这些，孙乙总算松了口气。嗨，还真不轻松啊！不经意的，孙乙忽然想：怎么感觉，所谓的项目启动会议，好像就是自己导演的一场戏啊？啊！这就是明悟啊！所谓的悟啊！想到这儿，孙乙有些激动：

项目经理的一个角色，就是担当导演，安排合适的舞台和布景，让合适的演员来演合适的角色。

下午 6:30，虽然努力控制了进程，但会议还是多开了半个小时。孙乙和大家一起走出会议室时，已经有些晕乎乎的了。

回到坐位上，孙乙将会议的主要内容整理了一下，并将结果进行了记录，然后创建了一个项目组的邮件列表，将会议纪要按照公司文档模板的要求email发给了所有会议参与人。

这个会议纪要整整写了孙乙将近1个小时，写完后，孙乙眼都花了，才想起要去吃饭。在吃饭时，孙乙忽然想到：除了这个会议纪要，还有项目章程、项目范围说明书等等公司CMM过程要求的文档等要编写，实在非非常琐碎。自己这么干下去可不行，非累死不可，该找个秘书或者说助理来帮助自己。顺便，这个助理还可以帮助自己安排很多后勤方面的工作。于是打定了主意，准备明天找李老板（现在李丁被孙乙称为老板了）要一个来。呵呵！可不可能是那个漂亮的周MM呢？

吃完饭，孙乙想想后面的工作，发现接下来最重要的，就是尽快将项目组开到现场开始工作。这种工程实施的项目，呆在家里是没法工作的。

次日一上班，孙乙就决定立即召开项目组工作会议，对到现场进行工作的安排讨论一下。另外，孙乙还想到，需要对昨天项目启动会中设计到的客户期望、公司管理层要求、项目工作范围说明书（SOW）进行一个初步的沟通，以便在到现场后，大家可以有一个一致的基本认识。

于是，在经过约30分钟的考虑，孙乙在基本确定了一个出发到现场的初步安排后，就召集牛技、各模块负责人、核心程序员等项目组全体（到目前为止）人员——也不过10人左右，并邀请了项目总监李丁，在一个小会议室共同召开了一次项目工作会议。

在会议期间，孙乙首先再阐明了一下客户和公司管理层对项目整体进度、范围、和质量等方面的要求。

关于进度，由于是个死要求，而且也随着项目范围的变化有着很大的弹性空间，大家目前都还没有太多的看法。

而在讨论到项目范围和质量方面时，孙乙拿着售前的胶片、技术方案建议书等投影到墙面上和大家讨论时发现两个重要问题：
1、有些方面有些模糊空洞，需要和客户做更加具体的讨论确认；
2、还有些方面可能要考虑对现在刚研发完成的XXP-BOSS2.0核心版本的技术实现做一些工作量相对较大的调整。如果真的这么调整的化，可能会对项目进度、质量目标产生较大的影响。

讨论到这儿，各位模块负责人普遍感觉，需要尽快到客户现场，和他们相应的业务模块负责人进行沟通讨论，将具体的要求细节、期望解决的业务问题（而不是现在技术建议书中的实现方式）搞清楚，否则后面的工作无法安排。

在讨论工作范围时，牛技提出了一个问题，引起大家的激烈争论。牛技认为：在本公司以往的BOSS系统中，对于内存技术的使用不足，导致了一些实时性、并发压力非常大的客户资料、费用信息查询性能没有很好的满足客户需求，为此客户一直都有些不满。所以希望在本项目中，由他本人来牵头负责，引入相对完整的内存数据库技术并进行相应的开发测试，将这些关键数据的查询，移到内存中进行。

但孙乙觉得，考虑到项目已经存在的很多工程实施方面的挑战和风险，在本项目中引入这一重大技术变化可能时间、费用、人力等资源不足，为此建议不要采用。

于是各位技术专家们进行了一场热烈的讨论。孙乙在讨论过程中，为了不让讨论无休止进行下去，果断的采用了一个策略，最后取得了大家的一致认同。该策略就是：求同存异。所有人一致认同的观点是：在确保时间进度，以及将来可获得的人力资源限制条件下，和在到现场和客户确认解决掉前面的2个重大项目范围问题的基础上，对采用内存数据库技术做一次相对详尽的分析，看看到底有多大的影响，如果该影响可以被接受，就采用内存数据库技术，否则暂时不考虑。但有一点是必须保证的：对于相应查询模块，要改造其接口设计，使得将来从数据库查询切换到内存数据库查询时，能够做平滑、无缝切换，从而确保即使将来在系统维护阶段，通过软件升级的方式来替换为内存数据库时，能够最大的降低在线系统进行软件升级更新的风险——也就是要实现所谓的“拔插件”效果。

由于这个讨论，这次会议花了将近3个小时才开完。这让孙乙充分体会到：求同存异，及时作出决断，对于项目来说是非常重要的。

在完成了项目整体进度、范围、和质量等方面要求的讨论后，进入了关于出发到现场的安排。正如孙乙预先设想到的，各模块负责人普遍认可到需要尽快到达现场，否则项目走到现在就很难高效的开展下去了。

由于有了前面的讨论，再加上各模块负责人本身也都是一些非常敬业的家伙，大家也都觉得本次项目非常具有挑战性，所以对接下来孙乙建议大家后天就出发到客户现场没有太大的异议。除了有个别家伙有些私事还需要料理下外，大家都基本没有问题。另外，讨论中大家还提到，由于后面项目组高峰期将发展到50人以上，以及这个项目成功后，T省运营商将会和公司成为长期合作伙伴，考虑在当前价格条件下的可怜的公司成本限制和一贯惯例，都住酒店吃不消，也需要这次到现场尽快将当地的办事处建立起来，包括租房、请保姆、聘请当地行政人员等等。

于是，会议结束后，孙乙统一给大家订了后天出发到客户现场的机票。

（二）和客户一起进行的项目启动：首次工程协调会

接下来，孙乙要做的，就是考虑关于带队到客户现场的相关事宜了。

首先，凭以往的经验，孙乙意识到要开一个项目启动性质的工程协调会。通过这个会议，让客户相应部门和责任人真正意识到项目开始了，需要配合做相应的工作了。其次，孙乙还觉得，为了让客户相应部门和责任人尽快进入状态，还需要给他们来段“热身”运动。为此，孙乙打算安排一个从项目组下飞机到达现场的宾馆开始的、一个严格的、维持一周左右的时间安排表。在这个时间安排表中，将安排一系列的工作，包括第一次工程协调会、售前技术方案的讨论、项目整体规划安排的讨论、自己和销售代表到客户各部门的拜访、各模块负责人和局方对口人员的沟通、以及接下来的到各部门的需求调研前期安排等等。

用了一天多的时间，通过自己不断的思考分析、以及和牛技、各模块负责人、李丁等的不断沟通讨论，孙乙总算拿出来一个相对完备的、长达10多页的详细时间安排表，以及相应的工作任务要求、项目组参加的人员、需要局方参加的人员，等等。

看着这份相对厚实的表格，孙乙满意的笑了。这下俺要开始折腾你们这些大佬啦！总不能老是让俺一个人这么忙吧？嘿嘿！

项目一开始，项目经理是最忙的，因为他要做很多的策划和启动工作。但要注意：项目经理就像一列火车的车头，必须尽快的将所有人发动起来，这对于减少项目资源的浪费非常关键！

考虑到和客户第一次开工程协调会，局方的高层领导会参加，孙乙就再次邀请了李丁、王富两位领导参加本次到客户现场的工程协调会。这两位领导在受到邀请后，也都很乐意的答应了下来，承诺到时候一定到场。其中王富还特意对李丁做了一下工作要求，认为即使自己不能到场，李丁也一定要到场（领导一般只会要求别人工作，呵呵！）。

做好这些准备后，李丁、王富、孙乙、牛技、七大模块负责人（以下与牛技合称八大罗汉）中的六位（有一人需要晚两天，处理点私事），就顺顺当当的来到了客户现场，并于当天入住了销售代表已经预先帮忙定好的（谈好协议价格的）的宾馆房间。在冲过热水澡后，孙乙、李丁和销售代表碰了下面，决定和局方约定第二天上午9点开项目启动会。

下面轮到局方人员出场啦！

局方中心主任赵丙，项目经理钱甲，已经预先通过和李丁、销售代表的联系知道了S 公司项目组到达现场的时间，以及孙乙提供的详细的工作任务时间表，也感到任务非常紧张。在收到电话后，立即和相应部门的领导、公司高层进行了充分的沟通，确定下来第二天到场的人员名单和大致的会议议程。

关于工程协调会议程，在孙乙、钱甲的建议下，李丁和赵丙（这两人已经算是老相识）沟通的结果是：

1、双方人员互相介绍认识；
2、T公司局方领导讲话，对各部门提出工作要求；
3、S公司领导（王富）讲话，应答本公司对项目的重视程度、资源调度安排等；
4、T公司赵丙作为实施负责部门，介绍目前的项目状况、安排和相应情况；
5、S公司李丁介绍S公司对项目的安排、人员情况等；
6、S公司项目经理孙乙介绍项目的初步计划，接下来一周内的详细工作安排；
7、T公司项目经理钱甲针对孙乙的计划、工作安排，介绍局方相应人员的工作安排；
8、问题讨论；
9、甲乙双方领导总结性发言；

会议时间：2.5～3小时，开始时间 9：00。

第二天的项目启动会，还算开得比较顺利。除了孙乙有些紧张，让局方感觉有些不老练外（后来的项目庆功会上，局方钱甲透露），基本感觉比较满意。公司领导王富也在最后时刻匆匆赶到，算是没有给大家带来太多的尴尬。由于准备充分，甲乙双方领导和责任人对接下来一周内的工作安排，除了有一些小的时间上、顺序上的变动外，基本感觉满意。同时局方也感觉项目组非常负责、积极，管理比较规范，准备的很充分，问题考虑的相当全面。这种认同感，为孙乙后续的工作开展起到了很好的铺垫作用。

在会议上，项目组的8大罗汉，结识了局方计费业务中心的4大金刚，分别找准了对口关系，也为后面大家结对交流打下了基础。

最后，在融洽的沟通气氛下，局方领导宣布项目启动结束，并给大家做了高标准、高质量、高速度的三高要求。局方各部门领导也都明确表态将全力支持这一关键性项目。赵丙还代表甲乙双方的项目组，表了决心。午餐时，王富作为S公司的领导，代表公司请所有与会人员吃饭。在饭局上，赵丙、钱甲、四大金刚以及孙乙、八大罗汉，大家同仇敌忾，意气奋发。从这一刻开始，甲乙双方的项目组，尤其是钱甲、孙乙分别带领的四大金刚和八大罗汉，算是捆绑成了利益共同体。

从项目一开始，取得局方对管理方式方法的认同感，以及将甲乙双方的项目组捆绑为利益共同体，对于项目后期的实施至关重要！

二、项目规划

项目规划对于一个项目，甚至可以说，无论多么扩大它的重要性都不为过。因为对于一个项目来说，存在着太多的不确定性。而项目规划的过程，就是将不确定性转化为尽可能的确定性的过程。

“项目”的三大特性之一——逐步明确的特点，注定项目规划不可能是一蹴而就的。为此，项目规划并不是仅仅在项目之初要进行，而需要在项目的整个进展过程中都不断的延续。事实上，项目规划应该可以说是项目经理的主要工作内容之一；一个好的项目经理，其项目规划的能力必然是好的。

再次提醒的是：项目第一次的规划，将会需要花去不少的时间，而此时切不可让项目组其它人员处于等待计划的状态之中，而应该让他们立即行动起来。对于BOSS工程这种实施性质的项目来说，就有很多工作可以提前做，无须要等待规划的。比如：系统建设方案的讨论沟通，网络建设的需求和步骤，软件需求的确认和差异分析，对客户进行新系统设计的培训等等。这些工作，往往立即就可以让项目组的老大们立即忙起来，而又不用太多的规划考虑。所以，前面项目启动阶段，孙乙同志的那个一周行动任务时间安排，是切合实际且非常必要的。

当然，能够预先就找到适当的任务，让项目组成员最快的进入状态，这和项目经理本身在领域内的业务、技术背景非常有关系。没有好的业务、技术背景，项目经理往往难以作出适当的决定。这应该说是为什么说“PM不能是纯粹管理人员”的原因之一吧！

一边忙忙碌碌的组织八大罗汉们和客户进行诸如需求确认、系统技术方案更技术细节层面的讨论、对客户进行新系统设计培训等等的工作，孙乙一边积极的进行项目规划相关的工作。
（一）范围定义与规划

项目规划的第一步、也是最基本的前提，就是对项目的范围进行界定（范围定义），以及对以后在项目中如何管理和控制这个项目范围制定游戏规则（范围规划）。

孙乙意识到了这一点。严格来说，这个项目的范围从售前技术方案建议书开始，就已经在开始定义了。孙乙从售前队伍那里接收过来，技术方案建议书中应该已经对项目范围做了基本的界定（对于有些项目来说，甚至已经界定到了非常详细的程度），但往往还不够细致和准确。

一切管理的真正目的，都不是从一些文档生成另一些文档这么简单。孙乙觉得，应该将项目的范围用一些简单的条款罗列出来，甚至用生动的语言描述出来，这样大家才能记住，包括客户和项目组本身。而只有真正记住项目的工作范围，才能让每个人更好的控制自己不要走偏，不要过于盲目的浪费项目资源。注意，这里用的是“不要过于盲目”。意思是说：任何项目，资源的盲目浪费，从某个角度来说是无可100％的避免的。管理的作用，就是尽可能的降低那些消极的趋势，但并不能做到真正彻底的消灭。

为此，孙乙首先在整合这几方面信息（技术方案建议书、商务合同、和客户初步沟通的情况、公司领导的期望、和项目组八大罗汉的讨论）的基础上，用一个简单的ppt胶片将项目范围罗列了一下，并根据自己的判断，对这些项目范围所涉及的工作内容进行了一个大致的优先级别排序。

然后，孙乙找到钱甲，两人针对这个项目范围进行了一次沟通。从沟通的情况来看，钱甲和孙乙发生了一些分歧。但大家本着务实的原则，坦诚的交换了各自的意见。虽然没有对具体的条款、以及他们的优先级别得到完全一致的认同，但至少对系统割接上前的工作内容还是有80％以上的一致的（实际上，包括割接后、初验终验前，只占到整个项目工作量的一半左右）。而对一些有争议的内容，钱甲、孙乙双方又达成了一个一致的做法：1、各自向自己的领导汇报后再沟通一次；2、目前先重点关注割接上前的工作内容，对于之后的内容，找合适的时机再沟通。

从这里可以看出：售前合同的内容签订的过于粗糙，甚至有过于其实的情况出现，导致后续的工程实施过程中很多东西都处于一种模糊的、非常容易发生争执的状况。就目前国内的市场环境、甲乙双方的管理水平来看，还难以短期内改变这种现实！这种情况下，本着务实的态度，甲乙双方应该在售后多做开放、互助互谅式的沟通。只要是朝着为了把事情本身做成功的目标出发，都不应该有任何成见！
和钱甲沟通后，孙乙回来又进行了项目范围定义的相关确认和考虑，包括找李丁沟通确认，对某些重点工作找相应技术人员讨论，找销售代表和售前技术支持人员了解售前承诺等等，结合钱甲的意见，孙乙做了一些调整。尤其是个别重点任务的具体工作内容、优先级别等。

当日下午，钱甲也找到了他的领导：赵丙。就相关问题进行了汇报、沟通。当天晚上，孙乙邀请到钱甲，对项目范围的定义再次做了沟通。

从第二次沟通的情况来看，大家对割接前的工作范围都已经基本没有太大的异议。当然，孙乙、钱甲双方也都做了一些适当的让步或变通。最后，两人盯着自己经过将近一天的辛苦工作，得出的一张简单的ppt胶片，有些苦涩而满意的笑了！包括前台业务的181个功能必须支持；割接时必须100％支持在网客户资料和费用数据的转换；必须支持规范要求的15大性能指标，等等，总共有5条，两人给其取了个好记的名字——五大纲要。

不仅如此，两人都深感，有必要为了尽可能提高以后范围可能发生调整时的沟通效率而制定游戏规则。由于有了前面沟通氛围的惯性，双方就这个问题没有争论太长时间，很快就确定了下来。包括双方的范围变更只能通过钱甲、孙乙两位沟通确定，其它人无权擅自决定；割接前2周停止非参数配置性质的需求变更，割接前半周停止一切新需求；等3条。两人对这个也给了个名字——三大纪律。

有了这三大纪律、五大纲要，钱甲、孙乙二位总算松了口气，在晚上23点左右总算各自打道回府休息。

次日，孙乙拿着这个五大纲要、三大纪律的ppt胶片，给项目组开了个会，也算是一次简单的沟通和培训。让大家都基本清楚了项目的实际工作范围（至少是割接前这段时间内，后面的还需要再沟通协商）和控制规则。

另外，孙乙也开始了编写《项目背景培训》胶片，该材料是作为后面进入项目组的员工进行基础培训的内容之一。这样，孙乙就顺势将五大纲要、三大纪律，扩充到这个胶片中去了。

在项目开始后，立即要做的一个非常关键的事情就是：将项目范围、任务优先级、变更范围的控制规则明确下来，和客户进行充分的沟通，得到双方的认同，并将这一成果在全项目组内不断的宣传、培训。这项投入将会为项目赢得出人意料的回报！！！

（二）进度计划和费用预算

接下来，孙乙知道，要立即着手开始制定详细的项目进度计划，这对于安排项目成员工作任务、后续人力资源调度等等，将是必须的前提。

制定进度计划的第一步，是制作工作分解结构。也就是将BOSS工程项目所涉及到的工作，从粗到细的识别出来，一直细化到可执行、可跟踪、可分配明确责任人和资源的程度。

根据以往的经验，结合自身对BOSS工程的认识，加上像诸位高人请教，孙乙认为从最粗的粒度来看，应该包括如下这四大方面的工作：

1、环境准备；
2、需求分析和确认；
3、软件客户化定制；
4、系统实施；

另外，项目规划本身也应该作为一项正式的工作内容管理起来，也应该在计划中考虑其所需要投入的资源、时间、费用等等。一方面，为了制定、评审出一个合情合理、综合多方利益的项目计划，以及后续的有效执行，必须将这个工作认真做好计划，并在项目进展过程中不断的重复执行这一任务；另一方面，要知道一个认真详尽的项目规划并不是项目经理一个人就可以搞定的，还需要项目组成员、客户、高层领导等多方面风险承担者（stakeholders）的参与，这些资源的消耗也会占去项目组不小的成本，为此也应该和必须科学有效的管理起来。

为此还需要增加第五类工作：

5、项目规划；

对于这5大项工作，孙乙的理解，认为包括如下这些内容和要求：

1、环境准备

对于BOSS工程现场项目组来说，一般主要包括这3方面的环境准备：
1）项目组办公、生活等方面的环境准备。

考虑到现场项目组成员的办公、生活环境，一般都是临时准备临时使用，项目结束后就要取消的，所以需要特别考虑这部分的工作安排。

这个办公场地，从信息安全、沟通效率、实施成本等多方面考虑，一般有甲方直接提供。于是，在经过和钱甲的协商后，钱甲承诺在1周内提供出来。而孙乙负责再用1周的时间，将接下来S公司马上要开到现场的近50人准备所有的网络、通讯等环境。另外，住宿、伙食等方面的事宜，孙乙认为这也是一个非常重要的工作（正所谓兵马未动，粮草先行）。于是，在将周MM立即调到现场让她这位经验老到的行政人员负责这项事务外，孙乙还为S公司将来在T省维护BOSS系统计，另外又在3天内招聘了一位家就住T省会的能干的吴MM来配合周MM的工作。

这下，孙乙想，周吴两位MM应该可以搞定了，自己就可以一门心思腾出来做业务上的事情。孙乙对周吴二人的要求是：2周内，搞定50人的生活、伙食等等方面的后勤事宜！而现在先头到达现场的10多人（孙乙、八大罗汉、李丁等领导）就住在宾馆，吃在外面饭店采用游击式了。

2）开发测试环境的准备。

无论是否采用产品化的软件，对于BOSS这一复杂系统来说，是不可能通过简单的“下一步”、“下一步”方式的安装配置，就能够立即投入生产系统使用的。它不可避免的会有一个复杂的安装、配置、客户化开发、测试、模拟运行等等复杂的过程。为此，必须为项目组搭建一个用于客户化定制所进行的参数配置、定制开发、确认测试等等工作而需要的软硬件环境——一般称为开发测试环境。这一开发测试环境，硬件方面不需要达到像生产环境那么高档的配置，但软件环境一定要做到尽可能得一致。比如：操作系统版本、数据库系统版本、开发语言等等。

经过和钱甲的讨论，认为可以利用T省公司原来的两台旧主机搭建开发测试环境。而至于本次XXP-BOSS2.0所使用的新系统软件，包括操作系统、数据库系统、中间件系统软件等，双方都通过商务渠道去找相应原厂商努力，让他们先提供评估版本（否则，等他们的正式发货到，黄花菜都凉了）。

由于这一个工作需要马上行动起来，在孙乙指定了项目组搭建开发测试环境的工程师，钱甲指定了相应局方配合工程师后，双方确定了2周内搭建完成这一环境的工作目标，并排定了详细的工作时间表。

3）生产环境的准备。

一般来说，BOSS工程主要的工作量，都是花费在客户化定制上。在客户化定制的同时，就完全有必要将生产环境的硬件、系统软件等安装配置好，以便于BOSS软件客户化定制完成后，能够立即着手将BOSS软件到生产环境安装、配置好，从而着手进行模拟生产环境运行的压力、联调测试等。

这一工作，应该在局方采购的主机、网络、系统软件等到货后，才能开始实施。

顺便提一下，孙乙记录项目计划的方式，是采用MS project 2000这个工具，在其中既包括记录WBS，也包括已经分配具体资源和时间的信息。

2、需求分析和确认

虽然说S公司的XXP-BOSS2.0 是个产品化的软件，已经实现了很多BOSS系统所需要的软件功能和特性，但这仍然是S公司研发团队在综合多个客户市场需求开发出来的最“核心”的版本，很多具体的功能仍然需要进一步客户化定制。

客户化定制的方式包括两种：参数配置和代码开发。孙乙知道，无论是哪一种，都属于自己项目组要做的工作，都必须调查清楚T省公司客户的具体需求细节，才有可能真正将系统实施上线。

为此，孙乙已经同牛技代表的八大罗汉确认成立以他们为主的需求调研小组，承担需求调研的工作任务。并在经过和T省公司项目经理钱甲的协商后，双方确定下来以项目的最初2周为需求调研的限期。这其中，当然，钱甲也已经和自己的领导——赵丙沟通过，并已经和T省公司市场部、各业务部门做过充分的沟通。

经过钱甲、孙乙、八大罗汉、四大金刚的共同讨论，大家认为：需求调研的结果，也就是需求规格书，应该按照七大模块来组织；而需求调研的步骤，应该按照局方的部门来安排，这些部门包括：计费中心、市场部、集团客户部、大众营销部、数据部、各市县公司人员（市场部、系统管理员、业务骨干等）等。而不同的部门，面对不同的人员，又需要安排不同内容的调研。为此，需要画出一个矩阵式表格，以八大系统模块为列，以所调研部门或对象为行，分别针对不同的部门或对象，设计不同的调研内容和问题，并注意安排调研部门的顺序和方式方法等。

在这个基础之上，孙乙、钱甲共同制定了为期2周的需求调研工作计划，其中包括到市场部、各业务部门进行走访的时间、人员等等。并且，针对需求调研的结果，提出了明确的成果物要求：《需求调研问卷及应答》、《需求规格书》、《需求项确认列表（含优先级、实现方式等）》等。

通过环境准备（办公生活环境、开发测试环境）、需求调研和确认这两项工作的情况再次可以看出：需要立即着手开展的工作任务，就需要立即确定下来的详细的工作计划。而不是或者没有计划就开始工作，或者等计划完全制定后才开始工作。项目经理采用不同的工作方式，越早、越积极的驱动项目组全体成员进入工作，对项目时间、成本等资源的浪费就越少。

2、需求分析和确认

虽然说S公司的XXP-BOSS2.0 是个产品化的软件，已经实现了很多BOSS系统所需要的软件功能和特性，但这仍然是S公司研发团队在综合多个客户市场需求开发出来的最“核心”的版本，很多具体的功能仍然需要进一步客户化定制。

客户化定制的方式包括两种：参数配置和代码开发。孙乙知道，无论是哪一种，都属于自己项目组要做的工作，都必须调查清楚T省公司客户的具体需求细节，才有可能真正将系统实施上线。

为此，孙乙已经同牛技代表的八大罗汉确认成立以他们为主的需求调研小组，承担需求调研的工作任务。并在经过和T省公司项目经理钱甲的协商后，双方确定下来以项目的最初2周为需求调研的限期。这其中，当然，钱甲也已经和自己的领导——赵丙沟通过，并已经和T省公司市场部、各业务部门做过充分的沟通。

经过钱甲、孙乙、八大罗汉、四大金刚的共同讨论，大家认为：需求调研的结果，也就是需求规格书，应该按照七大模块来组织；而需求调研的步骤，应该按照局方的部门来安排，这些部门包括：计费中心、市场部、集团客户部、大众营销部、数据部、各市县公司人员（市场部、系统管理员、业务骨干等）等。而不同的部门，面对不同的人员，又需要安排不同内容的调研。为此，需要画出一个矩阵式表格，以八大系统模块为列，以所调研部门或对象为行，分别针对不同的部门或对象，设计不同的调研内容和问题，并注意安排调研部门的顺序和方式方法等。

在这个基础之上，孙乙、钱甲共同制定了为期2周的需求调研工作计划，其中包括到市场部、各业务部门进行走访的时间、人员等等。并且，针对需求调研的结果，提出了明确的成果物要求：《需求调研问卷及应答》、《需求规格书》、《需求项确认列表（含优先级、实现方式等）》等。

通过环境准备（办公生活环境、开发测试环境）、需求调研和确认这两项工作的情况再次可以看出：需要立即着手开展的工作任务，就需要立即确定下来的详细的工作计划。而不是或者没有计划就开始工作，或者等计划完全制定后才开始工作。项目经理采用不同的工作方式，越早、越积极的驱动项目组全体成员进入工作，对项目时间、成本等资源的浪费就越少。

4、系统实施

我们知道，所谓的系统需求，一部分是通过软件来实现的，一部分是通过硬件方案（包括主机、网络、磁盘阵列等）的人工劳动来实施实现的。

所谓的系统实施，指得就是除需求调研、软件定制外的所有人工劳动过程和内容。一般包括：

1）应用软件系统在主机部署的设计和实施；
2）磁盘阵列划分的设计和实施（对于容灾工程，尤其内容多且重要）；
3）数据库方案的设计和实施；
4）其它合同范围内的集成方案设计和实施（如口令安全、系统备份、数据管理等）；
5）BOSS和外围接口方案的制定和实施；
6）BOSS应用软件的安装调测；
7）新旧系统客户资料、帐单数据等的转换；
8）生产环境下的系统压力、联调、模拟测试等；
9）最后一步：系统割接上线；

所有的这些工作，应该说才是BOSS“工程实施”类项目的重点工作内容，而且往往涉及到甲乙双方、多个厂商、多个工种人员的相互配合协调等等，所以非常复杂。

5、项目规划

对于BOSS工程来说，需要如下这些角色参加所有项目任务的计划过程（尤其是工作量时间等方面的估算、每个人可以投入的工作量和时间等等）：

1）项目经理；
2）项目整体技术负责人、各模块开发负责人、测试负责人；
3）开发人员代表；
4）测试人员代表；
5）主机、网络、DBA等参加工程实施人员；
6）公司能够提供资源的相关部门（直线）经理、财务人事等部门经理、高层领导等；
7）客户项目经理；
8）客户在主机、网络、数据库等方面的实施配合人员；
9）涉及到客户上述方面实施人员所在的部门负责人；

从这里可以看出，参与项目规划的人员，几乎涉及到项目相关的所有人员。这其实有两个简单的判断原则：
1）具体工作的工作量、时间等，最好由其具体执行人（如承担某个开发任务的程序员）或其代表参与讨论，而不应该简单的从上面“压”下去；

2）所有能够提供、控制资源的权力人（包括客户方），也要作为计划制定参与人考虑；

制定计划其实是一个自下而上、逐级汇总的过程。就是一方面，充分考虑具体执行责任人的估算（实际也是一种承诺），另一方面也结合项目总体的要求在上层进行控制和反馈。

经过上述的考虑，孙乙认为项目计划的第一个完整稿，必须在需求调研完成的2天内给出，并且大概总共需要消耗10～15人周左右的工作量，加上今后将不断的维护和细化该计划的内容，总得算起来，估计至少要占整个项目工作量的5%~10%左右。

孙乙觉得，除了需求调研和确认、办公环境准备、开发测试环境准备这些工作的计划必须立即确定下来外（其实，在那个一周时间表安排中，已经考虑了部分），其它工作计划的制定，还需要进一步和相应的人进行讨论沟通。

在基本已经考察完所有项目涉及工作的内容和结构后，孙乙汇总出来和一个初步的project WBS文档。拿着这份文档，孙乙开始开始进行了第一轮的活动定义、顺序安排、工作量估算、费用估算等工作。

首先，对于已经明确下来的需求调研和确认、办公生活环境准备、开发测试环境准备、项目规划这几个工作，由于这些是立即就要开展的工作，孙乙在项目范围（五大纲要、三大纪律）确定后的第二天，就制定了下来详细的内容（包括详细的任务名称、责任人、工作量人日、工期、先后次序等），并分发到相应人员的手中，并从第三天让所有相关人员都进入了工作状态。

其次，对于生产系统软硬件环境准备、客户化定制、系统实施等工作，孙乙先将其分解到目前能够分解到的、且仅仅是必要的细致程度，而对于活动的顺序、时间、成本等，根据自身和从其它大佬讨论得来得认识，先做了一个大致的估算。通过这个大致得估算，孙乙对项目的整体工期、成本预算、所需人力资源等，有了一个初步的认识，但还不能作为真正的计划内容。

按照孙乙的打算，是希望随着需求调研的完成，自己在每天参与的需求调研工作结束后，利用当天收集到的新信息，不断的同步希望自己的计划内容，知道2周后需求调研完成后的第二天，才真正完成第一轮的计划制定过程。

两周左右的需求调研工作非常辛苦。一方面，孙乙需要白天不断的跟踪、协调和组织八大罗汉在钱甲或四大金刚的带领下，到客户的各个部门去进行需求调研，而且这中间还由于局方相应部门工作时间的调整而不断的调整调研顺序；另一方面，孙乙和八大罗汉，以及钱甲、四大金刚，还要每天晚上将当天的调研结果总结出来，并对某些疑问作出应答。最令孙乙痛苦的，就是完成这些工作后，自己还要再坚持考虑及时的将工作计划方面的相应安排进行细化或调整。

两周的辛苦调研结束了（实际上，2周的需求调研是不够的，这里假设八大罗汉是超牛的人，他们对T省公司的需求基本已经有个了然；并且局方的配合也是无微不至的。后面孙乙就不再次安排单独的需求调研时间啦！虽然还会有些需求细节的反复，但应该不影响项目的计划安排了——改需求？大家加班搞定！实在搞不定的，就相应的调整工作计划吧？反正有详细的项目工作计划，每个任务的调整，到底产生什么样的影响，一下子就能看出来的。），孙乙委托牛技负责最后完成需求调研所需要的应答、规格书、需求实现方式和优先级列表等文档，而自己专心下来做项目规划的工作。

在牛技完成需求调研相应的工作成果后的2天，孙乙根据和牛技等八大罗汉的反复讨论，已经非常明确软件客户化定制的工作内容，甚至有些模块负责人已经非常清楚的知道某些需求具体该配置哪些参数、或者需要修改和增加哪些代码。

由于大家的拼命努力，才有了这个良好的基础，孙乙就制定出了几乎80%完整的工作分解结构（WBS），也就将80%以上的项目活动定义了出来，并对这些活动按照其本来的先后关系和优先级进行了顺序，然后让八大金刚为代表，为自己组兄弟们大致估算了每项开发、测试或实施任务所需要的工作量，自己部门可能参加的人选（当然，这期间经过N轮和其部门经理的交涉），以及这些人选能够投入的精力。考虑了种种的这些后，并经过N轮的反复调整，孙乙总算制定了一个第一版本的project计划。这个计划包括：WBS、工作量估算、资源安排（主要是人员安排）及其可投入时间百分比、工期估算等。

根据这个project文档，孙乙对每个资源赋予了其成本参数（当然，人员的加班工资基本是零的），作出了项目费用的人力成本估算，并在人力成本的基础上，考虑差旅、住宿、伙食、办公、活动等等费用后，给出了整个项目的预算。

最后，在带领项目组八大金刚来到现场后的第三周后，孙乙按照S公司的要求，提交了整个项目的计划和预算表格，在得到李丁和王富为代表的公司领导审批通过后，以及在现场办公生活、开发测试等环境顺利准备好的前提下，再加上接下来制定的人力资源计划，就开始调动大批的项目人员进驻现场，项目总算正式的如火如荼的开展了起来。

这里，要补充一个孙乙制定计划后的重要成果：里程碑计划。孙乙在制定项目进度计划的同时，也通过和局方钱甲的沟通，结合前面的工作分解结构，为了更好的控制项目进度，也为了方便汇报进展情况和不断得给项目组成员以信心，给出了如下几个项目里程碑：

1、生产环境硬件安装配置完成（要求设备到货后2周内）；
2、需求分析确认完成（要求项目启动后2周内）；
3、软件客户化定制完成（含功能确认测试，要求需求分析后8周内）；
4、生产环境软件安装配置完成（要求硬件安装后2周内）；
5、数据倒换脚本准备完成（要求项目启动后4周内）；
6、生产系统联调和关键性能指标压力测试通过（要求客户化定制后3周内）；
7、计费、出帐对比测试通过（要求客户化定制后2周内）；
8、系统割接上线（要求项目启动后12周内、或系统测试通过后1周内）；

虽然里程碑看起来比较多，但孙乙觉得有这个必要，因为这些里程碑能够清楚得反映出来BOSS工程建设的进展状况，而且里程碑控制得越细，就越容易及时发现问题和纠正偏差。

另外，从这个里程碑进度可以看出：设备到货时间，如果控制不当，将会影响整个项目的割接时间。关于这一点，孙乙已经和钱甲做过充分的沟通，钱甲也表示理解和支持这个观点。

到了这里，孙乙才真正找到了感觉，对项目的成功越来越充满成功的信心，对作为项目经理的辛苦工作也更加的充满了兴趣。

从这里的项目计划的制定过程可以看出：这里面充满了特定行业的业务、技术方面的知识和经验，同时也充满了对客户环境的理解和工作技巧等等。所以说：一个好的项目经理，并不是仅仅具备管理经验和技巧就可以的。也就是说，不仅仅通过一个PMP的认证就能够成为项目经理，还需要很多的行业特定的业务、技术背景，已经多年的实际项目管理经验。这里所说的，实际上只是项目管理所需要的“九牛一毛”。好的项目经理，至少需要经过5年甚至10年的实际项目经验的积累！

（三）人力资源规划

有了进度计划（包括WBS），实际就可以进行很多的、连带的相关项目规划工作了。这里，我不打算对所有需要规划的内容都罗嗦一遍，而只对我认为对BOSS工程比较重要几个方面进行介绍，包括：人力资源规划、风险规划、沟通规划。

要特别说明一下的是：随着项目规划的不断开展，往往会在做后续规划的过程中，发现前面的规划结果需要调整。尤其是在做风险规划时，更是如此。这对于一个项目来说，是非常正常的。实际上，不但如此，即使在项目规划完成后，项目实际开展过程中，项目规划的内容往往还是会发生调整。如果从项目规划的角度来看，甚至可以说项目经理80％以上的精力都是花在那个“计划”上面（当然，这优点夸张。实际上，应该说是为计划而进行的工作。包括后面在调整计划时，和各类人所进行的大量沟通协调工作）。所以，有人说：计划、计划、再计划。

对于前两项内容，一般比较简单。因为是由S公司的企业管理制度和惯例所决定的。也就是说：对于一个特定的企业，项目怎么做，往往都已经是确定的了。而项目中能够取舍的，往往就是根据项目实际需要而确定的特定角色和人员的有无。比如：是否需要DBA，是否需要网络工程师等等。

根据S公司的CMM 3级过程的管理制度要求，以及公司在BOSS工程项目方面的惯例，孙乙确定了如下的

1、项目角色和职责
1）管理类（各1人）：
项目经理（项目总负责）
项目助理（辅助项目经理工作，行政事务等）
QA（质量保证，监控者，领导的耳目）
配置管理员（负责配置管理）

2）技术管理类：
技术总监（1人，即技术总负责）
各模块开发组长（7个模块，负责各模块开发组的技术和管理）
测试组长（1人，负责测试组的技术和管理）

3）技术类：
系统分析师（2～3名，负责项目重大技术问题研究和决策）
开发工程师（按7个模块划分，若干名，负责相应模块的参数配置、定制开发）
测试工程师（按7个模块划分，若干名，负责相应模块的集成、压力、系统测试等）
DBA（1名，负责数据库管理系统的维护管理）
网络工程师（1名，负责网络方案的实施）
主机工程师（1名，负责主机设备的安装配置、环境搭建）
数据倒换工程师（2名，负责新老系统数据的转换，含脚本编写、测试和执行）

2、项目组织结构（即汇报关系）

1）项目