程式開發工作的時程預估

所有的開發專案一定都會要求時程預估，並依預估結果繪製時程表，進行專案時程的管控。然而，大家也都習慣性地把時程表不當一回事。『反正最後一定會 延遲。』『客戶一定會要求修改，我們再來趁機修改時程或刪減功能。』幾乎沒有一位專案經理可以在專案一開始，就相信專案可以如期交付，反正先硬著頭皮做了 再說，等專案真的延遲再想辦法。萬一真的不行，各種外力不可控制的理由紛紛出籠：『這根本是不可能的任務，當初業務就不應該答應。』『公司承諾的人力，因 為卡在某某案子，沒有如期到位。』『設備採購出問題，還要從美國坐船過來，導致後面的時程都受影響。』『系統軟體原廠支援不足，我們光排除安裝問題就多花 了兩個月。』

時程預估的不確定性

專案中的一個程式模組，指派給某個工程師要求預估工時，工程師如果回報的是 4 個工作天，有沒有什麼辦法可以確認這個數字是合理可行的呢？試著把同樣的工作交給另外一個工程師評估，有可能得到的是 9 天，也有可能得到的是 2 天。顯然的，預估工時在程式開發這個領域中是很不科學的，不同的人預估會得到不同的結果。到底我們該不該相信預估的結果？還是有什麼東西是過去一直沒有注 意到的？

程式開發專案中，充滿了各種不可控制因素，除了前面提及的『理由』外，還更多的是來自內部原因，例如：『工程師突然生病請假兩天。』『程式裡有個 BUG 一直找不到，多花了一個星期才找出問題。』本來一個 4 天預估工時的程式，因為發生一個找不到的 BUG，延後超過 9 天是常有的事。對同一件工作，預估工時為 2 天、4 天、9 天，其實都是合理的，只是大家是站在不同的考量點上，有人非常樂觀的預估，假設一切都很順利，只考慮實際上寫程式所需的時間；也有的人是過度謹慎的預估， 把所有可能的風險都列入，並假定這些風險都會發生，估出 9 天也不足為奇。

絕大多數的專案，是以客戶的時程為底線，再將專案工作分解後，硬塞入有限的工時之中，如果塞不進去，才會進一步檢視各個工作項目，是否可以縮減工時 或是提早開工，直到所有工作可以在客戶指定時程內完成為止。這樣的動作其實是非常可怕的，專案只有盲目地壓縮工時，整個過程充滿了『談判』、『協商』、 『要求』，沒有花心力去注意怎樣的時程才算合理。完全忽略了一個導致專案失敗的人性因素：如果預估工時，讓所有人都覺得根本無法達成，努力跟怠惰結果一樣 無法達成任務，大家就會選擇對自己比較輕鬆的方式，開始摸魚，反正都是做不完！

既然個別工作項目都可以三、四倍的預估落差，整個專案加起來也是一樣，不同的專案經理，在沒有時程的壓力下預估的總時程，落差也會很大。由於專案經 理提不出一個科學客觀的時程，只能憑『感覺』去爭取時程，完全沒有說服力，最後只能以客戶的時程為時程，專案經理幾乎沒有爭取時間的籌碼。

由於專案進度的掌控是以工時預估為基準，如果這個基準因為不同的人預估，而存在極大的落差，也會無從進行進度的控制。確實需要一個可以被大家普遍同意的預估方法。

PERT 時程預估法原理

計劃評核術 (Project Evaluation and Review Technique) 最早應用於美國海軍的北極星核子潛艦計劃，用來評估並管理時程難以精確估計的超大型專案。PERT 提出了機率管理的概念，這個方法認為不管第一次預估是 2 天、4 天或 9 天，都有其道理與考量，專案雖然只會有一個完成時間，但還沒開始動手之前，每一個時間都是有可能的，只是機率不同罷了。

PERT 假定工作完成機率的是 Beta 分佈，需要三個參考值，來計算機率的分佈，第一個值是『最快可能完成的時間』，第二個值是『最有可能完成的時間』，第三個值是『最慢可以完成的時間』，我們若分別 2 天、4 天及 9 天代入，可以得到如圖一的機率分布圖。

圖 1

