軟考：系統整合專案管理工程師(中級)案例、計算、默寫題總結

可研立項

1。1。

可行性研究報告的內容

1。2。

專案內部立項主要有幾方面原因

整體管理

2。1。

專案章程內容

2。2。

專案章程作用

2。3。

變更的流程

2。4。

變更的角色

& 職責 7

範圍管理

3。1。

範圍說明書內容

3。2。 WBS分解步驟 8

3。3。 WBS分解原則 8

3。4。 WBS 結構分為樹型和列表型 8

進度管理

4。1。

縮短工期的辦法

4。2。

進度壓縮

4。3。

資源平衡和資源平滑區別

4。4。

依賴關係

成本管理

（1）將專案總成本分攤到專案工作分解結構的各個工作包。 9

（2）將各個工作包成本再分配到該工作包所包含的各項活動上。 9

（3）確定各項成本預算支出的時間計劃及專案成本預算計劃。 9

質量管理

6。1。

質量成本

6。2。

質量審計

6。3。

質量工具和技術

人力資源管理

7。1。

好團隊

5個階段 12

7。2。 X，Y理論 12

7。3。

虛擬團隊優缺點

7。4。

衝突的解決辦法

7。5。

溝通方式

7。6。

權力利益方格

7。7。

干係人參與評估矩陣

採購管理

風險管理

9。1。 3法 14

9。2。

風險圖解技術可包括

： 14

9。3。

風險管理計劃

9。4。

風險識別原則

10.

合同管理

10。1。

條款

10。2。

過程

10。3。

索賠流程

10。4。

合同分類

11.

配置管理

11。1。

過程

11。2。 3個庫 16

11。3。

版本號

11。4。

配置審計

12.

計算題

12。1。

溝通渠道的總量

12。2。 EMV 17

12。3。

加權系統

12。4。

進度

12。5。

掙值分析、預測技術

12。6。

投資回收期

12。7。

歸一化評估結果

13.

案例萬金油簡版

14.

案例萬金油詳版

14。1。

可研過程中可能出現的問題

14。2。

整體管理可能的問題

14。3。

軟體專案失控的可能問題

3。1。技術無法擴充套件 20

3。2。技術是錯誤的解決方案 20

3。3。技術不具有要求的功能性等。 20

7。1。開發商與客戶的關係 20

7。2。銷售人員與技術人員的關係 20

7。3。專案管理者與開發人員的關係等。 20

14。4。

範圍管理可能問題

& 措施 20

14。5。

需求變更的可能問題

14。6。

進度管理可能問題

14。7。

成本管理可能問題

14。8。

專案質量管理可能問題

14。9。

應該怎麼解決或提高專案質量

14。10。

人力資源可能問題

14。11。

團隊組建常見問題

14。12。

溝通管理和干係人管理可能問題

14。13。

風險管理可能問題

14。14。

管配置管理問題

14。15。

變更中常見的問題

14。16。

合同管理裡可能會出現的問題

14。17。

可能的收尾的問題

14。18。

外包

（採購）的害處 27

14。19。

如何做好外包

（採購） 27

1。可研立項

1。1。可行性研究報告的內容

（1）專案概述

（2）專案建設單位概況

（3）需求分析和專案建設的必要性

（4）總體建設方案

（5）本期專案建設方案

（6）專案招標方案

（7）環保、消防、職業安全

（8）專案組織機構和人員培訓

（9）專案實施迸度

（10）投資估算和資金來源

（11）效益與評價指標分析

（12）專案風險與風險管理

1。2。專案內部立項主要有幾方面原因

第一，透過專案立項方式為專案分配資源。

第二，透過專案立項方式確定合理的專案績效目標，有助於提升人員的積極性。

第三，以專案型工作方式，提升專案實施效率。

2。整體管理

2。1。專案章程內容

（1）概括性的專案描述和專案產品描述。

（2）專案目的或批准專案的理由，即為什麼要做這個專案。

（3）專案的總體要求，包括專案的總體範圍和總體質量要求。

（4）可測量的專案目標和相關的成功標準。

（5）專案的主要風險，如專案的主要風險類別。

（6）總體里程碑進度計劃。

（7）總體預算。

（8）專案的審批要求，即在專案的規劃、執行、監控和收尾過程中，應該由誰來做出哪種批准。

（9）委派的專案經理及其職責和職權。

（10）發起人或其他批准專案章程的人員的姓名和職權。

2。2。專案章程作用

（1）確定專案經理，規定專案經理的權力。

（2）正式確認專案的存在，給專案一個合法的地位。

（3）規定專案的總體目標，包括範圍、時間、成本和質量等。

（4）透過敘述啟動專案的理由，把專案與執行組織的日常經營運作及戰略計劃等聯絡起來。

專案管理計劃內容

（1）所使用的專案管理過程。

（2）每個特定專案管理過程的實施程度。

（3）完成這些專案的工具和技術的描述。

（4）選擇的專案的生命週期和相關的專案階段。

（5）如何用選定的過程來管理具體的專案。

（6）如何執行工作來完成專案目標。

（7）如何監督和控制變更。

（8）如何實施配置管理。

（9）如何維護專案績效基線的完整性。

（10）與專案干係人進行溝通的要求和技術。

（11）為專案選擇的生命週期模型。

（12）為了解決某些遺留問題和未定的決策，對於其內容、嚴重程度和緊迫程度進行的關鍵管理評審。

2。3。變更的流程

（1）提出變更申請

（2）變更影響分析專案經理在接到變更申請以後，首先要檢查變更申請中需要填寫的內容是否完備，然後對變更申請進行影響分析。變更影響分析由專案經理負責，專案經理可以自己或指定人員完成，也可以召集相關人員討論完成。

（3）CCB 審查批准

（4）實施變更

（5）監控變更實施

（6）結束變更

2。4。變更的角色 & 職責

專案經理：

專案經理對專案負責，也對整個專案變更管理過程負責。專案經理負責變更申請的影響分析，

負責召開變更控制委員會會議，負責監控變更及已批准變更的正確實施等。

CCB：

變更控制委員會

（CCB）是一個正式的組織，負責審查、評價、批准、推遲或否決專案變更。 CCB 由專案所涉及的多方人員共同組成，通常包括甲方和乙方的決策人員。

3。範圍管理

3。1。範圍說明書內容

（1）專案目標

（2）產品範圍描述

（3）專案需求

（4）專案邊界

（5）專案的可交付成果

（6）專案的制約因素

