項目成果論文范文

前言：我們精心挑選了數篇優質項目成果論文文章，供您閱讀參考。期待這些文章能為您帶來啟發，助您在寫作的道路上更上一層樓。

第1篇

1.作人的姿態

作人似乎跟商務談判不太有關系，很多技術人員相信PM需要的是本事，是如何做好一個項目，而不是會搞好關系弄的四平八穩的人。隨著PM在中國的悄悄興起，越來越多的

的PM開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要PM們去揣摩客戶的心理。揣摩客戶心理需要有多方面的知識，需要深度和廣度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿態，對從技術人員轉型的PM們來說，是至關重要的。

降低作人的姿態需要從多個方面去實施，最主要應該記住：人不可貌相，更不可以地位衡量。很多公司為了保持公司形象，會統一叫員工打扮的好看一點，看起來象個白領的樣子。然而，老板多半是沒有約束的。中國改革開放才二十年，很多有錢的老板實業家文化層次都不高，往往是當大學生們只會把屁股坐在板凳上肆意揮霍父母辛苦積攢的財富時，他們已經在各地奔波，積累豐富的商業經驗并對金錢，人生和社會的本質有了充分的認識，形成了自己穩定的思維框架。這些人，很多都是穿著舊舊的衣服，戴著破破的手表，說話的時候經常會帶上三字經，鉆進上海的人堆里，搞不好你會把他當成民工。因為到他們所處的社會地位，已經不需要任何華麗的外表來襯托自己的身份，他們有的是底氣。對PM來說，這是個非常危險的挑戰。雖然說項目在初期有意向時會對對方的人事和關鍵人物有一定的了解，然而大項目里能說的上話的人太多了。上海人最瞧不起的就是土氣，很多人談項目的時候看到民工或很俗氣的表現不免會皺皺眉頭，往往在皺眉頭的時候就失去了項目，也就是失去了市場和金錢。PM必須作到能與每一個層次的人交談，尤其是看起來比自己層次要低的群體，哪怕是公司里掃地的阿姨。只有作到謙虛謹慎，不擺架子，尊重別人，才會得到別人的尊重，才有機會贏得項目。鼻子比眼睛高的人只會把自己的鼻子撞扁。

2.豐富的知識面

光尊重別人還不足以贏得項目，準確的說是贏得對方關鍵人物的信賴。PM一般用不著陪客戶喝酒吃飯，那是銷售們的事情，但是PM和客戶討論問題可能是最多的。討論問題的時候就是機會，如何投其所好，是一大關鍵。金錢與美女依然是常規的敲門磚，然而這種傻瓜也知道的辦法人人都會去做。老板的關系也只是一個方面，如今的大老板，哪個沒有關系？同等條件下PM憑什么去勝過別人一籌？

我一個朋友（PM）打一個單子時，發現對方對什么都不太感興趣，費了很大力氣也找不到突破口。對方這個人非常順利，金錢地位美女樣樣不缺。他花了好多天和對方交談，以自己的博學逐漸取得了對方的信任。后來他隱約發現對方對數學和天文學的發展史有所涉獵，如獲至寶，回家花一個通宵的時間在網絡上搜索相關資料。第二天他根本不談項目的事情，只跟對方大談特談哥白尼，布魯諾，伽利略這些人的生平，整整吹了一天。對方點頭如搗蒜泥，態度和熱情都來個一百八十度轉彎，隔天他就拿到了單子。這是個經典的戰例，誰能事先想到哥白尼會來幫助IT的人賺錢？這個PM靠的就是博學和由博學引申出的敏銳的感覺抓住了機會，讓客戶產生共鳴。客戶感覺他層次也很高，而且和自己有共通之處，信任度大大增強，把項目交給他放心。如今這種例子在商務談判中已經屢見不鮮了。對PM來說，并不要求在各個方面都很精通，那是不可能的事情，只要PM對一些流行的話題和天文地理歷史各方面的知識有個大概的了解，在需要的時候能盡快的掌握，才有機會創造機遇和把握機遇。

3.強大的溝通能力