其中第二個值是機率最大的時間，所以放在圖中曲線最高的位置，但是其他兩個值的相對機率是多少呢？PERT 的第二項假設是：最快與最慢的機率假設為最可能機率的 1/4。至於這個比值暫時不必去管是出於什麼道理，我們可以依此計算出平均值 ( 2 * 1 + 4 * 4 + 9 * 1) / 6 = 4.5 天。這個平均值是一個相對穩定的值，PERT 即以此平均值做為預估工時的基準。

平均值仍然不夠

雖然 PERT 已經提供了一個較為客觀且變異性不會太大的時程預估方法，但 40 多年來的應用並不普遍(較廣為應用的是 PERT 網路規劃圖及其衍生的要徑法)。原因在於 PERT 預估法只適用於時程變異較大的案例上，例如：太空科技的發展、新藥的研發、軟體關鍵技術的開發 … 等。在軟體開發專案中，並非所有的工作項目都具有很大的變異，例如：硬體設備的採購、使用者訪談、網頁圖素的製作、操作手冊的撰寫 … 等非程式開發項目。

我們再次觀察圖一中的平均值，會發現在平均值 4.5 天之前的曲線圖形面積，約略佔整個面積的 50%，也就是說到第 4.5 天完成的機率，其實只有 50%，另外約有一半的機率是會超過預估時間的。

再從圖中看起來，9 天似乎是一個較為『安全』的預估值，把時間定在 9 天，也許就有九成的把握完成程式項目的開發。4.5 天與 9 天恰好是兩倍的差距，專案經理對此亦相當的為難，定在 4.5 天最能符合客戶的需求，而定在 9 天能如期完成的『把握』較大。

許多專案經理就此放棄 PERT 法，定在 4.5 天風險太大，而定在 9 天根本無法被客戶接受，況且 9 天這個值也不是一個客觀值，由不同的人預估出來的差異很大。

掌握機率要靠控制而不是預估

不管怎麼樣，從 PERT 的模型中，仍可以看出由風險所導致的機率分佈現象，這個機率分佈確實能夠解釋，為什麼不同的時間或不同的人來做同一件事，完成時間會有差異。機率分佈模型 已經明白地告訴我們，精確的預估值其實是不存在的，圖一中的每一個時間都是有可能達成的，只是發生的機率不同，專案經理盲目的要求精確預估，只會是自欺欺 人的作法，怪不得大家都不會相信預估的結果。

如果我們已經承認預估工時不會精準，是否表示以後專案就不需要再作任何預估了？當然不是！工時預估只是作為進行專案資源分配的準備，接下來就是對時程的控制，而時程控制最重要是靠『預估時程表』以及可重分配的『緩衝時間』，隨時監看專案的進展。

當某個工作項目超過預估時程時，不是用任何方法鞭策工作人員，並要求自行加班以趕上專案時程，而該是深入檢討工作程序是否出了什麼問題？是否有已知 或未知的風險轉化成危機，需要立刻進行危機處理？必要時提出部份保留的緩衝時間，投入已延遲的工作中，並重新調整後續工作項目的開始時間點，讓專案能夠順 利繼續進行。要注意：專案的目的是完成工作，不是完成預估。

專注於緩衝時間的運用

專案裡每一個工作項目的預估工時，或多或少都會計算入風險控制工時，或是稱作緩衝工時，以因應風險的發生。這些緩衝工時存在的原因，就是要確保單項工作沒有機會延遲，但是這樣卻是造成整體專案延後的最主要原因：時間會被莫名其妙地浪費。

例如：一個預估工時為 9 天的工作項目，假設是作了最保守的估計，按照 PERT 的估計只需 4.5 天，而事實上程式發生了一點小問題，總共花了 6 天才完成。看起來是提早了 3 天完成工作，然而事實上這 3 天會被浪費掉，因為按照原定計劃，下一個工作項目要 9 天之後才會啟動，多出來的 3 天裡什麼工作也不會發生，即便是整個專案的時程已經很緊了，下一個工作也來不及接手，還是要等到第 10 天才會動手。

在 PERT 提出的 40 年後，制約理論 (Theory Of Constraints) 將最早發展於生產製造的緩衝管理方法，運用到專案管理的領域，認為專案最大的制約項目是時間因素，因此要投注最大的心力在時間緩衝的管理上。

