Archive for 一般

Diagram Tools 圖表工具

PMBOK的圖化工具重點落在Project schedule network diagram跟品質管控的部份:

  • Process Flow Diagram
  • Project Schedule Network Diagram
  • Data Flow Diagram
  • Network Diagrams
  • Context Diagrams
  • Affinity Diagram
  • Precedence Diagramming Method (PDM)
  • Cause And Effect Diagrams
  • Flowcharts
  • Pareto Diagrams
  • Histrograms
  • Control Charts
  • Scatter Diagrams
  • Interrelationship digraphs
  • Tree Diagrams
  • Matrix Diagrams
  • Influence Diagrams

  • Tornado Diagram

  • Decision Tree Diagram

  • Activity Network Diagrams

 

廣告

發表迴響

Analysis Tools 類工具

分析的重點就在設法把判斷轉換為實際可執行的專案管理計畫,因此除了第四章整合知識領域不會有之外,其他各知識領域都會有,在五大程序中主要落在planning程序大類。此外,專案的執行結果也必須用分析進一步了解專案的狀態-範圍、時間、成本、風險-並將分析結果呈現給利害關係人:

GENERAL

  • Reserve Analysis
  • Variance Analysis
  • Trend analysis
  • Root cause analysis
  • Multi-Criteria Decision Analysis

INTEGRATION

  • Regression Analysis
  • Causal Analysis
  • Failure mode and effect analysis (FMEA)
  • Fault tree analysis (FTA)

SCOPE

  • Multi-criteria decision Analysis
  • Document Analysis
  • Product Analysis

TIME

  • Alternative Analysis
  • Schedule Network Analysis
  • What-If Scenario Analysis
  • Monte Carlo Analysis

COST

  • Vendor Bid Analysis
  • Earned Value Analysis

QUALITY

  • Cost-Benefit Analysis
  • Force Field Analysis
  • Process Analysis

COMMUNICATIONS

  • Communication Requirements Analysis

RISK

  • Stakeholder Risk Profile Analysis
  • Strategic Risk Scoring Sheets
  • Documentation reviews
  • Information gathering techniques
  • Checklist analysis
  • Assumptions analysis
  • Diagramming techniques
  • SWOT analysis
  • Risk probability and impact assessment
  • Probability and impact matrix
  • Risk data quality assessment
  • Risk categorization
  • Risk urgency assessment
  • Interviewing
  • Probability distributions
  • Sensitivity analysis
  • Expected monetary value analysis

PROCUREMENT

  • Make-or-Buy Analysis

STAKEHOLDER

  • Stakeholder Analysis

Others

  • Prototypes
  • Alternatives Identification
  • Decomposition
  • Rolling Wave Planning
  • Templates
  • Dependency Determination
  • Applying Leads and Lags
  • Schedule Network Templates
  • Critical Path Method
  • Critical Chain Method
  • Schedule Compression
  • Benchmarking
  • Design of Experiments
  • Statistical Sampling
  • Organization Charts and Position Descriptions
  • Planning Meetings and Analysis
  • Contract Types
  • Proposal Evaluation Techniques

發表迴響

專案時間不足 如何達成不可能的任務

軟體專案開發常常會面臨時間不足的問題。 大多數軟體開發人員都不希望青春浪費在無意義且永無休止的加班上,然而,現實就是如此殘酷,受限於市場競爭壓力的考量,為了爭取案子,常常會不得不遷就營運觀點,而放棄工程與技術的堅持,因而使得專案無法爭取到合理的開發時間。

 

工程與技術的妥協

在台灣,軟體定價通常是由市場供需機制決定,不見得可以考量到軟體開發的成本。當市場競爭愈激烈時,軟體的價格相對降低。當軟體專案把軟體價格當做專案成本估算的基礎時,這樣軟體開發就會沒辦法重視專業,只能讓外行(市場因素)領導內行(研發設計專業),軟體開發者的痛苦夢魘於是從此開始。

開發單位為了獲利,於是就必須想辦法降低開發成本,但因為軟體價格實在太低了,開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的理想,無奈現實通常是「時間總是不夠」。

從我在工作上的觀察中發現,不少的管理者會將這個問題焦點放在團隊生產力上,以提昇軟體的開發效率來縮短開發時間。不過,實際上卻不見軟體開發成果獲得到顯著地提昇。

 

生產力的迷思

