<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>專案管理資訊協同平台</title>
	<atom:link href="http://www.pm-plus.net/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://www.pm-plus.net</link>
	<description>Make Project Management Easy</description>
	<lastBuildDate>Sun, 05 Sep 2010 12:54:48 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Lewis 專案管理流程模型 _(5)</title>
		<link>http://www.pm-plus.net/?p=279</link>
		<comments>http://www.pm-plus.net/?p=279#comments</comments>
		<pubDate>Sun, 05 Sep 2010 12:54:48 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=279</guid>
		<description><![CDATA[摘要
我們以過程方式（Process approach）或謂過程導向從事品質管理，是 ISO 9000：2000年版品質管理系統最為強調的一部份，因為制訂標準的 TC176 技術委員會接受了各會員組織要重視過程的建議，因為既然「凡事都在過程中完成」便應在管理中予以定調，將它列為管理原則之一，此原則同樣應用在專案管理。本文首先介紹過程導向專案管理的概念，接著說明專案管理模型的必要性，然後描述幾個技術面的專案管理模型，最後介紹 Lewis 的專案管理流程模型，並對該模型補充產品實現過程。
 目次：
　　1.　過程導向專案管理
　　2.　為什麼專案管理要做成模型
　　3.　專案管理模型的要素
　　4.　專案管理的4個現行模型
　　5.　Lewis專案管理流程模型(本節內容)
5.　Lewis專案管理流程模型
流程導向的可視化專案管理模型符合過程管理的原則。圖 6 及圖 7 所示 16 步專案管理模型是美國一位著名專案管理專家路易斯(James P. Lewis)所提出的。基於專案管理過程與專案產品實現過程的整合需求，我們對路易斯的專案管理模型增加了專案產品實現的過程如圖 8 所示。在路易斯的專案管理模型中劃分成五個階段及 16 個步驟，依據此模型進行專案的選擇及規劃實施，規劃越詳細則此模型越具可操作性。
路易斯的專案管理方法包含 5 個步驟：定義、策略規劃、實施計劃、執行與控制、總結教訓或結尾階段。
(1)  定義(definition)。專案就是為解決問題的有計劃行動–確保能定義出你要解決的問題，從而使你知道你想要的結果是什麼、任務是什麼。
(2)  策略規劃(strategy planning)。開展一個專案總的方法。
(3)  實施規劃(implementation planning)。確定專案實施的全部細節–做什麼、誰來做、如何作、做多長時間等。
(4)  執行與控制(executing and controlling)。比較所在位置，並在出現偏差時採取矯正措施。
(5)  終止與結束(closing)。在專案結束時做規範的事後評價與分析以總結經驗學習(lessons learned)。
而從路易斯的 16 步管理模型中可以看到專案的策略計畫所處的位置。這 16 步說明簡要如後。
1.概念確立。  就是對所要做的事情有一個框架性的設計，有一種思想。
2.問題的定義。  即對長遠目標說明。第二步驟是對第一步的進一步細化和具體化。
專案就是計劃要解決的問題，此外一步驟就是要保證能正確地定義出專案所要解決的問題，從而知道專案想要的結果是什麼、任務是甚麼。
3.產生專案的備選方案和策略計畫。  就是提供思路、備選方案和策略計畫總體思路。“策略”是指組織開展一個專案的總的方法，任何一個專案都會有一個策略，選擇正確的策略會關係到專案的成功。
4.策略計畫的評估和選擇。就是在選擇方案的同時，有一個從總體技術路線到總體專案管理策略的評價和選擇。
5.策略的確立。  就是確定具體的策略、目標。
6.制訂專案的實施計畫。  這是一個更加具體的、第二個層次的專案計畫，就是怎樣實施專案，確定專案的實施細節―做什麼、誰來做、如何做、做為多長時間等等。
7.專案利害關係人批准計畫。  這裏的計畫包括策略計畫、初步計畫、詳細計畫，
在這些專案實施前，都必須有一個批准的程序。
8.簽署專案計畫。專案的批准人、參與專案的有關干係人要簽署專案計畫，對計畫做出承諾，同時建立專案的跟蹤記錄，做一個專案進展情況日誌或者周誌、月誌、記錄，根據這些記錄資訊進行知識管理。
9.執行專案計畫。執行專案就是正式開展計畫，進展這個專案。
10.監控專案進展。計畫開始實施之後，就要考慮計畫執行得如何，有無問題，要對進展情況進行監控、監測和控制。
11.審查專案定義。專案實施之後，需要做一些評審，評審包括對原來工作的評審，同時也包括對專案目標定義的評審，如有問題就返回到步驟二，重新修正專案的定義。
12.對專案的戰略進行評審。首先是評價目標或專案的定義，然後評審戰略計畫、戰略制訂是不是有問題，如果有問題就返回步驟四，重新修正你的專案戰略。
13.專案的實施計畫。具體的計畫工作流程、對一些細節要進行評審，有問題就進行修改。
14.迴圈。按照整個過程不斷地從計畫的執行到監測、評審，有問題就要修改計畫，然後再執行，再評審，這個過程一直延續到全部工作結束。
15.總結經驗教訓。專案全部完成以後，及時總結經驗教訓，對一些問題進行歸檔，作為今後專案的指導和借鑒。
16.結束專案。
這是一個完整的專案管理流程，從這個流程可以看到整個專案戰略計畫實際上是在制訂專案的詳細計畫和實施計畫之前。在專案計畫的時候，首先要有一個總體的戰略計畫，在總體的戰略計畫指導下再開展具體的專案計畫。
路易斯的專案管理模型的的第 6 步包含許多分步驟，主要是說明制定一份專案計畫書的主要步驟，也是需要大量專案管理知識的時候。
此外，在針對專案產品實現部份，我們在路易斯的專案管理模型的的第 6 步增加了產品實現過程，主要是說明制定一份系統導向的產品實現步驟所需要的計畫書，確保專案產品的品質性能符合需求。雖然有許多專案管理模型被提出來，實際上正確的專案管理方法都是類似的，所以專案組織可以依照實際需求與專案管理環境，把個模型的優點結合起來，往往就會形成一個最適合你的新的專案管理方法或模型了。


作者：管孟忠 博士　開南大學 專案管理研究所

]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=279</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lewis 專案管理流程模型 _(4)</title>
		<link>http://www.pm-plus.net/?p=271</link>
		<comments>http://www.pm-plus.net/?p=271#comments</comments>
		<pubDate>Thu, 26 Aug 2010 03:21:02 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=271</guid>
		<description><![CDATA[摘要
我們以過程方式（Process approach）或謂過程導向從事品質管理，是 ISO 9000：2000年版品質管理系統最為強調的一部份，因為制訂標準的 TC176 技術委員會接受了各會員組織要重視過程的建議，因為既然「凡事都在過程中完成」便應在管理中予以定調，將它列為管理原則之一，此原則同樣應用在專案管理。本文首先介紹過程導向專案管理的概念，接著說明專案管理模型的必要性，然後描述幾個技術面的專案管理模型，最後介紹 Lewis 的專案管理流程模型，並對該模型補充產品實現過程。
 目次：
　　1.　過程導向專案管理
　　2.　為什麼專案管理要做成模型
　　3.　專案管理模型的要素
　　4.　專案管理的4個現行模型(本節內容)
　　5.　Lewis專案管理流程模型
4.　專案管理的4個現行模型
我們就代表專案管理的技術方面的 4 個現行的模型或結構加以摘要說明。雖然這些模型通常描寫了專案週期的技術方面並加強了模型可視化過程，但它們仍然都有一些重要的疏忽之處。出現這些問題的部分原因是在專案中找不到對技術方面進行管理的普遍認可的方法。此外，一些通用方法在給專案事件排序時出了差錯。更重要的是，它們不能區分順序驅動(sequence-driven)和情境驅動(situation-driven)兩種方式在管理方面的差別，只是單獨地按事件的順序來看待專案，這樣做只會使專案管理過程出現扭曲和偏差。
當我們開始將驅動專案週期的技術過程做成模型時，前述的最後兩個問題變得更加突出。我們就從大家普遍接受的循環圖(circular diagram)開始，見圖 2，有一個大的政府機構曾一度使用這個循環圖，這個機構擅長複雜技術專案的專案管理。這個模型很有教育 意 義 ， 因為它有一些顯而易見的不足之處。這個模型和另 外一個兩維模型(two-dimensional models)，一起呈現了一些由具體情形決定的活動，但實際上，有一些活動卻被錯誤地呈現為按照順序排列的活動，如風險分析和管理。

一些模型，例如美國國防部(Do 使用的一個技術構面的專案週期模型(DoD 標準2167A)，描述了與硬體相關聯的活動，而這些活動又與跟軟體相關聯的活動相互獨立，見圖 3。在專案進入最後的系統整合過程以前，這兩個關鍵的路徑能夠且應該分開管理，這種錯誤結論導致了許多專案的失敗。這個模型使用了幾十年，但在 20 世紀 1990 年代中期，當 DoD 開始指導它的員工和承包商採用軟體開發的商業標準時被放棄。

 
  圖 3 和瀑布模型(waterfall model)見圖 4，都是建立在一定的假設基礎之上，即假設直到工作上游(upstream)的不確定性問題得到瞭解決並已經滿足了主要控制關口(control gates)的審查要求後，下游(downstream)的工作才能開始。這個由Winston W. Royce1 博士發明的圖解表示方法將軟體專案週期表示為一連串的對角線步驟，垂直地從左上方走到右下方。把這個圖形叫做瀑布模型的原因是由於專案活動以不連續的順序，按照線性的階段從上端進行到下端。但是，對於一些複雜的高風險的專案來講，這種模型是不適用的。美國總會計署(General Accounting Office)的一名電腦科學家Rona Stillman認為：「瀑布模型是一種風險很高的模型。這種模型鼓勵進行不實際的成本和進度估算，促使了自由開發問題(problem free development)的出現。」  像硬體造型一樣，在專案週期的早期，經常需要進行軟體的設計和編碼，以便確保正確理解需求並証明技術可行。由於這些原因，很多組織並沒採用這些模型或者是相似的模型。對於許多實際情況來說，這種模型並不適用。
 
 螺旋模型(spiral model)，見圖 5，試圖強調以前的問題。這種模型由貝姆(Barry W. Boehm)2  博士發明，在軟體開發專案中應用很廣。為了彌補上面提到的不足之處，貝姆博士提出有必要盡早理解需求和可行性造型。雖然這種模型的確實現了減小風險的目標，但應注意到其螺旋形的表示容易令人混淆，放射狀的時間表示與傳統的由左到右的時間表示不一致；而且這種模型掩蓋了對基準演變的控制進行審查的必要性。它的另一個缺點是將風險管理描述成了先行進行的，並且延誤了低風險產品開發過程的一連串的分析活動(在左上象限)，而不是把風險管理看成是與正在進行的開發過程同時進行的工作。

作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=271</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lewis 專案管理流程模型 _(3)</title>
		<link>http://www.pm-plus.net/?p=266</link>
		<comments>http://www.pm-plus.net/?p=266#comments</comments>
		<pubDate>Fri, 13 Aug 2010 01:43:39 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=266</guid>
		<description><![CDATA[摘要
我們以過程方式（Process approach）或謂過程導向從事品質管理，是 ISO 9000：2000年版品質管理系統最為強調的一部份，因為制訂標準的 TC176 技術委員會接受了各會員組織要重視過程的建議，因為既然「凡事都在過程中完成」便應在管理中予以定調，將它列為管理原則之一，此原則同樣應用在專案管理。本文首先介紹過程導向專案管理的概念，接著說明專案管理模型的必要性，然後描述幾個技術面的專案管理模型，最後介紹 Lewis 的專案管理流程模型，並對該模型補充產品實現過程。
 目次：
　　1.　過程導向專案管理
　　2.　為什麼專案管理要做成模型
　　3.　專案管理模型的要素(本節內容)
　　4.　專案管理的4個現行模型
　　5.　Lewis專案管理流程模型

3.　專案管理模型的要素
在幾位專家一起確定的有效模型通用標準的基礎之上，我們增加了專案管理的特殊標準：

應該具備清晰地和可操作地定義的  (Explicitly ⎯ and operationally ⎯ defined)結構、變量及關係。
對所有的專案相關人來說，模型都應該是非常直觀和有效的(Obviously  valid and intuitive)。如果每次使用模型的時候都需要對模型重新進行研究，那麼這個模型將只能有最小的⎯甚至可能是負面的⎯價值。
在專案環境下有普遍的通用性 (General applicability)，這在某種程度上解釋了專案過程的複雜性和動態性，以及專案需求所扮演的特殊角色。
在實際專案中，有效結合以往的經驗  (Validated empirically)。

為了實施有效的專案管理過程，模型必須直觀易懂，因為如果不能讓人們快速地理解並且接受這種模型，那麼讓他們去安裝並使用這種模型是不可能的(即使人們接受了模型，安裝並使用起來也很困難)。基於一般所定義的可視化的專案管理模型，建立一種具備良好定義的“一流(best in class)”專案管理文化，結合專案管理培訓並授予團隊關鍵成員相應的培訓証書，便可以大大提高專案的成功率。專案密集型(project-intensive)組織必將最終實現它的目標，即依照計畫成功完成專案。
作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=266</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lewis 專案管理流程模型 _(2)</title>
		<link>http://www.pm-plus.net/?p=262</link>
		<comments>http://www.pm-plus.net/?p=262#comments</comments>
		<pubDate>Thu, 22 Jul 2010 03:44:36 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=262</guid>
		<description><![CDATA[摘要
我們以過程方式（Process approach）或謂過程導向從事品質管理，是 ISO 9000：2000年版品質管理系統最為強調的一部份，因為制訂標準的 TC176 技術委員會接受了各會員組織要重視過程的建議，因為既然「凡事都在過程中完成」便應在管理中予以定調，將它列為管理原則之一，此原則同樣應用在專案管理。本文首先介紹過程導向專案管理的概念，接著說明專案管理模型的必要性，然後描述幾個技術面的專案管理模型，最後介紹 Lewis 的專案管理流程模型，並對該模型補充產品實現過程。
 目次：
　　1.　過程導向專案管理
　　2. 　為什麼專案管理要做成模型(本節內容)
　　3.　專案管理模型的要素
　　4.　 專案管理的4個現行模型
　　5.　 Lewis專案管理流程模型
2.　為什麼專案管理要做成模型
模型有助於解釋工作是如何進行的(models help to explain how things work.)。我們可以按照個人的特點來選擇模型，並可以利用數學模型或數學公式對模型進行解釋。舉一個很簡單的例子：在往復式發動機的物理模型或者分子的物理模型面前，科學系的學生又怎能不受到啟發呢?

模型可以擴展我們的眼界  (models can broaden our perspective)，就如同地球儀或者太陽系模型給我們的幫助一樣。
就像通用詞匯表在溝通中起的重要作用一樣，模型可以提供通用概念參考框架 (models provide a common conceptual frame of reference)。
模型可以更加簡單地表達規則 (models can express rules more simply.)。模型經常可以表達一些比較明確的規則或者對這些規則提供強有力的補充。

模型可以澄清相互間的關係，識別出關鍵元素，有意識地減少可能引起的混淆 (models clarify relationships, identify key elements, and consciously eliminate confusion factors)。用 Thomas Kuhn 的話來說：「…所有模型的功能都很相似。除此之外，模型還可以提供比較受歡迎的類推或者比喻。」
模型使我們能夠想像到宏偉畫面的啟示(Models enable us to visualize the [...]]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=262</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lewis 專案管理流程模型 _(1)</title>
		<link>http://www.pm-plus.net/?p=253</link>
		<comments>http://www.pm-plus.net/?p=253#comments</comments>
		<pubDate>Fri, 16 Jul 2010 16:40:29 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[專案管理理論]]></category>
		<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=253</guid>
		<description><![CDATA[摘要
我們以過程方式（Process approach）或謂過程導向從事品質管理，是 ISO 9000：2000年版品質管理系統最為強調的一部份，因為制訂標準的 TC176 技術委員會接受了各會員組織要重視過程的建議，因為既然「凡事都在過程中完成」便應在管理中予以定調，將它列為管理原則之一，此原則同樣應用在專案管理。本文首先介紹過程導向專案管理的概念，接著說明專案管理模型的必要性，然後描述幾個技術面的專案管理模型，最後介紹 Lewis 的專案管理流程模型，並對該模型補充產品實現過程。
 目次：
　　1.　過程導向專案管理(本節內容)
　　2.　為什麼專案管理要做成模型
　　3.　專案管理模型的要素
　　4.　專案管理的4個現行模型
　　5.　Lewis專案管理流程模型
1.　過程導向專案管理
1.1過程導向
當開發、實施及改進專案品質管理系統之有效性時，ISO10006 標準鼓勵採用過程導向，以藉由符合專案利害相關者要求提高利害相關者的滿意度。一專案組織為使其專案管理功能有效果及有效率，其必須識別及專案管理許多相連結之活動。 一項使用資源並加以管理以便可將輸入轉換為輸出之活動，可視為一個“過程” (process)。
通常一個過程指的是接受輸入將它處理而轉變成為輸出的活動。而“系統”(system)係指各組成份子工作在一起共同完成系統目標的相互依賴網路，它是由輸入-處理-輸出三者所構成，所以我們可以說過程是組成系統的一部份。通常一過程的輸出，會直接形成下一過程的輸入，活動要項多時則形成內部相互關聯或交互作用活動之組合系統，為使組織有效運作，管理者須能鑑別及管理內部交互連結的過程與系統。因此，專案組織內各專案管理過程系統之應用，與這些過程之識別及相互作用與管理，通常可被稱為『過程導向』。
使用過程概念時，要注意過程的「順序」與彼此之間的「交互作用」，「監督與管制」，以及「持續改進」活動。專案管理者要知道那些是影響專案品質的關鍵過程，也要知道誰是過程負責人？他們是否有效運用資源？如何管制過程？能否達到顧客或專案利害關係人滿意的結果？ 過程導向專案管理之利益為提供專案管理過程系統內個別過程群組⎯啟動過程、規劃過程、執行過程、控制過程與結案過成⎯之間進行中的管制，以及相關於其組合與相互作用之連結。當使用於專案品質管理系統內時，此一導向強調下列各項之重要性：
a)     顧客或利害關係人要求之瞭解及達成，
b)     考慮以專案管理過程附加價值為觀點之需求，
c)     獲得專案管理過程績效與有效性的結果，及
d)     以專案管理目標客觀量測為基礎之過程的持續改善。
1.2過程導向原則
ISO10006《專案品質管理標準》將過程導向原則解釋為&#8221;當相關的資源與活動經過管理而成為過程時，便會更有效地獲得所希望的結果&#8221;因為這種作法就會產生較佳的資源利用，較佳的週期時間與較低的成本的效果。過程概念示意如圖 1 一般過程模式。
 
 專案管理過程必須予以管理以符合內部與外部顧客及專案利害關係人之要求與需要，故必須明確指定責任歸屬者，負責管理過程，也要同時鑑別過程與組織之部門間之介面關係並釐清其職責。
我們可從量測輸入、過程及輸出方面的績效，找出一些改進機會，要以過程改善來指陳專案實施過程中的問題與消除問題，因此，專案管理者便應注意執行下列七項活動：
(1)  確認專案的顧客及供應者，
(2)  規劃及管理專案相關作業，
(3)  找出專案管理過程中問題肇因，並設法消除，
(4)  持續改善專案管理過程，
(5)  提高專案資源使用效率，
(6)  降低專案營運成本，
(7)  對專案管理過程作必要的改變。
1.3專案的過程及階段
過程及階段是專案的兩個不同層面。專案可能區分為彼此相依的過程和階段，以作為規劃、監督目標實現及評估相關風險的一種方法。專案階段將專案生命週期區分成可管理的部分，例如：概念階段、發展階段、實現階段及終結階段。專案過程是管理專案，同時也是實現專案產品所必須有的過程。並非所有在國際標準討論的所有過程都存在於特定專案之中，其他專案的部分可能需要額外的過程。在某些專案必須對核心及支援過程作區分。附件 A 條列及摘要出應用於專案主要部分的過程。過程群是依據與其他過程的密切關係進行群組，例如，所有與時間有關的過程成為一個群組。專案過程表示成 11個過程群組。專案管理包括為達成專案目標，在持續的基礎下，對所有過程進行規劃、組織、監控、報告及必要矯正行動。
作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=253</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>專案管理過程中的問題分析與解決_(3)</title>
		<link>http://www.pm-plus.net/?p=248</link>
		<comments>http://www.pm-plus.net/?p=248#comments</comments>
		<pubDate>Fri, 09 Jul 2010 01:40:55 +0000</pubDate>
		<dc:creator>PM-Plus</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=248</guid>
		<description><![CDATA[摘要
摘要：我們常常發現，在同一個專案中，不同的專案管理人員可以根據其專業經驗和主觀判斷，選擇不同的管理方法。而應用同樣的管理方法，有的管理人員能取得顯著的成績，有的管理人員卻可能導致專案的失敗。究其原因，是由於人們對問題的不同看法所造成的。因此，在專案管理過程中對問題進行分析有助於提高專案管理人員的問題解決能力、管理水準和實踐能力，進而産生好的專案結果。本文介紹如何應用系統方法解決專案過程中的問題。
關鍵字：專案管理 問題分析
 目次：
　　1.　 引言
　　2.　系統方法問題解決過程(System approach problem-solving process)
　　3.　 定義問題－系統需求過程
　　4.　問題分析的具體內涵－系統分析過程
　　5.　解決方案的提出－系統綜合/系統設計(本節內容)
　　6.　評估與決策－系統評估與決策/系統最佳化(本節內容)
　　7.　解決方案的實施與監控－專案管理(本節內容)
　　8.　小結(本節內容)
5.　解決方案的提出－系統綜合/系統設計
在分析問題的性質和條件(找到根本原因)後，針對這個根本原因提出所有的解決問題的方案，先暫且不考慮該方案是否可行或者是否最佳。
提出解決方案可以通過多種渠道。決策者或問題提出人的意見和設想是渠道之一。專案管理人員在調查研究過程中可以收集到各種意見。另外，系統分析人員也可以提出若干管理措施。然而，任何一種管理措施的提出和形成都有賴於專案管理人員的分析和概括能力、想像力、創造力以及對專案實踐的深刻瞭解。在一個具體的專案管理過程中，人員的知識水準參差不齊，開發環境各不相同，客戶需求多種多樣，這些都無法採用某種固定的管理模式，而需要專案管理人員去探索和概括。
在研究解決方案的過程中，應盡可能地考慮各種因素，每個機會和建議都不要放過。最初難以理解的想法，仔細研究後卻可能有理。某項措施可能因爲違背了現有政策法規、不符合人們的習慣或超出了人們所能承受的能力而被視爲不現實，但並不意味著不值得考慮。如果當作一種潛在的管理措施去分析研究，得出的結論將更有說服力，也許某些有影響的決策者認識到這種措施在其他方面的優點和吸引力，可能改變原來的規定、政策而使看來不現實的措施成爲合理的辦法。值得注意的是組織和個人行爲對解決方案的影響。專案涉及的各個部門總是期望採取對自己有利的管理方式，而回避那些明知對專案整體有利而對己不利的措施。有許多因素會限制提出好的解決方案的思路。由於偏見，當專案管理人員提出某種解決方案時，這些人可能會毫無根據地認爲他們無法按照這種方案去服從管理。而另一方面，該方案也可能得到積極的支援，認爲這是一種最佳的解決方案。
我們認爲，專案管理人員必須獲得決策者的支援，否則將由於上層阻力而導致專案的失敗。但是，如果只是投其所好，片面地追求滿足決策者的意圖，也不能發揮其自身的作用，同樣會招致失敗的風險。優秀的專案管理人員應切實履行其工作職責，按照專案的總目標和約束條件，根據實踐經驗和科學理論的指導，對解決方案進行嚴格的篩選，明顯不符合專案整體利益的管理方式要刪除，或對其內容進行修改。總的說來，一個好的解決方案應滿足以下特點：
1.適應性：由於專案管理是一個不確定性的過程，提出的解決方案應能滿足各種情形下對專案提供指導的需求，在專案實施的各個階段，它應該都是有效的。
2.可操作性：首先應取得決策者的支援，其次該解決方案的實施應便於操作，如果爲了按照該方案進行管理而需投入大量的人力、物力就本末倒置了。
3.延續性：專案開發的一個很大的特點，就是採用模組化設計，人員流動大。因此，解決方案也應具有很強的延續性，在專案成員發生變更、管理體制起變化時，應不受干擾地繼續指導專案的正常活動。
4.可靠性：要求解決方案的實施過程中不出現失誤，或者出現失誤也能儘快恢復正常，而不至於造成很大的損失。這需要建立管理監督機構和資訊反饋渠道。
在解決方案的提出過程中，專案管理人員自始至終要注意發掘新的更好的方案，既要謹慎從事又要有勇氣提出創造性的建議。一個好的解決方案是進行專案管理的基礎，對於專案的成敗，這是很關鍵的。
6.　評估與決策－系統評估與決策/系統最佳化
當問題分析清楚之後，也提出了不同的解決方案後，就要進行評估與決策。負責問題解決的團隊先必須依據問題的性質和條件制定出評估方案的準則，然後，對每個解決方案進行評估。決策就是管理，決策就是決定。專案管理人員將每個方案評估後的結果進行比較和權衡，可能需要從成本、收益等方面考慮，決定出解決問題的最佳方案。
在專案管理過程中，管理人員需要正確的決策分析來支援日益龐大和日益複雜的管理活動。決策有個人決策和團體決策、定性決策和定量決策、單目標決策和多目標決策之分。戰略決策是在更高層次上的決策。在系統分析和系統綜合的基礎上，專案管理人員應根據主觀偏好、主觀效用和主觀概率做出正確決策。決策的本質反映了專案管理者的主觀認識能力，因此，就必然受到人的主觀認識能力的限制。近年來，決策分析技術受到人們的重視，系統分析者將各種資料、條件、模型和演算法放在決策支援系統中，該系統甚至包含了有推理演繹功能的知識庫，便決策者在做出主觀決策後，力圖從決策支援系統中儘快得到效果反應，以求得到主觀判斷和客觀效果的一致。
決策支援系統在一定條件下起到決策科學化和合理化的作用。但是，在專案決策實踐過程中，被決策物件往往包含許多不確定因素和難以描述的現象，例如，社會環境和人的行爲不可能都抽象成數學模型，即使是使用了專家系統，也不可能將邏輯推演、綜合和論證的過程做到像人的大腦那樣，有創造性的思維，也無法判斷許多隨機因素。群決策有利於克服某些個人決策中主觀判斷的失誤，但群決策過程比較長。爲了實現高效率的群決策，在理論方法和應用軟體發展方面，許多人做了大量工作。如多人多目標決策理論、主從決策理論、協商談判系統、衝突分析等，有些應用軟體已實用化。有了決策就要付諸實施，實施就要依靠嚴格的有效的計劃。以軟體發展爲例，爲實現專案的開發任務和發展目標，就要制定階段性的開發計劃和未來的發展規劃。條件許可的話，還要按産品組、專案組、開發人員分別制定實施計劃。一項大的開發專案，涉及設計、開發、研究和編碼等許多環節，每個環節又涉及組織大量的人、財、物。這些都需要制訂計劃來保障。
7.　解決方案的實施與監控－專案管理
專案管理人員按照最佳方案的要求，採取行動，具體落實行動方案，以此解決專案中出現的問題。經過前述系統方法所獲得的解決方案，必需有效實施完成，該項問題才算是解決了，若無法成預期，那麼殘餘的問題或二次問題就要再一次應用系統方法解決問題。解決方案的實施可視為一個「專案」來處理，解決方案的實施過程也必須管理與監控，因此，我們又可藉由專案管理過程來實施既定的解決方案，如下圖所示，以求如期、如質地解決問題。解決方案實施後，還要跟蹤方案的執行效果，檢驗和判斷問題是否得到真正解決。
專案的執行過程正如人的生長過程，可能會出現與計劃相出入的“生病＂現象，處理這種現象就如同給人看病，事後控制不如事中控制，事中控制不如事前控制，可惜太多的專案管理者均未能體會到這一點，開始時麻痹大意、掉以輕心，或者沒有防範於未然，等到實際的結果造成了重大的損失才尋求去彌補，往往是亡羊補牢，為時已晚。

8.　小結
專案管理過程，是一個複雜的大系統。從系統工程的觀點看，專案管理普遍涉及到多個目標的要求，一個優秀的專案管理人員，應該注重實踐中的分析問題能力，結合理論知識，建立系統方法解決問題的能力：系統需求(system requirements)→系統分析(system analysis)→系統綜合(system synthesis)→系統評估(system evaluation)→系統決策(system decision-making)→系統最佳化(system optimization)→系統實施(system implementation)系統實施階段則應用專案管理過程－啟始過程→規劃過程→執行過程→控制過程→結束過程，以提升問題解決成功機率。進而形成一套行之有效的管理方法，並再通過實踐來檢驗它的科學性。正如我們通常所說的，專案管理是一門藝術也是一種紀律，而藝術是無止境的，紀律則確保專案目標的達成。
作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=248</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>專案管理過程中的問題分析與解決_(2)</title>
		<link>http://www.pm-plus.net/?p=237</link>
		<comments>http://www.pm-plus.net/?p=237#comments</comments>
		<pubDate>Fri, 02 Jul 2010 06:18:41 +0000</pubDate>
		<dc:creator>mjkuan</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=237</guid>
		<description><![CDATA[摘要
摘要：我們常常發現，在同一個專案中，不同的專案管理人員可以根據其專業經驗和主觀判斷，選擇不同的管理方法。而應用同樣的管理方法，有的管理人員能取得顯著的成績，有的管理人員卻可能導致專案的失敗。究其原因，是由於人們對問題的不同看法所造成的。因此，在專案管理過程中對問題進行分析有助於提高專案管理人員的問題解決能力、管理水準和實踐能力，進而産生好的專案結果。本文介紹如何應用系統方法解決專案過程中的問題。
 關鍵字：專案管理 問題分析
 目次：
　　1.　 引言
　　2.　系統方法問題解決過程(System approach problem-solving process)
　　3.　 定義問題－系統需求過程(本節內容)
　　4.　問題分析的具體內涵－系統分析過程(本節內容)
　　5.　 解決方案的提出－系統綜合/系統設計
　　6.　評估與決策－系統評估與決策/系統最佳化
　　7.　解決方案的實施與監控－專案管理
　　8.　小結
3.　定義問題-系統需求過程
問題是現狀與目標的「差距」，解決問題的第一步就是定義問題，找出「差距」以確定問題的存在。
定義問題就是對問題的含義、內容本身作出定量、詳細的描述，以便專案小組能夠對問題本身形成一致意見，進而找到問題產生的原因，並針對問題提出解決方案。清楚的問題定義也可以作為將來評判問題是否得以解決的依據。
4.　問題分析的具體內涵-系統分析過程
在專案管理過程中，往往有兩種起不同作用的人員：一種是提出問題者，即專案發起者，他對專案管理的結果進行評估；另一種是解決問題者，即專案管理人員，他對專案管理過程負責。相應地，我們可以將專案管理分成兩部分活動，一是分析問題內容，著重從專案發起者的角度弄清該專案需要解決的問題集合；一是解決問題，著重從專業角度提出和分析各種問題的解決途徑。當然，兩者相互聯繫，問題的內容蘊涵著對解決問題所需資源的要求，而擁有資源又影響到問題內容的邊界。
在分析問題階段，我們應對專案中的某項具體問題和具體解決問題的活動作出詳盡的說明：規定問題的邊界和約束，劃分系統和環境，說明解決問題的對策和資源，並解釋問題內容和解決問題兩部分活動之間的相互匹配關係。此外，在專案管理的實踐中，還需要區分決策者、提出問題者、委託人和系統分析人員。決策者，能夠採取行動去調配資源以改變專案的內容；提出問題者，是對某種態勢感到不安，領悟到現狀和目標不適應的人；委託人，接受決策者的旨意，委託他人從事某項系統分析工作；系統分析人員，是專業人員，應處於不涉及自身利益、沒有偏見的位置。具體地說，我們把分析問題階段的工作內容概括爲5個部分：
4.1　分析問題的性質和條件
這裏包括兩部分內容：分析問題性質和分析問題條件。
分析問題性質主要是分析各種相關聯問題形成的問題集合和它們的來龍去脈，即問題的結構(structure)、過程(process)和態勢(status)。分析問題性質就是要識別、分析造成這一問題的症狀和可能原因。一個已經或正在發生的問題會有許多原因，應盡可能分析全面。通過收集數據和分析研究，對所有可能的原因進行鑒別，從中確定問題的根本原因。
爲此，專案管理人員必須廣泛地和決策者、與專案所有利害關係人進行對話和溝通。可以採用提問單的方式來獲得必要的資訊，例如下列問題：你認爲存在什麽問題？爲什麽這是個問題？如何出現的，什麽原因引起的？解決這個問題的重要性與急迫性何在？可能解決的方式有哪些？誰能採取解決問題的行動？這類行動會帶來什麽影響？等等。通過各種方式的溝通，資料的蒐集，專案管理人員才可能對問題的結構、過程和態勢獲得一個詳細、準確的總體印象，確定解決問題的需求。
分析問題條件主要是分析解決問題所需的資源。爲此，專案管理人員在管理過程中必須知道：涉及哪些專案資源分配問題？由誰實施分配？分配者的職權、作用如何？資源使用的監督、控制系統如何？必要時如何獲得新的資訊？等等。
對問題的性質和條件進行分析，目的在於檢驗問題的性質和條件是否匹配，使工作任務和所需資源相當，更重要的是在資源限制下專案管理人員必須決定問題解決的優先等級。如果力不能及或綽綽有餘都可從兩方面作適當調整，直至大體平衡，從而爲實現最佳化管理打下良好的基礎。
4.2　在里程碑處進行小結
應該將整個專案管理過程劃分爲幾個里程碑階段。每到一個里程碑處，應及時對前段工作進行審查與小結，必要時，並對後續工作進行計劃調整。這項工作的主要內容包括：識別階段工作的重要性；可能採取行動的組織和個人；與專案相關的利害關係人和組織；目標、評價指標(決策準則)、約束條件的初步描述等。通過在里程碑處的小結，專案管理人員可以看出在下一步管理過程中需要解決問題的大體方向和領域，以便給予較大的關注，而對於一些管理效果明顯的領域，則可不必投入較大的精力。
4.3　制訂管理目標
在專案管理過程中，要實施有效的管理方式，關鍵在於儘早明確管理目標。但由於專案開發的特殊性，我們很難從專案發起者那裏獲得準確的描述來判斷管理應達到的目標。管理體制上的隔閡，管理者個人的偏好，專案發起者的知識水準，都可能引起專案管理者在目標制訂上的偏差。
我們認爲，管理目標是分層次的，包括高層目標和低層目標。例如，改善組織的軟體發展能力，提高過程能力成熟度，是高層目標；在具體專案的某一階段節約成本、加快進度，是低層目標。一般說來，越是高層目標越能爲更多的人所接受，使用時期長、範圍廣。低層次目標應服從高層次目標。但是低層次目標比較明確具體，便於分析、管理。所以，管理人員需要全面分析管理目標結構，選擇適當的層次目標。目標太籠統，管理難度大；太具體又容易以偏概全。此外，同一層次的專案管理目標往往不止一個，如在某具體專案的編寫代碼階段，既要提高開發進度，又要保證程式品質，在資源既定情況下，這兩者是彼此衝突的。就是說，如有兩個以上的目標，除非一個目標隸屬於另一個，否則這些目標之間總是彼此矛盾的。在這種情況下，專案管理人員需要對各個目標排出優先次序，首先保證最優先目標的實現，然後盡可能在不損害第一項目標的前提下實現第二項目標，以最大化實現專案的整體目標。
4.4　確定管理效果評價指標
爲了衡量專案管理的效果，管理人員需要確定一組評價指標。一項合理的評價指標能準確的反映管理的效果，但並不是說任何指標都是合理的。例如，採用代碼行數作爲衡量開發人員努力程度的指標就是不合適的，因爲個人的編程風格、所採用的編程語言等，都會影響到這個指標的準確性。
在評價過程中，還需要根據專案實際情況，排出所有指標的優先次序。當存在難以直接量化的目標時，可以採用其他易定量化的代用指標。在有多個指標的情況下，必須將其組合成單一的指標。我們不能簡單的將各種性質截然不同的評價指標硬湊成單一的評價指標，這是不可取的。一般常用的方法是，對每個指標進行權重分析，然後綜合得出一個效用值函數(utility)。值得指出，這種效用函數在很大程度上是專案管理人員本人對各種指標相對重要性程度的判斷結果，具有很大的主觀性。因此，專案管理人員應在系統分析人員的指導下，按照系統分析的方法，科學地分配權重。確定評價指標不只是爲了獲得管理效果的結論，重要的是它所帶來的資訊，使專案管理人員易於把握管理中的薄弱環節，找到解決問題的辦法。
5.識別管理過程中的約束
約束是對專案管理在實踐中的限制。只有不直接或間接違反約束的管理方法，在專案實踐中才是可行的。它可能是資源的限制、組織體制的束縛、法規政策的界限等等。專案管理人員在專案實施中面臨著各類約束條件，如任意選定或全面照顧，都勢必造成整個專案的管理混亂。例如，在某個軟體的開發中，嚴格按照某一技術上的約束去設計，可能需要花費大量的人力、物力，而如果採用其他的方式來解決，並不需要如此巨大的投入。因此，專案管理人員要有能力去權衡利弊，從專案的整體角度考慮問題，必要的時候應放棄此約束條件。
當然，在分析問題階段不可能一次就把所有的約束都弄清楚，這是一個在管理過程中逐步積累、修正的過程。在專案實施的任何階段，發現管理的約束，都應該及時加以補充。
作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=237</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>專案管理組織的設計與選擇_(1)</title>
		<link>http://www.pm-plus.net/?p=224</link>
		<comments>http://www.pm-plus.net/?p=224#comments</comments>
		<pubDate>Wed, 23 Jun 2010 08:14:56 +0000</pubDate>
		<dc:creator>PM-Plus</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=224</guid>
		<description><![CDATA[摘要
20世紀初引進的廣為人知的命令、控制式組織結構正在迅速地退出歷史舞台，取而代之的是以任務為導向的、自我取向、自我管理的工作團隊和形形色色的專案化組織形成。在這些情況下，對員工的授權取決於這些新的組織結構。不論是組織結構的管理、組織結構的改善或是組織結構的重新設計，為了應對這種組織結構的變革和員工的充分授權，我們都需要擁有堅實的專案管理技能。在21世紀，專案管理勢必成為新的典範轉移(Paradigm-shift)。專案式的管理(Management by Project Managing或Organization By  Projects)將成為企業組織的最有效的經營管理模式。此外，美國學者 David  Cleland稱：在應付全球化的市場變動中，策略管理和專案管理將產生關鍵性的作用。因此，我們必須因應策略專案的實施，建立適當的組織結構。
 目次：
　　1.　 前言(本節內容)
　　2.　專案組織的發展(本節內容)
　　3.　傳統的組織環境
　　4.　專案卓越辦公室(Project Management Center of Excellent)
　
 1.　 前言
關於組織的理論有大量的著作，這是工業心理學家最喜歡討論的話題。和組織行為一樣，組織的形式(form)和秩序(order)多種多樣。經驗顯示，儘管組織秩序已經由管理層進行了合理設置，但是如果沒有向團隊成員和其他專案參與者充分解釋，那麼，這些根據組織秩序中定義的流程和關係來開展工作的人們就會感到困惑。如果流程中能夠清晰地定義好個人的和組織的角色和相互關係，大部分的困惑就會消除。最好的辦法是組織結構本身應該暗含這種秩序，例如問題解決(problem solving)、衝突解決(conflict resolution)和資訊分發(information)的邏輯路徑(logical path)，即便如此，在組織章程(organization chapter)中也應對此進行明確定義，並由專案經理不斷強調。
每個專案經理都需要調整組織結構以適應專案週期不同階段的需要。當有效的管理(effective management)、領導能力(leadership)和工作團隊(teamwork)已經對專案成功做出了相當大的貢獻時，最佳化組織結構(optimum  organization)往往能極大地影響專案的績效(performance)和效率(efficiency)。在大多數的組織中，除非專案是公司中的主要部分，一般專案經理都沒有權力去重新制定專案之外的會報關係(reporting  relationships)。例如，在一個矩陣型結構的公司裡，你通常沒有權力選擇專案型的結構。如果你處在一個穩定的、傳統階層結構的組織中，試圖去向矩陣型轉換，或者試圖創建跨部門的專案團隊，那麼這可能是最耗時費力的挑戰。1然而，理解各種組織的優勢和劣勢，將有助於你在權限範圍內更高效地工作，當發現某種改變可以取得高回報時，應積極推動這種改變的發生。下面會講到專案組織  ─  一個建立工作組織的管理元素。
 2. 　專案組織的發展
策略專案組織的設計應對團隊的權限範圍(dominant interfaces)和溝通管道(communication channels)起積極作用。專案團隊的目的是保証專案需求得以滿足，所以在專案需求確定之後很重要的事情就是建立專案組織。在實踐中，核心團隊(開始時包括專案經理、系統工程設計經理和其他領導人員)在調研階段就應當適時參與。
矩陣型組織(matrix organization)適合於大多數策略專案，因為它融合了純職能型因素和純專案型因素，其中的每一種都可能滿足某個特殊的專案或者環境需要。在研究了每種組織的優勢和劣勢後，我們將解釋選擇它們的主要原因。
 2. 1　客戶導向的組織
許多組織是由客戶驅動的。它們的運營過程和日常運作是按直接和客戶相關的方式設計的，它們衡量成功的標準也是直接和客戶相關的方式設計的，它們衡量成功的標準也是和客戶相關的。這樣的組織通常分配專人來了解客戶的要求並以專案的方式對其進行反饋，即或者以專案的方式來實現客戶的要求，或者指派專人（如專案經理）來處理客戶的需求。
“如果你不直接支持客戶，那麼就支持那些直接支持客戶的人。(If you don’t support the customer directly, you support someone who does support the customer directly.)”在今天的許多組織中，你對組織所做的貢獻正是按這種標準衡量的，即使你工作的責任在多大程度上體現了上述論述。如果你未對組織做出貢獻，你的經理就會想：為什麼要繼續雇用你這傢伙？記住，並不是你只要露了面就可以得到報酬！客戶到你那裡是期望得到立即滿足。如果你做不到，他們會去找那些能讓他們立即滿足他們的人。
這對專案經理而言意味著什麼呢？簡而言之，最基本的，也就是通過參與專案你需要找到給組織增加價值的途徑。而這些專案是以加強與客戶的關係，改善組織中和客戶相關的過程和商業程序為中心的。與此同時，你也需要通過參與專案來得到一個學習新技術或增強己有能力的機會。即使你現在參與的專案中沒有這樣的機會，也請記住，專案是提高你專業能力的很好途徑。你應該隨時隨地利用一切可能主動去尋找這樣的機會。
 2.2 　從功能型向過程型演化
隨這組織越來越專注於過程(Process)，對於博學的專案經理的需求也相應增加。這種趨勢並不見得會導致所需的專案經理的的數量增加，但確實增加了對於博學的專案經理的需求。
許多客戶導向的組織已經從曾經很流行的功能結構(functional structure)，例如市場、銷售、財務等，轉向了更專注於過程的結構(process structure)，例如訂單獲取到訂單完成、產品研發過程等。這種轉變使得企業可以根據能直接反映客戶需求的過程來定義自己的運作。企業重構運動促使了這種轉變。成本縮減、市場反應時間減少、生產率提高以及其他一些活動定位了這種轉變的種種特徵。
這對專案經理而言意味這什麼呢？這意味著在已經實現或者正在實現這種變革的組織中，為專案經理提供了無限發展的機會。對處於轉變中的組織而言，存在無數專案，這些專案都是為了定義和和實現代替功能方式的過程而服務的。
在已經完成轉變的組織中，有進行過程品質改進專案的機會，以此來磨勵新的商業模型。舉例來說，新實現的過程很可能達不到管理層期望的水平，因此改進勢在必行，而且一些意在進行這種改進的短期專案將被批准。這就給了專案經理和他的團隊許多進一步了解其組織業務功能和過程機會。我們將討論參與各項專案如何為特定的技能發展和職業成長提供機會。
 2.3 　任務突擊隊
伴隨著組織的種種變化，一種混合模式的組織結構應運而生，如魚網式、T 型、網絡式和無邊界式組織。許多這類新組織結構都是縮小規模和授權給員工的直接結果。這些新型式按任務突擊隊分類。
通常，我們認為任務突擊隊在於承擔一些責任和使命。它們是短暫的；一旦任務完成，該突擊隊也就不復存在。這種狀況類似於專案結構，只不過任務突擊隊成員一般都是兼職的。
如圖 1 所示的永久任務突擊隊承擔著特殊的責任，獨立於部門而行使，跨越若干功能領域而提供建議和培訓。各功能領域則充當支持者的角色。
永久任務突擊隊有以下 4 個優點：  
它和純專案的方式相同。在這種情況下，專案在組織下中有著很高的可視度(visibility)。資源不是為各專案所共享而是分配給各專案並受控於專案經理。任務突擊隊更適合於不斷變化的情況，能夠方便的做出相應的進度變化，並且通常能更好的控制成本。
它授權於員工並賦予責任和權利。任務突擊隊是獨立自主的，這意味著完成專案所需的技能必須存在於一個或幾個專案團隊的成員中。按照專案計劃，這些擁有專案技能的成員會有更多的自主權來完成他們的任務。
它通常更能鼓舞士氣。每個專案成員都帶給團隊某些特殊技能，因此他們的重要性都被認可，從而增加了自主性和士氣。
它提高了生產率和品質。因為團隊依賴於自己和他們自己特殊的貢獻，因此團隊成員擁有高漲的責任感，從而產生更高的生產率和品質。
這種永久任務突擊隊結構也有其缺陷：
實現時間較長。組建團隊需要時間。團隊成員必須先相互了解各自的工作習慣、人際技巧和會產生衝突的方式，然後才可能作為一個團隊開始工作而不是簡單的一組人而已。少有機會發展特殊機能。團隊成員為專案貢獻他們的特殊技能，因此較少有機會發展專案所需之外的新技能。
失敗的風險高。個人通常很難完成從自己為中心轉向成以團隊為中心的轉變，而通常又沒有幫助完成這種轉變的培訓。有太多的工作需要做，進度又很有挑戰性，通常專案經理都沒有意識到所需的培訓的價值。
沒有清晰的職業生涯。正因為專業技能的發展受到限制，所以職業成長和發展的機會同樣受到限制，使個人被困於任務突擊隊的結構中。
永久任務突擊隊的典型例子是自我管理、自我取向的團隊。團隊具有完成所分配任務所需的所有技能。如果缺乏某種技能，團隊有責任培訓他的成員或者另找擁有這種技能的成員。團隊通常有損益職責和用人的權力。從某種意義上論，團隊是企業中的企業。這種結構被認為是有效的專案管理。而事實上，這種任務突擊隊要想行之有效，有效的專案管理是其先決條件。因為這種團隊是永久的結構，他們擁有專案團隊所擁有的優勢。

 2.4 　專案驅動的組織
專案驅動的組織(Project Driven [...]]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=224</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>專案管理過程中的問題分析與解決_(1)</title>
		<link>http://www.pm-plus.net/?p=215</link>
		<comments>http://www.pm-plus.net/?p=215#comments</comments>
		<pubDate>Mon, 14 Jun 2010 21:34:24 +0000</pubDate>
		<dc:creator>PM-Plus</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=215</guid>
		<description><![CDATA[ 摘要
摘要：我們常常發現，在同一個專案中，不同的專案管理人員可以根據其專業經驗和主觀判斷，選擇不同的管理方法。而應用同樣的管理方法，有的管理人員能取得顯著的成績，有的管理人員卻可能導致專案的失敗。究其原因，是由於人們對問題的不同看法所造成的。因此，在專案管理過程中對問題進行分析有助於提高專案管理人員的問題解決能力、管理水準和實踐能力，進而産生好的專案結果。本文介紹如何應用系統方法解決專案過程中的問題。
 關鍵字：專案管理 問題分析
 目次：
　　1.　 引言(本節內容)
　　2.　系統方法問題解決過程(System approach problem-solving process)(本節內容)
　　3.　 定義問題－系統需求過程
　　4.　問題分析的具體內涵－系統分析過程
　　5.　 解決方案的提出－系統綜合/系統設計
　　6.　評估與決策－系統評估與決策/系統最佳化
　　7.　解決方案的實施與監控－專案管理
　　8.　小結
 1 引言
在專案管理過程中，並不是每一個出現的問題都能得到順利、及時地解決的，需要在反饋資訊的基礎上反復進行分析。管理人員在獲得專案開發過程中輸出的中間結果或最後階段的結果後，都可能改變最初的設想，或收集更多的資訊以修正原來的結果，甚至於修正原來的計畫。例如，專案經理在弄清解決方案的後果以前，往往難以有把握地提出某項目標；在獲得某些資訊後有可能加強管理力度，增加管理約束條件，修改原有的管理計劃等。此外，在專案管理過程中的要重視管理人員和專案發起者之間的溝通和對話。各個管理環節和管理階段都需要專案發起者的建議和判斷。而且，不斷對話意味著專案發起者考慮了問題的各個方面，感到親自參與了專案管理過程，使管理過程獲得支援，從而不至於因阻力太大而失敗。然而在實踐中，專案管理人員往往將問題簡單化，他們習慣於對專案中所有需要解決的問題進行精確定義，劃定其各自的邊界並直截了當地讓某些因素嚴格按管理計劃要求發生變化或保持不變。因此，專案管理所面臨的是一個由事態、組織、人員等因素組成的複雜的問題集合，對問題進行分析尤爲重要。
2. .系統方法問題解決過程(System approach problem-solving process)
專案團隊在實施專案計劃的過程中，總會遇到這樣那樣的問題。
有的問題很嚴重，如專案的執行結果根本滿足不了客戶的要求；有的則屬一般問題，如專案比計劃進度晚了一個星期，但並沒有給客戶帶來特別大的負面影響。有些是技術問題，如設備安裝後，總出現一些故障；有些則是非技術問題，如專案小組與客戶在工作分工上出現分歧。專案團隊是否有效解決問題，會直接影響到專案的成敗，因此，必須有一個規範、創造性和有效地解決問題的方法。
要解決專案過程中的問題（problem），首先就要明確何謂「問題」。根據KT 法創始人Charles H. Kepner &#38; Benjamin B. Tregoe 指出：問題是現狀（實際態勢、預期狀態、料想不到結果）與目標(應有態勢、期待狀態、預期結果)之「差距」(gap)。問題類型有三：(1)發生型：已經發生之問題；(2)探索型：精異求精之問題；(3)設定型：何去何從之問題。可藉由創新問題解決理論（TRIZ）、限制理論（TOC）、問題魔法屋（PsFD）、腦力激盪術（BS）、心智圖（Mental Map）、魚骨圖、Kj 法…等技術和方法找出問題真因與解決對策。
接著我們要瞭解何謂問題解決（Problem Solving, Ps）。問題解決始於某一問題之存在，當實際狀態（actual status）與目標狀態（target ttatus）間有差距（落差）存在之時，問題乃應運而生。問題解決需先經確認目標狀態後，個體（或群體）將採用一系列複雜「心智運作過程（歷程）」，以達目標狀態。而問題解決之心智運作過程  (歷程)  即為「問題解決程序（Problem Solving Process, PsP）」。換言之，問題解決是一個過程，也是由許多子過程形成的一個為了達成解決問題目標的一個「系統」。
系統方法解結問題是一種以系統思考為基礎解決複雜系統問題的程序：系統需求(system requirements)→系統分析(system analysis)→系統綜合(system synthesis)→系統評估(system  evaluation)→系統決策(system decision-making)→系統最佳化(system optimization)→系統實施(system implementation)  系統實施階段則應用專案管理過程－啟始過程→規劃過程→執行過程→控制過程→結束過程，以提升問題解決成功機率。這種基於系統工程與專案管理的問題解決程序見下圖所示。以下我們介紹如何應用

作者：管孟忠 博士　開南大學 專案管理研究所
]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=215</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>能力成熟度整合模式之發展及其在系統工程中的運用(1/5)</title>
		<link>http://www.pm-plus.net/?p=206</link>
		<comments>http://www.pm-plus.net/?p=206#comments</comments>
		<pubDate>Fri, 04 Jun 2010 02:32:07 +0000</pubDate>
		<dc:creator>PM-Plus</dc:creator>
				<category><![CDATA[文章分享]]></category>

		<guid isPermaLink="false">http://www.pm-plus.net/?p=206</guid>
		<description><![CDATA[ 摘  要
系統工程在國防工業中扮演重要之系統獲得的角色。該角色需能提供國防系統工程分析、獲得、及軟體工程等能力成熟度，以進行國防系統獲得及系統研發績效標準之指引與評量。由於國防系統的獲得與運作是迥異於企業以重複穩定製造生產或提供固定服務的產業模式，因此，必須以專案處理，惟專案建置因其暫時性和獨特性，較難事先具體而微地描述期望輸出，必須配合國防專案開發生命週期，採用能力成熟度模式整合，以循序漸進的方式，將各階段所輸出之基準作為專案範疇的最新定義，同時以系統工程的核心思想來貫穿處理國防系統獲得專案。
能力成熟度模型(Capability Maturity Model；CMM)原是一種用於評價軟體承包能力並幫助其改善軟體品質的方法，也就是評估軟體能力與成熟度的一套標準，它側重於軟體發展過程的管理及工程能力的提高與評估。其後CMM發展到其他相關領域，陸續衍生出其他CMM族的多種模型，形成整合軟體工程(SW)、系統工程(SE)、整合式產品與過程(IPD)及軟體採購(SA)等的整合模式，稱為能力成熟度整合模式(CMMI)。本文首先介紹CMMI之發展與應用現況，然後闡述流程導向的管理在國防體系中所扮演的系統工程、技術能量之獲得與運作維持的角色，同時介紹CMMI應用於國防體系的主要模組：SE-CMM、SW-CMM、IPD-CMM、  SS-CMM和People-CMM，進而建構CMMI知識本體的概念性框架，最後研究如何將CMM/CMMI知識本體應用於系統工程和系統獲得的整個生命週期中，以提昇持續改善國防系統獲得及系統工程流程之能力成熟度。
關鍵字:  能力成熟度整合模式(CMMI)、系統工程(SE)、系統獲得(SA)、SE-CMM、SW-CMM、IPD-CMM、SSCMM、PM-CMM
 1.  前言
 1.1.系統工程與系統獲得管理
在國防系統獲得過程中，系統工程(System Engineering)和系統獲得(System Acquisition)融合各種工程學科的努力將國防系統需求轉換為貫穿系統整個生命週期的獲得工程實施指南。系統工程是屬於系統方法中偏向硬性工程問題之範疇，其相關之內容及作法與系統分析(System  Analysis)和系統管理(System  Management)均有密切關聯，而所謂以系統管理方法執行系統工程，其最大之目的乃在於增進及協助管理人員(Manager)及工程師(Engineer)之間，對系統工程管理問題的處理獲取共同的認知，使確實能滿足顧客要求(customer’s needs)及系統需求(System Requirements)。由於專業領域的不同，功能部門管理者與工程部門工程師之間，在觀看問題的眼界、分析問題的途徑及解決問題的方法均有極大之差距，甚至易於發生衝突。因此，在系統管理的理論基礎上研究系統工程之課題，能增進管理與工程人員之共識，尤其是對以工程技術的研究發展專案管理(R&#38;D Project Management)而言，這種專案團隊對系統獲得的共識之建立無疑是極為重要的。
國防系統主要獲得來源有向國外直接採購、與國外合作開發及自立研製等三方面。由於國防系統發展的獨立特性，故國防獲得常以專案(project)或專案群(projects or program)方式來處理。為達成武獲目的，對於各項武獲專案在種種限制因素下所推動的系統分析(system analysis)、系統工程及系統管理等活動，如何有效整合及運用有限的資源以達成專案目標，則有賴於有效率的國防獲得流程，為此，流程管理(process management)領域知識的研究，特別是CMMI流程標準系統，就成為改善武獲流程的必要課題。
1.2.  能力成熟度模式
能力成熟度模式(Capacity Maturity Model; CMM)基本上是建立在統計流程控制(Statistical Process Control; SPC)理論基礎上的一種管理模式。從統計流程控制理論的實踐中，發現所有成功的企業的共同特點是它們都具有一組嚴格定義、完善管理、可量測、可控制而高度有效的作業流程(Operational Process)，並以流程導向進行經營管理。
系統工程能力成熟模式（Systems Engineering Capability Maturity Model; SE-CMM）是一種衡量系統工程實踐能力的方法，是一種使用工程流程導向的方法論。而軟體成熟度模式(Capability Maturity Model for Software; SW-CMM)則是透過軟體工程的理論基礎與全面軟體品質管理(Total Software Quality Management; TSQM)的機制，剖析探討軟體發展流程的持續改善之問題。此外，還有整合產品發展成熟度模式(Capacity Maturity Model for Integrated Product Development；IPD-CMM)是應用於整合產品與製程發展與管理，以落實同步工程的機制。
至於應用在現代專案管理領域之成熟度模式即稱為專案管理能力成熟度模式(Project  Management Capability Maturity Model; PM-CMM)，並以實現值(Earned Value; EV)之觀念作為專案績效衡量模式，又稱之為實現值管理成熟度模式(Earn  Value [...]]]></description>
		<wfw:commentRss>http://www.pm-plus.net/?feed=rss2&amp;p=206</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
