所谓，你赋予项目管理人员什么职责，你就去考核什么。
关于项目组织结构，这里就不详细谈了，主要分行政部门结构、纯项目经理结构、矩阵结构（弱、平衡、强）等。
一般来说，我们可以认为大部分公司的项目管理是弱矩阵结构，即项目经理有项目成员管理权但行政权利不强（如不能影响人员的工资），项目经理承担着准部门经理职责但没有行政权利。

下面，我谈谈基于这种组织结构下的人员考核体系，抛砖引玉、举一反三。
在这种弱矩阵结构下，技术团队人员通常会存在三类职责的人：

A类：参与到项目主体开发的人员，指参与在公司正式立项并取得项目财务编号项目的成员。
这些人从行政部门中抽调出来进入项目，在项目过程中间一般不会返回其所属行政部门（如软件开发一部）；

B类：非项目类，指未参与在公司立项项目，而是参与行政部门安排的任务工作，包括：产品维护、预研、工具开发等活动，通常由部门经理安排执行；
C类：项目支持业务人员，包括部门经理、配置和质量管理等工作人员。

区分好要考核的人群后，再去按职责设定绩效考核相应的负责人，负责人再依次分解：
对于A类人员，通常以项目绩效为主（TQC），辅助以知识积累、团队建设考核。
对于B\C类人员，则以任务完成情况、配合项目程度、部门管理指标去考核。

注意，考核是与激励挂钩的，否则考核就失去动力。
也就是说，你要提前考虑好人员的奖金激励盘子、人员工薪调整的规则。否则，考核基本就是形式化！！

下面给出一个我对某项目管理负责人的考核体系，其他人以此增减：
序号 KPI（GS）及目标值 权重（相加＝100%） 考核标准
1 项目开发时效 40% 在项目计划规定的时间内完成开发任务；
2 项目开发及服务质量 30% 设计质量，设计性能，文档质量，编码质量，开发量，bug率，故障率，系统支持维护满意度；
3 客户响应速度 10% 业务需求响应速度，问题/故障/Bug处理速度
4 团队建设贡献 15% 公司制度、政策的上传下达；掌握员工的情绪及工作情况的能力；维护与客户之间关系等
5 公司贡献 5%

说说我个人一点点不成熟地想法，考核光定出kpi和权重只是迈出了第一步，第二步是执行，第三步是沟通。
第二步，强力推动所有部门所有项目组所有成员参与到考核中来，过程是先试点再推广还是上来就全面实施不重要，关键是最后要全员都参与到体系中来，“参与”不是走形式，是裁判员要认真的考察、认真的打分。分是有了，往往的问题是每个人打分的标准是不一样的，比如有个小伙子技术中等态度中等贡献中等，不同的PM或DM可能给出60分，也可能给出80分。（这个问题我认为是难免的，不知道哪位同仁有比较好的办法？）所以考核的目的不是给人员划分出出三六九等，划出来也不准，反而会使大家觉得考评是不公平的，造成后续的消极、低迷、离职闪人。还有一些其他的弊端，相信经历过的同仁都很清楚，此处不赘述。
第三步，由于第二步存在一些弊端，所以建议执行第三步，第三步不是要在第二步之后执行，写法错误，咱别写第几步第几步了，写第几层吧，懒，前面的不改了。嘿嘿。
第三层是啥呢，沟通！考核前，要让全员知道考核管理或者绩效管理地方式、游戏规则、目的、意义。我认为意义的确是提升绩效，通过提升每个人的绩效达到提升组织的绩效之目的。考核中，项目经理或部门经理要对自己的成员负责，真的要不断的观察和沟通，知道他在做什么做的怎么样有啥子困难解决了没有等等，打分时候才能更贴近实际一点点。考核后，分打出来了，尽量找每个人聊聊，为什么你开发时效我给你85，而不是86，为啥你服务质量我给你90而不是91。你有啥子优点我希望你继续发扬，你有啥子缺点我希望你逐渐克服，你在职业发展和技术方向上有啥子困惑我帮你分析，等等等等等等。。。。。

最后，三层整完了还是解决不了全部的问题，所以请各位圈友继续拍砖。