▼今朝は雨模様です。
師走です。やはり慌ただしく日々が過ぎていくようです。なんとなく落ち着きません。
さて、前回はプロジェクトの目的と経営戦略の関係について考えました。すべてのプロジェクトは何らかの経営戦略に紐付くはずだというのが、キットＰＭの考えでした。
また、それを明らかにするためにプロジェクト体制の頂点にはプロジェクトオーナー（ＰＯ）という位置づけがあり、ＰＭとオーナーとのコミュニケーションが重要になるということを明らかにしました。
でも、現実にはそう簡単にいかないことも多いわけです。そこがＰＭの悩みでしたね。
▼もちろん
日頃から戦略経営を実践している会社であれば、その戦略が企業のトップから末端まで浸透し、理解を得られているはずです。
であれば、プロジェクト憲章で示すプロジェクトの目的について明確にすることは、それほど難しくはありません。（のはずです）
ただし時として、経営陣の中でも戦略のとらえ方に差がある場合もあります。その場合、ＰＯや場合によっては社長がＯＫしたプロジェクト目的について、否定する役員や管理職が存在することもあるのです。
そのためにも、プロジェクト憲章に目的や目標を明記し、全社的な合意形成をプロジェクトとして行うことは重要になります。
▼もう少し具体的に
考えてみたいと思います。
本当に全てのプロジェクトの目的は、経営戦略と関係しているのでしょうか？
例えば、「人事評価の手法を見なおす」という目的を持ったプロジェクトがあります。
なぜこのような要求が出てきたかを想像するとき、当然そうせざるを得ない何らかの状況が発生しているわけです。
しかもそれは人事評価という、言わば会社経営の根幹に関わることであることから、大きな変革に基づいた判断であることが解ります。
ここまでは、なんの説明を受けなくてもＰＭなら理解できるはずです。理解しなくてはいけません。
次の行動として、ＰＭはその変革が何であるかを紐解き理解するように努力することになります。
▼ところがこの例の場合
上層部からの要求が「人事評価に新しいＩＴシステムを導入する」となることがあるのです。しかも利用するアプリケーションまで指定されていたりします。
まじめな（未熟な）ＰＭは、このアプリケーションをどうやって効率よく導入するかが自分に与えられた使命だと、捉えてしまいます。しかも与えられるプロジェクト期間は短いわけです。
こうなると、なぜ人事評価を変える必要があるのか。どう変えるべきなのかなど考える余裕がなくなり、ひたすらアプリケーションの導入を進めようとすることになります。
でも、ＰＭは少なくともそのアプリケーションを選択した理由を明らかにした上で、作業を進めるのは大切なことになります。
なぜだか解りますよね。
▼もし、アプリケーションの
選択権限がプロジェクトにないのであれば、その選択責任を明確にすることはプロジェクトとして必要です。プロジェクトの制約事項として認識するわけです。
プロジェクトの途中で、選択したアプリケーションに問題が起きた時、ＰＭの判断基準に大きな影響を与えます。
制約事項を事前に明確にすることで、プロジェクトの選択肢を確保することに繋がるのです。
話が逸れてしまいました。
要は、ＰＭはプロジェクトの開始時点で明らかになっている情報とそうでないものを明確に判別しなければならないわけです。
そのとき、プロジェクトを開始するために必要な情報が欠落していればそれを補うのもまたＰＭの責任となるわけです。
▼次回はもう少し
この掘り下げていきます。その上で、ＰＭは具体的にどのように考えるべきか解決の手法について考えて行くことにします。