第12回 パーパスの実現度を振返る
◆VUCA時代のプロジェクトマネジメントの2つのポイント
本連載では、パーパスに焦点を当て、VUCA時代のプロジェクトマネジメントの在り方やパーパスの設定方法について整理し、前々回、前回はVUCA時代のプロジェクトマネジメントの具体的な手法として、アジャイルプロジェクトマネジメント、OODAプロジェクトマネジメントについて概要を解説しました。
この連載もまとめに入りますが、まず最初はプロジェクトの振返りの方法について考えてみたいと思います。プロジェクトの振返りの基本は、計画どおりに実行できなかったところに対して、その理由や次のプロジェクトからの計画の策定、マネジメントの方法などの改善策を考えることです。もちろん、これはこれで必要なのですが、VUCA時代のプロジェクトマネジメントにおいては、以下の2つがポイントになると考えられます。
一つは、計画変更の適切さです。VUCAなプロジェクトにおいては計画変更が起こること自体は問題がありませんし、ある意味で普通のことです。注目すべきはそのタイミングやプロセスの適切さにあります。あるいは、計画自体の適切さにあります。
もう一つは、パーパスや目的の実現度です。パーパス(目的)にはプロジェクト目標になっているものとなっていないものがあります。プロジェクト目標になっているものは、一般的なプロジェクトの振返りでチェックしますが、今のところ、プロジェクトのパーパス(目的)に注目されることは稀です。
◆プロジェクトの成功/失敗の判断
プロジェクトの成功の判断は一般的にはプロジェクトの目標の達成で行われます。目標達成でプロジェクトの成功/失敗の評価をする場合には、達成できれば成功、できなければ失敗という考え方をするのが一般的です。
例えば、多くのプロジェクトで目標にする指標にQCDSがあります。この中で、多くのプロジェクトでは品質については目標達成できなければそのプロジェクトは失敗であるとみなされます。
これに対して、スコープ、スケジュールはプロジェクトによって異なります。例えば商品開発のプロジェクトであれば多少のスケジュール遅延は問題ないとされる場合もある一方で、イベントプロジェクトのように1日でも遅れれば意味がなくなり、失敗だとみなされるプロジェクトもあります。スコープ、予算についても同様な考え方ができます。
厳密にいえば、目標達成しなくても失敗とみなさないものは目標ではありません。そういう意味では、目標は達成できれば成功、できなければ失敗ということになります。逆にいえば、100%達成しなくてはならないもの以外は目標に設定すべきではないといえます。
◆パーパスとプロジェクトの成功/失敗
これに対して、プロジェクトのパーパス(目的)の場合、100%実現できなくても即座に失敗とは考えません。極論すればプロジェクトのパーパスは全く実現できなくても目標を達成できればいいと考えることが多いようです。
例えば、特定の顧客向けの製品開発で、パーパスは顧客を満足させることで、目標をQCDSに設定しプロジェクトを進めて行くとすれば、どのようなQCDSにすればパーパスを実現できるかはあまり考えず、どにかく顧客が了解するような目標にすることはよくあることです。
一方で、VUCA時代のプロジェクトは目標が達成できなければ失敗と言い切れない部分があります。少なくとも初期目標は変わってしまう可能性大ですし、目標を変えなくてはならないという認識でどのような目標にするかを見極めるためにプロジェクトを進めていかなくてはならないこともあります。考えようによっては、プロジェクトの目標は設定できないとも言えます。
例えば、製品開発のプロジェクトで、予定のスケジュールでは顧客ニーズが変わりそうだというときに、
(1)スコープを変える
(2)売上げ目標を変える
(3)スケジュールを変える
といった目標を変更する対応が考えられます。このとき、どの方向に変化させるか、そして、新しい目標をどう設定するかは進めていきながら考えたいようなケースです。
◆プロジェクトの評価にパーパスの実現度を用いる
このように目標がプロジェクト評価の指標として使いにくい場合、指標にしたいのがパーパス(目的)の実現度です。ただし、パーパス(目的)は定量的なものとは限りませんので、プロジェクト評価に使うには工夫が必要です。
まず、考えなくてはならないことは、上で述べたようにプロジェクトのパーパス(目的)は100%実現できて初めて成功というものではないことです。
実際にある企業の一つの事業部でプロジェクト目的を評価対象にする仕組みづくりをした経験を紹介します。これにはパーパスという考え方は含まれていませんが、目的をパーパスと読み替えてください。
◆ある企業の取り組み
仕組みを作って、運用初年度は実現度50%を超えるプロジェクトが全プロジェクトの30%強でした。プロジェクトの中には目標を達成できなかったものもありますが、全プロジェクトの80%はすべての目標が達成できた上での目的の実現度でした。
ここから、3年後には同じ指標で目的の70%実現が80%を超えるという目覚ましい改善がされました。ちなみにこの組織(事業部)では5年後の売り上げが130%になっており、その一因にプロジェクト評価の変更によるプロジェクトリーダーやメンバーの意識の変化があったと評価しました。ついでにいえば、目標の達成度は年ごとの変動はありますが、5年後には60%程度に下がっていました。これは興味深い点です。
目的の実現度の評価方法ですが、具体的な方法は書くことができませんが、基本は定性的な評価です。
例えば、プロジェクトの目的が「世の中にないものを作って市場における知名度を高める」であれば、目的を「世の中にないものを作る」、「市場における知名度を高める」の2つに分離し、「できた」、「かなりできた」、「あまりできていない」、「できなかった」の4レベルに分けて、スコアリングしていきます。
パーパスについても目的と同じような形で実現度の評価ができます。
◆ある企業の取り組み(その2)
このように求めたパーパス(目的)の実現度から、プロジェクトの成功か、失敗の判断をするという考え方になります。ただし、目標達成のようにプロジェクトが成功したか、失敗したかのどちらかに分けるというのはあまり現実的ではありません。
上の事例でいえば、当初はプロジェクト目標の達成度によってプロジェクトの成功/失敗判定をしていました。それが機能しなくなったために導入したのが目的の実現度の評価でした。そこで、目的実現率〇%以上を成功判定の指標にしようとしました。
しかし、うまく行きませんでした。理由は2つあり、一つは目的の策定が不慣れで、不適切なものが多かったことです。この企業に限ったことではありませんが、プロジェクトの目標はステークホルダーからの要求で決まることが多いものです。従って、目的の策定はプロジェクトマネジメントのドキュメントを作る際に形式的に決めるというのが実態でした。
このとき、プロジェクトの目標のステークホルダーとの交渉は、現場の事情(例えば、要員とか、スキルなど)に基づいて行われます。これをやっている限り、適切な目的は策定できません。現実には難しいのですが、やはり組織やプロジェクトリーダー、メンバーにとっての存在意義を明確にし、そこをベースにして目標を交渉し、決定していくことが本来の筋です。そこで、そのようにすることにしました。事例の企業の場合、これが売上げ増加の要因になったようです。
もう一つは、そもそも、目的の実現度でプロジェクトが成功したか、失敗したかという評価ができるのかということでした。
そこで、目標で行っていたときのような、プロジェクトの成功/失敗の判断をすること自体をやめました。もともと、成功/失敗の判断というのは、プロジェクトマネジメントのための風土づくりと人事評価のために使っていたもので、少し、判断を止めることに苦労したようです。
◆まとめ
以上のように、VUCA時代のVUCAなプロジェクトに対するプロジェクトマネジメントでは、必ずパーパス(目的)の実現度を評価し、振返りを行い、パーパス(目的)の実現度の向上のためのマネジメントの改善方法を検討する必要があります。
その際に、従来から行われている知識エリアごとのプロジェクトマネジメントの振返りという方法は有効です。これについては例えば、こちらをご覧ください。
PMスタイル考
第92話:振返りの質を高める(2014/10/27)
https://pmstyle.biz/column/pmstyle/pmstyle92.htm
◆関連セミナー
パーパス・ドリブンのコンセプチュアルプロジェクトマネジメントについて学ぶセミナーです。
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆パーパス」でプロジェクトを動かす
コンセプチュアルプロジェクトマネジメント◆
日時:2020年 09月 16日(水) 10:00-18:00(9:40受付開始)
場所:国際ファッションセンター(東京都墨田区)
講師:好川哲人(エム・アンド・ティ コンサルティング代表)
詳細・お申込 https://pmstyle.biz/smn/conceptual_pm.htm
主催 プロジェクトマネジメントオフィス、PMAJ共催
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
1.VUCA時代に求められるプロジェクトマネジメントの特徴
2.成果と成果物を分けて考える
3.プロジェクトのパーパスを決定する
4.プロジェクトへの要求の本質を反映したコンセプトを創る
5.コンセプトを実現する本質目標を決定する
6.本質的な目標を達成する計画を策定し、実行する
7.トラブルの本質を見極め、対応する
8.経験を次のプロジェクトに活かす
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
この記事が気に入ったらサポートをしてみませんか?