DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

こんにちは。
前回は、若手PMのOJTの中で、プロジェクト計画書をどのように点検するのか、ポイントをご説明しました。それを実践した経験の浅い若手PMのエピソードを、引き続きお話しします。
彼の担当する企画がどんな状況になり、彼が洗い出した問題や見つけた原因は何だったのか、そして原因をどのように取り除いたのでしょう。

***************
プロジェクトの停滞
企画室のひとりの若手PMが、自社の営業現場の情報収集システムのシステム化企画を担当していました。
営業現場では、情報をより早く入手して業務の改善をすることには、総論賛成。でも、この情報さえあればここが改善できる！という各論が決まりません。その情報はあった方がいいけれど、さりとて業務改善を労するほどの役にも立たなさそう、という議論の繰り返し。

大きな目標はあっても、具体的なサービスや新しい業務を創造することができず、全く先に進まない状況です。
そのうえ、現場の関係者は日常業務に忙しく、未知数の企画にそうそう時間を割いてはいられません。そうこうしているうちに、打ち合わせの参加者も減って全員が揃うことも稀になり、合意がとれない状況となりました。

しばらく進捗がなく、プロジェクトが停滞してしまいました。
そんな折、彼の上司が、改善後のイメージを描いてみるように導きました。
・新しい情報をいち早く入手して営業提案に盛り込むことができ、受注がUPする。
・情報を共有することで、営業スキルや知識に影響されない提案が出来る。
　等・・・
とりあえず描けましたが、それを段階的にどう落とし込んでいくか、さっぱりアイデアが浮かびません。
彼の先輩も業務の再整理の指導にあたりましたが、やはり進捗せず、課題解決の策あらず。

その後、室長から私に依頼がありました。彼に、プロジェトマネジメントの基礎を改めて教育して欲しい、と。

プロジェクトマネジメントのおさらいと計画の棚卸し
彼に、計画の棚卸しをして見直そう、そのためにまずプロジェクトマネジメントの基礎に立ち返ってみよう、ともちかけました。一緒にプロジェクトマネジメントの5つのプロセス群と9つの知識エリアについて、おさらいをしました。

—
ではここで、PMBOKのプロジェクトマネジメントのプロセス群と知識エリアについてみてみましょう。
PMBOKで定義されているプロジェクトマネジメント・プロセスは４２あり、５つのプロジェクトマネジメント・プロセス群と、９つのプロジェクトマネジメント知識エリアに仕分けができます。
仕分けした表は以下の通りです。

この表を見て何か気付きませんか？
そうです。全プロセス４２のうち、計画プロセス群に２０ものプロジェクトマネジメント・プロセスが存在します。
ということは、プロジェクトマネジメントは計画を立てるのに、非常に多くの労力が必要だということです。
『計画なくしてプロジェクトマネジメントにあらず』です。

（注）　上記内容はPMBOK第4版です。
　　　　現在PMBOK第5版が発行されています。
　　　　第5版では、５つのプロセス群／１０の知識エリア／４７のプロセスに変更されて　　　　　います。
　　　　知識エリアには「プロジェクトステークホルダー・マネジメント」が追加されました。
　　　　PMBOK®ガイド第5版日本語版はただいま翻訳中だそうです。

—
彼にも、計画の重要性について理解してもらいました。

その後、彼が立てた計画を点検するため、あるべき計画書と彼が作成した計画書の項目を照らし合わせました。

・目的
　あるけれど夢のような内容で、かつ抽象的。実現可能とは思えない。
　プロジェクトメンバーが目的に向かうために実現可能なものを書くべきなのに・・・
・前提・制約条件
　洗い出していない。
　法令やビジネス上の競合、技術的制約、場所等、多方面から考える必要があるはずな　のに・・・
・進め方のアプローチ
　そもそも、そのようなお題が無い。
　組織で採用している標準やガイドラインはないの？
・体制・役割
　関係者の名前が並んでいるだけで、誰が意思決定して責任を持つか、それぞれのタス　クの実行者は誰かが記載されていない。
・リスク
　洗い出していない。
　リスクを洗い出し、その予防策等を考えて、計画に盛り込む必要があるはずなのに・・・
・スケジュール
　フェーズレベルの定義のみ。WBSがないため実行タスクがわからない。
　これではだれも作業に取り掛かれない・・・

プロジェクト計画書とは、プロジェクトメンバー全員で方向性を合わせ合意し、一丸となって遂行するための重要な資料です。
プロジェクト計画書が「作れと言われたので、とりあえず作っておいた」では、PMとしてプロジェクトを進めることはできません。
私は彼にプロジェクト計画書というアウトプットの形だけではなく、その意義を理解してもらうために、一つひとつの項目に対してなぜ必要なのか、今の内容では何がダメなのか、どのようにしたら有効な計画になるのかを教えました。

プロジェクト計画の意義を理解した彼は、今ある計画をあっさり捨て、一からプロジェクト計画を作り直したいと言いました。

自己流のプロジェクトマネジメントから、基礎に立ち返って
プロジェクト計画再作成後の彼は、見違えるようにきびきびと、関係者に向けてプロジェクト計画を説明し、プロジェクトメンバーと合意を取り、士気を上げ、プロジェクトを再開しました。
結局、計画当初より1年程度遅延しましたし、プロジェクト遂行中も難しい局面がありましたが、プロジェクトを最後まで進めることが出来ました。

後日の彼が言っていました。
自分の企画が停滞していた頃、ただいたずらに自身の無力さを責めるだけで、何がいけなかったのか考えもしなかった。プロジェクトマネジメントについてはなんとなく知っていたが、あのおさらいの時間の中で、計画を立てることの意味が腹に落ちた、と。

***************
彼のエピソードはここまでです。

次回は、文章表現を磨く取り組みをした若手のエピソードをご紹介したいと思います。

響子さんプロフィール

響子さん
部署名：コンサルティング本部
入社年：2006年

独立系ソフトハウスで、中小企業向けのアプリ開発や、病院向けシステムのカスタマイズに従事。その後、コールセンターでユーザーのサポートに着任。2006年より現職。
プロジェクトマネジメント標準策定、大規模プロジェクトのマネジメント支援、IT組織の戦略策定支援、IT人材育成支援に従事。