今天跟大家分享一下，我建立的IT项目管理体系，根据公司的实际环境建立，目前运行非常顺畅。
从项目的申请，到项目的验收付款，每一个环节都通过系统展现出来，我自己给这套体系叫做“数字化项目管理体系”。这套体系不依赖于我的能力，即使我休假或离职，也可以很好地运行，我是完全游离在体系之外，观察并优化其瓶颈，我也时常戏称为去中心化式的项目管理体系。
这套体系包括OA系统中的项目申请流程，Redmine项目管理系统，开发管理系统和IT项目展示系统（我们内部叫红灯系统）四个模块。通过以上四个模块，将项目的各方（用户，IT工程师，外部开发人员，领导或利益相关方等）都很好地连接起来，提高项目沟通效率的同时，项目进度管理和项目质量管理也就水到渠成。
开始之前，先聊聊之前的项目管理存在的问题，或许会有共鸣。
1、缺乏目标：项目没有明确的、共同的目标。如用户和IT工程师并不完全清楚项目最终将实现的效果，或很模糊；项目没有明确的上线时间，做到什么时候就什么时候上线，如果忘了就不了了之。比如OA系统中还有两年前的申请未结案，不管是用户，还是IT工程师根本就忘了这事，直到有领导过来骂人。
2、缺乏用户导向：项目没有唯一的负责人。因为我们IT团队开发能力不足，80%的开发都是外包，如果有熟悉ABAP，JAVA，.net开发的朋友，也可以跟我联系，或许会有兼职外包开发的机会哟。如果一个需求涉及多个业务系统，用户需要提交多个申请，对每一个申请分别抛外包开发PO。不同的申请由不同的IT工程师负责，相互之间没在关联和交流，经常会出现一个系统的开发完成了，用户满心欢喜地以为可以上线试用了，被告知你去问问B工程师那边做完了没有，B工程师一眼蒙逼，你没有给我提需求啊，我都不知道这个事儿。好吧，用户还得乖乖地再提一个B系统的申请，就这样，一个简单的需求，由于没有统一管理，时间跨度会很长。
3、对“完成”的理解有偏差：IT工程师报告的完成是指开发完成，而不是指项目上线给公司带来真正的效益。比如刚开始时，工程师汇报说这一项已经完成了，就随口问了一句，那现在用户使用中是否有问题？得到的答案是只是我们开发完了，还在测试系统测试，请问这是完成了吗？这又回到第一点，我们IT部门的目标是使优化成果给公司带来经济效益，而不是简单地做了这件事情。
4、缺乏交付标准：同一件事情，不同的工程师交付的结果是不一样的。如OA流程界面可以说是百花齐放，函数的命名规则、字段的命名规则等。
以上只是简单列举几条较严重的问题，针对这些困局，我提出了观察、梳理、高效三步曲。
对IT工程师的要求是软、硬技能两手抓。硬技能包括学会绘制LOVEM流程图，学会利用思维导图收集用户需求，学会制作原型图和用户确认，学会编制项目相关文档。软技能包括提高项目管理能力、时间管理能力，提升思维模式和解决问题的方法论。部分PPT及培训文稿请出门左转。
对人的要求如此，对系统的要求更是如此。
只有人和系统的完美结合，才能使IT项目管理高效的运行。对人的软、硬技能培养部分有机会再讲，今天先回到我们的正题 - 数字化IT项目管理体系。
公司的理念是能让系统做的事就不要让人来做，机器做更稳定，不易出错且效率更高。所以，公司的信息化水平还算不错，所有的信息系统都已打通，优化端到端的流程，消除了信息孤岛。当然，我们IT部门也很苦逼，累成狗。但给公司带来了很大的利益，系统效率提高了，操作人员减少了，节省了不少人力成本。奖金是没有的，只能自己苦中作乐，寻求一些成就感！哈哈！
我们的IT项目管理按项目大小分为两类，较大的项目如：新系统开发或实施，旧系统在新公司实施等。本体系主要是适用于另一类，即IT优化类项目。较大的项目我们采用敏捷管理框架，IT优化类项目采用的瀑布管理模型，为什么这么选，这可能就是最佳实践 。
由于是内部优化项目，为简化管理，我们只重点管理项目范围、项目进度、项目风险和质量等维度。
从项目实施的时间顺序，划分为项目申请，项目评估，项目实施，项目测试，项目上线及验收五个部分。并未严格按照PMP的五个过程组，十大知识域。
1、项目申请
项目申请主要通过OA系统中的项目申请流程，也可以称之为立项。
1.1、提出需求
所有的需求必须通过OA系统提交申请，以便于通过系统集中管理。这是项目的入口，必须严格要求，尤其是外地子公司。
IT项目将采用项目经理负责制，一个需求，无论涉及多少业务系统或多少位IT同事，用户都只需提交一个申请，由项目经理对整个项目负责，协调内、外部资源。这一步通过重新设计优化OA流程来实现，对项目的进度管理起到至关重要的作用。
多啰嗦几句，以前一个需求涉及多个系统，需要提交多个申请，是因为OA系统向PO抛订单的问题未解决。通过重新设计OA流程，一条OA流程可以同时抛多个PO，对应不同的外部开发顾问。
提交申请时需主要填写以下信息：
1) 项目名称或申请主题：用一句话描述项目的主要内容。
2）发起人：发起人是项目的实际发起人，也是项目最重要的干系人，可能与申请人不是同一个人。
3）项目适用范围：选择项目适用的公司名称，可多选。在后面项目测试和项目上线时将作为管控对象。
4) 业务现状描述：对业务现状的描述，即未开发或未优化前的业务情况。
5) 希望实现的目标：对业务优化、改善的详细描述。
6) 主要风险控制点：业务实现过程中已知和未知风险，需要用户和IT工程师共同识别。
7) 涉及或受影响的部门负责人：如果项目涉及到其它部门，需要纳入进来管理其需求，相当于项目干系人管理。
1.2、认领项目或指定项目经理
根据用户提交申请时选择的系统类型，流程会自动推送给相关的IT工程师，根据工作分担情况，IT工程师认领项目，并成为该项目的项目经理。IT项目采用项目经理负责制，由项目经理负责整个项目的进度和质量，并协调内、外部资源。
2、项目评估
2.1、IT工程师评审需求，即需求分析
需求分析是整个项目管理的重点，是决定项目是否能够近期交付的关键。
之前的旧模式是，用户邮件或电话给IT工程师，或召开会议讲一遍需求，然后IT工程师就开始着手开发。一方面需求未经过深入讨论，可能用户自己也没想明白或讲明白，或者是需求来源于某一领导口头指示，提交申请的人自己也没搞明白；另一方面IT工程师的理解和用户的实际需求之间有很大偏差。结果就是测试时总是无法满足用户需求，反复修改，最终上线的产品和用户的原始需求相距甚远，用户，IT工程师和外包开发工程师都苦不堪言，项目无限期延期，领导也极不满意。
在需求评估环节，需要完成以下工作：
1）和用户及相关部门充分沟通需求，制定方案，对于复杂的项目，需要编制流程图、绘制原型图向用户确认。
2）项目任务分解，类似于WBS，但和WBS还不完全一样，按功能和用户的操作步骤拆分，一步步描述，以便于用户测试确认，越细越好。
3）识别项目的风险，填入OA表单中，以便于用户测试时逐一确认。
4）项目经理确认实施人员，哪些是内部实施，哪些需要外包开发？填入实施人员，将自动汇总项目评估人天，自动计算项目的计划上线日期，项目较多时，会根据评估的优先级排序，项目的实施成本，计入部门费用等。
外包开发通过开发管理系统管理，需要外包的项目，会传到开发管理系统。
选择发送给至少3个开发工程师，开发工程师将收到短信提醒，同时登录平台可以看到完整的项目信息。评估需求后给出报价人天，内部IT工程师可以看到各开发工程师的报价，选择一个合理的报价即可。这个功能相当于一个简单的招投标管理平台。
2.2、项目方案确认及审批
项目经理提交方案和需求清单后，先由产品经理再次确认，确认无误后经需求部门领导审批、涉及部门负责人审批、IT部领导审批后，项目进入实施阶段。
各级领导审批通过是项目启动阶段完成的标志。
3、项目实施
项目审批完成后，会通知IT工程师实施，如果有外包开发工程师，会通过短信通知。同时，OA系统会向SAP抛一个采购订单凭证，处于锁定状态，验收通过后，方可解锁付款。
项目经理组织项目团队开始实施项目，并在实施过程中控制项目的范围、进度、成本、质量和风险，并积极地管理干系人的参与。实施过程中，项目经理应与产品经理保持密切沟通，关注项目的变更情况，产品经理也应积极主动地与项目团队沟通，如有任何变更，应当第一时间通知项目经理，项目团队评估变更对项目范围、项目进度、质量和成本的影响，并将变更信息填入OA流程中。如果变更影响到外包开发成本，将返回需求部门事业部总经理重新确认。
3.1 Redmine项目管理系统
Redmine是开源的项目管理系统，功能非常强大，不再详述，我们自定义了大量的字段，并且与OA打通。
项目管理体系建设初期，开发管理系统和IT项目展示平台还未建立时，所有的项目都从OA自动传送至Redmine，现在主要用于管理较大的项目。
有需要沟通Redmine的朋友可留言或私下沟通。
3.2 开发管理系统
开发管理系统是用户、IT工程师和外部开发工程师交互的平台，除了前面提到的得的询价功能，还主要有以下功能：
1）开发工程师登录后，可以看到自己有哪些项目正处于实施的任何一个阶段？是否有延误？哪些项目已经完成？哪些项目可以对账×××等。
2）可以看到自己的平均按时完成率，在当前所有外包开发工程师中的排名，以利于我们评选优秀合作伙伴。
3）收到可以实施的短信通知后，开始实施，实施结束后需上传相关的文档，如函数名、字段名、SAP传输请求号等。
4）用户在测试过程中发现的问题，直接在开发管理系统反馈，类似于BUG管理系统的功能，项目测试过程会提到。
3.3 IT项目展示平台
IT项目展示平台，不仅可以展示项目的整体指标，还能详细地展示每个项目的进度状态（我们内部叫红灯管理），如下图所示：
有了这些数据，做分析统计，就非常容易了
1）可以清楚地看到每一个项目每一阶段的标准时间和实际耗时，因此可以初步预测项目是否可能延期？
1） 可以清楚地看到各个阶段有多少优化项目，每一位项目经理分别是多少？
2）按月份统计，每个月有多少优化项目申请，每一位项目经理分别是多少？
3）每一位项目经理的平均响应时间，平均完成时间，平均按时完成率等。不过目前我们的整体水平还没这么高，而且考虑到内部用户的工作忙碌程度及配合程度，项目按时完成率方面不是太高。但考虑到全球的项目平均按时完成率只有60%多，我们也很欣慰了。
通过设计这些指标，从项目数量，完成质量上都可以很好地考核，并实时展现出来。
4、项目测试
内部优化项目不同于新业务系统上线等大项目，用户领导的关注度较低，用户也因为日常工作较忙，可能会疏于测试。正式上线之后，经常会发现很多场景根本就走不通或存在BUG，一般情况还好，用户找IT工程师修改即可，遇到较真或喜欢骂人的领导就麻烦了，任何一个小问题可能都少不了一顿臭骂。
1) 为确保项目质量，在用户测试前，项目经理必须组织项目团队开展内部测试，达到交付标准后（即需求清单要求的功能都实现并已满足用户期望），方可交由用户测试。事实证明，这一步的效果非常差，原因可能是多方面的，反正短期内不容易提高。
2) 项目团队内部测试通过后，项目经理发邮件通知所有的干系人开始用户测试，邮件需注明测试时间段，正式上线日期，测试方法和注意事项等。由于第一步的效果非常差，这一步就是最后一根救命稻草，否则，出了问题，用户和IT工程师都会挨骂。因此，我们选择在这一环节由用户和IT工程师共同测试。
3）用户在测试过程中发现的问题，直接填写在开发管理系统，也即集成了BUG管理系统的功能，类似于以前常用的Issue list Excel表格。外部开发顾问，IT工程师和用户都可以跟踪处理进度。
4) 需要对每一家公司在项目需求评估阶段列出的功能点和风险点逐一测试确认。为了确保测试效果，由系统自动生成一份项目测试清单，如下图所示。逐一测试通过后，用户及直属领导签字确认后上传，方可认为测试通过。这一步把用户的直属领导拉进来，出了问题就有人替我们IT背锅了。
5、项目上线及验收
用户测试通过后，项目团队再部署至正式环境，开始上线试运行。
新开发的功能部署至正式环境时，需要提交《IT变更管理流程》，按变更管理的要求执行。
5.1 项目上线试运行
上线试运行一般为1个月，新业务系统上线后试运行一般为3-6个月。
试运行期间，如发现Bug，由产品经理联系项目经理确认并修改，如需要对程序增减功能，此时不再允许变更，待业务运行一段时间后，再重新提交新的优化申请。
如果项目适用于多家子公司（根据申请时选择的公司名称），必须在申请单中逐一勾选并确认所有子公司都已上线，方可流转至下一节点。
5.2 项目收尾验收
项目收尾是指项目经理和产品经理确保所有的项目工作都已完成，项目目标都已经实现后，需求部门对项目进行验收确认，以及项目团队对项目经验的总结。
项目收尾是公司内提高项目管理绩效的简单易行、立竿见影的有效方法，只有总结，才能持续改进、不断提高，项目收尾也是最好的团建活动。
1) 项目经理应邀请所有合适的干系人参与本过程，参与人员包括项目团队成员和关键用户。
2) 总结项目经验，分享在项目中的成功经验和教训。
3) 更新并归档项目文档。包括但不限于：项目管理计划、项目范围、进度计划、风险管理、变更管理文件等。
4) 如果项目包含了合同，在该阶段也需要结束合同。如果项目失败，仍然需要结束合同。
5) 会议结束后，项目经理需要邮件给所有干系人，包括外部兼职开发顾问，宣告项目结束。
项目通过验收并收尾后，标志着项目管理的工作结束，正式进入运营阶段。
5.3 对账及付款
因我们80%的开发都是外包，项目验收后，需要和外部开发工程师对账并付款。
外部开发工程师对账和付款都在开发管理系统中完成，类似于SRM系统的功能，外部开发工程师可以随时查询付款历史，待付款金额等信息。外部开发工程师开好发票后，IT工程师选择需要付款的项目（可多选），输入发票号，点击付款按钮，即可自动生成OA系统中的《供应商月结付款流程》，无需用户及IT部门再次审批，即可由财务部门完成付款，费用根据申请用户的部门，计入对应的成本中心。