企業專案治理

關於主管的時間管理

工時長,似乎已經成了高階經理人的宿命,當你是個副理,你做著副理的工作,當你升經理,你做著副理+經理的事,當你是個總監,你做的是副理+經理+總監的工作,職稱變動了,你的工作內容也有些改變,唯一不變的,就是工作量愈來愈大。

管理是一種態度,一種要求把事情做到、做好的態度

總經理:「對,這是我們花了兩年的時間才累積來的,我覺得企業的管理不見得需要很多規章,它有時只是一種態度,一種大家都想把事情做到做好的態度,一開始是我要求這些主管,他們也會要求自己的部屬,時間久了,我不用要求大家也會這樣做,因為這已養成一種習慣了,但我不會改變我『要求』的習慣,因為我認為只有當我持續要求,所有人清楚我對希望把事情愈做愈好的態度,他們會更努力找尋進步的空間,而不會流於形式。」

企業專案治理 初探

所以如果你打算只開一間店,我猜你的經營重點,恐怕會擺在找個有能力的廚師、找個人潮聚集的地點、想辦法壓低經營成本、好好訓練服務人員等相關事宜上。 就算你完全不會煮菜,只要願意花錢雇個有能力的大廚,你就可以把一切事情都仰賴在他身上。 不過這位廚師可忙了。 他需要設計菜單、採買食材、並在廚房實際烹飪,所有流程可能也搭配著他來設計(送菜、跑堂、點餐等)。 換句話說,他大概是整間店的靈魂人物。 有甚麼資源,都應該投資在這個角色身上,所有人都應該配合他來演出。

改革要成功,你該先搞定這三件事

我們是商業顧問,所以不可避免常常會有人來找我們諮詢管理問題、請我們去上課、或是協助內部改革。 多年的觀察下來,我的結論是:任何改革要成功,其實有幾個關鍵的前置準備。 換言之,講師與顧問不是魔法師,在你的組織還沒有準備好之前,外部顧問其實幾乎不會產生甚麼決定性的作為。 但甚麼是該事先準備呢? 我覺得有三件事。

沒有資訊背景與經驗! 該如何委託外包商開發軟體?

這幾年認識許多軟體創業的朋友,他們在找尋不到合適的技術合夥人且自己不懂程式的狀況下,會轉向委託軟體外包商開發產品,可是軟體外包涉及的層面非常廣,如果沒有外包的經驗,就算是專業的軟體公司也很難與外包商磨合,更別論沒有資訊背景的朋友了。

我的Scrum新體驗 - 測試策略篇

在規劃測試時, 我們一開始面臨的問題是, 整個開發時程分成哪些階段. 也就是說, 是否要都是要由 iteration 組成呢? 可是我們公司有所謂的 alpha 和 beta 階段, 尤其是 beta 階段, 我們必須把產品交給外面客戶去做測試, 這可能是無法廢除的, 那要怎麼配合呢?

我的Scrum新體驗 - 回顧會議篇(Retrospective Meeting)

回顧會議是 Scrum 中最重要的一個會議, 它讓你有機會反省在上個 sprint 所做的一切事情. 老中很努力工作, 可是卻不檢討做事方法, 所以工作的很辛苦,卻不見得有效率.

我的Scrum新體驗 - 每日會議篇(Daily Scrum Meeting)

我的專案開始採用 Scrum 的方法來開發專案, 這是一個新的體驗. 一開始時是工程師們說要這麼做, 我的想法是一則以喜, 一則以憂. 喜的是終於有機會可以嘗試 agile 的方法了, 憂的是在這麼短的時程內, 用新的方法似乎風險很大. 不過既然大家都願意這樣做, 那就豁出去了. 因此, 接下來我將會分享這幾個月來(開始於2009/2中), 使用 Scrum 的風風雨雨.

為什麼我不推薦敏捷開發