TOC 主張個別工作項目不應該各自擁有緩衝時間，工作項目設定一個較為緊的工時：『約有 50% 的把握如期完成工作』(與 PERT 的預估結果雷同，但不用複雜的機率估計法)，專案保留一定比例的緩衝時間 (約為總預估工時的50%)，隨時依專案進行的狀況，將緩衝時間分配給已延遲的工作項目運用。以圖一為例，預估工時即為 4.5 天，但另有額外的 2.25 天，提撥到專案統籌管理運用。

(註：有關 TOC 在專案管理的應用，請參考由天下文化出版的『關鍵鏈』一書)

專案經理要改變管理的觀念

由於程式開發的風險很大，要讓專案進行順利，專案經理首先要改變管理的觀念，承認風險的存在，並允許風險在工作項目裡發生的可能。預估工時與實際工 時常有出入，不見得是寫程式的人不努力，也不見得是預估工時的人不專業，主要是風險由可能發生的機率，變成已經發生的事實，進而衝擊到工作的進行。例如： 硬碟故障需要重灌系統而延後兩天，誰該負責呢？

沒有人要對此事負責，但專案衝擊已然發生，整體時間往後遞延兩天，專案經理以及整個專案團隊都要付出代價。在風險管理的前提下，保留的緩衝時間就能夠於此時派上用場。所以專案經理要改變管理的觀念，與其追求精確的預估工時，不如花時間在風險的管理之上。

作者：周旺暾，PMP (台灣微軟應用開發技術經理)
2005 年 1 月

談程式開發專案進度管控

早期軟體工程的研究，著重在軟體需求的流程上，把所有的目光集中在客戶需求的滿足，目的在撰寫出完全符合客戶需求的程式。於是專案進度的超時與成本的超支，成為軟體開發者的夢魘，甚至被視為理所當然，大家常開玩笑地說：『時程表就是用來延遲的』。

由於專案的超時與成本的超支，直接影響到專案是否能繼續進行，為了確保專案的成功，我們不應該將超時與超支視為專案的常態，任由成本與時程如洪水般的失控，而要將成本與時程這兩項重要因素，與客戶的需求並列為專案管控的成功要素，只有當這三項目標同時達成，專案才算成功。

計劃不等於執行過程

用過 MS Project 的人都對『甘特圖』印象深刻，但是大多數人只把它用在專案計劃之中，並不曉得如何用來有效管理專案進度。事實上，MS Project 不只用在專案計劃中，還能夠設定專案每一個工作項目的執行進度，進一步結合資源與成本規劃之後，還可以經由實獲值分析法  (Earned Value) 計算出整個專案的執行百分比。

圖 1

[圖一] 是我們常見的進度報告，這個進度報告存在一個最大的問題是：『實際執行進度與現在的時間完全相同，時間走到那裡進度也就到那裡。』有經驗的專案成員應該很 清楚問題所在，尤其是程式開發專案，開發過程中充滿了許多的不確定性，專案的進度很少是一分不差地照著專案原先的計劃在走。由於不確定性因素很高，每一項 工作項目的執行進度有快也有慢，沒有道理完完全全地符合專案計劃所規劃的進度。

見到 [圖一] 這樣的進度表，最有可能的解釋是：專案經理沒有實際掌握專案執行的進度，只是因為時間走到這裡，進度就顯示到這裡。還有另一種可能是：專案經理的主管根本 不懂專案多變的特性，盲目地要求專案經理填報完全符合計劃的進度。不管是上述哪一個理由，結論都是這個專案的進度沒有確實反應到現況，如果未能採取進一步 的改善措施，本專案必然是嚴重延誤的下場。

解決這樣的問題，專案經理和專案經理的主管都必須改變一個觀念：專案雖然是照劇本 (專案計劃書) 在進行，但是目標要放在確保專案在期限之前完成，過程中是快是慢並不是重點，專案提前固然值得慶幸，專案延遲只是一個警訊，必要時，要大家坐下來檢討資源 配置或工法，以確保整個專案能如期完成。

實際評估專案進度

