こんにちは、カユウです。
システム屋のプロジェクトマネージャー (PM) といえば、KKD (勘、経験、度胸) と言われていたのは今や昔。
プロジェクトマネージャーをやる上での必須知識として、 PMBOK (Project Management Body Of Knowledge) が挙げられるようになってきました。
プロジェクトによっては、PMはPMP有資格者であること、という条件がつけられることもあるそうです。
ただ、PMBOKはもともとアメリカの非営利団体であるPMIが発表したプロジェクトマネジメントに関するノウハウや手法を体系立ててまとめたものです。
世界中から成功したプロジェクトの事例を集め、分析した結果がベースになっているそうです。
ですが、プロジェクトの進め方を事細かに書いてあるわけではありません。
プロジェクトの流れ、成功するために気にしなければならないポイントが書かれているだけです。
PMの教科書とも言うべきPMBOK 。
本書はそのPMBOKに載っていない課題の解決方法がストーリー仕立てで書かれています。
プロジェクトとは?
プロジェクトマネージャーが管理する対象のプロジェクトとはどのようなものでしょう?
それは「有期性」と「独自性」があるものを指します。
- 有期性:明確な開始、終了が決まっている
- 独自性:ユニークな点がある
例えば、旅行や結婚式、家やビルを建てるというのがプロジェクトになります。
どれも開始と終了が明確で、 人によってユニークな点がありますよね。
では、プロジェクトではないものは?
それは 定常業務、ルーチンワークになります。
繰り返されるので明確な開始、終了がなく、誰がどうやっても同じ結果になるもの、と定義できるでしょうか。
例えば、営業電話をかける、交通費精算、資料整理などです。
毎日、毎週、毎月、毎期、毎年など、繰り返す頻度はまちまちですが、繰り返されるものは定常業務になります。
プロジェクトを定義したところで、「エピソード1 できもしないこと」から、僕がダメージを受けたところを抜き出してみましょう。
「できそうもない約束」を口にするだけ信用ゼロ
小説の状況をサラッと書かせてもらうと、こんな感じです。
本書の主人公、檜山大樹は28歳にしてPMを拝命。
PMをやっているプロジェクトのやることが山積みで、プライベートでは結婚記念日が目前に迫っている中、帰れない日々が続いている。
進捗の遅れを気にした顧客より、リカバリープランの提出を求められては2度のダメ出しを食らっている。
そんな状態で、PLにも無理だといわれるリカバリープランを考えている最中、不意に妻から言われた一言が頭の中でよみがえる。
「できもしないこと、言わないでよね」
目の前の関門をくぐり抜けることだけに集中してしまうと、できもしないことを口にしてしまうことがあります。
口にされたということは、相手はその内容が約束されたものだと認識します。
その結果、約束が果たされなかったとき、相手からの信用がゼロになります。
難しいお客様や、作業進捗によりスケジュールに遅れが出てしまったとき、つい「間に合わせます」と言ってしまいがちです。
そこをぐっとこらえて、少し先の未来まで想像を働かせ、できること、できないこと、どうしていったらいいのかを考えられるようにならないといけないなぁと思いました。
一人で考え込まない
一人で考え込んでしまうと、客観性が失われてしまいます。
困っていることがあれば、仲間に相談することで、自分では浮かばない解決策やアイデアをもらうことができるでしょう。
時間がなくて、一人でさっさと決めてしまいたいときほど、衆知を集めて客観性を担保する必要があります。
追いつめられ、思い込んでしまってから出るアイデアはあまり良いものではない、というのが僕の経験則です。
とはいえ、余裕を確保し続けるのもかなり大変な作業なのですが。
変更を余儀なくされた時は、一回限りのつもりで、ダイナミックに見直せ
変更の都度、計画の評価やリスク対策の立案実施、調整、折衝、周知徹底など、プロジェクトに多くの負担がかかります。
そのため、小刻みな変更を繰り返すプロジェクトは本来の作業以外に多くの時間をとられてしまい、より深刻な状況になっていきます。
変更するときは一回限りのつもりで大幅は見直しを行い、そのうえである程度のことが起こっても耐えられるような余裕を組み込んでおくことが大事になります。
とはいえ、理論ではわかるのですが、実際に大幅に変更するとなるとお客様との調整、合意形成に最もエネルギーが必要になります。
お客様の中ではそのプロジェクトが他のプロジェクトにも影響しているかもしれません。
そうすると、そのプロジェクトが遅れることで、他のプロジェクトのスケジュールに影響を与えてしまうことも考慮しなければなりません。
できる限り、マスタースケジュールに影響を出さず、余裕を組み込んだ大胆な見直しをするのが現実的なところではないかな、と思います。
通常、お客様は他のプロジェクトのことは教えてくださらないので、打合せやメール等から推測するだけになると思いますので、難しいところですが。
PMBOKには掲載されていない、そのときどきの手法について、ストーリー仕立てで読めるので、自分の状況に当てはめやすいと思います。
ではでは、今回はここまで。