（7）假設條件

3。2。 WBS分解步驟

（1）識別專案交付物和相關工作

（2）對WBS的結構進行組織

（3）對WBS進行分解

（4）對WBS中各級工作單元分配識別符號或編號

（5）對當前的分解級別進行檢驗，以確保它們是必須的，而且是足夠詳細的。

3。3。 WBS分解原則

（1）在各層次上保持專案的完整性，避免遺漏必要的組成部分。

（2）一個工作單元只能從屬於某個上層單元，避免變叉從屬。

（3）相同層次的工作單元應有相同性質。

（4）工作單元應能分開不同的責任者和不同工作內容。

（5）便於專案管理進行計劃和控制的管理需要。

（6）最低層工作應該具有可比性，是可管理的，可定量檢查的。

（7）應包括專案管理工作（因為管理是專案具體工作的一部分），包括分包出去的工作。

（8） WBS 的最低層次的工作單元是工作包。需要遵守 8/80 原則。

3。4。 WBS 結構分為樹型和列表型

樹型層次清晰，非常直觀，結構性很強，但是不容易修改，

適用於中小型專案。

列表型直觀性差，適用於大型專案。

4。進度管理

4。1。縮短工期的辦法

（1）趕工，投入更多的資源或增加工作時間，以縮短關鍵活動的工期；

（2）快速跟進，並行施工，以縮短關鍵路徑的長度；

（3）使用高素質的資源或經驗更豐富的人員；

（4）減小活動範圍或降低活動要求；——-注意甲方同意

（5）改進方法或技術，以提高生產效率；

（6）加強質量管理，及時發現問題，減少返工，從而縮短工期。

4。2。進度壓縮

（1）趕進度。對費用和進度進行權衡，確定如何在儘量少增加費用的前提下最大限度地縮短專案所需時間。趕進度並非總能產生可行的方案，反而常常增加費用。

（2）快速跟進。這種進度壓縮技術通常同時進行按先後順序的階段或活動。快速跟進往往造成返工，並通常會增加風險。

4。3。資源平衡和資源平滑區別

資源平衡是一種進度網路分析技術，用於已經利用關鍵路線法分析過的進度模型之中。

資源平衡的用途是調整時間安排需要滿足規定交工日期的計劃活動，處理只有在某些時間才能

動用或只能動用有限數量的必要的共用或關鍵資源的局面，或者用於在專案工作具體時間段按

照某種水平均勻地使用選定資源。這種均勻使用資源的辦法可能會改變原來的關鍵路線。

資源平滑對進度模型中的活動進行調整，從而使專案資源需求不超過預定的資源限制的一

種技術。相對於資源平衡而言，資源平滑不會改變專案關鍵路徑，完工日期也不會延遲。資

源平滑技術可能無法實現所有資源的最佳化。

4。4。依賴關係

1）強制性依賴關係：是法律或合同要求的或工作的內在性質決定的依賴關係

2）選擇性依賴關係：有時又稱首選邏輯關係、優先邏輯關係或軟邏輯關係。

3）外部依賴關係：是專案活動與非專案活動之間的依賴關係。這些依賴關係往往不在專案團隊的控制範圍內。例如，軟體專案的測試活動取決於外部硬體的到貨。

4）內部依賴關係：是專案活動之間的緊前關係，通常在專案團隊的控制之中。

5。成本管理

管理

& 應急儲備

應急儲備是是包含在成本基準內的一部分預算，用來應對已經接受的己識別風險，以及已經

制訂應急或減輕措施的已識別風險。應急儲備通常是預算的一部分，用來應對那些會影響專案

的

“已知一未知”風險。

管理儲備是為了管理控制的目的而特別留出的專案預算，用來應對專案範圍中不可預見的工

作。管理儲備用來應對會影響專案的

“未知一未知”風險。管理儲備不包括在成本基準中，但屬於專案總預算和資金需求的一部分，使用前需要得到高層管理者審批。

成本估算

（1）識別並分析成本的構成科目

（2）根據已識別的專案成本構成科目，估算每一科目的成本大小

（3）分析成本估算結果，找出各種可以相互替代的成本，協調各種成本之間的比例關係。

成本預算

（1）將專案總成本分攤到專案工作分解結構的各個工作包。

（2）將各個工作包成本再分配到該工作包所包含的各項活動上。

（3）確定各項成本預算支出的時間計劃及專案成本預算計劃。

6。質量管理

6。1。質量成本

預防成本：是指那些為保證產品符合需求條件，無產品缺陷而付出的成本。如，專案質量計劃、

質量規劃、質量控制計劃、質量審計、設計稽核、過程控制工程、質量度量、測試系統建立

（測試裝置及系統的設計與開發或購置）、質量培訓、供應商評估等都是預防成本。

評估成本：是指為使工作符合要求目標而進行檢查和檢驗評估所付出的成本。如，設計評估、收

貨檢驗、採購檢驗、測試、測試結果的分析彙報等都是評估成本。

缺陷成本：又進一步分為內部的和外部的缺陷成本。

內部缺陷成本是指交貨前彌補產品故障和失

效而發生在公司內的費用。如，產品替換、返工或修理、廢料和廢品、複測、缺陷診斷、內部

故障的糾正等都是內部缺陷成本。

外部缺陷成本是指發生在公司外部的費用，通常是由顧客提

出的要求。如，產品投訴評估、產品保修期投訴、退貨、增加營銷費用來彌補丟失的客戶、廢品召回、產品責任、客戶回訪解決問題等都是外部缺陷成本。

6。2。質量審計

1）識別全部正在實施的良好及最佳實踐；

2）識別全部違規做法、差距及不足；

3）分享所在組織或行業中類似專案的良好實踐；

4）積極、主動地提供協助，以改進過程的執行，從而幫助團隊提高生產效率；

5）強調每次審計都應對組織經驗教訓的積累做出貢獻。

6。3。質量工具和技術

7個老的質量工具（由粗到細，由表面到根本）散點圖、直方圖、帕累託圖、因果圖、以及流程圖、表差表和控制圖

7個新的質量工具：親和圖、過程決策程式圖、關聯圖、樹形圖、優先矩陣、活動網路圖、矩陣圖

老

7個

1）因果圖，又稱魚骨圖或石川馨圖，用來追溯問題來源，回推到可行動的根本原因。透過看問題陳述和問“為什麼” 來發現原因，直到發現可行動的根本原因，或者列盡每根魚骨上的合理可能性。