要怎麼有效追踨專案進度呢? 如果各別工作項目的成員隱瞞或虛報進度怎麼辦? 就以 [圖一] 為例，其中第三項工作項目提報進度是 33%，專案經理和專案成員是如何達成一致的共識，確定它就是 33% 呢? 為什麼不是 30% 或是 40%？特別是在程式的開發上，我們很難引用一個客觀的方法來衡量個別程式的進度。 別忘了，『專案的最終時程是否能達成才是我們的要求，個別工作項目是否精確的開始或結束，相對之下不是那麼重要』。我們需要一種客觀的指標，能夠讓下到專 案成員，上到客戶、老闆都能一致清楚並同意的進度衡量指標。建立這樣的衡量指標需要經過充分的溝通，不是單方面由專案經理或主管決定，否則衡量指標的執行 效益會很差。

工作項目狀態	進度
未開始	0%
進行中	50%
已完成	100%

圖 2

[表一] 是常用的進度衡量指標，[圖二] 則是依據此衡量方式可能產生的結果，表面上看起來似乎擴大了專案進度的衡量偏差，其實不然，因為使用了客觀的衡量指標，使得人為主觀的偏差反而大幅減少， 更能接近專案實際上的執行現況。 也許有人會覺得這樣的衡量指標似乎太粗糙，能不能把指標分得更細，分成五個階段甚至更多的階段？當然，你可以這麼做，但是通常沒有必要。不是每一個工作項 目都可以分得更細，而且若分得更細，可能會失去衡量的客觀基準。進一步來看，如果有某一個工作項目可以分成更多的執行細節，我們大可把它分解成更多的較小 的工作項目，直到不能再細分下去為止。

專案經理在追蹤進度時，問題從『你手中的部份做得怎麼樣了？』改成由專案成員自動填報工作現況，專案經理不必逐一檢查每一個工作項目，只要把焦點放 在有機會造成整體時程延後的工作延誤上，而這些延誤通常是出現在『要徑』(Critical Path) 之中 ([圖二]中紅色的部份)。專案更聚焦也有助於專案資源投注在確保專案順利完成的事務上。

進度落後要有效控制，而不是過度驚慌

所有的專案經理都會關注『延遲』，延遲若是沒控制好，總是會像傳染病般，迅速地蔓延到專案的各個角落。理由很簡單，當某一個工作項目延遲了，會導致 接下來的工作項目延後開始，而下一項工作延後結束，又影響到更後面的工作項目，而延後開始還有可能讓計劃中排定的關鍵資源卡到其他的計劃(例如：預約使用 測試中心進行壓力負載測試)，於是『延遲』不僅會逐漸傳佈到各個角落，還會如滾雪球般越滾越大。

想要有效控制『延遲』，首先是要調整專案經理的觀念，要認淸程式開發的不確定性很高，可能一個 bug 卡很久找不出來，也可能原本預計 20 個人時的工作，一天之內就完成了，工作項目可能慢也可能快完成。專案經理先要有『延遲』的容忍度，若是缺乏對『延遲』的容忍度，會造成專案成員對『延遲』 事件的隱匿不報，專案經理反而更無法掌握目前專案真正的執行進度。一個 bug 卡很久，其實對專案成員來講，心理上會有很大的壓力，專案經理要注意別施加更多的壓力在專案成員身上，要鼓勵專案成員主動提出狀況，也許其他成員曾經解決 過類似的 bug，問題馬上迎刃而解。

『延遲』的容忍度應該要有多大呢? 到什麼情況下要採取進一步的措施? 關鍵在對專案所保留的『風險緩衝』剩下多少，因為工作延遲會直接或間接影響到專案的最終時程，專案計劃通常會保留一部份『風險緩衝』的時間，就像是專案經 理口袋裡的『時間存摺』，當工作延遲就從緩衝中提出時間來貼補，工作超前就把多餘的時間存回存摺中，留待因應後續的狀況發生。

