其实项目在不同阶段，项目管理的侧重点也会相应发生变化，此时项目报告模板也应做相应调整。
今天我们聊聊项目在准备进入转运维阶段时的项目周报该如何呈现？
不一样的项目周报
项目报告真的仅仅是为了告诉干系人我们做了什么吗？这样的话，报告能发挥的力量就明显大打折扣了（注意：好的报告是驱动项目成功的关键因素）。
经过大量项目的丰富实践，针对转运维阶段的项目周报，我梳理出一套“报告四原则”：
原则一.驱动项目成员的成长，使其由“需求驱动”思维转换为“价值驱动”思维。
IT人员在做项目的时候，很容易掉入“只问需求，不问价值，若有问题，干就完事”的陷阱中，这是目前国内绝大部分项目实施成员的通病。
这种项目心态表面来看对提升项目交付效率很有帮助，但深层次思考下，其实是百害无一利。
1. 需求是做不完的。
如果需求本身找不到落脚点，那就是无根之萍，一是散乱不堪，二是无穷无尽造成项目范围蔓延。
在项目启动之初的需求落脚点是公司战略规划，而在项目实施过程中需将落脚点再次分解，并用一根主线串起来，串起来的这根主线，我们叫它“价值链”。
因此本质上来讲，凡是不在价值链上的需求均可以不做或者搁置，否则做了也难得到项目sponsor的认可。
到时候很可能一顿操作猛如虎，一看价值在低谷。
2. 要做有价值的事。
在之前的文章《一个实践者的角度：项目管理三段位》中有讲过，项目成员的成长是PM工作的重中之重。
我们要积极引导他们将所做的工作价值最大化，忙忙碌碌一场空是我们必须要摈弃的状态。
我们得让他们知道为什么要做，做了有什么用，用处在哪里。这样才能让他们看透需求的本质，并从中找到成就感。
如果每个需求的价值本质他们都能把握到，他们对这个行业的理解就会到一个全新的高度，对他们的成长帮助是不可衡量的。
原则二. 保持项目的透明度，站在用户的立场告诉他们我们做了什么，计划做什么。
项目能否保持始终透明，是项目成功的核心因素之一。项目Sponsor出了钱并组织了一个庞大的业务群体支持我们的项目工作，于情于理我们都需要对他们有所交代。
交代的原则应该是“事事有回响”，需要定期告诉他们我们做了什么，计划做什么。以此提升大家对项目实施工作的信心，也能侧面提升项目团队成员的执行力。
原则三. 提升业务领导的参与度，以便后面能获取更多的业务支持。
IT人员一般比较低调、内敛，因此在项目管理过程中很多IT项目容易陷入一种状态：和关键用户打的火热，却把业务领导冷落在了一边（因为他们认为关键用户会和他们的业务领导汇报），进而导致业务领导对项目情况了解很少，一旦PM想获取更多业务支持的时候非常容易陷入业务领导不支持的困境。
故大胆起来吧，如果你可能需要谁的支持，就要提前铺路。
在平时的报告中“指名道姓”，以既有现象去驱动他们的关注。关注的多了，他们对项目的理解就会越来越深，才能更精准地了解自己在项目中应承担的职责。
这样后面你争取资源的时候，才容易水到渠成。
原则四. 赋能业务团队，平滑完成能力/角色从项目组到业务职能团队的切换。项目在试运行期间，为了快速上线，项目组往往会大包大揽。这样导致项目在进入运维阶段后，业务用户既没能力也没意愿去接手运维工作。
这样就导致，运维的工作一直挂在项目组身上，从而造成很多困扰。
因此得想办法谋求运维角色的转变，这样就需要在报告里做一定的策略。
报告中可以积累一些平时容易遇到且通过培训业务部门能自我解决的问题，做成运维tips。
光明正大地给业务部门赋能，为后面定岗定责铺路。
基于以上4项原则，模板如下，以飨读者。
图解PMBOK，需要的同学可以私信我哦！
更多精彩内容请点击“了解更多”
