1 平衡原则
在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了"做什么"，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。如果需求范围很大，要在较少的资源投入下，很短的工期内，很高的质量要求来完成某个项目，那是不现实的，要么需要增加投资，要么工程延期；如果需求界定清楚了，资源固定了，对系统的质量要求很高，则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误，就是鼓吹"多快好省"四个字，"多快好省"，多么理想的境界啊？需求越多越好，工期越短越好，质量越高越好，投入越少越好，这是用户最常用的口号。
多：需求越多越好吗？
软件系统实施的基本原则是"全局规划，分步实施，步步见效"，需求可以多，但是需求一定要分优先级，要分清企业内的主要矛盾与次要矛盾，根据PARETO的80-20原则，企业中的80%的问题可以用20%的投资来解决，如果你要大而全，对不起，你那20%的次要问题是需要你花费80%的投资的！而这一点恰恰是很多软件用户所不能忍受的。
快：真能快起来吗？
"快"是用户、软件开发商都希望的。传统企业里强调资金的周转情况，软件企业里强调的是人员的周转情况，开发人员应尽快做完一个项目再做另外一个项目，通过快速的启动项目、结束项目来承担更多的项目，来获利。但是"快"不是主观的拍脑袋定工期就可以完成的，工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。软件毕竟需要一行代码一行代码的写出来，他的工作量是客观的，并非?quot;人有多大胆，地有多大产"式的精神鼓动就可以短期完成的。
好：什么是好软件？
软件系统的"好"字是最难定义、最难度量的。"让用户满意"是最高目标，你可以做到，但是资金的投入与时间的投入用户能否承担的起呢？在硬件生产企业中，产品的需求是明确的，是有形的，质量目标是明确的，是可以分解到各个作业环节中去的，而软件生产不具备此特征。在硬件生产中，生产能力是基本稳定的，对人员的依赖性较小，质量的要求对进度的影响并不是差别很大，而在软件生产中质量的一点提高或降低可能会对工期、投入产生巨大的影响，尽管用户没有明确定义出质量要求，所以软件生产是质量敏感型的生产。
省：省到什么程度？
"一分钱一分货"，这是中国的俗话，他是符合价值规律的。甲方希望少投入，乙方希望降低自己的生产成本，省到乙方仅能保本的时候，再省，乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。
2 高效原则
在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈， "产品早上市一天，就早挣一天钱，挣的就比花的多，所以一定要多挣" ，基于这样一个理念，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则，对项目的管理需要从几个方面来考虑：
要选择精英成员
目标要明确，范围要清楚
沟通要及时、充分
要在激励成员上下工夫
3 分解原则
"化繁为简，各个击破"是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。
4 实时控制原则
在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。作者一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用"紧盯"2字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精神要求是很高，我们需要有一种进行实时控制项目进度的机制，依靠一套规范的过程来保证实时监控项目的进度。如在微软的管理策略中强?quot;每日构建"，这确实是是一种不错的方法，即每天要进行一次系统的编译链接，通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。
实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展。
5 分类管理原则
对于不同的软件项目其项目目标差别很大，项目规模也是不同的，应用领域是不同的，采用的技术路线差别也很大，因而，针对每个项目的不同特点，其管理的方法、管理的侧重点应该是不同的。就像古人讲的，"因材施教"，"对症下药"。对于小项目你肯定不能象管理大项目那样去做，对于产品开发类的项目，你也不可能象管理系统集成类的项目那样去做，项目经理需要根据项目的特点，制订不同的项目管理的方针政策。如，下表是作者为一家应用软件公司制订的项目管理的方针：
在该案例中，将项目分成了订单类项目与非订单类项目，非订单类项目是指由公司根据市场的需求开发一个标准产品的项目，而订单类是指针对某个具体的客户定制软件的项目，订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类，非订单类根据估算的工作量的大小也分成了A、B、C三类，估算的工作量超过720人天的为A类，超过360人天的为B类，360人天以下的为C类。不同类的项目管理的侧重点是不同的，从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑，以确保管理的可行性。
6 简单有效原则
项目经理在进行项目管理的过程中，往往会得到开发人员这样的抱怨"太麻烦了，浪费时间，没有用处"，这是很普遍的一种现象。当然这样的抱怨要从2个方面来分析，一方面从开发人员本身可能存在不理解，或者逆反心理的情况，另一方面，项目经理也要反思：我所采取的管理措施是否简单有效？搞管理不是搞学术研究，没有完美的管理，只有有效的管理，而项目经理往往试图堵住所有的漏洞，解决所有的问题，恰恰是这种理想，会使项目的管理陷入一个误区，作茧自缚，最后无法实施有效的管理，导致项目的失败。
7 规模控制原则
该原则是和上面提到的其他原则相配合使用的，即要控制项目组的规模，不要人数太多，人数多了，进行沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了。在微软的MSF中，有一个很明确的原则就是要控制项目组的人数不要超过10人，当然这不是绝对的，也和项目经理的水平有很大关系。但是人员"贵精而不贵多"，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。