2）流程圖，也稱過程圖，用來顯示在一個或多個輸入轉化成一個或多個輸出的過程中，所需要的步驟順序和可能分支。

3）核查表，又稱計數表，是用於收集資料的查對清單。

4）帕累託圖，用於識別造成大多數問題的少數重要原因。排列圖也被稱為帕累託圖，是按照發生頻率大小順序繪製的直方圖。表示有多少結果是由已確認型別或範疇的原因所造成的。按等級排序的目的是指導如何採取主要糾正措施。該法則認為：相對來說數量較小的原因往往造成絕大多數的問題或者缺陷。此項法則往往稱為二八原理，即 80%的問題是 20%的原因所造成的。也可使用帕累託圖彙總各種型別的資料，進行二八分析。

5）直方圖，用於描述集中趨勢、分散程度和統計分佈形狀。可反映各變數的分佈。每一欄代表一個問題或情況的一個特徵或屬性。每個欄的高度代表該種特徵或屬性出現的相對頻率。這種工具透過各欄的形狀和寬度來確定問題的根源。

6）控制圖，可以判斷某一過程處於控制之中還是處於失控狀態。它是一種帶控制界限的質量管理圖表。運用控制圖的目的之一就是，透過觀察控制圖上產品質量特性值的分佈狀況，分析和判斷生產過程是否發生了異常。

7）散點圖，可以顯示兩個變數之間是否有關係，一條斜線上的資料點距離越近，兩個變數之間的相關性就越密切。

新

7個

1）親和圖。針對某個問題，產生出可聯成有組織的想法模式的各種創意。在專案管理中，使用親和圖確定範圍分解的結構，有助於 WBS 的制訂。

2）過程決策程式圖（PDPC）。用於理解一個目標與達成此目標的步驟之間的關係。PDPC 有助於制訂應急計劃，因為它能幫助團隊預測那些可能破壞目標實現的中間環節。

3）關聯圖。它是關係圖的變種，有助於在包含相互交叉邏輯關係的中等複雜情形中創新性地解決問題。

4）樹形圖也稱系統圖，可用於表現諸如 WBS、RBS 和 OBS 的層次分解結構。

5）優先矩陣。用來識別關鍵事項和合適的備選方案，並透過一系列決策，排列出備選方案的優先順序。先對標準排序和加權，再應用於所有備選方案，計算出數學得分，對備選方案排序。

6）活動網路圖。進度網路圖

7）矩陣圖。一種質量管理和控制工具，使用矩陣結構對資料進行分析。在行列交叉的位置展示因素、原因和目標之間的關係強弱。

7。人力資源管理

7。1。好團隊5個階段

（1）形成階段：—個個獨立的個體成員轉變為團隊成員，開始形成共同目標，對未來團隊往往有美好的期待。

（2）震盪階段：團隊成員開始執行分配的任務，一般會遇到超出預想的困難，希望被現實打破。個體之間開始爭執，互相指責，並且開始懷疑專案經理的能力。

（3）規範階段：經過一定時間的磨合，團隊成員之間相互熟悉和了解，矛盾基本解決，專案經理能夠得到團隊的認可。

（4）發揮階段：隨著相互之間的配合默契和對專案經理的信任，成員積極工作，努力實現目標。這時集體榮譽感非常強，常將團隊換成第一稱謂，如“我們那個組” “我們部門”等，並會努力捍衛團隊聲譽。

（5）結束階段：隨著專案的結束，團隊也被遣散了。不管目前團隊處於什麼階段，新增加一個人或減少一個人，都是從形成階段重新開始。

馬斯洛理論

馬斯洛的需求層次結構是心理學中的激勵理論，包括人類需求的五級模型，通常被描繪成金字塔內的等級。從層次結構的底部向上，需求分別為：生理（食物和衣服），安全（工作保障），社交需要（友誼），尊重和自我實現。這種五階段模式可分為不足需求和增長需求。前四個級別通常稱為缺陷需求（

D 需求），而最高級別稱為增長需求（B 需求）

7。2。 X，Y理論

1）X 理論主要體現了獨裁型管理者對人性的基本判斷，這種假設認為：

（1）一般人天性好逸惡勞，只要有可能就會逃避工作。

（2）人生來就以自我為中心，漠視組織的要求。

（3）人缺乏進取心，逃避責任，甘願聽從指揮，安於現狀，沒有創造性。

（4）人們通常容易受騙，易受人煽動。

（5）人們天生反對改革。

2）Y 理論對人性的假設與 X 理論完全相反，其主要觀點為：

（1）一般人天生並不是好逸惡勞，他們熱愛工作，從工作得到滿足感和成就感。

（2）外來的控制和處罰對人們實現組織的目標不是一個有效的辦法，下屬能夠自我確定目標，自我指揮和自我控制。

（3）在適當的條件下，人們願意主動承擔責任。

（4）大多數人具有一定的想象力和創造力。

（5）在現代社會中，人們的智慧和潛能只是部分地得到了發揮。

7。3。虛擬團隊優缺點

優點：

1在公司內部建立一個由不同地區員工組成的團隊。

2為專案團隊增加特殊技能的專家，即使這個專家不在本地。

3把在家辦公的員工納入虛擬團隊，以協同工作。

4由不同班組（早班、中班和夜班）員工組成一個虛擬團隊。

5把行動不便或殘疾的員工納入團隊。

6可以實施那些原本因為差旅費用過高而被忽略的專案。

缺點：

虛擬團隊也有一些缺點，例如，可能產生誤解、有孤立感、團隊成員之間難以分享知識和經驗、

採用通訊技術也要花費成本等。

措施：

在建立一個虛擬團隊時，制訂一個可行的溝通計劃就顯得更加重要。

7。4。衝突的解決辦法

（1）問題解決：問題解決就是衝突各方一起積極地定義問題、收集問題的資訊、制定解決方案，最後直到選擇一個最合適的方案來解決衝突，此時為雙贏或多贏。但在這個過程中，需要公開地協商，這是衝突管理中最理想的一種方法。

（2）合作：集合多方的觀點和意見，得出一個多數人接受和承諾的衝突解決方案。

（3）強制：強制就是以犧牲其他各方的觀點為代價，強制採納一方的觀點。

（4）妥協：妥協就是衝突的各方協商並且尋找一種能夠使衝突各方都有一定程度滿意、但衝突各方沒有任何一方完全滿意、是一種都做一些讓步的衝突解決方法。