當專案經理預見到『時間存摺』可能耗盡時，就要緊急召開會議，討論目前的狀況，並討論是否需要變更後續的專案計劃，以達到預期的專案最終時程。要特 別注意的是：會議討論的重點不是『如何趕上專案計劃的進度』，而應該是『如何滿足專案的最終時程』，因為專案計劃中的進度是『計劃』來的，隨時可以透過計 劃修正改變它，但專案最終時程是由合約或市場決定，通常不允許被改變。專案在計劃初期，通常是考慮風險最小或成本最低的資源與工法，一旦專案受到某種程度 的壓縮，特別是因為延遲所造成的可用時間減少，就得考慮在不影響專案內容的前提下，以部份金錢爭取寶貴的專案時間。例如：原來某一個元件的開發，是為了投 資公司內的元件發展，但如果市場上有其他可購得的元件，可考慮以採購的元件暫代，或者是調整元件化的順序，先進行功能開發，之後開進行元件化工作，雖然整 體費用可能較不經濟，但專案進度獲得改善才是最重要的。

進度超前要擴大戰果

不知大家有沒有遇到一個經驗：某工程師預估一項工作約需 10 個工作天，結果他花 6 天就把工作完成，但卻沒有想到告訴任何人，他心想：『反正下一個工程師還在忙其他的工作』，繼續做其他的工作，等 10 個工作天到了，專案經理來接收進度，他馬上交出已完成的工作，專案經理也很高興地拿著成果交給下一個工作師繼續專案的進行。

這樣故事天天上演著，專案經理也沒有發現什麼不對，該工程師確實如期交付他的工作，雖然他提前完成，沒有人認為他要提早交出成果，即使是提早交出成 果，下一位接手的人，可能認為計劃時間還沒開始，拿到手的工作也會先擺著，直到計劃開始時間到了，才開始進行計劃中的工作，一切似乎沒什麼不對。

但是從整體進度掌控的角度來看，工作可能延遲也可能超前，延遲的工作要消耗『時間存摺』裡的預備時間，而所有超前的工作若都被視為『如期完工』，並 未把節省下的時間加入『時間存摺』之中。『時間存摺』只有出沒有進，如非當初預留的緩衝時間很多 (其實不太可能有足夠多)，整個專案只有超時收場。

專案需要一個獎勵措施，讓省下來的專案時間可以存入『時間存摺』之中，包含兩個要件：一是工作項目提前完成，二是接下來的工作項目提前開始進行。獎 勵方法可能是口頭上或實質上的獎勵，不管是什麼方式，一定要有適度的激勵作用，不要只是流於形式。也要避免過度的獎勵，扭曲了專案執行的重點，例如：為了 賺取獎勵，故意浮報工時的預估，或是虛報實際的工作進度。

由於程式開發時程的不確定性非常高，大多數專案經理只好依照客戶的需求，抓一個不知該如何完成的時間規劃，心裡抱著：『不管怎麼規劃，大家都會認為 不夠用，反正等做不到，再來開會研究。』這個心態是很不健康的。專案經理如同樂團的指揮，透過小小的指揮棒，指揮整個樂隊完成一場漂亮的演出。

作者：周旺暾，PMP (台灣微軟應用開發技術經理)
2004 年 12 月

Managing a Doomed Software Project: Practical Suggestions for Breaking the Bad News

When that high-profile project just ain’t gonna happen, how can you ensure that your head isn’t on the chopping block? Matt Heusser provides some practical suggestions for passing on the bad news without just passing the blame.

Does this scenario sound familiar to you?

The company, department, or customer bets the farm that project X will be done by late October in order to make the Christmas sales period. Various managers assure them that this can be done. Around June, the big boss calls you into his office and explains to your team the importance of the project, its crucial nature to the business, the value of your contribution, and the importance of the deadline.

Time passes…

Sometime around July 15, you realize that there’s no way you can meet the deadline. It doesn’t matter how much overtime you work, it doesn’t matter how lucky you get—it just won’t happen.

Welcome to the doom train. All aboard.

If you’ve been a technical contributor for long, this scenario is probably rather familiar. In fact, you may be living it right now. If that’s the case, take heart—we’ve all been there before. This article is written just for you.

It’s important to note that being doomed has nothing to do with performance; it’s all about expectations. Whether having project X done by October 15 is reasonable does not really matter if project X is expected on that date. In my own career, literally every single time I have been doomed has been due to this expectation gap; nothing else comes close.

Before I offer advice, we need to make sure that you really are doomed. The expanse of human potential is incredible; don’t count yourself out just because things look grim today. If you just had a bad day, you are just stuck on a particularly nasty problem, or the project is challenging but possible, throwing in the towel early and following the advice in this article can make your life much worse.