通常,管理者會希望軟體開發者加班或是增派開發人力,來提昇軟體開發的生產力。軟體開發每日總工時增加了,照理說應該是可以增加軟體開發的效率,但卻也因此引發出新的問題。像是,隨著每日工作時數或開發人力增加軟體開發出錯的機率反而增加,反而降低了軟體開發的效能。

為什麼會這樣呢?綜歸一句話,生產力增加了卻讓軟體開發變得更複雜,使得團隊無法有效整合、發揮綜效。而這種現象又可從兩個方面來看,一方面是加班讓開發者身心耗弱、無法集中心力來完成任務,因此常因為工作疏忽而產生錯誤,反而讓問題變得更複雜,需要花更大的心力來解決。另一方面則是團隊規模變大,需要更多的溝通時間與成本來整合工作成果,因此每個人的工作量不減反增,同時又有意見分歧可能引發團隊衝突影響專案績效的風險。

理論上,壓縮專案時程可以運用趕工(crash)或作業重疊(fast tracking)的方式來減少開發時間。趕工讓工作者加班而增加開發成本,作業重疊則會增加工作產出重工(rework)的風險。因此,原本以為只要多付一些成本來支應加班的需求或加強風險管理就可以達到時程壓縮的目標。然而,由前面的分析我們卻可以發現到,軟體開發的複雜度經常超乎我們想像,由此可知,軟體專案的時程上的妥協其實是很難用成本來彌補的。

我最近才聽到朋友告訴我一個軟體專案失敗的案例。該專案是以另一個將近結案的專案為基礎。原來他評估勉強半年可以完成,本來公司把專案交由他負責,但最後專案經理卻因為客戶的意見而交由負責該客戶的業務來掛名,實際上專案由我的朋友來負責開發。

然而,當我的朋友才開始需求訪談時,專案經理卻告訴我的朋友他程式開發時間要在三個月內完成。而在我的朋友認為,應該研讀前一個專案的程式碼,以求了解程式架構以後才能根據客戶需求加以修改,那位專案經理卻以前專案「沒有問題」為由,要我的朋友立刻著手動手修改程式,後面再來處理其他問題。

雖然我的朋友還是在時限內完成了程式,不過,這時候問題才真正開始。客戶驗收後提出了上百個程式錯誤。這時候我的朋友才發現,這專案所依據快結案的專案本身就有很多問題,事實上,有3/4的bug都是那個專案本來就有的。

此外,客戶還提出了一些原先沒談到的需求,而那位專案經理則要求我的朋友要在不增加時間的情況下照單全收。因此,在需求不斷膨脹的情況下,這個專案最後還是失敗了。當然,最後那位專案經理把失敗的所有責任都推到我朋友身上。

相信任何有經驗的軟體開發者看到這故事都會了解,那個專案經理實在是太外行了。他以為軟體開發只是依據客戶的需要來產出程式,認為只要壓縮開發者的時間來產出更多的程式就可以解決問題。殊不知軟體開發在缺乏產能的情況下,再多的產出也只是徒增軟體的複雜度與風險,這樣要完成專案目標只能靠聽天由命了。

 

開發產出與產能之平衡

由此可知,在專案開發時間不足的情況下,生產力迷思下的程式產出,其實多半無法具有實質效用。開發者在龐大時間壓力難有思考的空間,將使他的產能逐漸耗竭殆盡。即使在剛開始,一時滿足了客戶的需要,然而長久下來,卻在無形之中增加了專案的複雜度,最終只會在耗盡開發者的青春與熱情之後,得到專案失敗的苦果。

因此,在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。

至於如何增進良好設計架構的產能呢?依我軟體專案開發的實務經驗來看,關鍵在於必須同時兼顧客戶價值與開發風險。而要做到這一點則必須要讓開發者與客戶充分溝通。

我常常觀察到許多開發者習慣把客戶提出來的功能直接當做軟體需求規格,卻沒有深入分析客戶真正遇到的問題。他們以為問題領域、業務流程或現場作業等知識是客戶的專業,開發者無從介入,因此往往在不知客戶要求之所以然的情況下,直接把客戶的話轉換成軟體規格。

然而,客戶所知道的並不是軟體需求(requirements),他們對系統的觀點只能顯露出他們對系統的需要(needs)。需要是抽象而片斷的,本身是非結構化的,而可用的軟體需求卻必須是具體而完整一致的,具備結構化的特性。

因此,如果開發者沒有針對客戶需要分析他們的問題,設計解決方案,只是直接把客戶的想法直接轉成軟體規格的話,客戶心中想的那朵雲,隨時都會變幻出各種不同的形狀,需求不斷變動乃是必然。如果開發者沒做適切的分析及設計,只靠技術是很難滿足客戶多變的渴望與需要的。

