(三)時程中的資源。
| 項次 | 專案管理的意義 | 微軟Project軟體的重點 |
| I | Bottom-Up estimating (i)作業(activity) (ii)作業工期(activity duration) (iii)資源清單(resource list)& Resource Calendars (iv)資源單價(resource unit price) (v)資源指派(resource assignment) (vi)資源投入量(resource planned unit) | (1)檢視/資源工作表 類型：工時、材料、成本。 ※成本無法設定單價，只能於專案/任務資訊(資源)下直接設定總額。 基準行事曆 最大可用量(100%=1單位) (2)工具/分派資源 (3)專案/任務資訊(資源) |
| II | (工時=單位*工期) 任務類型： (i)固定工期 (ii)固定單位 (iii)固定工時 | (1)工具/選項(排程) 預設後續建置的任務類型。 (2)專案/任務資訊(進階) 特定任務指定任務類型。 |
| III | Contingency | (1)檢視/資源工作表 + 專案/資源資訊(成本) 提供五個頁籤設定不同成本單價。後續可在檢視/其他檢視/任務分派狀況(一般)的成本比率表選定所又的成本頁籤。 |
資源在專案中的運用，相對於組織與專案本質有著非常密切的關係。就肥蝦有限使用專案管理軟體的經驗(P6還尚未領教過)，對系統中這部份的設計與操作，個人均非滿意。原因在於專案的資源不是來自於公司組織內部、外購，或者自專案中產生，但是系統較少缺乏與其他部門整合的介面。就以軟體專案而言，人力資源為專案主要投入資源，但公司的人事資料與差勤記錄絕少能接入專案管理軟體；人力成本計價多事屬人事部門與會計部門，而資源使用成本的分攤與計價也無法自該等單位之系統或作業匯入。肥蝦在從事軟體系統的分析與整合非常重視邏輯架構中的”主從”關係。就專案管理的角度，專案管理系統當然屬於主動的地位；但在專案可使用資源的部份，肥蝦以為這應該比較屬於從屬的角色。
肥蝦之所以論及上述問題，主要在於提醒：「專案管理工具是在協助專案的執行，沒有一套絕對的系統可以掌控專案的狀態，專案經理應必須視專案與公司情況，並瞭解可使用系統的限制與長處，因時、因地動態的考量與使用特定系統的部份功能，而非要把系統所有功能套進專案，這將衍生出更多專案管理的問題。」
微軟的Project軟體，就專案的資源管理上，肥蝦以為這只能在專案的資源已經公司指定之後，方能啟始，並必須要隨時注意更新，尤其在功能組織的公司中，更應該加強注意與協調。此外，有一點比較trick就是到底專案經理是要先設定任務的工期，還是先指派任務使用的資源，這情況在愈是知識服務的專案就愈顯唐突。在實作建築裝潢的案例中，因為工期已經預先設定，待學員指派依據任務的起迄時間指派資源，但是就肥蝦所經驗的資訊建置專案中，所遇到的情況恰好是反過來的。那真實情況為何呢？其實這依據專案的本質與組織Organizational Process Assets與Enterprise Environmental Factors而異，並無定論，也無絕對的法則。另外，在此可以分享的一個經驗是：若是使用Project軟體做資源的規劃，應切勿一開始就指派特定的資源入特定的任務，而是建立一個或多個虛擬的群組，比如：初級程設師、高級程設師、分析師、高級分析師之類，此不但可設定任務要求的條件與成本設定，也可避免功能部門主管溝通、進行資源撫平與日後維護的困難。
此外，Joe也提醒學員，切割任務之時應協調資源的完整性，設法將完整使用資源的工作設定為一個任務，以避免有太過複雜的管理介面。這建議是因應系統操作的方便與可讀性，而與專案管理本質間進行trade-off的關係，這就要由使用者自行判斷，當然如果這系統是由成員與客戶間共同使用，那這trade-off的關係會更加複雜。
最後Joe提到專案資源中Contingency的設定方法：(1)追加資源的unit與duration。(2)非要徑任務拉長工期，但調整unit與duration。(3)建立一Contingency的資源。以上這已是所有可能的作法了，至於要如何做？就看公司與客戶而定，如果您的時程表要給對方檢閱，而對方又是箇中高高手，且下手無情，一心逼您到最低的成本，那…那就~~~~~天可憐見了！
(四)時程的安排。
| 項次 | 專案管理的意義 | 微軟Project軟體的重點 |
| I | CPM | (1)檢視/追蹤甘特圖 |
| II | Total float vs. Free float Leads and Lags | (1)插入/欄(可寬延的總時間Total Float/可用可寬延時間 Free Float) (2)專案/任務資訊(前置任務) 延隔時間為正代表Lag；為負代表Lead。 |
| III | Resource Leveling | (1)檢視/資源使用狀態表 (2)檢視/資源圖表 (3)工具/資源撫平 Bryan特別提醒此功能僅能當參考使用。 |
| IV | Triple constraints trade-off | |
關鍵路徑(Critical Path)為專案活動最長的路徑，也是完成專案最短的期間，即該路徑上的Total Float最低。若再加上Resource的考量就是關鍵鍊Critical Chan Method。基本上，專案經理必須隨時緊記：「關鍵路徑是會變動的！」因著專案的執行或環境的更迭，關鍵路徑是會轉彎的。一些已具功力的專案經理投注全力在關鍵路徑的活動之上，而忘了此點。此外，就如前述(二)所強調的Dependency Determination，關鍵路徑中的Discretionary Dependency是專案經理可以去溝通協調的主要部分，至於Mandatory與External Dependency的活動就應考慮是否加入Eliyahu M. Goldratt於【關鍵鍊】乙書中所說的接駁緩衝或瓶頸緩衝，另外針對資源有限的部分考量資源緩衝，整體專案則視需要加入專案緩衝。不管緩衝的目的為何！這個Buffer就是一種時間的Contingency，因此如何安插也如同安插資源Contingency的一般，須視組織與客戶的觀點與認同，以及時限的壓力。
配合此段專案管理功能的講解，Joe與Bryan提供了一個非常有趣又好玩的案例－”天上掉下的燙手山芋”。 針對此案例肥蝦已另行撰寫【「D3動態時程規劃營」個案心得】乙文，此處就不再贅述。只是肥蝦那信口亂謅的那『玉米田裏遍金黃，人形孤單鴉滿天。穗飽汁鮮雀先嘗，披星戴月屎滿身。』就感慨個人接手或中間介入那處於困境的專案的感觸。近來肥蝦又補上了一句：「專案管理只有壞的怕狠的，狠的怕沒天良的!心軟的注定該死！」的現境哀鳴。就如同此案例所言：「前手因罪入獄，被指派臨時接任，主要專案資料也已隨人一同入監。」在專案緊迫之下，新任PM如何把死馬當活馬醫？這非常人所可為呀！
針對此案例，肥蝦必須衷懇的給Joe與Bryan一個建議。在研討會中，大家拿到案例就埋頭看活動項目、內容與資源，對於那案例的背景陳述，文字記載甚少關注。這情況並不符合一個PM應有的作法。在PMBOK 2008中特定把專案相關的記錄、文件等資料合併為Project Documents，在程序之中需要不斷更新，並且把位階拉抬至專案管理計畫(Project Management Plan)一般，何為？因為專案經理首要掌控專案的第一手資料為Project Management Plan與Project Documents。一個專案經理剛接觸專案不仔細審視Project Documents，以及其上的文字記載，建立全盤的瞭解，只知聽人言，埋頭做，往前衝，那專案也將是汲汲可危，專案管理的價值與精神也是蕩然無存。肥蝦另有撰寫一篇個人的心情隨筆，就是描述了專案經理如何稱職的消毀或不留下文件，以使後續者無以為繼的案例。這也是為何閱覽戰爭史書中戰敗者撤離前一定要燒毀文件是一樣的道理。因此下次的研討會，建議Joe與Bryan應花點時間讓大伙看看資料後發表自己或各組的思考點與見解後，方行進行專案時程的重新安排。(待續)
沒有留言:
張貼留言