PMstyleプロデュース

プロジェクト憲章を作るようにしたものの、あまり効果が出ないケースは、インフラストラクチャーがきちんと整備されていないケースが多い。グランドデザインを持たないままで、プロジェクト憲章でプロジェクトデザインをしているわけだ。

イメージがわきにくいかもしれないので、PMstyleで使っているインフラストラクチャー（グランドデザイン）の例を示す。PMstyleでは、ＰＭＢＯＫのプロセスに併せて、立ち上げ、計画、実行・コントロール、終結のそれぞれに対して、プロジェクトグランドデザインとして決めるべきことを設定している。

プロジェクトの立ち上げに対するグランドデザインの例だ。

・プロジェクトスポンサーシップは明確で、確立されているか。明確に述べられているプロジェクトのビジネス目的は何か。
・プロジェクト憲章はどのように作られるか。誰が作成し、誰が承認するのか。
・初期のスコープ定義をどのように決めるのか
・ステークホルダ特定はどのように確認されるのか
・チームをどのように作るのか。チーム編成に際してどのような要求があるか
・コミュニケーション計画はあるか。コミュニケーションにどのような環境が必要か。
・統合変更管理をどのように実施するか。
・チームにおける意思決定にどのようなプロセスを使うか。
・イシューマネジメントをどのように行うのか。
・問題のエスカレーションにどんな基準を使うのか。
・コンフリクト解消のマネジメントをどのような方法で行うのか

◆標準とインフラストラクチャー

この例をみて、お気づきの方もいらっしゃると思うが、この中でいくつかの決定は、組織のプロジェクトマネジメント標準として行うようになっていると思うが、すべてをカバーしている組織はまず、ないと思う。というよりも、そもそも、プロジェクトインフラストラクチャーは、標準にすべきものではない。

たとえば、立ち上げの例でいれば、チーム編成や意思決定プロセス、コミュニケーションの計画、統合変更管理の方法、イシューマネジメントなどは、プロジェクトの事情を鑑みて決定して初めて意味があるもので、標準で決定すると足かせになることが多い。

少し脱線するが、標準化で過剰管理になっているケースはこのパターンが実に多い。マネジメントドキュメントを片っ端から、標準にしようとする。

たとえば、初期のスコープ定義に対して、ＳＯＷのフレームワークを標準化している組織が多い。ＳＯＷはプロジェクトの見方であるので、ステレオタイプのプロジェクトについては項目を決めておいて問題ないが、変種のプロジェクトになると対応できなくなる。この種の問題は、プロジェクト憲章など、上流側のツールにはよく見られる現象である。

もう少し、制度的なものを上げると、プロジェクトスポンサーの選定基準を標準化することがある。たいていは、組織上の職位が基準になる。プロジェクトスポンサーはプロジェクトのビジネスの責任者であるので、最終責任者は職位で決められて然るべきだが、プロジェクトスポンサーは市場の特性、顧客の特性、チャネルの特性などを十分に踏まえてスポンサーシップを発揮できる人を選ぶ方が現実的である（ただし、そのようにするとガバナンスが難しくなる）。

◆インフラストラクチャーの過度の標準化は思考停止をもたらす

意図はよく分かるが、このやり方は現場を見ないで、ルールを決める典型である。もちろん、プロジェクトガバナンスの観点から現場の事情に関係なく従わせるべき要素があるのは確かだが、境界になるのがインフラくストラクチャーだと考えた方がよい。その上で、標準化するのはよいが、一方でインフラストラクチャーとして、どのような標準を使うのかを決めれるようにしておくべきである。

そうしないと、プロジェクトにおける意思決定が形骸化し、プロジェクトマネジャーをはじめとするマネジメント担当者の「当事者意識」が薄くなり、プロジェクトの成果が形骸化することになる。現にそうなっている組織は珍しくなく、形骸化という悩みを持つ組織は、

標準による過剰管理→インフラストラクチャーの軽視→形骸化（思考停止）

というコースを辿っていることが多い。

立ち上げを中心に議論してきたが、計画やコントロールでもまったく同質の問題がある。具体的なインフラストラクチャーについては触れないが、たとえば、計画の中における重要な意思決定の一つは

・どの標準を使うのか、あるいは、どの方法論を使うのか

である。マネジメントと管理の区別のついていない組織では、このインフラストラクチャーが抜けていることが多い。