事實上,軟體開發是知識與腦力密集的工作。自許為知識工作者,重要的不在於產出的數量,而在產出的品質。要讓產出具有足夠的品質,必須要在問題領域的分析投入足夠的時間,才可能為客戶設計出可以解決他們問題的軟體,為客戶創造價值;軟體也才能具備足夠彈性適應客戶千變萬化的需求,有效地降低開發風險。

 

正確的溝通

於是,當我們用以上的思路來看軟體開發時,縱使專案沒有足夠的開發時間,我們依然要會從客戶的立基點中去思考問題,並從中找出最可行的技術來創造客戶的最大價值。同時,在這樣的情況下,開發者展現了足夠的專業,客戶也會很自然地信任開發者誠意與專業,形成了良性的雙向溝通。

在這種客戶與開發者良性溝通的情況下,客戶可以決定了時程、成本、品質等限制條件,而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。

也就是說,客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則針對問題分析出需求規格、發展出技術架構,並據此實作出軟體後再交由客戶驗收。然後,客戶再依軟體實際使用狀況予以回饋,開發者再依照客戶的意見反覆地演化系統,使軟體更趨於完善。

理想狀態是,客戶應該優先提出最關鍵及最核心的業務問題,而開發者則必須針對這些問題分析,發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決,而開發者也可以針對客戶問題而設計,而不會浪費時間與成本在過度設計上,降低了軟體開發的風險與複雜性,使得產出與產能可以相互配合。

開發產出與產能相互平衡,才不會偏廢於需求面或技術面,使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠,至少也可以用空間換取時間呀。無論如何,客戶至少都會擁有一個可用的系統,而不是一堆無法正常運行的程式碼與文件。

發表迴響

項目管理9大知識體係與5個具體階段

驅動21世紀新型商務企業發展的原動力是什麼?有人答曰:項目管理。的確,項目管理作為一門新興的學科,發展之快已超過了我們的想像。美國Fortune雜誌甚至預言,項目經理將是21世紀的首選職業。讓我們共同走近項目管理。

“金字塔工程”到“北極星導彈計劃”
論起項目管理的起源,其實很早。古代諸如金字塔、長城等著名的偉大工程項目的成功,都得助於當時對工程項目進行的嚴密和科學的管理。 20世紀60年代初,在著名數學家華羅庚教授的倡導下,將項目管理的概念引入了我國,並在當時的國民經濟各個部門進行試點應用,將這種方法命名為“統籌法”。之後,中國科學院管理科學與科技政策研究所,還牽頭成立了“中國統籌法、優選法與經濟數學研究會”。改革開放後,項目管理在水利、建築、化工等領域開始被大量地應用起來。 2000年底,聯想在“天麒”、“天麟”兩款計算機產品的開發過程中,結合業務對項目管理的需求,配合項目管理相關理論、方法編制軟件方案,使該項目在8個月的時間內便全部完成,並達到了國際上PC生產技術的最高水平。

現代項目管理的概念起源於美國。上個世紀五十年代後期,美國的Booz-Allen Lockheed公司首次在北極星導彈計劃中運用了PERT技術。同一時期,美國的Dupont and RamintonnRand公司創造了CPM方法,用於研究和開發、生產控制和計劃編排,結果大大縮短了完成預定任務的時間,之後它們分別被稱為“計劃評審技術”和“關鍵路徑法”。現代項目管理科學便是從這兩項技術的基礎上迅速發展起來的,融合了後來發展起來的WBS工作分解技術、蒙特卡羅(Monte Carlo)模擬技術和EV掙值分析技術,形成了一門關於項目資金、時間、人力等資源控制的管理科學。著名的阿波羅登月計劃、曼哈頓計劃等都是採用項目管理的理論和方法而取得成功的經典案例。