胸中有萬千墨水卻不知如何表達其實是比較少見的，但并非絕對沒有。每個人的人生軌跡都有所不同，思維受環境的影響也各有差異。包括象我們目前這個班級里的一些未來的MSE們，一定有比較內向或者不太愛表達自己觀點的人，這些人比較被動，往往很難承擔起談判的重任。從今天開始，這類人就必須重新學習如何說話，如何大聲的爭論。溝通，并不僅僅是大聲說話，而是在表達自己觀點的同時發現問題并綜合整理加以解決。除此之外，溝通的能力與社會經驗息息相關，與PM的見識聯系緊密。在日常生活中，PM就要多留心，多思考，當別人想到某個層次的時候要爭取比別人考慮的更深。當然，也有一些不夠踏實的朋友把溝通和吹牛當成了完全的一回事情，在和客戶交流的時候口若懸河的說一些不著邊際的話。這種人，碰到不懂，不太認真或者好奇心強的客戶是有一定市場的；而有水平，負責任的客戶往往會覺得這種人不可靠，一般不會把單子交給他。PM需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎的去吹，對從來沒涉及過的領域或者根本不懂的東西輕易不要發表意見，挑選自己熟悉的方向合理的進行發揮，適當的留上一兩手，給對方高深莫測的感覺，效果最好。

4.優秀的售前團隊

這個團隊一般是由總經理發起并組建的，通常不指定PMP，對團隊的成員如SALES，PM，SA，ENGINEER們的團隊合作提出了比較高的要求。一般公司在接下一個單子進行到一定程度的時候，PM往往會尷尬的發現協議上銷售代表們對客戶的一些承諾是幾乎做不到或者根本做不到的事情。這種情況非常多，銷售的任務是拿下單子，我聽到的銷售們說的最多的就是"沒問題"或者"NOPROBLEM"，但是當我聽到客戶的要求和銷售的回答時我總是心驚肉跳，很不自然。銷售是非常辛苦的，為了建立客戶關系，尤其是空白的市場是很不容易的，往往為了一個單子會犧牲非常多。在這種情況下，和銷售進行協調自然而然的又落到了PM的頭上。在銷售和客戶做承諾之前，PM要主動的跟銷售交流，提供粗略的總體設計框架和技術難關以及能考慮出的工作量，而不是等出了問題再被動和銷售在老板面前互相推委責任。在組建團隊的時候，PM要根據團隊里每個人的素質和任務進行因人置宜的信息傳遞。優秀的售前團隊合作是接單的重要保障。

在商務談判的實際操作中，存在著各式各樣的問題，PM的職責和要求絕非以上幾點所能描述詳盡。根據環境，政策，人文，關系等各方面的不同情況，PM的不同成長經歷，每個PM最終都會建立自己對商務談判的看法和經驗。但是有一點的職責和要求絕非以上幾點所能描述詳盡。根據環境，政策，人文，關系等各方面的不同情況，PM的不同成長經歷，每個PM最終都會建立自己對商務談判的看法和經驗。但是有一點可以肯定，這是PM成為PM的第一道關，也是最重要的一關。接不到單子，PM將失去去存在的意義。與銷售有所不同，PM在該階段的任務除了接單，還要盡可能的搜集客戶關鍵人物的資料并與對方各個階層的負責人建立良好的客戶關系，以便在項目實施時充分調動資源。

二.啟動階段

1.項目的一些基本概念

項目三要素有多種版本，各不相同。實際操作中多分為范圍，成本與進度，其中最重要的莫過于范圍。我們把項目最終生成并提交給用戶的產品和文檔統稱為遞交件。談判的時候一定要確立遞交件的標準和要求，也就是范圍。盡管商戰的時候不可避免的客戶會不斷提高標準和要求，而承諾的款項卻不會有一分錢的增加。但是這個標準對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。除非是為了二期有利可圖或者是為了搞好關系，否則范圍超過底線的時候情愿不做，再厲害的PM在這種情況下也是無能為力。建立范圍需要的就是PM的多年的實戰經驗，在大大小小的項目中用血淚換來的一些體會。在這個時候，很能體現PM與技術人員的區別。成本就是客戶答應付的款項，與我們的投入成本并不是一回事情。進度就不用多描述了。

