本格的リニューアル構想中のため、一部表示に不具合があります m(_ _)m

プロジェクト憲章の作成意義

プロジェクトマネジメント(基礎編) プロジェクトマネジメント(基礎)
この記事は約8分で読めます。

■ 「プロジェクト憲章」の必要性

プロジェクトマネジメント(基礎編)
今回から、具体的に、プロジェクトマネジメントについて、「プロセス」「行動」「ツール」など、できるだけ重要性の高いもの、そしてプロジェクトの始まりから順に説明を進めていきたいと思います。
まず、プロジェクトを始めるにあたって、

「なぜ」プロジェクト始めなければならないのか、大義名分はどこにあるのか
「なにを」プロジェクトで達成(または解決)したいと考えているのか
「どうやって」プロジェクトを進めていくつもりなのか

の3つを、プロジェクト関係者の間で意識合わせをしておく必要があります。
あくまで相対的なことですが、「ルーチン業務」と比較して、「プロジェクト」は、

  1. 目的が限定的・具体的に定義されている(べき)
  2. 期間(納期)が明確になっていて、しかも、どちらかというと短期間の設定になっている
  3. 忙しいので、意思決定ルールを予め合意しておいたり、使用する管理帳票の定型化を図ったりして、円滑なコミュニケーションの準備をしておいたほうがよい

という特徴があります。
したがって、プロジェクト関係者間で、プロジェクトに関する3つの「なぜ」「なにを」「どうやって」をきちんと文書化して、プロジェクトにかける期待や進め方について、『合意形成』をやっておく、そのための文章を「プロジェクト憲章:Project charter」と一般的に呼んでいます。

 

■ 「プロジェクト憲章」の中身

「プロジェクト憲章」でググれば、いろんな template にお目にかかることができます。プロジェクトでは、「文書体系」といって、プロジェクトで「使う」または「作る」文書を全て、プロジェクト開始前に定義し、複数の文書間の相関関係(どちらが親でどちらが子か、その文書はどういうグループで、何に使うものか)まで定義しておきます。
「プロジェクト憲章」の目次・構成は、論者それぞれ意見があるところなので、ここではその優劣をいちいち評価はしませんが、筆者が考える「プロジェクト憲章」とは、プロジェクトで「使う」か「作る」すべての文書の親分、総元締め、の位置づけであれば、乱暴に言えば、何がどのように記述されていてもよい、というものです。
何か、プロジェクト中に問題が発生して、判断に迷った場合、プロジェクト中にメンバーが作業の方向性を見失った場合、プロジェクト途中で作業に大幅な遅れが発生して、当初の計画を変更しなければならなくなった場合、いずれも「プロジェクト憲章」を読み返して、

「そもそも『なぜ』『なにを』『どうやって』このプロジェクトを始めよう(進めよう)としたのか」

を再確認するときに使用します。
なんども説明文に登場した、「なぜ」「なにを」「どうやって」が書いてあれば、それは「プロジェクト憲章」です。文書名が何であっても。
PM(基礎編)_プロジェクト憲章の内容

 

■ 「Why」 プロジェクトを始める大義名分

このブログ内の別シリーズ「経営戦略(基礎編)」で、「戦略論の古典 クラウゼヴィッツの『戦争論』における「目的」と「目標」」という説明があったのですが、目を通していただいているでしょうか。会社に限らず、組織にとって、組織の存在意義または活動意義から導かれる組織的活動の「目的」が必ずあるでしょう。いえ、あるべきです。管理会計システム構築プロジェクトでいえば、「製品ポートフォリオ管理をするために、グローバル製品別損益が分かるデータを使って、製品ごとの採算を測定する」というのが、プロジェクトの「目的」となるでしょう。
次に、「目的」を達成するために、クリアしておかないといけない当面のプロジェクトワークの「目標」が設定されます。
以下は、「目標」設定の例になります。

  • 20○○年4月に、管理会計システムが本番稼働していること(納期目標)
  • グローバルで統一された製品マスタを使って処理されたデータが全体の85%以上になっていること(データ品質目標)
  • 製品群別の限界利益の向こう3年間のシミュレーション結果を、販売数量、為替変動、販売価格(値引き率)、製造変動費単価、販売変動費単価の5つの変数で予測できること(システム機能目標)
  • 画面に変数変更の入力をして、演算結果が15秒以内にレスポンスされること(システム非機能目標)