9大知識體係與5個具體階段
早期的項目管理主要關注的是成本、進度(時間),後來又擴展到質量。最近十幾年間,項目管理逐漸發展成為一個涵蓋9大知識體系、5個具體階段的單獨的學科分支。 9大知識體系包括:

  1. 集成管理在項目分析中,項目管理人員必須把各種能力綜合起來並加以協調利用。
  2. 範圍管理定義項目的邊界,著眼於“大畫面”的事物。例如項目的生命週期、工作分工結構的開發、管理流程變動的實施等。
  3. 時間管理要求培養規劃技巧。有經驗的項目管理人員應該知道,當項目出現偏離規劃時,如何讓它重回規劃。
  4. 成本管理要求項目管理人員培養經營技巧,處理諸如成本估計、計劃預算、成本控制、資本預算以及基本財務結算等事務。
  5. 人力資源管理著重於人員的管理能力,包括衝突的處理、對職員工作動力的促進、高效率的組織結構規劃、團隊工作和團隊形成以及人際關係技巧。
  6. 風險管理需要管理人員在信息不完備的情況下作決定。風險管理模式通常由三個步驟組成:風險確定、風險影響分析以及風險應對計劃。
  7. 質量管理要求項目管理人員熟悉基本的質量管理技術。例如:製作和說明質量控製圖、實施80:20規則、盡力達到零缺陷等。
  8. 採購管理項目管理人員應掌握較強的合同管理技巧。例如,應能理解定價合同相對於“成本附加”合同所隱含的風險。應了解簽約中關鍵的法律原則。
  9. 溝通管理要求項目管理人員能與他們的經理、客戶、廠商及屬下進行有效的交流。

5個階段是:

  1. 項目啟動、
  2. 項目計劃、
  3. 項目執行、
  4. 項目控制、
  5. 項目收尾。

除此之外,作為一個稱職的項目管理專業人員,還必須具有相應的通用管理知識和經驗、相關的業務知識背景以及精深的風險管理經驗。也就是說,項目經理應當是一個具有相當豐富的知識並具有合理知識結構的高級複合型人才。

現在,項目管理在全球範圍內被政府、大型公司、企業以及小型非贏利組織廣泛地採用。與此同時,具備項目管理經驗和項目領導才能的管理者,在職場上變得炙手可熱。因為全球化的競爭要求新項目和新業務的發展都要在預算範圍內按時完成。

向項目管理要高效
項目是一項為了達到一個特殊目的而進行的臨時性活動。每一個項目有明確的開始和結束時間,項目能夠由組織的各個層次創建;涉及的人數可以是一個人,也可以是上千人;可以只涉及一個單獨的部門,也可以是跨部門的合作。項目管理可以應用於任何項目,而不受它的大小、預算或期限的限制,例如:

  • 開發一個新產品或服務;
  • 設計一個新車型;
  • 運作一次政治競選;
  • 建一座大橋;
  • 發射火星探測器;
  • 建立一個電子商務站點。

那麼,什麼是項目管理呢?按照PMBOK2004的定義,項目管理是運用相關的知識、工具和技術管理的活動,目的是滿足客戶對特定項目的要求。項目經理負責管理整個項目,他的工作主要是:

  • 在項目範圍、時間、成本、風險和質量之間做出最佳平衡;
  • 滿足不同項目干係人的不同需要和期望;
  • 實現既定的需求目標。

理想情況下,所有的企業都能夠從項目管理中獲益,特別是在管理資本投入和間接活動的花費上。在當今快速多變、全球化的市場環境下,所有類型的企業都需要看到它們投資在固定資產設施、房地產建設以及一些設備的升級上面的回報和收益,或者要對一些內部功能的管理和跟踪,如IT項目、市場項目等。無論什麼行業,項目管理都可以使企業通過更好的信息共享來提高生產率和降低成本,在有限的資源條件下更快地以更低的成本交付產品和服務,從而增加營收。

項目管理可以幫助企業通過把日常工作標準化、減少可能被遺忘或被忽略的任務,來達到客戶的期望值;項目管理也能使可利用的資源以最有效的方式得到最佳的利用;項目管理還能使高級管理者洞察到組織內正在發生的和將要發生的事件。
項目管理原則的應用能夠幫助高級管理層做到:

  • 建立成功的衡量指標;
  • 以客戶為中心並與客戶保持一致;
  • 量化體現價值的成本;
  • 優化組織資源的使用;
  • 貫徹質量原則和標準;
  • 實施戰略計劃;
  • 縮短新產品的研製週期并快速進入市場。

世界範圍內許多企業及組織,例如美國航空航天局(NASA)、IBM、AT&&T、西門子、Chiyoda Corporation、普華永道等,都把項目管理用於管理創新過程,用於計劃組織和控制戰略活動,用於監控企業的績效以及分析重大偏差,並預測它們對組織的影響等。