項目如何成功？也有一些關鍵的因素。個人的理解也不盡相同，通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優秀的PM和開發團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當的監控和反饋。這里要注意的就是資源和高層的支持。一個上規模的公司總是同時會有很多項目，可是再大規模的公司資源也不足以保證每個項目都能組建最合適的開發隊伍或擁有最好的環境。這時候各個團隊或者部門之間不可避免的會發生資源爭奪戰，摩擦再所難免。這時候對PM的作人再次提出挑戰。除了高層對PM項目的重視程度，如果PM平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。相反，一個不會作人的PM由于人緣差，即使高層強壓別的部門或團隊配合，別人也會能拖就拖，延緩項目的進度和質量。有時候，這種內耗對項目和PM來說是毀滅性的。對客戶的積極反應也比較關鍵。一般來說PM已經被項目里大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情。然而，這個時候，越是困難，越是覺得累，越是要去主動。客戶往往也不是特別的積極，主動與客戶聯系溝通和測試能及早發現問題。從風險控制的角度來說，問題發現的越早，風險越小，損失也就越小。積極的態度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以后接單或者做二期三期會打下良好的基礎。因為在和別的新客戶談判的時候，新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂的上你很費心的十句。

項目具有商業行為的幾個重要特征，有消費源，有參與者，有成功關鍵因素，有財務目標，有風險。

2.啟動階段的主要任務

根據PMI的解釋，接單之后項目自然轉入啟動階段。啟動階段PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進入下一階段的批準。在這個階段，隨著需求分析的深入，PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。

在收集完數據之后，PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征并將其寫入合同文本，同時準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。接下來就是需求分析。由于專業的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。

需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。對一個已經啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶的工作說明書或招標文件及附件上。這種需求一般比較含糊，無法體現客戶真正的需求。前期團隊要根據自己的經驗和客戶溝通并引導客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數據流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說"這個東西不要你們做了"之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

對快速開發和疊代開發來說，需求和實現往往是同步進行，開發速度快是一大優勢。對有相同或類似模式的小項目來說采用快速開發或疊代開發是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場上就只有產品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發模式基本上分需求分析，總體設計，軟件開發，測試等幾個階段，然而究竟應該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。而需求分析和總體設計沒有做好就急忙上馬進行開發的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設計上。基礎夯實了，金字塔就容易造了。

在日本公司打工的程序員們可能都知道，小日本的軟件規范非常厲害，他們花在需求分析和總體設計上的時間通常在40%到50%左右，遠遠超過國內軟件項目的實施，效果也要強的多。他們總體設計的規范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫(if...else)語句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。所以在日本和歐美經常會有程序員是低級工作一說，很多人不明就里，對國內程序員也照搬，對國內的程序員來說是很不公平的。在國內，只會照抄別人代碼，一點都不懂創新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優秀的不斷進取的程序員也很多。由于國內沒有象CMM這樣的軟件規范或者很少，所以這類優秀的程序員不少都是干著系統分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經濟不景氣，東京倒閉了160家軟件公司，這個數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規范和質量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經作到PM或QA或者熱愛CODING的朋友例外。

需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。

詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯。大家對那段歷史有些含糊，很多人認為蘇聯人上了美國的當。其實并不完全如此，蘇聯人的情報機構無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經開始著手NMD系統軟件的需求分析，前后耗資數億美圓，耗時兩年，僅僅是做需求分析，終于發現存在著在當時技術上無法達到的高度，隨后項目被放棄。

3.項目啟動

項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產品和服務向下包廠商下訂單。這個時候的PM會忽然發現有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯系方式等等都要在會議上確立，并做會議記錄。這都是些非常瑣碎的事情，聽起來婆婆***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

這時候，作為公司高層，應該向全公司發表申明，正式給PM項目經理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責任感是有很大助力的。

三.計劃階段

1.定義結構分工結構圖（WBS）

啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說，WBS是計劃階段的核心。WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。WBS有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節或者工具使用不做詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深，WBS樹也就越深。由于WBS是實用性的東西，根據個人理解也不一樣，所以一個項目可能會有幾個正確的WBS，看PM的需要和最適合當前團隊狀態的進行選擇。

WBS的定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風暴式（BRAININGSTORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。在頭腦風暴式思考時，會有很激烈的爭論，PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進度越快。

