コンセプチュアル・マネジメント

◆プロジェクトマネジメントプロセス

さて、この中で、いわゆるプロジェクトマネジメントプロセス

立ち上げ　→　計画　→　｛監視・統制　←→実行｝　→　終結

はどのように位置づけられるのだろうか。

話がややこしくなるのだが、まず、このプロセスは一つのフェーズの中のマネジメントプロセスについて言及するものであることを理解しておく必要がある。

フェーズの中で、もっともプロジェクトマネジメントが重視されるのは、実行のフェーズである。つまり、構想し、賛同者が出てきて、組織も承認した後のフェーズである。もっとも、厳密に実行フェーズを分けることは難しい。おそらく、プロジェクトのデザインを構想の中で行う。売り込みの際に紆余曲折があり、プロジェクトデザインに対して、組織の承認が下りたところが実行フェーズの始まりとなるケースが最も多い。つまり、そのプロジェクト活動に対する投資対効果に対して承認をしていることになる。

プロジェクトマネジメントの適用は、組織としてのプロジェクト実行の管理を目的に、実行段階を対象に行われることが多い。

◆実行以外へのプロジェクトマネジメントの適用

ただ、構想や売り込みを対象にして悪いわけではない。ここでは、どのようなことが行われるのだろうか？商品開発のプロジェクトを考えてみよう。

商品開発のプロジェクトでは、年度ごとに事業計画の中で、プロジェクトの実施が予め承認されていることが多い。事業計画の中でどの程度までプロジェクトデザインが進んでいるかは組織によって異なる。テーマと予算くらいしか決めていない組織もあれば、プロジェクトデザインが終わっているような組織もある。事業計画の位置づけが違うからだ。

構想のフェーズは一般的にはこの前の段階から始まる。終わりは、事業計画として承認された段階だと捉えることもできるし、事業計画が枠取りだけのような場合には、事業計画の後まで続き、売り込みを始めるまでだと考えることもできる。

ここでしばしば問題になるのはコンセプトデザイン作業の取り扱いである。コンセプトデザインは本来は実行である。コストが発生するためだ。しかし、実際には機能組織が費用を負担し、構想の一環としてやっているケースもある。また、古くは３Ｍ、最近ではグーグルのように、いわゆる「スカンクワーク」を公式に認めている組織もある。この場合には、コンセプトデザインは構想として行うことが認められていることになる。

ＩＴでいえば、構想は営業のフェーズになる。入札がある場合には、入札以前の活動である。営業や在場のリーダーが顧客の動きを掴んで、ソリューションを考案するフェーズである。

このような構想にプロジェクトマネジメントを適用して管理していくことは決して不可能ではない。実際に行っているところもある。やり方として、コストそのものを管理することは得策とはいえないようだ。組織としてのメリットは、スケジュールを見える化することであり、担当者に良い意味でのプレッシャーを与えることである。

また、もう一つ、構想にプロジェクトマネジメントの手法を適用する意味としては、ガバナンスの強化を上げることができる。特に、プロジェクトデザインの手法の中に、ガバナンスの強化のための施策を取り込むことは有効である。

◆売り込みへの適用

次に「売り込み」の段階であるが、これは構想書や企画案を持って、なんとかプロジェクトを実現するために、協力者を集める段階だ。ゴールは組織がプロジェクトを承認することだ。社内の話だけではなく、顧客プロジェクトの場合でも、顧客に入り込み、顧客の中に協力者を作り、ＲＦＰ（提案要求）を作ってもらうところまでこぎ着ける段階というのがある。

ここがおそらく最もプロジェクトにしにくい。ここをプロジェクトにしようとすれば、その前段である構想からプロジェクト化をし、売り込みのゴールをプロジェクトのゴールにするような形が適している。

最近、この段階に「プロデュース」という提案型のプロジェクトマネジメント手法を適用する方法が注目されるようになってきた。プロデュースは、構想や売り込みだけではなく、実行のマネジメント、さらには終結のマネジメントも行うものだ。現在のところ、あまり実践的なレベルではないが、今後が期待される。

◆終結への適用
終結への適用も重要である。別の記事で書きたいと思うが、プロジェクトを創り出す始まりは、終結であることが多いからだ。

本来、プロジェクトライフサイクルは以上のようなものである。プロジェクトの中で起こる問題を「他責」にしないためには、ＰＭＢＯＫプロジェクトマネジメントやプログラムマネジメントのような範囲だけのものではないことを、管理者もプロジェクトマネジャーも認識しておく必要がある。