（5）求同存異：求同存異的方法就是衝突各方都關注他們一致的一面，而淡化不一致的一面。一般求同存異要求保持一種友好的氣氛，但是迴避瞭解決衝突的根源。也就是讓大家都冷靜下來，先把工作做完。

（6）撤退：撤退就是把眼前的或潛在的衝突擱置起來，從衝突中撤退。

溝通和干係人

7。5。溝通方式

參與討論方式、徵詢方式、推銷方式

（說明）、敘述方式

以上四類溝通方式從參與者

（傳送資訊方）的觀點看，參與討論方式的控制力最弱，隨後逐步加強，以敘述方式的控制力最強。從參與者（傳送資訊方）的觀點看，其他參與者的參與程度恰巧相反，也就是討論方式下參與程度最高，然後逐步減弱，以敘述方式下參與程度最弱。在傳送方自認為已經掌握了足夠的資訊，有了自己的想法且不需要進一步聽取多方意見時，往往選擇控制力極強、參與程度最弱的“敘述方式”；其次，選擇“推銷方式”，而當自己掌握信息有限，沒有完整成型的意見，需要更多的聽取意見時，一般選擇“討論方式”或者“徵詢方式”。

7。6。權力利益方格

7。7。干係人參與評估矩陣

8。採購管理

招投標法和採購法相關日期記下，主要考選擇

9。風險管理

9。1。 3法

德爾菲法，也稱專家調查法，其本質上是一種反饋匿名函詢法，其大致流程是在對所要預測的問題徵得專家的意見之後，進行整理、歸納、統計，再匿名反饋給各專家，再次徵求意見，再集中，再反饋，直至得到一致的意見。

頭腦風暴法（

Brain storming），是指由美國BBDO廣告公司的奧斯本首創，該方法主要由價值工程工作小組人員在正常融洽和不受任何限制的氣氛中以會議形式進行討論、座談，打破常規，積極思考，暢所欲言，充分發表看法

所謂

SWOT分析，即基於內外部競爭環境和競爭條件下的態勢分析，就是將與研究物件密切相關的各種主要內部優勢、劣勢和外部的機會和威脅等，透過調查列舉出來，並依照矩陣形式排列，然後用系統分析的思想，把各種因素相互匹配起來加以分析，從中得出一系列相應的結論，而結論通常帶有一定的決策性。

9。2。風險圖解技術可包括：

（1）因果圖，又稱石川圖或魚骨圖，用於識別風險的起因。

（2）系統或過程流程圖，顯示系統各要素之間的相互聯絡及因果傳導機制。

（3）影響圖，用圖形方式表示變數與結果之間的因果關係、事件時間順序及其他關係。

9。3。風險管理計劃

（1）方法論

（2）角色與職責

（3）預算

（4）時間安排

（5）風險類別

（6）風險機率和影響的定義

（7）機率和影響矩陣

（8）修訂的干係人承受力

（9）報告格式

（10）跟蹤

9。4。風險識別原則

（1）由粗及細，由細及粗。

（2）嚴格界定風險內涵並考慮風險因素之間的相關性。

（3）先懷疑，後排除。

（4）排除與確認並重。對於肯定不能排除但又不能肯定予以確認的風險按確認考慮。

（5）必要時，可作實驗論證。

10。合同管理

10。1。條款

範圍

驗收時間

驗收標準

10。2。過程

合同管理主要包括合同簽訂管理

合同履行管理

合同變更管理

合同檔案管理

10。3。索賠流程

（1）提出索賠要求

（2）提交索賠資料

（3）索賠答覆

（4）索賠認可

（5）提交索賠報告或者：（4）索賠分歧（5）提請仲裁（或者提起訴訟）

10。4。合同分類

範圍分

（1）總承包合同

總承包合同也稱

“交鑰匙承包”，發包人把資訊系統工程建設從開始立項、論證、施工到竣工的全部任務，一併發包給一個具備資質的承包人。這種承包方式有利於充分發揮那些在工程建設方面具有較強的技術力量、豐富的經驗和組織管理能力的大承包商的專業優勢，保證工程的質量和進度，提高投資效益。採用總承包的方式進行承包，發包人和承包人要簽訂總承包合同。

（2）單項專案承包合同

發包人將資訊系統工程建設的不同工作任務，分別發包給不同的承包人。單項工程承包方

式有利於吸引較多的承包人參與投標競爭，使發包人有更大的選擇餘地

；也有利於發包人對建設工程的各個環節、各個階段實施直接的監督管理。這種發包方式較適用於那些對工程建設有較強管理能力的發包人。

（3）分包合同

總承建單位將其承包的某一部分或某幾部分專案，再發包給子承建單位。簽訂分包合同應

當同時具備兩個條件

：第一，承包人只能將自己承包的部分工程分包給具有相應資質條件的分包人；第二，分包工程必須經過發包人同意。另外，還有隻能將非關鍵、非主體部分進行分包，而且不可以進行二次分包。

付款方式

（1）總價合同

總價合同又稱固定價格合同，是指在合同中確定一個完成專案的總價，承包人據此完成項

目全部合同內容的合同。這種合同型別能夠使建設單位在評標時易於確定報價最低的承包商，

易於進行支付計算。適用於工程量不太大且能精確計算、工期較短、技術不太複雜、風險不大

的專案，同時要求發包人必須準備詳細全面的設計圖紙和各項說明，使承包人能準確計算工程量。

總價合同也可以為達到或超過專案目標

（如進度交付日期、成本和技術績效，或其他可量化、可測量的目標）而規定財務獎勵條款。另外也允許根據條件變化（如通貨膨脹、某些特殊商品的成本增降），以事先確定的方式對合同價格進行最終調整。

（2）工料合同

這類合同的適用範圍比較寬，其風險可以得到合理的分攤，並且能鼓勵承包人透過提高工

效等手段從成本節約中提高利潤。這類合同履行中需要注意的問題是雙方對實際工作量的確定。

（3）成本補償合同

成本加酬金合同，是由發包人向承包人支付工程專案的實際成本，並且按照事先約定的某

一種方式支付酬金的合同型別。在這類合同中，建設單位須承擔專案實際發生的一切費用，因

此也承擔了專案的全部風險。承建單位由於無風險，其報酬往往也較低。這類合同的缺點是建

設單位對工程造價不易控制，承建單位也往往不注意降低專案成本。

這類合同主要適用的專案有

（1）需立即開展工作的專案。

（2）對專案內容及技術經濟指標未確定的專案。