2.風險管理

既然是商業行為，那么項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什么樣的風險，能避免盡量避免，所以有必要對風險進行管理。由于風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。

首先要識別風險。這是個難度很高的活。PM要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經驗的人都將參加。然后審核由項目小組生成的風險清單并與重要成員進行風險溝通，檢查一些重要的風險源如WBS，成本（時間）預估，人員計劃，采購管理等等。最后就要用到PM本身在以前類似項目中得到的經驗教訓。

識別之后要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。高和中，中和中的搭配都是屬于高風險，中和低，低和低搭配屬于低，高和低搭配屬于中。

針對出現的可能性，需要采取一些手段降低風險。到目前為止也沒有一個定論說有絕對好的方式，只能盡其所能的避免。有幾種方法可以考慮，第一種是將風險納入項目管理計劃并指定負責人，由外部人員定期檢查項目風險，一旦風險發生，執行風險管理計劃；第二種是保險，這種屬于風險轉嫁；第三種方式有點，不過最保險，就是把客戶拖下水，讓他們一起參與風險管理，呵呵，到時候就好說話了：）

風險管理作為項目計劃之后，PM需要更新WBS，修改日程計劃和更新風險管理計劃。

2.啟動階段的主要任務

根據PMI的解釋，接單之后項目自然轉入啟動階段。啟動階段PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進入下一階段的批準。在這個階段，隨著需求分析的深入，PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。

在收集完數據之后，PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征并將其寫入合同文本，同時準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。接下來就是需求分析。由于專業的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。

需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。對一個已經啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶的工作說明書或招標文件及附件上。這種需求一般比較含糊，無法體現客戶真正的需求。前期團隊要根據自己的經驗和客戶溝通并引導客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數據流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說"這個東西不要你們做了"之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

對快速開發和疊代開發來說，需求和實現往往是同步進行，開發速度快是一大優勢。對有相同或類似模式的小項目來說采用快速開發或疊代開發是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場上就只有產品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發模式基本上分需求分析，總體設計，軟件開發，測試等幾個階段，然而究竟應該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。而需求分析和總體設計沒有做好就急忙上馬進行開發的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設計上。基礎夯實了，金字塔就容易造了。

在日本公司打工的程序員們可能都知道，小日本的軟件規范非常厲害，他們花在需求分析和總體設計上的時間通常在40%到50%左右，遠遠超過國內軟件項目的實施，效果也要強的多。他們總體設計的規范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫(if...else)語句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。所以在日本和歐美經常會有程序員是低級工作一說，很多人不明就里，對國內程序員也照搬，對國內的程序員來說是很不公平的。在國內，只會照抄別人代碼，一點都不懂創新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優秀的不斷進取的程序員也很多。由于國內沒有象CMM這樣的軟件規范或者很少，所以這類優秀的程序員不少都是干著系統分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經濟不景氣，東京倒閉了160家軟件公司，這個數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規范和質量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經作到PM或QA或者熱愛CODING的朋友例外。

需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。

詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯。大家對那段歷史有些含糊，很多人認為蘇聯人上了美國的當。其實并不完全如此，蘇聯人的情報機構無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經開始著手NMD系統軟件的需求分析，前后耗資數億美圓，耗時兩年，僅僅是做需求分析，終于發現存在著在當時技術上無法達到的高度，隨后項目被放棄。

3.項目啟動

項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產品和服務向下包廠商下訂單。這個時候的PM會忽然發現有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯系方式等等都要在會議上確立，并做會議記錄。這都是些非常瑣碎的事情，聽起來婆婆***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

這時候，作為公司高層，應該向全公司發表申明，正式給PM項目經理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責任感是有很大助力的。

三.計劃階段

1.定義結構分工結構圖（WBS）

啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說，WBS是計劃階段的核心。WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。WBS有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節或者工具使用不做詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深，WBS樹也就越深。由于WBS是實用性的東西，根據個人理解也不一樣，所以一個項目可能會有幾個正確的WBS，看PM的需要和最適合當前團隊狀態的進行選擇。

WBS的定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風暴式（BRAININGSTORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。在頭腦風暴式思考時，會有很激烈的爭論，PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進度越快。

2.風險管理

