PMBOKは、あくまでもプロジェクト管理に必要な知識体系を整理したもので、 そのまま即実践に応用できるものではない。これを現場のプロジェクトで使える ようにしたものが「PYRAMID」(ピラミッド)です。本章ではこのプロジェクト管 理手法 「PYRAMID」 について紹介いたします。
PYRAMIDにおけるPLとPMの役割の違い
プロジェクト体制図を見ると、 プロジェ クトリーダー (PL)の上にプロジェクトマ ネージャー (PM) を置いているケースが よくある。 一般にPLは実際プロジェクトを 推進する人で、 PMは単に部長や課長がな るというお飾り的なものが多い。 「PMの役 目はプロジェクトの完成責任を持つこと」 という定義がもっともらしく聞こえるが、 部長や課長なら責任がかかるのは当たり前 であり、PMが何をすべきかを明示してい ることにならない。 PLからの報告だけを聞いて管理した気になっているPMというの が実に多い。
PYRAMIDにおけるPMの役割は、 「PLに プロジェクト管理を徹底させること」と定 義している。つまり自身でプロジェクトを 切り盛りする必要はないが、PLがプロジェ クト管理をきちんとやっているかをチェッ ク、フォローすることにしている。 プロ ジェクト管理のためのドキュメントの作成 や申請はPLが行ない、 PMはそれをチェッ ク、承認するという役割になっている。
PYRAMIDの基本的な考え方
各テンプレートの内容は以降の章で具体的に説明するとして、ここでは PYRAMIDの基本的な考え方を示しておこう。
PMBOKに合致した現場重視の実践手法
前出の表1を見てわかるようにPYRAMIDはPMBOKの体系に沿っている。 知識集であるPMBOKを現場で使えるように実践手法としたものが PYRAMIDの位置づけだ。 しかし、位置づけはそうなっているが、実は PYRAMIDはPMBOKをベースにして作ったものではない。 あくまでも、も ともと現場で使っていたプロジェクト管理ツールを標準化したもので、 PMBOKの出現の際にその知識体系とすり合わせて整理し、 バージョンアッ プしている。そのため、 PYRAMIDの考え方はかなり現場寄りであるし、みなさんもおなじみのテンプレートが多い。 現場で受け入れられない頭でっか ちなプロジェクト手法はまったく役に立たないという考えが、 PYRAMIDの 基本的な考え方になっている。
テンプレートリード方式
多くの企業でプロジェクト管理の強化を図っているが、どうしても理論が 先行してなかなか現場で使いこなせていない。 いくら高な理論が背景に あっても、そしてそれを実現するための手段が記されていても、具体的な ツールがなければ現場に浸透しない。 本当に使われるためには、「はい、こ れを使いなさい」 というように具体的なツール テンプレートを示す必要が ある。 そこでPYRAMID は、 PMBOKの理論を背景にしつつ、 Excelという誰 でも使える (修正もできる)ものでテンプレートを用意した。 決められたテ ンプレートを使うことが、 そのままプロジェクト管理を行なうことになる。 現場浸透のために「まず、テンプレートを使う」というのがPYRAMIDの基 本的な考え方なのである。
柔軟な管理レベル
がちがちの硬いプロジェクト管理は現場からそっぽを向かれる。 実際、ど の程度厳格にプロジェクト管理を行なうかは、プロジェクトの規模や対象シ ステムなどにより異なる。 比較的小規模なプロジェクトなのに、大規模プロ ジェクトと同じように管理資料を山ほど作らせるのは非効率だ。
PYRAMIDでは、プロジェクトスタート時に管理レベルをPMとPLの間で 協議して決めることができる。 プロジェクトの規模や難易度に応じて、 どの資料を作成するかなどをあらかじめ決める。 その代わり、いったん決めたな らばそれら成果物がきちんと作成されていくかをきちんと管理する。「今回 は、この程度の管理でよいだろう」と柔軟に決め、その決定をもとに成果物 の作成状況をフォローできる仕組みを持つというのがPYRAMIDの特徴だ。
「プロジェクト管理」 を管理する
プロジェクト管理手法を与えられても、 使わなければ意味がない。 実際、 プロジェクト管理者自身が忙しくなり、プロジェクト管理がおろそかになっ てしまうケースは非常に多い。 そこでPYRAMIDではプロジェクト管理者が プロジェクト管理をきちんと実施しているかを管理する仕組みまで考慮して いる。 プロジェクト管理をする人をPL、 PLがプロジェクト管理実施状況を 管理するのがPMと位置づけ、 PMがPLの実施状況を管理するためのテンプ レートを用意している。 PMの役割は部門長となるケースが多いだろうが、 部門長としてではなくPMとして該当プロジェクトの管理がしっかり行なわ れるように管理するのだ。
Webシステム化する
PYRAMIDがPMBOKをそのまま手法化したものでないように、 Object Browser PMも PYRAMIDをそのままWebツール化するものではない。 シス テム化するからには、マスタデータは一元管理され、 管理データは複数の知 識エリア、 プロセスに渡って関連付けられる。 たとえば、スコープ管理にお けるスコープはタイム管理におけるタスクに連携し、タイム管理における進 捗報告はコスト管理における原価に連携する。
また、Web-DBシステムとなるので、データを蓄積して積極活用するような機能にも重点をおく。 たとえば、 PYRAMIDでは総合管理の終結プロセス として「プロジェクト管理報告書」というテンプレートを用意している。 Object Browser PMでは、これらの情報をナレッジとしてデータベース化し、 社内で情報共有する仕組みを実装する。 また、 調達管理の終結プロセスと して「協力会社評価」 などの報告入力にも遷移し、協力会社の評価、 メン バーの評価などを共通管理するような仕組みも追加している。
まとめ
さて、最後にもう一度この章の鉄則を復習しよう。 企業でプロジェクト管 理を強化する場合、プロジェクト管理強化委員会のようなものを作ってプロ ジェクト管理手法を策定してゆくことが多い。その際に大切なことは最初か らあれもこれもと欲張らないことだ。 最初から消化不良を起すようなものを あてがっても機能を果たさない。 手法の優秀さを追求するよりも、いかに現 場で使えるかを優先した方が結局うまくゆく。
成功のために:
-
どんなにすばらしい手法・ツールでも、簡単にわかるものでなければ現場に普及しない
-
どんなシステムでもまったく同じ管理レベルを適用するのは、頭の固い現場無視の発想だ
-
プロジェクト管理だけでなく、管理が行なわれていることを管理する仕組 みも必要である
詳しくNALまでお問い合わせ ください。