專案進度控制是專案經理的一項重要職責。俗語說的「時間就是金錢」在這裡體現得再明顯不過了。專案管理和自駕車回老家過年是相同的，實際上按照專案的定義，「自駕車回老家過年」也是乙個不折不扣的專案，只是它更貼合大家的生活，更容易引起共鳴，我們就拿它來做例子說明。
從乘客的角度，如果坐車很久，但是沒有達到預期的目 的地的時候，就會產生疑問，一般都會去詢問司機「到**了」，如果司機的回答沒有那麼令人滿意，這個疑問就會積累。積累到一定程度，就會開始懷疑是否迷 路，如果這個疑問一直無解，最終就會要求停車問路。如果坐的是計程車，就會導致乘客下車，換車繼續前進。
專案進行過程中同樣如此，因為軟體專案的「不可見」特性，客戶心理更脆弱和不穩定。如果每次專案經理給出的進度都是無法驗證的，客戶的疑問就會積累，最終到無法忍受而爆發。
人對乙個事物的完成都會有自己的「心理預期值」，這 個值會隨著人對該事物的了解的加深而進行調整，並變得越來越準確。乘客坐車到目的地，如果他對路線熟悉的話，一般都會跟蹤一些關鍵的地標和時間的對應關 系。比如從南山科技園到深圳火車站，一般用時不會超過1小時，開車走深南的話，肯定會經過世界之窗、市民中心、帝王大廈，最後到火車站。如果在晚上8點出 發，過了半小時都沒看到世界之窗，乘客會怎麼想？
專案也是如此，客戶的心理預期就是專案「里程碑事件」的到達時間。專案經理制定專案的里程碑，目的之一就是去影響客戶的心理預期。但是這種行為是一把雙刃劍，會影響客戶的心理，同時也會對專案構成約束。
實際上，專案進度表現在兩個程度，乙個是微觀的層 面，這個層面上，所有的事情都是乙個乙個的task，乙個專案下來，有成百上千個task要去完成，這個層面是專案經理和專案組員關注的，是最準確的進度 描述；另乙個是巨集觀的層面，這個層面是客戶以及專案外部的干係人所關注的，每乙個進度都是乙個「里程碑事件」，這種層面的進度描述並不是十分準確。
依然從心理角度去分析，專案經理給出的進度有誤差是 肯定的，關鍵是和現實的落差是否在範圍之內。如果客戶持續覺得專案的進度描述是準確的，那麼對專案也就越有信心，對專案的支援也就越好，對失誤的寬容度也 越高。反之，如果對專案進度沒有信心，那麼就會對專案施壓，對失誤的處置也會越嚴厲。
如何把握進度和進度的報告，常用的方法有「堵」和「疏「。所謂的」堵「就是隱瞞，專案經理可以進度造假造得很漂亮，但是到最後交付不了，就會被修理得很慘；而」疏「則是如實匯報，讓專案干係人透明地掌握專案的主要細節。實踐中，很多專案經理採用了折中的方法，有些如實匯報，另外一些則隱瞞起來，避免不必要的麻煩。但是實際上，專案經理」說真話「是要有一定能力的。
首先是」專案組實際的完成能力「，通俗點就是每天、 每週最多能完成多少任務，如果專案經理和客戶都知道這個速度，客戶就不會提出過分的進度要求，專案經理也可以拒絕所有超出能力的進度要求。這個」能力「其 實就是專案經理」say no「的底氣**。現實中很多專案經理因為不知道團隊真實的能力，胡亂應承，結果害了自己，也坑了團隊。
其次是」專案進度的**能力「，如果專案經理給出的完成時間每次都能做到，他以後的專案工作就會越來越順暢。許多專案組和客戶的衝突，起因大都是因為」進度**不准「甚至」無法**進度「導致的，進度再一再三地突破客戶的心理預期，想不讓人發飆都不行了。
在 專案實戰中，專案進度的評估和**非常不容易，但是並不是完全做不到的。我們可以反過來看，從專案結項的那一刻開始。在結項時刻（算上變更之後的），專案 的進度毫無疑問是100%，往前推一周，我想進度是可以**的，但是往前推乙個月就會模糊一點了，越往前越模糊。換言之，專案的進度**是隨著專案的進展 而越來越清晰的。
先 分析」為什麼會模糊「。問題在於兩個方面，乙個是」任務分解「，乙個是」臨時性的任務「。對於前者我們可以逐步分解、逐點清晰的方法來解決，對於後者我們 可以預留時間。我們可以先用大塊的任務寫在任務列表中，等要處理之前再去分解細化並再評估，隨著工作的進行，任務列表會越來越細，評估也越來越準確。對 於」臨時性任務「則在計畫表中預留時間去處理。
接下來分析」如何清晰「。
首先是」預估「，把當時能夠想到的所有任務都寫在計畫表中，不要怕不詳細，也不要怕不準確，有總比沒有好，但是要記得及時對所有可以細化的任務進行細化；
其次是」記錄「，專案經理把專案組所有做過的任務都記錄到任務計畫中，等到積累到一定程度之後，就可以從計畫表中看到專案組完成任務的速度，即」專案組實際的完成能力「，這個能力值的單位可以是」任務/天「、」工時/天「、」工時/周「等。同時可以得到的，就是」計畫外工作量「的值，這個值可以指導專案組調整為「臨時性任務」預留的時間。
最後就是「優化和**」，通過前兩步的成果，對未來的進度進行**並及時進行調整。
總之，專案進度管理中，要遵循的就是如下三個公式，任何乙個懂得小學數學的人都可以完成：
開發速度 = 已完成工作量 / 已耗費時間
當前進度 = 已完成工作量 /總工作量
剩餘時間 = 剩餘工作量 / 開發速度 = （總工作量 - 已完成工作量） / 開發速度
而實戰中，通過「記錄任務」知道「已完成工作量」，並得到「開發速度」，通過不斷細化逐步逼近「總工作量」，也就得到了越來越準確的「當前進度」和「剩餘時間」了。
專案進度管理其實並不難，不是嗎？真正難的，是「驅散恐懼」。
關於專案進度控制的思考
思考源於最近的工作經歷。去年下半年開始的乙個大專案，我作為其中乙個子專案的專案經理。因為外部因素，專案整體進度延後，何時上線並不明朗。我負責的子專案在3月份按照初始設計完成功能開發和測試，之後一直進行修改和完善。但進度一直很不如意，分配的任務總是延期。最近插入乙個新專案，只有三周時間要完成開發和上線...
BI專案進度控制的方法
專案進度控制 bi專案其實與軟體專案結構也大同小異，模型相當於資料庫層，etl相當於業務邏輯層，essbase與前端相當於應用層。業務邏輯在軟體中表現為類，而在bi專案中表現為sql語句或儲存過程。前端有兩種展現方式，多維 用工具實現 報表 用bi.office實現 對於前端，可以先設計錶樣出來，不...
有效控制專案進度的幾點技巧
文 白天 軟體開發的專案週期大體分為3個階段 獲取需求和定義產品 開發和測試 部署和運維。在獲取需求和定義產品階段，需要防止 的不是進度太慢而是過快 過草率。特別是對於創業公司的產品經理來說，很可能因為看到開發人員無事可做而感到壓力，所以盡快完成產品定義，而沒有充分了解 市場和競爭對手資訊，沒有與合...