既然是商業行為，那么項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什么樣的風險，能避免盡量避免，所以有必要對風險進行管理。由于風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。

首先要識別風險。這是個難度很高的活。PM要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經驗的人都將參加。然后審核由項目小組生成的風險清單并與重要成員進行風險溝通，檢查一些重要的風險源如WBS，成本（時間）預估，人員計劃，采購管理等等。最后就要用到PM本身在以前類似項目中得到的經驗教訓。

識別之后要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。高和中，中和中的搭配都是屬于高風險，中和低，低和低搭配屬于低，高和低搭配屬于中。

第2篇

國際避稅的前提是熟悉東道主國家相關稅收制度或者《稅收法》，因為稅法是一個國家控制企業經濟活動的主要法律手段。國際工程稅收籌劃的基本步驟是：

1.預先安排

工程項目中標之后就要開始進行商務談判和合同簽訂，這是控制稅收的關鍵步驟，作為承建方的東道主國家從主觀上是重視國際工程項目的，預先安排工作是決定規避稅收程度的前提，因此，在商務談判中，往往會根據我國特殊情況或者不適應的稅收制度進行例外規定，我國應該抓住這些優勢，鋪墊更多有利于后期規避稅費的條件。比如爭取每一個單項項目的稅收減免，有時候東道主國家為了促成該工程項目會提出很多關稅優惠政策，這也是我國企業要努力的重點，這些正好彌補了我國施工企業利潤低下的弱點。預先安排可以說是規避稅費的前提條件，也是關乎稅費能夠避免多少的關鍵步驟。

2.進程控制

國際工程項目比較大，工期比較長，實施過程中又會涉及到多個國家的材料采購、工作人員等等，設計、施工和預制都比較復雜，每一步都有可能影響到稅負的繳納，在這個過程中，需要對稅收成本收益進行充分的分析，這是進行決策前必備的工序，這些都屬于進展過程中的控制手段。比如，對于企業中的設備是自己采購還是進行租賃，這些都需要企業進行相關的關稅、增值稅費、利潤稅等多種費用進行綜合分析，最后選取最優的結構。此外，還有人工費，一定要對該國的人工成本加以考量。既然是國際工程項目，就一定要充分的利用當地人工、材料、施工等優勢來降低稅費。

3.索賠工作中稅收安排

在國際工程項目中還有一項稅費不可忽視，就是索賠稅費，因此對于該項內容也要給予足夠的重視。當今，國際項目競爭激烈，工程造價又比較透明，導致了利潤率也比較低，因此在工程進展過程當中，必須考慮到附加工程或者項目所帶來的影響，對其及時采取優惠政策，比如，將臨時進口關稅采購的機器轉換為永久進口型的，這樣就可以減免一定的關稅。

二、國內部分的稅收籌劃及管理

1.增值稅方面籌劃及管理

眾所周知，增值稅是每個國家稅種中比較重要的一種，因此各國對于增值稅的征稅范圍都比較明確———貨物和提供的服務兩個方面。比如，我國對外承包項目，其中那些對外工程所用的設備、機械或者生活物資，甚至是不再運回境內的工具按照現行稅收法律政策是能夠免稅或者享有退稅等優惠政策的。因為在貨物購買后，出口之前，已經在采購價格當中包含了增值稅，因此國家對于出口產品進行免稅或者退稅的做法是合理的。此外，對外承包工程的企業有時候會向國內某些公司進行業務的分包，分包施工企業為了項目的實施需要采購出口的物資，比如水泥、安裝材料或者是一些消耗性的建材，這些材料在采購時是可以享受退稅或者免稅政策的，雖然這些分包公司沒有對外出口的權力，也不會直接承擔國外工程的施工，但是卻可以借助對外承包工程企業的名義進行退稅，或者申請對外工程承包企業為其進行退稅，但是退稅的工序比較復雜，要求的條件和需要協調的部門也很多，因此本文還是建議這些分包公司自己進行退稅，該公司在進行退稅的時候可以適當的減少分包合同中的標額，這樣就可以減少一定的營業稅和城建稅，最終達到節省對外承包工程項目承包中的成本。

2.營業稅方面籌劃及管理

