今朝は穏やかに晴れた北摂地方です。
日経コンピュータ調べで、IT開発プロジェクトの成功率が2008年の31.1%から、2014年までのたった6年で、75%まで上昇したのはなぜかについて考えています。
前回はポジティブな視点でその原因を探っていきました。第一に考えられるのは、PMIの活動やPIMBOK、P2Mのマネジメント標準の普及により、マネジメント技術の向上が寄与したということです。恐らくこれが最大の理由だと推測しています。
ただ、PMBOKが日本でも広く認知され始めたのは2000年頃からですので、2008年からの急激な成功率の改善に対する影響があったとするには腑に落ちません。経営層の意識の変革にそれだけ時間が必要だったということでしょうか。
もう一つは、経営的な観点からの考えです。
この時期に起きた経済的なトピックは、もちろんアメリカのサブプライムローンバブルの崩壊とリーマンショックです。これによる景気の落ち込みから投資に慎重になった経営者が、どうしてもプロジェクトを成功させる必要性から、プロジェクトにある程度の余裕を与え、資源を集中し、その経過に注目しサポートするようになりました。
つまり、これまで現場レベルの意思で責任を持っていたプロジェクトではなく、経営レベルがコミットするようになったということです。そのため、プロジェクトマネジメントの品質は向上し、成功に導くことが可能になったのではないでしょうか。
では次に、ネガティブな視点からこの現象を検討してみましょう。成功率向上にネガティブな要素が関係するのか、という疑問があるかとは思いますが、キットPMの経験では”成功”の裏には色々と表に出ない理由も存在するのです。
まず気になるのは、雑誌のアンケート内容が2008年と2014年で同じだったかということです。ネット上で調べてみましたがわかる範囲ではどうも一緒だったようです。もちろんそうしないと比較の意味はなくなるのですから、当たり前です。
では逆に考えてみましょう。アンケートに応える側に何らかの変化があったのかもしれません。
アンケートではプロジェクトの成功の基準は、”品質””予算””納期”の3つが当初計画通りであったかということです。
なるほどこの3つが予定通り実現できれば、プロジェクトは成功したと言えそうです。ただし、ここで言うプロジェクトがIT開発プロジェクであることを思い出してください。アンケートに答えるのも当然IT部門の人となります。ここにヒントがあるかもしれません。
ここでちょっと初心に戻って、プロジェクトの成功とは何かを考えてみます。一般に企業がITの業務システムを開発する場合のプロジェクトの目的は、システムが業務に役に立って、その結果企業の儲けにつながるということです。
であれば、先に挙げた”品質””予算””納期”が予定をクリアしたとしても、開発したシステムを利用して、企業に儲けをもたらせることができたかという、業務基準の視点からの評価が必要になります。
キットPMがこのブログで再三述べていることですが、プロジェクトの目的の設定は、企業の戦略に沿ったものでなければなりません。ですから、ITの○○システムを開発するということは目的にならず、「新しく開発する○○システムを業務で生かすことによって、これだけの利益を上げる」となる必要があります。
このように考えたとき、この雑誌が上げたプロジェクトの成功の定義が、あくまでもITシステム開発プロジェクトの成功の定義であることに気づきます。つまり、評価基準に”プロジェクトの目的は果たされたか”がないということは、本当のプロジェクト成功の基準にはならないのではないかと思います。
では実際にプロジェクトの現場で何が起こっているのでしょうか。次回はプロジェクト成功率について、さらに考えを進めて行きます。
日経コンピュータ調べで、IT開発プロジェクトの成功率が2008年の31.1%から、2014年までのたった6年で、75%まで上昇したのはなぜかについて考えています。
前回はポジティブな視点でその原因を探っていきました。第一に考えられるのは、PMIの活動やPIMBOK、P2Mのマネジメント標準の普及により、マネジメント技術の向上が寄与したということです。恐らくこれが最大の理由だと推測しています。
ただ、PMBOKが日本でも広く認知され始めたのは2000年頃からですので、2008年からの急激な成功率の改善に対する影響があったとするには腑に落ちません。経営層の意識の変革にそれだけ時間が必要だったということでしょうか。
もう一つは、経営的な観点からの考えです。
この時期に起きた経済的なトピックは、もちろんアメリカのサブプライムローンバブルの崩壊とリーマンショックです。これによる景気の落ち込みから投資に慎重になった経営者が、どうしてもプロジェクトを成功させる必要性から、プロジェクトにある程度の余裕を与え、資源を集中し、その経過に注目しサポートするようになりました。
つまり、これまで現場レベルの意思で責任を持っていたプロジェクトではなく、経営レベルがコミットするようになったということです。そのため、プロジェクトマネジメントの品質は向上し、成功に導くことが可能になったのではないでしょうか。
では次に、ネガティブな視点からこの現象を検討してみましょう。成功率向上にネガティブな要素が関係するのか、という疑問があるかとは思いますが、キットPMの経験では”成功”の裏には色々と表に出ない理由も存在するのです。
まず気になるのは、雑誌のアンケート内容が2008年と2014年で同じだったかということです。ネット上で調べてみましたがわかる範囲ではどうも一緒だったようです。もちろんそうしないと比較の意味はなくなるのですから、当たり前です。
では逆に考えてみましょう。アンケートに応える側に何らかの変化があったのかもしれません。
アンケートではプロジェクトの成功の基準は、”品質””予算””納期”の3つが当初計画通りであったかということです。
なるほどこの3つが予定通り実現できれば、プロジェクトは成功したと言えそうです。ただし、ここで言うプロジェクトがIT開発プロジェクであることを思い出してください。アンケートに答えるのも当然IT部門の人となります。ここにヒントがあるかもしれません。
ここでちょっと初心に戻って、プロジェクトの成功とは何かを考えてみます。一般に企業がITの業務システムを開発する場合のプロジェクトの目的は、システムが業務に役に立って、その結果企業の儲けにつながるということです。
であれば、先に挙げた”品質””予算””納期”が予定をクリアしたとしても、開発したシステムを利用して、企業に儲けをもたらせることができたかという、業務基準の視点からの評価が必要になります。
キットPMがこのブログで再三述べていることですが、プロジェクトの目的の設定は、企業の戦略に沿ったものでなければなりません。ですから、ITの○○システムを開発するということは目的にならず、「新しく開発する○○システムを業務で生かすことによって、これだけの利益を上げる」となる必要があります。
このように考えたとき、この雑誌が上げたプロジェクトの成功の定義が、あくまでもITシステム開発プロジェクトの成功の定義であることに気づきます。つまり、評価基準に”プロジェクトの目的は果たされたか”がないということは、本当のプロジェクト成功の基準にはならないのではないかと思います。
では実際にプロジェクトの現場で何が起こっているのでしょうか。次回はプロジェクト成功率について、さらに考えを進めて行きます。