當專案成員越多,我越不推薦敏捷開發,原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前,就跳下去玩敏捷開發,那和比通靈還慘,通靈起碼還有個目標物在前面,搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。 敏捷開發 - MBA智库百科 最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟體開發 - 維基百科。 誤解一:敏捷對人的要求很高 說高不高啦,撇開實作技術不談,你覺得要找到清楚專案開發流程、知道每位專案成員的工作內容、職責範圍、產出,並清楚專案目標、需求、使用者需要的開發人員(含設計師)很容易嗎? 如果上述條件無法達成,又

《超速變革》閱讀心得

這幾日看完了John P. Kotter的最新作《超速變革》這本書。 我之前讀過他《領導人的變革法則》這本書(很不錯的一本,但可惜已經絕版),對於他針對組織變革的概念非常認同。 尤其他提到領導人在變革前要花時間努力建立危機意識,跟我的經驗完全吻合。 我自己在很多企業協助推動專案制度的變革(這類變革通常都會影響整個公司層面),也發現只要公司高層在前期沒有花足夠時間由上而下的溝通「為何要做這類事」、「為何是現在這時間」、「為何這麼急迫」,結果通常就很難讓人滿意。 要不是會因為大家重視的問題不同而在方向上逐漸失焦,再不然就是中階主管因為工作增加而

《Google模式》閱讀心得 - 塑造讓成員能自我判斷的文化

這本書我目前其實才看到第二章。 這篇(以及後續可能的篇章)不是書的導讀,只是我針對其中幾個論點,我衍生的一些想法。 甚至這些要點之間恐怕未必有什麼連帶關係。 只是看了覺得有趣,所以寫下來。 一方面方便自己記憶,一方面大家不嫌棄的話,也可以順便看看。   1. 關於自我判斷的文化塑造   過去總聽很多人宣稱, Google是個完全任由工程師自由做自己想做事情的公司 - 因為它們給工程師絕對的自由,所以創意以及偉大的產品才能因此產生。 我自己因為沒深入了解過Google,所以我無法評論這論述的真偽。

《動態競爭優勢時代》讀後感

這本書是前兩週天下出版的編輯部送給我試讀的。 不過在剛收到她的推薦Email時,因為名稱看起來很硬,讓我有點意態闌珊。 不過編輯信中還提到這作者的概念跟我們七月出的那本〈三年後你的工作還在嗎? 掌握關鍵職能,迎向工匠、總管與行腳商人的時代!〉很類似,只是這本書是從企業經營策略的角度出發。而這點吸引住了我... 「原來,我們的想法也有國外的大師用不同的面想闡述過嗎?」這讓我被誘惑住了,所以就趁著週末把這本書讀了一遍。(說起來我意志力還真弱XD) 這本書的作者是哥倫比亞大學商學院的教授,名叫莉塔・岡瑟・麥奎斯(Rita Gunther M

組織為何會慢慢讓人失去同理心?

最近有個老闆來找我們,希望我們能幫忙他規劃一個講座。 我說,『關於甚麼題目? 專案管理的知識嗎?』 他搖搖頭說,「我們內部已經有設計很嚴謹的管理流程了(得意貌),只是我覺得我的員工常常相互推卸責任。 部門之間的隔閡也一直很嚴重! 很多人事情只做一半。 明明多用心一些,幫其他部門多擔待一下,不是能讓事情更圓滿嗎?」

阿婆問路最終章 - 如果樂觀悲觀都不對,到底PM該怎麼辦?

上次在 阿婆問路與天期預估的進階版 的最後提到,若你考量到人性的弱點後,你會發現無論是樂觀預估或是悲觀預估,專案最後產生延遲的狀況都不會改變。 所以我在文章最後丟出一個問題:「如果預估的樂觀與否跟專案能否順利完成沒有正相關,那作為一個PM到底該怎麼辦呢?」 :D 這篇就要來談談我的看法。

身為PM,你不該只是個接線生

最近這半個月,身邊有四位擔任PM的朋友像約好了似的,和我吐露了他們的職場困境。這幾位當中有親戚、有我班上的學生、也有演講的聽眾。他們年紀都是40上下,曾在科技或軟體業擔任專案經理的職位。在這波不景氣下,有的失去了工作,有的被困在不理想的職位上進退維谷,有的則是看不到職場的下一步。