按照《營業稅暫行條例》的規定，對外承包工程的企業因為承包工程項目的實施并不在國內，因此無需繳納國內營業稅，這是根據使用地來確定的，但是比較大型的國際工程項目在完成的過程中一般無法自身獨立完成，會對某些工程進行分包，比如設計、土建、安裝、調試、培訓等方面都是可以進行分包的，因此，一旦這些業務分包給國內或者國外分包，由于國內企業不能直接承包對外承包過的工程項目，因此該企業仍然需要繳納一定的營業稅和城建稅或者是教育附加費，但是分包公司畢竟承擔的是對外承包工程中國內的一部分業務，因此沒有責任承擔合同全額應該繳納的營業稅，所以對外工程承包企業在與國內分包企業簽訂分包合同時，應詳細劃分分包合同中國內與國外部分的工作及其價格。分包企業應僅就國內工作的價款部分，開具營業性發票給對外承包企業用于賬務處理，而國外工作的價款部分，開具結算單用于賬務處理。這樣做的結果是降低了分包合同的價格，從而節約了對外工程承包項目的成本。

三、國外部分的稅收籌劃和工程管理

1.關稅的稅收籌劃與管理

我國的對外承包企業一般會將目標定位于發展中國家，因為這些發展中國家的關稅政策有著很多相似的地方。想要做好關稅的有關籌劃與管理要做到以下幾點：第一，考察我國與工程實施所在國是否存在相關的關稅協定，如果我國工程設備或者貨物是由第三方采購而來，那么就要考慮該國與工程實施所在國是否存在關稅相關協定；第二，考慮工程實施所在國的海關是否能接納關稅保函，也就是利用保險公司給開出的保單來代替所得稅的繳納，這樣的話就可以在實施工程的時候臨時借用工程所在國的設備或者機械，等工程結束之后進行歸還，這樣就可以免繳部分關稅。第三，考慮到不同的商品運用不同方式，不同語言進行報關稅率不同的問題，比如國外工程運用外文進行描述就能獲得較低的稅率。本文建議，在談判合同時，最好讓業主承擔關稅，他們作為當地業主在關稅規避方面有很多優勢，往往在做清關和繳納關稅上會事半功倍。

2.企業所得稅的稅收籌劃與管理

我國財政部和國家稅務總局印發的《境外所得計征所得稅暫行辦法（修訂）》（財稅字[1997]116號）規定：對于納稅人由境外所得，不論是否要求匯回，只要處在納稅年度就必須按照條例和相應的實施細則進行計算并上繳所得稅。但是對于海外項目有例外規定，比如一旦對外承包企業在海外實施項目時已經向項目實施所在國繳納了企業所得稅，并且兩國之前還存有免征雙重稅的協定的，在我國繳納所得稅時是可以相互抵扣的，當然抵扣限額應該按照我國稅費算法計算，對于超出限額的不得抵扣，低于限額的部分進行補繳。很多國家對于一些大型的對外承包項目有著特殊的規定，尤其是在企業所得稅方面存在大量的優惠政策。據此，國內企業在承包國外工程的時候應該盡可能地運用各種手段爭取在當地進行企業所得稅的繳納，充分利用好本國特殊優惠政策，比如在當地設立公司的分支，先按照工程所在國的稅法或者政府的規定進行繳稅，其中便會享受減免政策，等到稅務機關批準之后，再按照本國相關減免政策進行抵免。本文以國際工程項目籌劃與管理的概念分析作為基礎，捋清對國際工程項目稅收籌劃時的步驟，通過合理有效的籌劃方式來減少不必要的稅費開支，從而獲取一定金額的籌劃收益。總之，國內企業在承擔對外工程施工工作時不應該再遵循過去那種比較粗糙式的管理方式，應該向著細化、精確、技術性的方向加以研究，在激烈的市場競爭中，通過有效的管理方式來確保對外承包工程項目的順利實施，利用好國家給予的優惠政策，最終增強企業在對外承包項目時的競爭力，促進我國對外承包項目的長期發展。

四、結語

第3篇

論文摘要:國際工程項目是指國際工程領域中的項目,也稱國際領域中的工程項目。文章以工程項目組織結構模式為對象,探討了各類工程項目組織結構模式的特點,提出了項目組織形式選擇的基本要求。

