業內流傳著這樣一句令人心酸的話：「規劃規劃全是鬼話，計畫計畫全是空話」。實際上，開發管理模式選擇不當將極容易造成進度失控，也將會導致兩個問題: 一是質量無法控制，二是時間無法控制。因為，專案進度的延遲總是在快到計畫結束的時刻暴露出來，結果是誰也不知道到底什麼時候才能夠結束專案，到最後專案經理只好請辭。那麼，到底問題出在哪呢?
艱難的專案進度管理
軟體開發管理一直有乙個令人困惑的難題，就是如何確保專案進度管理。專案進度控制是專案管理工作中的重要一環，也可以說是最艱難的工作之一。在軟體開發中專案進度失控受到很多因素的影響，主要有以下幾種情況：
(1)缺少進度指路明燈
當我們在路上行走的時候，會在沿途**路標，當到達某乙個路標時，我們便知道還有多少路或多少時間才能夠到達終點。這些路標是我們在旅程中的里程碑，讓我們可以清楚地知道目前所在地離開目的地有多遠，也讓我們能估算何時才能夠到達目的地。
對於在路上行走的我們，可以通過路邊的里程碑這乙個簡單工具來獲知自己的進度資訊。當進行軟體開發的時候，我們也需要建立開發專案的里程碑，使我們知道專案的進度。里程碑是專案管理不可忽視的一部分，通常意味乙個時間點上可交付成果的完成，好的里程碑管理就像一張地圖指示我們走向專案目標的進度。
(2)專案進度估算準確性差
軟體專案開發進度控制面臨的最大挑戰就是專案進度估算的準確性差。據統計，在對軟體專案進度與成本估算時，大多數專案實際完成時間超過估算進度的25%到100%。根據我的經驗要想對專案進度進行有效的估算，必須抓好以下兩個方面：一是專案計畫的可行性和可操作性，這是進度估算的基礎。二是要對專案進度進行合理的度量，這樣才能夠獲得專案的真實進展情況，並對專案估算做出相應調整。
(3)前松後緊，專案進度缺乏有效監管和控制
一般人在工作時都有前松後緊的習慣，而里程碑強制規定在某段時間做什麼，從而合理分配工作，細化管理粒度。對複雜的軟體開發專案而言，每一階段的進度都需要逐步逼近目標，里程碑產出的中間「交付物」就是每一步逼近的結果，也是控制的物件。如果沒有里程碑，中間想知道「現在進度做的怎麼樣了」是很困難的。
(4)沒有盡早發現和降低專案風險
在軟體開發中錯誤發現得越晚，對於開發造成的損失越大。里程碑式開發模式可根據每個階段產出結果分期確認成果，避免血本無歸。通過早期里程碑評審一般可以提前發現需求和設計中的問題，降低後期修改和返工的可能性。例如，在需求分析階段發生的錯誤，那麼最多就是把需求分析寫一遍，損失的是乙個人的勞動;而到了測試階段發現了需求錯誤，再回去重新做需求分析，那麼損失可能是致命的。
目標導向衍生里程碑式管理
一般來說，在專案開始時專案經理都會對開發專案進度制定乙個詳細的計畫。通常情況下，這需要採用一些具體的開發模式技術，最常用的技術是網路計畫和里程碑計畫。網路計畫是任務導向，以工作分解結構(wbs)為基礎;里程碑計畫是目標導向，以目標分解結構(obs)為基礎。有時兩種方法可以混合使用，如在網路計畫中設定里程碑。
(1)什麼是里程碑式管理
里程碑是乙個目標導向模式，它表明為了達到特定的里程碑需要完成的一系列活動。里程碑式開發是通過建立里程碑和檢驗各個里程碑的到達情況，來控制專案工作的進展和保證實現總目標。
軟體開發專案生命週期中有三個與時間相關的重要概念，這三個概念分別是：檢查點、里程碑和基線。檢查點是指在規定的時間間隔內對專案進行檢查，比較實際進度與估算計畫之間的差異，並根據差異進行調整。我們可以將檢查點看作是乙個固定「取樣」時點，而時間間隔根據專案週期長短不同而不同。里程碑是指乙個具有特定重要性的事件，通常代表專案工作中乙個重要階段的完成。在里程碑處，通常要進行檢查。基線則是指乙個配置在專案不同時間點上通過正式評審而進入正式受控的一種(里程碑)狀態。
三者的關係是：重要的檢查點是里程碑，重要的需要客戶確認的里程碑，就是基線。有一句通俗的話是這樣描述：沒有檢查點，工作難進展，不設里程碑，專案往後推，基線不評審，客戶吃不準。
(2)怎樣才算是乙個里程碑呢?
簡單的說里程碑是完成乙個階段工作後可以看到部分結果的檢查點。一般來說，在軟體開發過程中，我們都會經過一定的流程或階段，例如資訊蒐集階段、需求分析階段、系統設計階段、系統開發和系統測試階段。每個階段都會產生交付物，每乙份交付物的完結說明我們已經完成了乙個階段的工作，一般情況下我們是在確認這乙份工作成果後才會進入下乙個階段的工作。因此，每乙份交付物將就是開發過程中的里程碑。
里程碑(基線、基點)是乙個軟體配置在開發周期內的某一特定時刻、正式的事件，它也就是階段性目標。里程碑是團隊階段性工作完成的標誌，對於任何乙個里程碑都應該給於認真的檢查、審定和批准。在里程碑中間應要設定大量的檢查點，這些檢查點應要細分到一旦檢查點出現問題不至於在進度上失控。
(3)里程碑可為進度預留緩衝時間
使用里程碑式模式還有乙個好處，就是將大專案分成若干里程碑式的重要階段時，可在各重要階段之間預留有緩衝時間。使用緩衝時間，可以很好的在專案未來實際執行進度和預計進度之間取得平衡。一般來說，在專案中我們需要為意外事故保留總開發1/3的時間，即「緩衝時間」。緩衝時間有助於乙個專案適應意料之外的事件，例如緩衝時間可以用於彌補進度延誤，或者是技術困難或是由於疏忽而忘記把任務寫入進度，或者是未料到的難題而形成的時間損失，這種應付突發事件的緩衝時間在開發和穩定化過程中是每乙個主要里程碑的一部分。
(4)警惕只問結果的里程碑陷阱
眾所周知，里程碑是專案進度控制中的乙個極為重要的概念，也正因為如此，人們也易於過於依賴里程碑，反而使專案進度落空。里程碑陷阱表現為人們在軟體專案的里程碑被設定以後，認為「目標管理是只問結果，不計過程」，從而忽視對過程的監控而導致專案里程碑不能按期達到。
如何實施里程碑式的管理
里程碑一般是專案中完成階段性工作的標誌，不同型別的專案，里程碑也不同。其精髓首先是將大專案劃分成若干個子專案或若干個子階段;其次，是通過每一階段對各人員角色職責的考核和監管，以保證開發過程的進度和質量。
(1)劃分若干個子專案，設立里程碑檢查點
專案進度是以里程碑為界限，將整個開發周期劃分為若干階段。根據里程碑的完成情況，適當的調整每乙個較小的階段的任務量和完成的任務時間，這種方式非常有利於整個專案進度的動態調整，也利於專案質量的監督。
在里程碑式的開發模式下，因為按子專案或子階段來劃分里程碑，每乙個子專案都會經過一定的穩定化階段。當再進入到第二個子專案的時候，就是基於前乙個相對穩定的子專案基礎之上，這樣就將風險或錯誤的累加分散到最低。以區域性的進度控制和質量控制來保證整體開發過程的穩定，使得質量和進度得以很好的控制，這就是里程碑式的開發模式優秀之處。
(2)每個具體的里程碑應與具體角色相關聯
里程碑模式也可以稱作專案實施進度管理模式，一但開發專案立項確定，需要做的第一件事情就是確定專案進度的里程碑。在里程碑中應清楚地定義每乙個階段的開始時間、結束時間、負責人和階段的提交成果。
因此，里程碑是專案經理進行開發進度控制的主要依據，里程碑一旦確定，各相應負責人應確保按時交付成果，這樣既便於明確各個角色責權範圍，也有利於按時完成任。例如每個具體的里程碑與開發組某一具體的人員角色相關聯，達到某個里程碑表明對此負有主要責任的人員角色完成了任務。因此，基於里程碑的軟體質量控制必然會演變成對角色的質量控制，這樣才能真正達到對軟體質量的控制，
(3)確保里程碑有可驗證的標準
我們經常看到許多專案進度中，都像模像樣地設立了里程碑。但實際上，最大的問題就在於許多里程碑沒有設定相應的驗證標準。在軟體開發專案中設立的里程碑，其作用是在專案進行時確認進度用的，沒有設定驗證標準就等於沒有里程碑管理。因此，需要給出乙個清晰的驗證標準，用來驗證是否達到里程碑。
(4)里程碑應標明交付成果的進度
在標識里程碑時，要根據里程碑完成情況標明交付成果的進度。更通俗地說，就是讓每個里程碑帶上乙個百分比，清楚的告訴團隊通過這個里程碑說明專案完成了多少。當然隨著專案進度的動態變化，未到達的里程碑的也應該做出相應的調整。
開發里程碑計畫 專案里程碑為什麼如此重要？
相信許多專案經歷都有這樣的感受 想要知道專案的最終結果與最初的計畫有多大的不同。專案里程碑就能夠幫助我們更早地發現問題，並採取適當的行動改變來交付專案預期的結果。里程碑是沿著專案時間線出現的重要的 有標記的進度點。一般來說，里程碑意味著專案開發中的乙個重要變化或步驟。里程碑將時間線劃分為幾個階段，我...
專案管理里程碑事件及相關
其實我心裡明白 使用者對專案不放心！由此，我想到 不僅中國使用者不放心，外國使用者也不放心，據說外國的月亮和中國的是乙個月亮。使用者給了你很多錢，總得聽個響聲吧，呵呵！1.美國空軍不放心 網路計畫技術 曼哈頓 計畫 1945年7月16日 2.美國海軍不放心 計畫評審技術pert 北極星 飛彈計畫19...
專案管理重要性
軟體工程的經驗告訴我們，乙個軟體開發過程是可以很長但也可以很短的時間。為什麼這樣說呢？其實道理很簡單，長的時間說明這個專案很難搞，時間長。短呢？說明專案容易很快就搞完。假如這樣看待乙個專案過程，那麼你就錯了。乙個專案過程往往不可以看得這樣簡單，因為這個過程是複雜。下面看乙個例子 乙個公司的老闆外包了...