（3）風險大的專案。

11。配置管理

11。1。過程

制定配置管理計劃、配置標識、配置控制、配置狀態報告、配

置審計、釋出管理和交付。

11。2。 3個庫

（1）開發庫，也稱為動態庫、程式設計師庫或工作庫，用於儲存開發人員當前正在開發的配置實體。動態中的配置項被置於版本管理之下。動態庫是開發人員的個人工作區，由開發人員自行控制。庫中的資訊可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到專案的其他部分。

（2）受控庫，也稱為主庫，包含當前的基線加上對基線的變更。受控庫中的配置項被置於完全的配置管理之下。在資訊系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。

產品庫

，也稱為靜態庫、發行庫、軟體倉庫，包含已釋出使用的各種基線的存檔，被置於完全的配置管理之下。在開發的資訊系統產品完成系統測試之後，作為最終產品存入產品庫內，等待交付使用者或現場安裝。

11。3。版本號

（1）處於“草稿”狀態的配置項的版本號格式為 0。YZ。

（2）處於“正式”狀態的配置項的版本號格式為 X。Y。配置項第一次成為“正式”檔案時，版本號為 1。0。如果配置項升級幅度比較小，可以將變動部分製作成配置項的附件，附件版本依次為 1。0，。1。1，……。當附件的變動積累到一定程度時，配置項的 Y 值可適量增加，Y 值增加一定程度時，X 值將適量增加。當配置項升級幅度比較大時，才允許直接增大 X 值。

（3）處於“修改”狀態的配置項的版本號格式為 X。YZ。配置項正在修改時，一般只增大 Z 值， X。Y 值保持不變。當配置項修改完畢，狀態成為“正式”時，將 Z 值設定為 0，增加 X。Y 值。

11。4。配置審計

（1）防止向用戶提交不適合的產品，如交付了使用者手冊的不正確版本；

（2）發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更；

（3）找出各配置項間不匹配或不相容的現象；

（4）確認配置項己在所要求的質量控制稽核之後納入基線併入庫儲存；

（5）確認記錄和文件保持著可追溯性。

12。計算題

12。1。溝通渠道的總量

n*（n-1）/2；n為干係人數量

12。2。 EMV

EMV=機率1*影響1+機率2*影響2+。。。+機率n*影響n；

投資或擴建方案，哪個利大選哪個，自制和外購決策，哪個便宜選哪個

12。3。加權系統

12。4。進度

總時差

=LS-ES=LF-EF或用關鍵路徑-當前活動所在的路徑

自由時差

=min（緊後工作ES-此活動的EF）

LF=LS+工期；EF=ES+工期

期望公式

期望時間

=（樂觀時間+悲觀時間+4*最可能時間）/6

標準差

=（悲觀時間-樂觀時間）/6

示意題：

A任務持續時間悲觀估計為36天，最大可能估計為21天，樂觀估計為6天。那麼A行為在16到26天之間完成的機率有多大？解答：

（1）求出σ σ = （36-6）/ 6 = 5

（2）期望時間=（36+6+4*21）/6=21

（3）由 σ可知 21+5=26 21-5=16，因此16—26天落在1 σ分佈內。

（4）由1 σ的機率P為68。3可得答案為 68。3%

數值 -1σ~1σ=68。3%；-2σ~2σ=95%；-3σ~3σ=99%；

12。5。掙值分析、預測技術

EV、PV、AC、BAC、CV、SV、EAC、ETC、CPI、SPI公式

CV=EV-AC>0節省，否則超支；SV=EV-PV>0提前，否則滯後

CPI=EV/AC>1節省，否則超支；SPI=EV/PV>1提前，否則落後

ETC=BAC-EV 非典型

ETC=（BAC-EV）/CPI典型 EAC=AC+ETC演化EAC=AC+BAC-EV——非典型；EAC=AC+（BAC-EV）/CPI 典型

VAC（完工偏差）=BAC-EAC

12。6。投資回收期

12。7。歸一化評估結果

13。案例萬金油簡版

士氣低落：團隊建設沒做好

客戶投訴：溝通有問題，干係人沒管理好

爭吵：衝突沒做好

加班：成本超支、質量有返工

時間

/工期緊張：沒有冗餘思想

推諉扯皮：職責不清

不滿意：溝通不暢

驗收不透過：驗收標準沒定義好

變更：變更流程控制

新技術：存在風險

一個人編寫計劃：應該全員參與

多頭彙報：專案經理許可權問題

文件不清晰、混亂：文件配置沒做好

不斷提出新需求：需求蔓延

活動並行：存在風險

WBS 不熟悉：早期沒有參與

專案文件：甲方是否參與、批准

過了很久：監控不力

專案章程釋出：專案經理只能寫，不能釋出

外包商：監控不力

評審：甲方是否參與

方案：甲方是否批准

技術人員：專案經驗不足

核心人員離職：團隊管理有問題

身兼數職：管理經驗不足，身心疲憊

14。案例萬金油詳版

14。1。可研過程中可能出現的問題

1．專案經理的技術經驗不足

2．沒有正式、書面的新產品研發專案建議書就開展可行性研究工作

3．新產品研發的可行性研究工作不充分，尤其缺少技術可行性分析和論證

4．研發過程中對人才缺乏、竟爭對手等帶來的風險缺乏充分的分析，沒有合理有效的應對方案

5．沒有新產品的初步設計方案就開始研發工作

6．新產品的需求和技術指標不應由領導把關，應進行外部評審

7．在專案啟動前缺少對專案成本的估算或成本估算工作未到位

8．可行性研究報告缺少必要的內部論證或外部評估環節

9．沒有制訂綜合、全面的專案管理計劃，進度計劃不能代替專案管理計劃，領導的指示不能代替專案管理計劃

10．專案發生進度延誤的可能性時未及時調整或更新進度計劃並與領導及相關各方溝通

11．前期立項工作中人員參與不充分，缺少關鍵技術人員和財務人員

14。2。整體管理可能的問題

1．專案管理計劃不應由一人制定，應有專案組參與。

2．專案計劃缺少相關分計劃，如質量計劃、溝通計劃等

3．制定進度計劃的方法不合理，沒有預留一定的緩衝時間。

4．專案計劃缺少評審和審批環節。

5．沒有處理好外部因素（天氣）和內部因素（團隊）帶來的風險，缺乏有效的應對措施。

6．專案發生變更時沒有及時更新專案計劃。