國際工程項目是指國際工程領域中的項目,也可以說是國際領域中的工程項目。工程項目組織(ProjectOrganization)是指在工程項目管理人員中的職位結構設置及設置結果。工程項目組織的目的是按任務或職位制定好一套合適的職位結構,以使項目人員能為實現項目目標而有效的工作。工程項目組織的結構模式是指在項目上級組織的影響下,項目與上級組織以及項目內部的聯系方式。由于項目組織是在上級組織內形成,而上級組織通常是一種常規組織,所以項目組織與常規組織既不同又有聯系。按照這一思想,在項目管理組織中,形成了幾種項目組織的結構模式:職能化項目組織、項目化項目組織、矩陣化項目組織和混合組織。

一、工程項目組織結構模式

(一)職能化項目組織

與常規組織聯系最密切的就是職能化項目組織(FunctionalOrganization)。這種模式為了給項目安個“家”,把項目放到常規組織的一個職能部門去,使項目組織成為常規組織的一部分。在職能化項目組織中,人員利用上有最大的彈性及適應性。部門作為項目相關專業技術專家的基本管理基礎,專家可被臨時安排到項目中,完成所需要的工作后被立即安排回他們的常規工作;部門中的專家也可以被組織起來共享知識和經驗,個別專家還可以被不同的項目利用。因此,職能部門在個別人離開項目甚至上級組織時,仍可保持技術上的延續性。

在這種模式下,客戶、委托人不是活動和關心的焦點。職能部門有自己的常規工作要做,這些工作通常是優先于項目考慮的,因此客戶常被忽視。有時在職能化項目組織中,沒有一個人對項目負全面責任。這種不明確責任的失誤通常意味著項目經理只對項目的一部分負責,而其他人卻對項目的另一部分甚至更多的部分負責。不難想象,這必然會導致缺乏協調和扯皮,進而造成對客戶的需要反映既慢又困難。這種模式不利于促進形成項目的系統管理方法。

(二)項目化項目組織

項目化項目組織(ProjectizedOrganization)也可稱為純項目組織,在項目上與上級組織聯系方面,是另一個極端。在這種模式下,項目與上級組織的其他部分分離,成為一個自給自足的單位,它有自己的技術人員、自己的管理、由定期的成果進展報告和工作監督而保持著與上級組織的微弱關系。

在項目化項目組織模式下,項目經理在整個項目上有足夠的管理權,項目經理是真正的項目領導,項目班子所有成員都只對項目經理負責,在做出技術決策前不用請示任何職能部門負責人。當項目與職能部門分開時,項目經理繞過了整個智能結構直接與公司高級組管溝通,溝通線路縮短了,使得溝通更迅速。同時,由于權力集中,做出快速決策的能力極大增強,整個項目組織也就可以對客戶的需要和上級的要求做出快速反應。當存在若干個連續的類似項目時,項目化項目組織就可以穩定地擁有或多或少能開發出特定技術的一批骨干專家,從其成員當中開發出高水平的完成任務的能力。項目化項目組織結構簡單而且靈活,理解和實現相對容易。這種形式易于形成對項目的系統管理方法。

然而,當上級組織同時進行幾個項目時,要滿足每個項目的人員配備需要。這會導致從行政部門人員到高級技術人員的重復配置。為確保技術知識和專門技術使用權的需要,導致了項目經理儲存設備和技術以便當需要時就能得到,因而一些掌握關鍵技術的人是在可得時而不是在需要時就被項目占有了。把項目從職能部門的技術控制下解放出來,有利也有弊,尤其是項目帶有“高技術”的特征時更是如此。雖然參加項目的技術人員對項目技術問題有一定的研究深度,但仍然還是落后于其專業中的其他一些人。在項目化項目組織中,項目采取自己的生活方式,常發生項目間的對抗及痛苦的爭斗。

(三)矩陣化項目組織