There are lots of ways to figure out whether you’re doomed. One simple approach is a burn-down chart. Break the project into tasks and assign a point value to each task, such as how many hours the task should take. Figure out how many points your team is accomplishing per week, and you can project out to when the project will finish. If projected completion is past the due date, you’re doomed. If the project is visibly off-track, you can try to brainstorm a half-dozen actions within your power to bring it back on track. Have you given up bull sessions and web-surfing, put in reasonable overtime, tried to offload non-project work, and every other reasonable step?

Yup, still doomed.

Like any recovery program, we’ve completed the first step—recognizing the problem. Recognizing your doomed-ness is liberating, because you can stop wishing and hoping and “trying harder,” and instead take actual steps to improve your life. Despite the dark cloud hanging over you and coloring your vision of the world, it’s possible to improve the situation, given just a few techniques and a plan. Let’s talk about some specific techniques first.

“I Can’t Do This”: The Power of Congruence

The typical response to doomed-ness is fight-or-flight: getting scared and working lots of overtime, or getting defensive and finger-pointing. Neither of those options deals with the real problem—the combination of expectation and ability.

If you were picked to work on the big critical piece of the product, odds are that it’s because you are good at what you do and well suited to do it. Perhaps no one else knows the technology or codebase as well as you, or you may have certain natural talents.

If you are coming from such a position of respect, you can arrange a private meeting with the boss and tell him very respectfully, “I can’t finish project X by October 15. I want to. I’m working hard at it and I want us to succeed. Perhaps you can find someone else to do it, but I can’t.”

Of course, there is no one else. A savvy boss will realize this fact very quickly. If you can’t do it, nobody can. At this moment, you are no longer doomed—you have transitioned the doomed-ness to the boss. This will completely upset his sense of control, and trigger his fight-or-flight response. To smooth things over, you’ll want the next step, covered in the following section.

“I Might Be Able To Do This If“: Creating a Negotiation

Managers like to have control. This makes perfect sense; out of control and responsible is a very scary place to be. One form of control is choice. To create choice, just give the boss options:

• We could slip the project by two weeks.
• We could split the project into phases, delivering a completed, working system on time and delivering follow-up functionality two months later.
• I could stop working on the super-gonzo project.
• I could stop other related support activities. (If you track your time for a few days, you might be surprised at all the extra little activities you’re supporting. If you stop supporting those activities, people will probably complain. Framed this way, though, it’s the boss’ decision, not yours.)
• We could lower the mean time between failure (MBTF) expectations of the system. In other words, expect the system to error more often, and thus lower quality requirements.
• We could block off boardroom A and get the entire project team working in the same place 100% of the time, and we might have a chance.

Offering options has a wonderful effect. With reasonable management, you can back out of unrealistic expectations, provide management with a sense of control, and reframe the entire project to be possible.

Squeak Early, Squeak Often

The earlier you provide this information to management, the more they can do about it. Remember: Keeping management in control is in your own best interests. Squeak far enough into the project, and with enough data, and it will be clear that you’re a committed contributor who isn’t just crying wolf.

If the information you provide seems to go in one ear and out the other, start sending it by email. Daily. In most organizations, you can carbon copy (cc:) two or three levels up the chain of command in status updates; they may even thank you for it. You can also carbon copy the customer or other key stakeholders on the project.

In any event, this is a lot more than just covering your tail, although it does work wonders for that purpose. Squeaking often and consistently will lower expectations, thus formally un-dooming you.

What Should I Work On Today?

At this point, you’ve told the boss that you will not hit the date. You have reframed the problem from a personnel problem (you are late) to a project management problem (someone needs to adjust the schedule to reflect reality). The next question is this: “What should I work on next, boss?”

This question preserves the manager’s sense of control and gives him choices. If you have to be explicit, ask, “Should I work on features or fix bugs? What features? What bugs?”

The doomed-ness is now at the feet of the manager. Do your best, be professional, and stay committed to the project, but you can now officially stop feeling bad that you cannot do the impossible. (But if by chance you’re doomed a lot and no one else in the organization is, seriously consider whether you are cut out for the role you are currently assigned.)