あとは、必要に応じて、「海外販社の会計システムがバラバラに動いているので、どうやってスムーズにデータ連携させるか」という、プロジェクト開始前に分かっている解決すべき「課題」や、「第30期 新中期経営計画において、製品ポートフォリオ管理の強化が謳われた」というプロジェクトがそもそも考えつくことになった発端としての「背景」等も記載されていれば、尚良しです。

 

■ 「What」 守備範囲と納期

会社経営をしていて、こういう管理会計(損得や採算など)のデータがあったら、もっと有利な判断ができるのに、と思った経営者が、管理会計システム構築のプロジェクトを始めることを指示することが多いです。しかし、一方で、会社の資源(ヒト、モノ、カネ、時間)は有限です。したがって、「やりたいこと」と「できる(と思える)こと」の間には百万光年の開きがあります。
「やりたいこと」から、あるクライテリア(判断基準)に照らして、本当にプロジェクトで「やらなくてはいけないこと」に優先順位をつけて、重要性の高い(効果の大きい)ものから着手することにします。その時に、今回のプロジェクトでやるものと、やりたいけどあとまわしにするもの、を分類しておく必要があります。それを記載しているのが「スコープ」です。
例えば、管理会計システム構築のプロジェクトで説明すると、

  • 製品別の営業利益の過去実績10年間のトレンドデータを表示する
  • 製品別の営業利益の中計3年間の目標と実績の差異を表示する
  • 製品別の向こう3年間の営業利益のシミュレーション演算結果を表示する

しかし、

  • 製品別の、ライフサイクル採算(研究開発費や、製品販売終了にかかる費用も含めた損得)は対象外とする
  • 組織別の業績評価制度の見直しは対象外とする
  • 制度連結決算との差異分析は対象外とする

という感じになります。
そして、今回のプロジェクトでやるやらないを決める判断基準の中で影響力が最も大きいと筆者が思うものは、「納期」です。プロジェクトは、有期限な活動であり、いつか終わるものです。いつ終わるか(終わらせたいか)、この時間設定で、プロジェクトの「スコープ」は大きく変動することが多いです。活用できる予算や人材リソースも、例えば外部のコンサルタントを使って、プロジェクトを実施することを考えると、「時間」でコンサルタントへの委託料の多寡も、どういうスキルレベルのコンサルタントがアサイン可能かも、左右されます。

 

■ 「How」 アプローチとルール

所期の「目的」を達成するために、最も効果的な「プロジェクト体制」と「コミュニケーション・ルール」を設定するか、はこのパートの大事なもののひとつです。会社内部の人材だけでプロジェクトをやりきるのか、外部のコンサルタントを使うのか、経理部の人員だけでやるのか、情報システム部のメンバーをどう絡めるのか、海外子会社の誰をプロジェクトに絡ませるのか、「体制」― メンバーの選定と意思決定・命令指揮の在り方ひとつで、プロジェクトの成功確率を始める前からある程度決定してしまいます。
例えば、会社グループ全体(連結ベース)で管理会計システム構築のプロジェクトをやる場合、

  • 海外子会社の経営陣には、どういう風に意思決定に参加してもらうか、あくまで承認を得る必要があるのか、参考意見をできるだけ出してもらうだけでいいのか
  • 海外子会社へプロジェクトの趣旨説明や途中経過報告の段取りをどういう風につけるか
  • 全社一斉に新しい管理会計システムの使用を開始するのか、それともパイロットプラン的な試用期間を設けて、一部の会社から使い始めることにするのか

ということが、よく論点になります。
また、体制を考えるときに、便利な言葉として、「ステアリング・コミッティー」「PMO(Project/Program Management Office)」というものがあるのですが、それぞれの権限と職責はプロジェクトごとに様々です。名前だけで判断せず、権限と職責をきちんと「プロジェクト憲章」に記載して、関係者相互の誤解発生を予防しておく必要があります。

■ 「プロジェクト憲章」の絶対性

最後に、「プロジェクト憲章は一度作成したら、変えてはいけないのか?」というよくある質問に対して。会社経営にあたって、絶対不変なものと、環境・時代に合わせて変化させるべきものがあるように、慎重を期した上で、必要とあらば、「プロジェクト憲章」は改訂させるべきという立場を筆者はとっています。この辺は、次回に説明したいと思います。
ここまで、「プロジェクト憲章の作成意義」を説明しました。
PM(基礎編)_プロジェクト憲章の作成意義

コメント