7．應識別受裝置到場所影響的活動，對於不受影響的活動不應推遲進行。

14。3。軟體專案失控的可能問題

1。需求不明確，即需求過多、需求不穩定、需模稜兩可或需求不完整等。

2。不充分的計劃和過於樂觀的評估

2。1。工作責任範不明確，WBS 與專案組織結構不明確或者不對應，各成員之間的接ロ不明確，導致一些工作根本無人負責；

2。2。每個開發階段的提交結果定義不明確，中間結果是否已經完成、完成了多少模不清，以致專案後期堆積了大量工作；

2。3。開發計劃沒有指定里程碑或檢查點，也沒有規定設計評期：

2。4。開發計劃沒有規定進度管理方法和職責，導致無法正常進行進度管理：

2。5。對工作量的重要性認識不足：軟體開發經常會出現一些平時不可見的工作量，如人員的培訓時間、各個開發階段的評審時間等，經驗不足的專案經理經常會遺：

2。6。出於容戶或公司上層的壓カ在工作量估算上予以妥協，例如客戶威脅要用工數更少的開發商，公司因經營困難必須削減費用、縮短工期，最後只能妥協，寄布望於員工加班；

2。7。設計者過於自信或出於自尊心問題，對一些技術問題不夠重視；

2。8。過分相信經驗，沒有具體分析就認為此次專案差不多，卻沒有想到此次專案有可能規模更大、專案成員更多且素質差異很大，或者專案出自於一個新的行業。

3。採用新技術，或關心創新而不關心費用和風險

3。1。技術無法擴充套件

3。2。技術是錯誤的解決方案

3。3。技術不具有要求的功能性等。

4。管理方法缺乏或不恰當。

5。效能問題。

6。團隊組織不當

6。1。專案團隊過小，所分配的技術人員水平達不到特定專案的要求；

6。2。專案團隊缺少資源人員，從而設計能カ不足：

6。3。沒有對分包商的設計能力仔細評價。

7。人際因素

7。1。開發商與客戶的關係

7。2。銷售人員與技術人員的關係

7。3。專案管理者與開發人員的關係等。

14。4。範圍管理可能問題 & 措施

問題

1．沒有挖掘到全部隱性需求，缺乏精確的範圍定義

2．沒有有效的範圍管理，造成二次變更

3．對範圍控制不足

4．沒有和客容戶進行需求確認

5．沒有制定範圍管理計劃或專案管理計劃

6．變更結果沒有得到容戶的確認。

7．專案範圍說明書內容不全面（或者專案範圍定義不充分）

8．沒有及時評估容戶提出的變更要求對專案帶來的影響並與容戶及時溝通

9．變更不應由專案經理審批，應有CCB審批

10．專案變更實施前沒有及時變更合同

11．缺少範圍確認環節（或專案需求、設計等沒有得到使用者的正式評審）

12．範圍控制存在問題

措施

1．專案範圍進行清晣定義，並根據定義對工作進行分解，制定WBS

2．對專案進行合理估算，對工作量有量化的把握

3．對專案範圍進行有效控制

4．重新定義專案範圍必須得到高層和容戶的確認

5．進行溝通管理，協調多個項日干系人之間的矛盾

14。5。需求變更的可能問題

1。沒有按照嚴謹的變更控制流對整個需求變更做完整的記錄和跟蹤（對於需求變更請求沒有記錄、沒有對變更進行正式的評審批准、對於變更的結果沒有驗證）

2。對需求變更可能造成的影響進行全面的評估和分析（只分析了需求變更對於工期的影響）

3。需求變更後沒有修改專案管理計劃並重新評審（專案經理不應口頭佈置任務，同時里程碑的調整沒有通知相應的管理層）

4。配置管理工作沒有做好（沒有對需求檔案和設計檔案進行修改，並升級相應版本，相應的模組編碼的修改也沒有進行版本控制）

5。變更結果沒有跟容戶溝通（需求變更實施完成後，沒有讓客戶對最終結果進行確認）

14。6。進度管理可能問題

1。團隊成員沒有及早參與，需求分析耗時長，要早期參與進專案

2。經驗不足，進度計劃制定不準，沒有采取有效的歷時估算方法和網路計劃技術，制定進度計劃

3。沒有考慮專案期間特定時期會對進度產生影響

4。増加資源有時可能壓縮工期有限，1項任務10個人做，和10個人做一個專案的效果不一樣

解決方案

1．増加人手，聘請更有經驗的人員，或找兼職人員

2．加班

3．並行

4．重新估算後面的工期

5．加強溝通，減少變更

6．加強控制，避免返工

7．外包

8．加強溝通，先完成關鍵需求

9．關注關鍵路徑，在關鍵路徑上加資源

10．關注里程碑

11．加強進度與成本、風險、質量等知識點的協調

12．向公司中請増加資源，或使用經驗豐富的員エ

13．最佳化網路圖，重排活動之間的順序，壓縮關鍵路徑

14．臨時加班（趕工），儘可能補救耽誤的時間或提高資源利用率

15．將部分階段的工作改為並行，並進行內部流程的最佳化

16．變更原來的進度計劃。根據上一階段的績效，對後續工作重新評估，修訂計劃，並徵得專案干係人的同意

17．加強同項目千系人的溝通

18．加強對交付物、專案階段工作的及時檢查和控制，避免後期出現返工

19．儘可能調配非關鍵路徑上的資源用於關鍵路徑上的任務

20．最佳化外包，採購等環節，並全程監控。

14。7。成本管理可能問題

1。沒寫成本管理計劃

2。估算不準確

3。預算不準確

4。沒做好成本控制

5。成本觀念淡薄

6。指標沒有量化

14。8。專案質量管理可能問題

1．沒有制定可行的質量管理計劃並枳極實施

2．沒有全面的質量管理進展情況報告

3．溝通方式單一或不全面，容易誤導使用者，導致使用者不必要的擔心

4．質量保證過程中缺乏QA的參與

5．質量控制環節缺失，例如評審和測試

6．測試方法不當或不充分

7．測試控制的流程不對，或測試安排的緊張，或末進行質量控制就進行了範圍確認

8．沒有進行質量保證

9．檢查頻率的設定有問題。

10．應加強專案過程中的質量控制或檢査，不能等到工作產品完成後オ檢查

11．QA發現問題應與當事人協商，如果無法達成一致要向專案經理或更高級別的領導彙報，而不能自作主張。

12．在質量管理中，沒有與合適的技術手段相結合

