企業專案治理

越來越多人想做專案管理這一行!但專案管理真的是個行業嗎?

這篇文章希望對想從事專案管理相關工作的朋友有些幫助。如果我的預測沒錯,大家對專案管理的重視在未來只會更多,而且會擴散到幾乎所有產業。道理很簡單,就是「創新」兩個字!幾乎沒人會反對,人類經濟的成長從來沒有像今天這樣高度仰賴創新,而所有的創新都是獨特的、不重複的,這些都仰賴專案的形式來達成,所以很難想像,未來的企業或個人,能在沒有專案管理能力的狀況下達成任務。是時候該備妥這項新技能了!

先做迅速有成效的事:新任PMO主管該做的三件事(下)

前篇文章中提到,PMO在這幾年變成了一個新鮮的議題。身邊滿多讀者或是朋友,因為公司轉型或是任何理由,被要求負責這部門的建置或營運。我每次給這些「苦主」的建議,都是請他們立刻思考這三件事:避開常見陷阱、搞懂你所處的狀況、做很快能有成效的事情。上一篇談了第一件事以及第二件事,這篇則要跟大家分析一下,所謂「做很快能有成效的事情」背後的理由是什麼,又具體該做些甚麼。

關於主管的時間管理

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

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

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

企業專案治理 初探

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

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

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

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

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

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

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

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

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

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

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

為什麼我不推薦敏捷開發

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

《超速變革》閱讀心得

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

專案經理必會拿捏的藝術:關於授權

最近很少接觸技術類的內容,都沒什麼機會撰寫一些深入技術面的內容跟大家分享,只好跟大家分享自己在管理上的一些經驗,讓同為IT人的大家參考參考,在講這個之前,我還是必須要先聲明,管理/領導的手法百百種,不見得我的方法適合用在每個場合,大家可以提出不同的看法與案例一起討論討論。 我想我可以有這麼多機會學習,去碰壁,我都要感謝我的主管R先生跟N小姐,由其是R先生讓我有很多的機會嘗試各種管理手段,在一次又一次的碰壁中學習,這樣的經驗真的很珍貴,而我也希望這樣的經驗可以給各位做為參考。

如何帶領團隊往正確的方向衝?

三年多前我剛進入兵荒馬亂的環境,承受一波又一波的挑戰時,老闆古哥對我們部門說了這麼一段話: 『唯有不斷的進步,超出業務單位的想像,我們才能獲得更多的掌聲,也才不會被業務單位壓著打。』

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

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