Nine times out of ten, the original due date will come and go, the company will survive, and your job will be safe. If the organization is going through some internal meltdown and your job really is in jeopardy, I hope that I have helped you recognize the unreasonable management, and you have been working on an escape plan.

Customer Involvement

The previous sections assume that the big boss is the one who doomed you, but often there’s another interested party: the customer. The customer may be a single company you work for, a particular executive, a business unit, a person in marketing or sales, a “program manager,” or someone else entirely.

One common problem that can accelerate doomed-ness is the customer and the big boss having different expectations. Perhaps one of the compromises I have described so far could lead to an outcome that is perfectly acceptable to the customer, but the boss (the liaison between the two groups) just can’t see it. Perhaps they disagree on a key feature, or quality expectations, or have some other issue that’s creating conflicting expectations—and you, as a contributor, cannot fulfill both at the same time.

Generally speaking, the person who is going to be hurt the most if you can’t make a delivery date is the one who is paying for the software—the customer. If the customer is not represented in the discussion above, negotiation may be impossible. This can be fixed by bringing the customer into the decision-making process. You can do this in a number of ways, such as suggesting, “Since we are not expecting delivery on date Y, you’ll update the project plan and discuss options with the customer, right?”

In Agile environments, you may be working directly with the customer, and the customer may see you as a living, breathing human being. In that case, the customer is much more likely to view the schedule as something flexible that can change, not a contract written in stone to be insisted upon.

So if you are doomed and the customer isn’t involved, try to get her involved. Make sure that she feels in control. Otherwise, we’re back to fight-or-flight.

All or Nothing

I have worked on several projects where the customer insisted that it was “all or nothing”—they needed all the features, on the exact date, at high quality, or the project simply was not worth doing. With no lever to push, the success of the project relied entirely upon the feasibility of hitting the date.

In all of these cases, when push came to shove, the customer found functionality to cut. When they made the choice earlier in the project, they made the choice consciously, and they felt in control of the choice, customers were much more likely to view the project as a success, and the doomed-ness evaporated.

Suppose you want the customer to make the choice early and she keeps insisting that it is all or nothing. What can you do?

First, ask what features are the most important—the key features you need to deliver to test early.

Second, put it this way: “I want to get everything done on time. We may be able to. I may not need to even ask this, but if you had to pick just one feature to cut in order to make the deadline, what would it be ?”

Once the customer identifies that non-essential feature, ask for just one more. Then one more.

Pretty soon, without even meaning to do it, the customer has prioritized the features, allowing you to work on the key features first, and, more importantly, break the project into phases.

About Your Expectations

Very rarely is management truly unreasonable, but I’ve worked with the occasional manager who essentially said, “La-la-la, I can’t hear you….” With unreasonable management, almost no project outcome is a success; if you actually seem to be pulling off the impossible, they’ll make the schedule more aggressive in order to “keep the heat on.”

If management is unreasonable, it’s time to change your expectations. In this situation, the goal is very different: Keeping your integrity, dignity, personal sense of well-being, and sanity.

Sometimes, the pressure is turned up so high that the difference between reasonable management and unreasonable management is hard to tell; in that case, I have room for one additional technique.

One Final Idea

At one point in my career, I was involved in a project that was completely doomed from the beginning. Three executives, one of whom was non-technical and another a new hire, without any specific knowledge of the work involved, took a guess at the delivery date for a major project. After the date was set in stone, they brought in the technical team to do the work.

And, of course, they were wrong. Wildly wrong. A three-month project for 10 people turned out to be a nine-month project with a staff that ramped up to 40, which was only possible because the people we brought in knew the system well and could be productive.

To get those people, we had to take them off other projects, so not only was the big project late—the entire project portfolio for the year was late.

Down from the mountain came the announcement—the big boss wanted to know why the big project was late. The big boss wanted to know who was responsible.

I was called into a meeting and asked “Why was the project late?”

I was doomed. After taking a deep breath and counting mentally to five, I took pains to say in my most congenial, non-confrontational voice, “Why did you think it was going to be done on time?” Suddenly, the environment changed to something besides blame: Honesty.

The rest of the after-action review process was unclear to me. I don’t know what happened or who said what to whom. In fact, I know only two things:

• No one was ever fired.
• No one ever asked me a single follow-up question.

Risk is par for the course on high-technology projects; without risk, there’s no reward. Doomed-ness, on the other hand, is temporary, and best avoided when possible.

For More Information

If you enjoyed this article and would like to read more from the Doomed-Ness Body of Knowledge (DNBOK), I recommend these books, all of which inspired examples in this article:

• Death March: The Complete Software Developer’s Guide to Mission Impossible Projects (Prentice Hall, 2003), by Ed Yourdon
• The Deadline: A Novel About Project Management (Dorset House, 1997), by Tom DeMarco
• Behind Closed Doors: Secrets of Great Management (Pragmatic Bookshelf, 2005), by Esther Derby and Johanna Rothman

Matthew Heusser actively develops working software and also writes and speaks on systems improvement. You can email Matt at Matt.Heusser@gmail.com, or visit his web site, Excelon Development.

source post [informit]

Something’s Missing

In any business function, there are a number of components that are necessary for the success of the function, many of which we take for granted.  I want to argue today that there are at least four significant components to any business function, especially those where a team or workgroup are involved.

The four significant components are:

– Methodology
– Process
– Software
– Culture

Here’s an example for context:  Think about sales management and CRM.  Most firms of any size now manage their distributed sales force using a combination of methodology, process and software.  The methodology is the training and the sales approach, usually based on some great thinking from authors or consultants like Miller Heiman or Strategic Selling.  These methodologies and the type of sale required lead to a process.  Most firms track sales processes as “Lead, Prospect, Opportunity, Qualification, Win” or something similar to that.  Each stage has a set of actions and determinants.  The process is used by everyone and is consistent across the team.  CRM or other software supports and enables the process, by providing a common data infrastructure that’s integrated and allows anyone to evaluate the progress against the process.  Finally, sales management uses its culture to motivate and compensate the sales representatives to achieve their goals.  Through a means of corporate influence, sales management and personal compensation, the culture reinforces the goals of the organization.

Are any of these components more important than the other?  In a small organization or team, the software may be as simple as a shared folder or Excel spreadsheet, but the data management is still required.  Often you’ll find that processes are informal and not defined, but rigidly enforced.  In firms where one factor is missing, other factors overcompensate to adjust.

I’ll argue that culture is probably the most important of the factors, since a firm can have a great process and powerful software that is never used, due to the fact that the culture does not reinforce the use of the process or software.  I can, through sheer power of will, force people to improve a business process with few tools or processes if the culture is strong enough.  Southwest Airlines used to be a great example of that.  There were no process manuals and few software applications, just a corporate culture so strong that it would ultimately prevail.

But in a great performing organization, each factor – methodology, process, software and culture – work together and are equally important to the success of the function.  When one or more of these factors is missing or not considered an equal to the others, the function will falter.  To continue the CRM example, early CRM “failures” were not failures of the software or of the business process, they were failures built by low expectations or no cultural reinforcement, proving once again that 1) culture is the strongest of the factors and 2) a perfect software system and a perfect process cannot compensate for the lack of cultural reinforcement.

Today, many firms want to be “innovative”, yet they lack software tools and defined processes.  In some cases the culture may overcome these hurdles.  However, that requires a consistent understanding of the importance of innovation and what it means throughout the organization.  In the absence of all of these factors, innovation (or any function) will falter until the factors exist in an equal balance.

source post [think faster]

Blox0r: AJAXy Outlooky RSS reader

TV Squad guy Keith McDuffee got it right when he said “silly name, neat interface” telling us about Blox0r, which advertises itself as “The best online aggregator ever!” Its an AJAXy feed reader that uses a classic Outlook three-pane interface. On the left is a list of feeds you’re subscribed to, a la Bloglines, and on the right are two panes, one for headlines and one to show the stories you click on. I like the default mode because it takes you to the actual web site so you can read comments and so on, but it also has a Preview Summary mode which will show summaries of all of the recent stories in a particular feed. It has most of the features you expect from a web-based feed reader and a few more, so despite the name it’s worth a look if you’re in the market for a feed reader. What’s more, it’s open source, so you can download it, tweak the code, and run your own aggregator service if you want.

source post [download squad]