13．對程式設計師在質量意識和質量管理的培訓不足

14．職責分配不清楚

15．專案經理在專案質量管理方面的經驗欠缺

16．進度計劃制定的不合理（或進度計劃安排過於緊張）

17．需求分析、系統設計階段的質量控制可能不到位、缺少評審環節

18．測試過程中配置管理工作未到位

19．專案缺乏質量標準和質量規範

20．沒有建立專案的質量保證體系

21．在質量管理中，沒有采用合適的工具、技術和方法

14。9。應該怎麼解決或提高專案質量

1。嚴格執行公司的質量管理體系規範工作流程

2。制定質量管理計劃

3。執行質量保證計劃

4。調配相關資源（如：人、財、物等）加強後續質量保證工作

5。加強後期的質量控制和測試，應安排相對獨立的測試人員

6。提前加強產品交付後的客戶服務和維護工作；

7。加強溝通

8。建議必要時修改質量基準爭取以最小的代價獲得使用者認可。

9。參與開發專案的軟體過程描述。評審過程描述用於保證該過程與組織政策、內部軟體標準、外界標準及專案計劃的其他部分相符：

10。按質量管理計劃實施質量檢查，檢查是否按標準過程實施專案工作。及時完成專案過程中的質量檢查，在毎次進行檢查之前應檢查清單，並將質量管理相關情況予以記錄：

11。依據檢查的情況和記錄，識別與相應軟體開發過程的偏差，分析問題原因，發現尚可能存在的問題，並與當事人協商，爭取解決問題。問題解決後要進行驗證，如果無法與當事人達成一致，應按問題上報流程報告專案經理（或更高級別的領導），直至問題解決

12。定期給專案干係人分發質量報告：

13。協調變更控制和變更管理，並幫助收集和分析軟體度量資訊等；

14。為專案組成員提供質量管理要求方而的培訓或指導等。

15。強有力的領導

16。建立組織級專案管理體系

17。建立組織級質量管理體系，包括制定可行的過程規範和質量目標、質量標準

18。建立專案級激勵制度

19。理解質量成本

20。提高專案文件質量

21。發展和遵從成熟度模型

22。應安排獨立於專案組的有經驗的質量保證人員負責質量保證工作

23。對軟體開發的過程實施質量軍計

24。注重對需求和設計等開發過程檔案的技術評審工作

25。應加強需求和設計方案評審和質量控制工作

26。應加強專案實施過程中的配置管理工作

27。提出合理有效的質量整改措施（如建議的糾正措施、對專案計劃可能的更新等）

14。10。人力資源可能問題

1。缺乏足夠的專案管理能カ和經驗：

2。兼職過多，精力和時間不夠用，顧此失彼：

3。沒有進入管理角色，定位錯誤，疏於對專案的管理

4。新人缺乏培訓和全程的跟蹤和監控

5。沒有進行良好的衝突管理

1．事先制定崗位的要求、職責和選人的標準，並選擇合適的人選：

2．對工作進行全面估算，如果有人負荷過重，需要找人代替，解決負載平衡問題

3．事前溝通並對相應人員明確要求，明確角色的輕重緩急，促使盡快轉換角色

4．上級應該注意平時對人員的培養和監控

5．對專案團隊進行有效的衝突管理

6．採用合適的團隊建設手段，消除團隊成員間隔

7．明確專案團隊的目標及專案組各成員的分工

8．建立清晰的工作流程和溝通機制

9．建立明確的考核評價標準。

10．鼓勵團隊成員之間建立參與和分享的氛圍。

11．制定有效的激勵措施

14。11。團隊組建常見問題

問題

1。招募不到合適的專案成員：

2。團隊的組成人員儘管富有オ千，但卻很難合作

3。團隊氣氛不積極，造成專案團隊成員計程車氣低落

4。專案團隊的任務和職責分配不清楚

5。人員流動過於頻繁

6。沒有能夠建立人カ資源獲取和培養的穩定機制

7。沒有完整識別專案所需的人力資源種類、數量和相關任職條件

8。沒有建立一個能充分、有效發揮能力的團隊

9。沒有清楚地分配工作職責到個人或人力單元

措施

1．建立穩定的人力資源獲取和培養機制

2．在專案早期，進行專案的整體人力資源規劃，明確崗位設定、工作職責和協作關係

3．進行專案團隊建設，加強團隊溝通，建立合作氖圍

4．根據專案團隊成員的工作職責和目標，跟蹤工作績效，及時予以調整和改進，提升專案整體績效

14。12。溝通管理和干係人管理可能問題

問題

1。缺乏溝通，合作氛圍不夠

2。沒有對團隊成員的測通需求和溝通風格進行分析

3。沒有開一個高效的會

4。溝通方式單一

5。沒有衝突管理

6。內部管理有問題，監管不力

7。沒有或極少與容戶進行直接溝通

8。現場管理制度執行不力

9。總包與分包責任不清

10。容戶獲取的資訊失真，總包推卸責任

11。客戶自己本身的問題，包括資金、管理水平等

12。可能監理工作沒到位

措施

1．及時資訊分發，加強溝通，讓客戶瞭解專案具體情況

2．注重溝通技巧，建立融治的合作氣氛

3．分析成員的溝通風格，從而採用相應的溝通方式

4．多種溝通方式

5．採用一些溝通模板

6．加強衝突管理

7．採用一些溝通模板

8．加強衝突管理

9．多供應商的溝通

10．解決衝突，包括千系人對專案期望之間的衝突、資源衝突等

11．做好乾系人分析，調研各整合商的溝通需求

12．週期性的溝通

13．突發事件的協調

14．發揮總包的牽頭和監理的協調作用

15．對共用資源可用性進行分析，引入資源日曆

16．建立健全專案管理制度並監管其執行

17．採用專案管理資訊系統

14。13。風險管理可能問題

問題

1。沒有正確理解業務問題

2。使用者不能恰當的使用系統

3。拒絕需求變更

4。對工作的分析和評估不足

5。人員流動

6。缺乏合適的開發工具

7。缺乏合適的開發與實施人員

8。缺乏適合的開發平臺

9。使用了過時的技術

原因

1．專案干係人對業務問題的認識不足、計算起來過於複雜、不合理的業務壓力、不現實的期限

2．資訊系統沒有與組合戰略相結合、對使用者沒有做足夠的解釋、幫助手冊編寫的不好、使用者培訓工作做的不夠

3．固定的預算、固定的期限、決策者對市場和技術缺乏正確的理解