面向普及,走向協作
在激烈競爭的環境下,面對各種複雜的項目有大量的信息與數據需要動態管理,要提高管理水平與工作效率,就必須使用先進的方法和工具。有數據表明,美國項目管理人員中,有90%左右的人已在不同程度上使用了項目管理軟件。其中,有面向計劃與進度管理的,有基於網絡環境信息共享的,有圍繞時間、費用、質量三坐標控制的,也有信息資源系統管理的。
在過去的十幾年裡,項目管理得到了普遍的應用,這是因為我們的工作環境發生了以下一些變化:

  • 集約化(更少的人做更多的事);
  • 項目和服務變得更大和更複雜;
  • 激烈的全球競爭;
  • 網絡的普及;
  • 客戶對高質量的產品和服務需求日益多樣化;
  • 新技術的快速更替;
  • 跨國公司對項目管理進行劃一的管理。

目前,項目管理已由適用於對某個項目進行管理,擴展到採用項目管理的理論和方法,對整個商務活動進行管理。許多企業都計劃採用項目管理,來使自己的組織變得更有效、更敏捷、更易於控制。企業希望通過項目管理,得到以前只能在典型的財務成本控制中心得到的信息,例如:基於每天或每週監控項目業績和進展,並且按照優先級和業務條件進行糾偏和變更,同時使業務的責任明確劃分,使組織的敏捷反應和易控制性大大獲益。

現在,越來越多的面臨著激烈競爭的企業意識到,應該更有效地配置一個高度專業化而且精益的員工隊伍;開始懂得了在項目管理中項目小組更好地協作(Collaboration)的重要性;也意識到通過項目管理可以更好地在高級管理層和項目幹線人之間共享信息。

那麼,項目管理未來的發展趨勢是怎樣的呢?

  1. 我們將可以看到,更多的企業開始接受項目管理的思想,並使用項目管理的技術和方法進行管理。
  2. 為了實現項目管理的全部潛能,許多企業將對他們的項目經理和項目小組進行培訓,並鼓勵他們取得專業認證。同時設立標準,不僅要保證項目小組成功,而且也要保證公司層面持續的成功。
  3. 轉向項目管理的努力將使企業在尋找項目管理系統時,不僅關心集成,還要考慮協作(Collaboration)和項目智能(Project Intelligence)。一個集成的系統可以使企業用最小的努力管理整個項目生命週期;而一個具有協作功能的項目管理系統,卻可以對所有的項目干係人(合作夥伴、客戶、承包商和其他項目干係人)提供訪問和可視化功能,因此協作變得更加重要。

發表迴響

PMP

PMP是由PMI發起的項目管理專業人員資格認證,其目的是為了給項目管理人員提供一個行業標準,使全球的項目管理人員都能夠得到科學的項目管理知識。美國項目管理協會(PMI)一直致力於項目管理領域的研究工作,全球PMI成員都在為探索科學的項目管理體係而努力。今天,PMI制定出的項目管理方法已經得到全球公認,PMI也已經成為全球項目管理的權威機構,其組織的項目管理資格認證考試,也已經成為項目管理領域的權威認證。全球每年都有大量從事項目管理的人員參加PMP資格認證。

發表迴響

PMBOK:Project Management Body of Knowledge

簡稱為PMBOK。這是PMI在20世紀70年代末提出的項目管理的知識體系。該知識體系構成了PMP考試的基礎,它的第一版是由200多名國際項目管理專家歷經四年才完成的,集合了國際項目管理界精英的觀點,避免了一家之言的片面性。而更為科學的是,每隔數年,來自於世界各地的項目管理精英會重新審查更新PMBOK的內容,使它始終保持權威的地位。

由於從提出知識體係到具體實施資格認證有一整套的科學手段,因而使PMI推出的PMBOK充滿了活力,並得到了廣泛的認可。國際標準組織(ISO)以PMBOK為框架制訂了ISO10006標準。同時ISO通過對PMI資格認證體系的考察,向PMI頒發了ISO9001質量管理體系證書,表明PMI在發展、維護、評估、推廣和管理PMP認證體係時,完全符合ISO的要求,這也是世界同類組織中唯一獲此榮譽的。

發表迴響

項目主要文件

PMBOK®指南介紹了三個主要的項目文件,每一個都有具體的用途:

  • 項目章程(Project Charter)。正式核准項目。
  • 項目範圍說明書(Project Scope Statement)。說明應完成何種工作,需要提交哪些可交付成果。
  • 項目管理計劃(Project Management Plan)。說明如何實際完成這些工作。

圖III-2表示出這三個文件及其同組成部分之間的關係。
項目管理計劃由各個不同過程完成的計劃書與文件組成。這些成果屬於項目管理計劃的分計劃和組成部分。項

發表迴響

Older Posts »