Excerpts from The Deadline

by Tom DeMarco

Four Essentials of Good Management: (p.28)
· Get the right people.
· Match them to the right jobs.
· Keep them motivated
· Help their teams to jell and stay jelled
(All the rest is Administrivia)

Safety and Change (p.35)
· People can’t embrace change unless they feel safe.
· Change is essential to all success in project work (and in most other worthwhile endeavors).
· A lack of safety makes people risk-averse.
· Avoiding risk is fatal, since it causes you to miss out on the associated benefit as well.
· People can be made to feel unsafe by direct threats, but also by the sense that power may be used against them abusively.

Risk Management (p.83)
· Manage projects by managing their risks.
· Create and maintain a census of risks for each project.
· Track the causal risks, not just the ultimate undesirable outcomes.
· Assess each risk for probability and likely cost.
· Predict, for each risk, the earliest symptom that might indicate materialization.
· Appoint a risk officer, one person who is not expected to maintain a Can-Do attitude.
· Establish easy (perhaps anonymous) channels for bad news to be communicated up the hierarchy.

Playing Defense (p.93-94)
· Cut your losses.
· You can improve overall performance more by containing your failures than by optimizing your successes.
· Be aggressive about canceling failed efforts early.
· Don’t take chances on team jell if you don’t have to. Seek out and use preformed teams.
· Keep good teams together (when they’re willing) to help your successors avoid problems of slow-jelling or non-jelling teams.
· Think of a jellied team – ready and willing to take on a new effort – as one of the project deliverables.
· A day lost at the beginning of project hurts just as much as a day lost at the end.
· There are infinitely many ways to lose a day . . . but not even one way to get one back.

Ambigous Specification (p. 216)
· Ambiguity in a specification is a sign of unresolved conflict among various system stakeholders.
· A specification that doesn’t contain a complete census of inputs and outputs is a nonstarter. It simply doesn’t begin to specify.
· Nobody will tell you if a specification is lousy. People are inclined to blame themselves rather than it.


Conflict (p. 225)
· Whenever there are multiple parties to a development effort, there are bound to be conflicting interests.
· The business of building and installing systems is particularly conflict-prone.
· Most system development organizations have poor conflict-resolution skills.
· Conflict deserves respect. Conflict is not a sign an unprofessional behavior.
· Declare up front that everybody’s win conditions will be respected. Make sure that win conditions are elicited at all levels.
· Negotiation is hard; meditation is easy.
· Arrange up front that when win conditions are mutually exclusive or partly so, the parties will be expected to move into mediation to resolve conflict.
· Remember: We are both on the same side; it is the problem that’s on the other side.