4．缺乏專案管理經驗、工作壓力過大、對專案工作不滿意

5．不現實的工作條件、較差的工作關係、缺乏對職員的長遠期望、行業發展不規範、企業規模較小

6．技術經驗不足、缺乏技術管理準則、技術人員的市場調研或對市場理解有誤、研究預算不足、組織實力不夠

7．對組織架構缺乏認識、缺乏中長期的人カ資源計劃、組織不重視技術人オ的技術工作、行業人才緊缺

8．缺乏遠見、沒有市場和技術研究、團隊龐大陳舊難以轉型、缺乏預算

9．缺乏技末前瞻人オ、輕視技術、缺乏預算

措施

1。使用者培訓、系統所有者和使用者的承諾與參與、使用高水平的系統分析師

2。使用者的定期參與、專案的階段交付、加強使用者培訓、完善資訊系統文件

3。變更管理、應急措施

4。採用標準技術、使用具有豐富經驗的專案管理師

5。保持好的職員條件、確保人與工作匹配、保持候補、外聘、行業規範

6。預先測試、教育培訓、選擇替代工具、増強組織實力

7。外聘、招募、培訓

8。全面評估、推遲決策

9。延遲專案、標準檢測、前期研究、培訓

14。14。管配置管理問題

問題

1．沒有專案管理經驗，不適合專案經理的職位。

2．專案經理兼任配置管理員，精力不夠，無法完成配置管理工作

3．範圍管理有問題

4．版本管理沒有做好，沒有統一的版本管理機制，各版本不可追溯，導致重要版本丟失

5．專案中沒有建立基線，導致需求、設計、編碼無法對應：

6．沒有做好變更管理，專案中的變更不可控

7．配置管理計劃不應由CCB制定

8．基線變更流程缺少變更驗證（或確認）環節

9．CCB成員的要求不應以人數作為規定，而是以能否代表專案干係人利益為原則

10．該公司可能沒有版本管理規定或甲乙沒有統一執行版本規定

11．變更審查應該提交CCB軍核

12．變更釋出應交由CMO完成

13．甲乙兩人不能同時修改錯誤

14．沒有做配置管理規劃，缺少完整的配置管理方案

15．缺少配置管理及變更管理流程，沒有配置管理委員會

16．試執行的系統版本沒有及時建立基線並讓各業務部門正式確認：

17．配置許可權管理存在問題：

18．人員職責不清晰，沒有CMO（配置管理員）的參與並控制配置許可權

19．開發人員沒有按照變更流程的要求修改系統及程式碼

20．開發人員修改程式碼後沒有及時修改文件，導致兩者不一致

21．程式碼被修改後沒有及時進行迴歸測試並請干係人確認

22．文件管理存在問題，沒有做好文件的交接、更新、變更管理工作

23．配置管理過程中沒有做好相應的記錄；

24。新人的培訓工作沒有跟進到位。

措施

1。從專案整體出發，做好配置管理規劃

2。定義合理的配置管理流程，規定專案中出現變更的處理辦法

3。與各方干係人達成共識，組建配置管理委員會

4。識別配置項，併為配置項建立惟一標識，保證其可追溯

5。建立配置基線，使重要配置項處於受控狀態

6。定期提效配置狀態報告，改進配置管理方法

7。組建配置管理方案設計小組

8。仔細瞭解單位的情況、歷史、人員、組織形式等

9。對配置管理工具進行有效評估

10。制定全面有效的配置管理計劃，包括建立配置管理環境、組織機構、成本、進度等，在配置管理計劃中詳描述，建立示例配置庫、配置標識管理、配置庫控制、配置的檢查和評審、配置庫的備份、配置管理計劃附屬文件

11。梳理變更脈絡，確定統一的最終需求和設計：

12。梳理配置項及其歷史版本

13。對照最終需求和設計逐項分析現有配置項及歷史版本的符合情況

14。根據分析結果由干係人確定整體變更計劃並實施

15。加強整體版本管理。

14。15。變更中常見的問題

1．沒有遵循變更控制流程

2．沒有書面的記錄

3．應該有CCB進行審批

4．沒有及時更新專案管計劃。

14。16。合同管理裡可能會出現的問題

1。合同沒定好，沒有就具體完成的工作形成明確清晰的條款

2。甲方沒有對需求及其變更進行統一的組織和管理

3。缺乏變更的接收/拒絕準則

4。專案干係人及其關界分析不到位，範圍定義不全面、不準確

5。甲乙雙方對專案範圍沒有達成一致認可或承諾

6。缺乏專案全生命週期的範圍控制

7。缺乏客戶/使用者參與

8。甲方無法進行跨部門協調

9。實施範圍不清楚、驗收標準不清楚

10。專案溝通有問題

11。客戶不驗收或拖延驗收、簽字、容戶有情緒、不付款

12。客戶對專案質量信心不足、售後沒有承諾等

13。缺少違約責任相關條款

14。缺少變更處理及索賠相關條款

14。17。可能的收尾的問題

1．沒有充分做好驗收前的準備，或軟體系統沒有達到驗收前的標準，或軟體還存在計劃修復的缺陷，這些缺陷未經修復和確認便進入正式驗妝環節。

2．在驗收過程中末根據變更控制流程對軟體進行修改，導致文件與軟體不一致

3．軟體更新後沒有對文件進行變更便交付給客戶

4．專案驗收未正式完成，未簽署驗收報告變更進行了專案總結

5．專案收尾過程不完整，缺少正式的專案總結環節，不能只編寫總結報告

6．專案總結報告末能反映專案的實際情況

7．缺少專案評估或審計環節驗收中存在的主要問題

8．沒有進行有效的系統測試

9．沒有準備好相應的文件

10．沒有按照規範的流程進行驗收

11．與客戶的溝通不良

14。18。外包（採購）的害處

1。無法達到預期的成本降低目標

2。以前內部自行管理領域的整體品質降低

3。未和服務供應商達成真正的合作關係

4。企業僱主和服務提供商在服務品質和酬勞議題上有爭議

5。無法藉機開拓出滿足客戶新層次需求和符合彈性運作需求的機會。

14。19。如何做好外包（採購）

1．慎重的選擇合格的外包商

2．互相同意對方的承諾

3．需要經常保持交流

4．根據合同的承諾跟蹤承包商實際完成的情況和成果，也就是說要多溝通，多監控。

軟考：系統整合專案管理工程師(中級)案例、計算、默寫題總結

相關文章