一.平衡原則
在我們討論軟件項(xiàng)目為什么會失敗時可以列出很多的原因，如 管理問題、技術(shù)問題、人員問題等，但是有一個根本的思想問題是 更容易忽視的，也是軟件系統(tǒng)的用戶、軟件開發(fā)商、銷售代理商更 不想正視的，那就是：需求、資源、工期、質(zhì)量這四個要素之間的 平衡關(guān)系問題。結(jié)合實(shí)際，我們可以通俗地理解這四者之間彼此的聯(lián)系，需求的增多，必然會帶來資源消耗的增多和工期的延長；而用戶的需求又與工期密切關(guān)聯(lián)，用戶不希望工程交付過晚；相對而言，追求更高的質(zhì)量，需要我們投入更多的人力物力資源，甚至更長的工期；同樣，一個高質(zhì)量的產(chǎn)品，也不是盲目得趕工期，多投入就可以完成的。這就要求我們在實(shí)際中考慮平衡需求，資源，工期，質(zhì)量并得到各方面均衡的一個更優(yōu)解。在軟件項(xiàng)目中我們不僅僅是關(guān)注項(xiàng)目的進(jìn)度，質(zhì)量，范圍和成本四要素的平衡。還需要關(guān)注人員角色分工的平衡，冒險和保守的平衡，外部和內(nèi)部的平衡，紀(jì)律和靈活性間的平衡等等。任何一個方面失去平衡，項(xiàng)目都可能處于危險中。

二.卓效原則
記得看過一篇facebook創(chuàng)始人扎克伯格回憶自己創(chuàng)業(yè)之初的故事，有一句話讓我印象深刻，“真實(shí)決定人生高度的，是你做事的速度”。當(dāng)初，心血來潮的扎克伯格從產(chǎn)生想法，到實(shí)現(xiàn)一款簡單的應(yīng)用--大頭照對比評分應(yīng)用FaceMash，僅用了6個小時。在短短的時間內(nèi)，他獨(dú)自一人完成了產(chǎn)品的設(shè)計，開發(fā)，上線....這在當(dāng)時可能是一個小型企業(yè)兩天的日常工作量。而他的對頭，在哈弗就讀的Winklevoss兄弟，總說扎克伯格抄襲了他們的創(chuàng)意，才有了后來的facebook，而事實(shí)呢？在Winklevoss兄弟在猶豫是否要投入做社交網(wǎng)站時，扎克伯格的facebook已經(jīng)覆蓋了29所學(xué)校，7.5萬注冊用戶。促成他們以后差距的，正是二者執(zhí)行力的差距。也只有像這樣在短時間內(nèi)完成高質(zhì)量的任務(wù)才能稱之為卓效。

三.優(yōu)先原則
在軟件工程中存在這樣的PARETO定律：在實(shí)際中企業(yè)80%的問題可以用20%的投資解決，而20%的次要問題則需要花費(fèi)80%的投資的。在軟件項(xiàng)目中，如果出現(xiàn)了過多的需求，通常會導(dǎo)致項(xiàng)目超出預(yù)算和預(yù)定進(jìn)度，更終導(dǎo)致軟件項(xiàng)目的失敗，此時需求的優(yōu)先級可能比需求本身更為重要。仔細(xì)分析一下，這些項(xiàng)目要求分為需要的非需要的，因此我們建議是壓縮非需要的部分或是暫時將其放在一邊不必太重視。軟件項(xiàng)目開發(fā)事實(shí)告訴我們，開發(fā)人員在非需要的項(xiàng)目要求上耗費(fèi)了太多的精力，用戶的需求變更的大部分出現(xiàn)在"更好有"這一部分，實(shí)際上用戶并不看重這些需求（即使去除這些需求），而我們所做的，往往是舍本求末。
在實(shí)際情況中，軟件開發(fā)負(fù)責(zé)人員往往會面臨需求方提出的一系列繁復(fù)的需求，在實(shí)施過程中一定要將需求劃分為不同的優(yōu)先級，建立項(xiàng)目開發(fā)的需求優(yōu)先級隊(duì)列，對于一個管理良好的軟件工程必不可少。反之，盲目追求對細(xì)枝末節(jié)的全覆蓋，反而會很大拖慢工期進(jìn)度，甚至影響產(chǎn)品質(zhì)量。

四.分解原則
“分而治之”是計算機(jī)領(lǐng)域的一個重要思想，對于軟件項(xiàng)目來講，可以將大的項(xiàng)目劃分成幾個小項(xiàng)目來做，將周期長的項(xiàng)目化分成幾個明確的階段。在需求管理中首先要進(jìn)行分類管理，將軟件需求分出層次，不同層次需求的側(cè)要點(diǎn)、描述方式和管理方式是不同的。對于管理層而言，提出的需求可能會更加偏向于全局性的目標(biāo)需求，對于底層實(shí)現(xiàn)和分工并不關(guān)心；而中層需要將具體的操作，代碼分配給不同部分，人員進(jìn)行實(shí)現(xiàn)，同時需要考慮各部分之間的相互銜接。項(xiàng)目越大對項(xiàng)目組的管理人員、開發(fā)人員的要求越高，參與的人員越多，需要協(xié)調(diào)溝通的渠道越多，周期越長，開發(fā)人員也容易疲勞，將大項(xiàng)目拆分成幾個小項(xiàng)目，可以降低對項(xiàng)目管理人員的要求，減少項(xiàng)目的管理風(fēng)險，而且能夠充分地將項(xiàng)目管理的權(quán)力下放，充分調(diào)動人員的積極性，目標(biāo)會比較具體明確，易于取得階段性的成果，使開發(fā)人員有成就感。

五.風(fēng)險原則
某家知名軟件公司曾總結(jié)出排行前幾的為軟件管理埋下風(fēng)險的罪魁禍?zhǔn)?，分別是：
1.人為缺陷；2.不切實(shí)際的時間表和預(yù)算；3.開發(fā)錯誤的功能和屬性；4.開發(fā)錯誤的用戶交互；5.畫蛇添足；6.持續(xù)的需求更改.....
軟件項(xiàng)目管理的過程中，唯一不變的就是"變化"。風(fēng)險管理也是始終貫穿于軟件項(xiàng)目管理之中的重要元素，在項(xiàng)目中不考慮可能發(fā)生的變化是不可思議的。不過在面對項(xiàng)目可能發(fā)生變化而帶來的項(xiàng)目風(fēng)險時，項(xiàng)目管理人員往往會懷有逃避的態(tài)度。經(jīng)濟(jì)學(xué)里大名鼎鼎的風(fēng)險規(guī)避原則便是項(xiàng)目管理人員心理的有效描述。作為項(xiàng)目管理人員來說，應(yīng)該及早預(yù)測可能出現(xiàn)的風(fēng)險，做好風(fēng)險儲備。雖然風(fēng)險儲備不能解決所有的問題，但預(yù)防勝于治療"。通過學(xué)習(xí)項(xiàng)目管理知識掌握風(fēng)險識別、量化、對策研究、反應(yīng)控制的工具和方法，掌握項(xiàng)目風(fēng)險管理所必備的知識。通過加強(qiáng)對項(xiàng)目規(guī)劃中風(fēng)險管理計劃的審核提高項(xiàng)目組的風(fēng)險管理意識。