Project Sociology (p. 275)
· Keep meetings small by making it safe for unessential people not to attend. A published agenda, rigorously followed, is the easiest way to make nonattendance safe.
· Projects have need of ceremony.
· Use ceremony to focus attention on project goals and ideals: small meetings, zero-defect work, etc.
· Take steps to protect people from abusive anger.
· Remember: Anger = Fear: Managers who inflict abusive, angry behavior on their subordinates are almost always doing it because they’re afraid.
· Observation: If everybody understands that Anger = Fear, anger will be a transparent signal that the angry person is afraid; since there is an inclination not to reveal fear, he or she won’t be able to vent the anger anymore. (This doesn’t solve the angry person'’ problem, but it sure can make it easier on everyone else.)

專案管理技巧 WBS

Work Breakdown Structure (工作分解結構)

WBS使用階層樹狀結構（Hierarchical Tree Structure）與100%原則（100% Rule）來定義與組織專案範圍（Project Scope）。一個優良的專案WBS技巧，是針對產出（Outcomes）所進行的拆解，而非工作項目（Actions）拆解。



腳踏車WBS展開圖 Source: Wikipedia

from MECE原則與專案管理技巧
add.. 專案管理與專案生命週期
MECE

什麼是專案管理

專案管理是為了達成專案目標的協調工作。專案小組的負責人是專案經理，負責執行這項工作及其最終的結果。專案經理憑藉知識、技能、工具及方法來：

• 確立專案的目標、需求及限制。
• 協調各專案關係人 (包括小組成員、資源經理、資深管理階層、客戶及贊助商) 的不同需要和期望。
• 根據確立的專案目標來規劃、執行及控制專案的任務、階段及交付項目。
• 當專案完成時關閉專案，並且記錄當中所累積的知識。

專案經理也負責平衡和整合互相競爭的需求，以利成功地執行整體專案，如下：

• 專案範圍 確立專案要完成的特定工作。

• 專案時間 設定專案的完成日期，以及階段、里程碑及交付項目的中期期限。

• 專案成本 計算及追蹤專案成本和預算。

• 專案人力資源 任用完成專案任務所需的小組成員。

• 專案採購 取得完成專案任務所需的材料和設備資源。

• 專案溝通 向小組成員和其他關係人傳達工作分派、更新、報表及其他資訊。

• 專案品質 確立專案目標可接受的品質層級。

• 專案風險 分析潛在的專案風險和回應計畫。

瞭解專案管理基本概念

平衡 範圍、時間及金錢 通常是專案經理的最大責任。
如果您增加範圍，三角關係中的時間或金錢兩邊也會增加。如果您需要縮減時間 (即提前專案完成日期)，則可能需要減少範圍，或藉由增加成本來增加資源。

step by step - Microsoft Project 2003 : 建立project計劃

專案管理術語

使用Microsoft Project促進專案發展

• 比較基準 任務的重要專案資訊快照，例如開始日期、完成日期、工期及成本。使用比較基準資訊，您便可以和任務實際進度做對照。

• 日期限制 與特定任務關聯的特定日期。例如，日期限制會指定任務必須在特定日期前完成，或不在某個特定日期之前開始。

• 交付項目 必須產生的實質結果或項目，以標示專案或專案階段的完成。通常，交付項目必須獲得專案贊助商或客戶的核准。

• 相依性 某個任務對另一個任務的依賴。當某個任務必須在關聯的任務開始或完成時才能開始或完成，任務就是彼此相依 (或相關)。又稱為任務連結或任務關係。

• 甘特圖 專案的圖形表示。甘特圖的左邊是一個表格，當中列出任務名稱和其他任務相關資訊。甘特圖右邊則是橫條圖和時間表，其中每個橫條分別代表任務、開始和完成日期，以及任務工期。此外也會顯示其他任務的連結。

• 里程碑 專案中有意義的事件，通常是完成了主要交付項目或階段。里程碑是專案任務清單的一部分。

• 網狀圖 專案的圖形表示，以節點表示任務，並以連結線顯示任務關係。有時又稱為 PERT (計劃評估及審核技術) 圖。

• 階段 一組任務，代表專案生命週期中的主要階段。階段的結果通常是主要交付項目。

• 範圍 專案中必須完成的特定工作，以交付產品或服務。

• 關係人 可由專案結果獲得既定利益，並且可以影響專案結果的個人或組織。關係人包括專案經理、專案小組成員、贊助組織及客戶。

The mythical man-month

ch2

好菜都得多花些時間準備，為了能讓您享受到更美味、更可口的佳餚，請您務必耐心稍待。

——紐奧良，ANTOINE餐廳的點菜單

軟體專案進行不順利的原因或許很多，但絕大部分都是肇因於缺乏良好的時程規劃所致:

1. 我們目前的時程預估技術還非常不成熟，糟的是，這些不成熟的技術背後都反映出一個假設，亦即，一切都會進行得很順利，但這實在是大錯特錯。
   
2. 我們的預估技術誤把工作量和專案進度混為一談，這又隱含了另一個假設，以為人力和工時可以互換。
3. 由於我們對自己所做的預估都無法篤定，所以專案經理通常缺乏Antoine餐廳廚師那種委婉的堅持。
4. 時程進行缺乏監控，並把其他工程領域上被證明可行或慣用的技術套在軟體工程上進行改革。
5. 當發現時程延誤的時候，自然而然的（也很典型的）反應就是增加人手，但這簡直就是火上加油，只會把情況弄得更糟。

過於樂觀 :
第一個錯誤假設就是一切都會進行得很順利，亦即，每項工作都將只會耗費掉它「理應」耗費的時間。

就單獨一件工作而言，如果假設一切都將順利進行，其結果會對時程造成何種影響就要看運氣。從機率分佈的角度來看，「完全不延期」也是有一定的機會，所以， 或許它真的能如計畫所預期地進行，但是，如果面對的是大型軟體開發專案，包含的是一大群工作，而且彼此環環相扣，那麼，一切都將進行得很順利的機率將是微 乎其微。

人月的迷思 :
第二個錯誤的想法，是來自於預估和排定時程所使用的人月，這正是一般用來衡量工作量的單位。成本確實會隨著人力與工時的乘積而變， 但工作的進度可不是如此，所以用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思，使用人月的前題必須是在人力和工時可以互換 的情況之下。

只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才算成立，像割小麥或採收棉花就是這樣，但這對程式設計來說卻完全不適用。

當一份工作因具有連續性的限制而不可切分時，就算投入再多的人力，也不會對時程有所影響，生小孩就是需要九個月，你叫多少個媽一起生都一樣，軟體工程就是像這樣的工作，因為它必須除錯，而除錯就具有連續性的本質。

系統測試 :
在時程中，組件除錯（component debugging）和系統測試（system test）是受連續性限制影響最徹底的部分，甚至，需要耗費的時間是基於所遭遇到的錯誤數目以及錯誤的棘手程度，理論上，這個數目應該是零，但因為樂觀， 使我們預期的錯誤數目往往會比真正遭遇到的少，因此測試總是大大地延誤時程。

我要特別指出，沒有分配足夠的時間給系統測試，就會釀成大災難，這是因為等到交貨在即，發現時間不夠用的時候，時間卻已經快用光了，而在這之前，都沒有人會意識到時程有什麼不對勁，結果，在噩耗、落後竟然都沒有任何預警的情況下，把你的顧客和老闆嚇一大跳。

要有勇氣堅持自己的預估 :
請注意，程式設計師的遭遇跟廚師一樣，顧客的催促也許會左右工作的預定完成時間，但對工作的實際完成時間不會有什麼影響。一客煎蛋卷，答應兩分鐘做 好，而且看起來應該可以順利上桌，但是如果到了兩分鐘還沒有做好，那麼這位顧客只有兩種選擇──繼續等，或者吃生的。你的軟體顧客也是只有這兩種選擇。 　　

當然廚師還有另外一種選擇，他可以把火加大，那煎蛋卷就完蛋了──有一半燒焦，另一半還是生的。 　　

我不認為軟體 專案經理在先天上就缺乏廚師的勇氣與堅持，或是在這點上比其他工程領域的管理者還差，但是在軟體界，以錯誤的時程去配合顧客期望的日期，這是比其他工程領 域還普遍的現象。對於缺乏數據、僅憑很少的資料、主要靠著專案經理的直覺所預估出來的時程，很難提出一個強而有力、能夠自圓其說，並足以擔保一切風險的辯 解。

明顯地，這必須從兩方面來解決。我們先要蒐集並告知大家有關生產力的資料、錯誤發生率的資料、預估時程的法則等等，唯有藉著分享這些資料，整個軟體界才能夠獲利。

另一方面，在為預估方法找到一個更為堅實的基礎之前，專案經理個人必須挺起胸膛，勇敢為自己的估計堅持立場，保證就算是他的直覺再不濟，也比用願望來做預估要好。 　　

雖然不夠嚴謹，看來也異於常理，我們還是在此提出Brooks定律：在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。（Adding manpower to a late software project makes it later.） 　　

這 定律破除了人月神話。軟體專案會耗費多少時間是看它有多少連續性的限制，該投入多少人力是看它可以切分成多少獨立的子工作，根據這兩點，我們就可以推論出 用人較少、耗時較多的時程（唯一的風險就是軟體落伍的問題），然而，你是無法得到一個用人較多、耗時較少而又行得通的時程。軟體專案進行不順利的原因或許 很多，但絕大部分都是缺乏良好的時程規劃所致。

博客來 人月神話 : 軟體專案管理之道