摸清楚公司经营目标，各项目的利益诉求以及自己的角色，各项目优先级； 抓住需求、项目阶段去评估评价，让乙方提交相应的工作结果； 招待好你的乙方项目经理，如有可能培养自己的架构师去把握乙方关键点。 余下的就是实践、积累了。

没有怎么做过甲方，不过我觉得都是项目，甲方是需求方，我觉得最关键是把需求做好。如果能够掌控流程的话，不妨尝试按照scrum迭代来走。这样可以避免甲乙双方因为需求理解问题而导致的沟通问题，延期等等。需求管理可以考虑用下我们开发的禅道项目管理软件，或者可以要求乙方也使用禅道。这样大家都可以及时了解项目的进展情况。

没有需求人员吗？或者要求对方给你整理需求 当然了，自己得把握住需求和设计要求，这是必须的，细化或者展开的工作可以交给别人，自己做评审

就我之前银行项目经理的经验来看，甲方的项目经理就两件事做好就行，一个是需求理清楚，二是会办事，协调好各方的关系。

大家说了很多项目管理专业方面的，我觉得还有一些问题需要注意 1. 作为甲方的项目经理，最重要的是有内部的授权。比如一个企业，往往会让IT部门的来当项目经理，但是项目的最终客户是给其他业务和管理人员用的。如果领导认为这仅仅是IT部门的工作，业务部门在需求参与，确认、试用等环境参与度不高，那项目很难推进，也很难做好。 2. 就像 @何明璐 老师说的一样，甲方项目经理和乙方项目经理不太一样，不需要对项目细节过于关注，很多情况下重两头、卡节点 就可以了。 中两头是项目需求调研、设计、评审阶段，和软件的确认、试用阶段。卡节点就是在过程中对于里程碑、例会等进行阶段性的检查，发现问题就要要求乙方立即纠正。 3. 有的时候如果是IT人员做甲方项目经理还会出现一个问题，用自己的技术观念主导需求开发，有时候可能会让业务设计过于复杂，或者超出了使用人员的理解层次，给项目增加了风险，需要注意。 4. 如果精力有限，有时候花钱找找靠谱的监理也是办法

甲方项目经理难做人，乙方项目经理难做事。甲方的项目管理侧重于间接管理，重点是需求控制和甲方项目关系人管理（甲方人员也适合干这2件事，对于需求控制，如果甲方有业务流程管理部门还好做一些），还有制定项目管理制度和对乙方查缺补漏的事情，定时卡卡进度。甲方项目关系人管理是重中之重，因为最终的验收要靠这些甲方关系人，平时甲方的资源协调也要靠这些人。其次就是需求控制和需求变更管理，一定要有优先级安排，甲方需求做不好控制，一定是项目超期超支，甲方项目管理人员一定会跟着挨板子，而这个事情由甲方项目管理人员做会较合适（乙方做需求控制很容易导致甲方人员的抵触心理）。

在这里谈下从甲方立场的IT类项目的研发管控。首先对于开发厂商的研发过程，给出一个最简单的基于CMMI思路的一个研发过程图如下： 那么站在甲方的思路，要加强开发过程和质量管控的最好的方式就是加强对需求方案和验收发布两端的强管控能力，对于研发过程中加强里程碑评审的能力。对于项目管理而言则加强PMO对项目群管理的能力。在支撑域中最基本的配置管理和变更管理是必须的，要注意到甲方对配置管理的层面往往高于单个应用，往往涉及到的是更加全局跨系统的配置和变更管理能力，端到端的需求全程跟踪和闭环管理能力。 对于甲方驱动的研发过程管控能力，可以总结为三大类，具体如下：

• 可固化：主要是指规范，流程和相关工具的制定和采用。
• 可管控：主要是项目管控过程中的评审，决策，沟通汇报，问题风险管理和监控预警机制。
• 可量化：主要是指研发管理中的基础度量和KPI指标体系的建立

可以讲做好上面三个方面的内容是甲方逐步深入研发过程管控的一个基础。甲方的研发质量和过程管控不是要替代单个应用开发商的研发项目管理和质量管理，而更多的目的是类似CMMI三级一样形成一个适合甲方管理的组织级的过程和管控机制，从单个应用厂商本身的成熟还不足够，更加重要的是组织级的基线和成熟度。 对开发厂商的管控逐步打开内部的黑盒，但是要注意不是完全接管，而是加强关键点的里程碑评审和结构化决策机制。基于这个思路，另外再提下研发过程管控的一些关键点。 对于需求层面，我们要注意往往不是简单的统一需求方案，特别是涉及到跨多个应用系统的方案制定的时候，需要的不仅仅是需求方案，同时包括了技术方案。这个方案会约束高层的的一些总体架构设计和实现思路方面的内容，以防止后续各个应用在实现过程中走偏。 加强对两端的管理，包括需求方案和验收发布两端的管理，而弱化对厂商开发内部的管理，对于开发厂商内部的过程管控只需要加强里程碑监控和评审即可。以做到最基本的闭环管理。对于开发商内部的研发过程重点是制定相应的标准规范和约束，加强QA管控。 配置管理要形成企业级的配置管理库，各个厂商最终的研发过程资产都必须入库，要加强各种配置审计工作，同时源代码配置管理也需要逐步深入管理，方便后续的统一发布和部署流程的对接。而取代原因的开发厂商在验收的时候才一并提交验收资产的模式。 在纵向团队的基础上，可以考虑形成各种横向的联合性质的虚拟团队。包括易用性团队，性能优化团队，技术专家团队，业务专家团队等，以专家团队的方式来解决各个应用可能存在的共享问题，并且在解决后逐步上升到企业知识库中。形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制。这一点往往是最难的，但是又必须执行，至少需要做到定性+定量的开发商考核和评估机制。