為了能將項目化項目組織的優點與職能化項目組織有利的方面結合起來,同時也避免其各自的缺點,人們發現了矩陣組織(TheMatrixOrganization)。在效果上,職能化和項目化項目組織代表兩個極端,矩陣組織則是二則的結合,它是覆蓋于上級組織的職能部門之上的項目組織。由于是由項目化項目組織和職能化項目組織結合而成,根據兩個極端中哪個的作用強,矩陣組織又分為強矩陣組織(Strong

Matrix)和弱矩陣組織(WeakMatrix)兩種形式。

在矩陣化項目組織中,項目是強調的重點,項目經理個人負責管理項目,使項目按期、在規定費用以內達到預定要求。在這點上矩陣組織與項目化項目組織是相同的。由于項目組織是覆蓋在職能部門之上的,從中臨時抽調人力資源,項目對職能部門的技術專利庫有了合理的使用權。當有多個項目時,所有項目都可能得到職能部門的專利,因而極大地減少了項目化項目組織的重復配置。矩陣組織對上級組織內部的各種要求反應也是既快又靈活。在矩陣管理中,項目有上級組織各行政管理單位的代表并有對他們的使用權。其結果是使項目保持了在政策、實踐和程序上與上級組織的一致性。當同時進行幾個項目時,矩陣組織可以實現較好的資源綜合平衡,進而實現每個項目不同的時間、費用、性能目標。這種整體優化方法可使得所有項目人員配備得當,進度安排合理,從而優化整個系統而不是犧牲其他項目而實現一個項目的目標。在職能項目組織中,毫無疑問職能部門是決策的核心,在項目化項目組織中,顯然項目經理是項目權利中心。到了矩陣組織,權利則要更多地在二者之間平衡,通常這種平衡相當細致。但若果對誰負責的問題出現疑問時,項目工作就會受阻。

在多個項目間優化項目目標的能力是矩陣組織的一個優點,但這種能力也有反面。多個項目必須當成一個整體慎重監控,而這是一項艱難的工作。為滿足多個項目的進度而在項目之間調動資源可能引發項目經理間的明爭暗斗,這些項目經理都總是考慮確保自己的項目的成功而不顧組織整體的優化。在使用矩陣組織的項目上,傳統做法是項目經理負責管理決策,職能部門領導負責技術決策,但這種分工在實踐中是很復雜的,沒有談判能力強的項目經理就不能保證項目成功。

矩陣管理破壞了命令統一的管理原則,項目人員至少有兩個上級,他們是職能經理和項目經理。它使人員無法忠實于雙向領導,也無法應付可能的混亂局面。任何在這種體制下工作的人都會體會到它的難處,沒使用過這種方式是體會不到這一點的。

(四)混合組織系統

純職能和純項目組織在一個公司里可以同時存在,這就產生了混合形式(MixedOrganizationalSystems)。這種形式通常是將一些大的、長期良好運行的項目分離出一些附屬項目或獨立的活動。許多公司在已有的職能部門中先培育一些還未穩定的小項目,然后讓它們“斷奶”,形成有自己獨立身份的純項目,最終形成“攻關隊”,大項目還可以成立“攻關實體”。混合型式的雜交帶來了靈活性,它使公司能通過適當的組織結構設置,滿足解決各類特定問題的需要。然而,由于利益和興趣都不同,這種雜交中也有明顯的危險,相同責任的不同組合會鼓勵重疊、重復和虛構。

二、項目組織結構模式的選擇

(一)影響選擇項目結構模式的因素

選擇組織形式不是一件易事,要依據項目的特點和公司的資源來選擇。有的只是少量的設計原則,不會告訴你確切需要哪一種形式,也沒有建立組織的詳細指南。能做的就是考慮未來項目的性質、各種組織形式的特征、各自的優點和缺點,最后拿出折中的方案。在下表中列出了12項反映項目性質、特征的因素,它們基本上從各個方面描述了項目的情況,每種特性的評價分為三個等級或種類,各等級或種類對應著與其適應的三種項目組織形式之一。

(二)選擇項目組織結構模式的基本要求

1.總的來說,職能化組織常用于需較深技術運用的項目,而不是以降低成本、滿足特殊的進度、實現對變化的快速反應為主的項目。

2.如果公司要管理數量較多的類似項目(如建設項目),項目化項目組織更適合。同時還可用于一次性較強、較獨特且需要慎重控制而且不適于單一職能部門完成的任務,例如新產品生產工藝的開發。