帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――"所有员工的思想觉悟异常崇高"。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。

　　七、时间分配原则

　　在项目计划编制过程中，我们常常将资源可用率(人、设备)等设置为，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓8小时工时制实际上是徒有虚名。由于项目管理人员的"无知 "，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80%已经时很不错的了，我个人 比较倾向于60%左右(黄金分割点)。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划(该计划没有考虑到资源可用率)的4/3- 5/3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实是这么严酷。这很大范围内"归功于项目管理人员。是的，我们的确 没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。转自项目管理者联盟

　　八、变化原则

　　也许有人问过你，在项目管理中不变的东西是什么?我可以告诉你，项目中不变的是"变化"。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为 项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但预防胜于治疗"。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。

　　九、作业标准原则项目管理者联盟文章

　　一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以"作坊式"为主，高举"我们符合国际CMM X规范(ISO某某规范)"的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因， 在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗?不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范 性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你不会是的这副狼狈相。

　　十、复用和组织变革原则-解决项目问题的未来之路

　　如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速的进入项目问题定义之中，减少项目开发人员的工作量，从而尽可能 的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革(Moc)，精简项目管理机构、重新定义工作职责，制定柔性的项目工作流程，改善项目开发人员的沟通状况，提高项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。

　　结论

　　作为一个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知识和技巧，还必须深入学习项目管理(建议参看PMI《PMBOK》)、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的项目管理人员看自己个人简历时方不会觉得脸红，才能 在公司中树立自己的管理权威性，同样也才会有一个良好的职业经理生涯的开端。