專案裡那些容易忽略,但沒做可能會死的關鍵工作

專案裡那些容易忽略,但沒做可能會死的關鍵工作

最近不約而同的收到幾位 PM(Project Manager)來詢問在實務上遭遇的疑難雜事,多半都與人相關,我回答起來,也幾乎多不是工具和知識架構所能解決的問題。

是的,一個優秀的 PM 除了搞清楚專案本質,以及 WBS、資源、利害關係人……這些重要大事之外,還有幾項隱而不顯卻非常重要的「內部」工作,而這些事情還通常都沒人教。

1. 盡早把遊戲規則談清楚

首先,我要強調三次:愈早愈好、愈早愈好、愈早愈好,等你出事再來訂規則,不但效果不好,還會變成團隊的怨氣標靶。(出事時都要忙死了,還要應付 PM 新搞出來的規則,有事嗎?)

1.1 談清楚「會議規則」:專案會議怎麼開?哪些人需要參加?多久開一次?主要討論的內容是什麼?報告格式長怎樣?每一次的主持人、紀錄是誰?如果誰不能來,那麼他必須請代理人來參加嗎?

如果可以,最好在專案初期就先 Booking 好團隊或其他重要利害關係人的會議時間。

才不會等你想到這件事的時候,大家的時間都「剛好」湊不到一起,不是東缺一個西缺一個,就是會議根本無法順利展開,而且到時候才約時間,凡是一開始沒有先講好的,團隊絕對會認為是多出來的工作,得花上數倍的心力,還吃力不討好。

1.2 談清楚「範疇管理規則」:若有人發現不在專案範疇內的工作或任務,要怎麼回報?怎麼處理?有沒有統一評估的窗口?或者要怎麼在第一時間統一說法回覆客戶?

1.3 共識「假勤規則」:雖然在台灣,大多數的 PM 在跨矩陣組織中,都沒有團隊准假的實際審核權力,但與其怨天尤人,還不如先和團隊共識好,發生什麼狀況的時候,大家可能要暫時延後休假?哪些人和哪些人盡可能不要一起休假?

1.4 共識「代理制度」:專案內的代理人制度要如何運作?誰是誰的當然補位人選?

2. 決定權責結構

2.1 決定「客戶問題處理權責」:客訴發生的時候,誰是第一線?誰統一處理和回覆?不要到時候訊息大亂,每個人回給客戶的都是不一樣的答案,造成更大的麻煩和危機。

2.2 決定「內部執行規範權責」:(以軟體舉例)內部的開發或設計規範,要遵照什麼標準?誰有權限可以去調整和異動?不在這個規範當中的事情,由誰來負責拍板和決定 。所以我認真說,PM 絕對不應該是外行人,就算當下還少了團隊的專業,也要盡快的利用時間能補多少是多少。

2.3 決定「專案變動通報權責」:團隊如果預期專案可能要 Delay 或超支,什麼情況下必須主動通報?多少比例之內由誰來決定?多少比例之外要到誰來處理?

3.定義資料與資訊收集規則

3.1 大家必須要定期回饋哪些資料?多久一次?回饋給誰?

3.2 工作進度回饋的方式?認列進度的方法?特別是難以量化的工作(像是處理客訴、與供應商議價、測試程式等)。要如何認列回報進度的共同原則?

3.3 專案進行過程中,應該要給客人什麼東西?什麼時機點給?

3.4 要不要報專案工時?若要,專案工時的分類結構與定義為何?

3.5 哪些資料不能外流?哪些資料內部和提供給外部必須要是不同版本?

3.6 哪些類型的資訊可以透過 email 通知?哪些請盡量用電話或面談搞定?哪些問題「才」需要 c.c.(副本)給誰?到哪個層級?或是盡可能不要使用「密件副本」,因為很可能不小心沒發現自己是密件副本的收件者,突然跳出來回信,會「有點危險」。

所以,正在火線上的 PM 們,你的 Check List,絕對不會只有 WBS,多半我們能夠容易學到的,是方法和知識架構;而決定你的生存機率的,常常是這些看起來好像是微不足道的小事,但是卻很關鍵的規則。

 

原文轉貼自:Elva手記原文連結

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。