実体験としての失敗で、マネジメントを人に任せてしまったと言うのを
前回のブログで書きましたが、他にも色んな失敗を繰り返していました。
例えば、
・PJオーナーの本当のニーズ誤認
・納品物を事前に取り決めせずに契約
・曖昧な要件は設計しながら、、、と開始
・見積もりを誤る
・大雑把なWBSで作業管理
・品質計画を立てずメンバーに依存
・リスクを識別せずに問題発生時に初めて対処
・・・
挙げれば切りが無い程です。
会社の仕事で、庶務、経理、営業、・・・仕事の内容については
大体どこの会社においても同じであることが多く、
その職務の経験において転職しても活用する事は簡易です。
しかしながら、プロジェクトマネジメントに至っては、その業務を
定義した（整理された）ものは、長い間存在していませんでした。
業務が定義されていないと言うことは、企業によってその考え方が
まちまちで、プロジェクトマネージャはその知見・経験が豊富で
あっても、他社で担当した場合も同じように能力を発揮する事は困難です。
しかし、全ての会社のプロジェクトマネジメントの定義が同じで
あった場合はどうでしょうか。
マネージャはどのプロジェクトにおいても成功体験・失敗体験を
活用でき、経験を積む毎にその精度が増していくのではないで
しょうか。
プロジェクトマネジメント業務に新しい考え方が入ってきたとしても
それをPDCAで実行し、良い結果も悪い結果も知の共有にて新しい
マネジメント業務として取り込んで行けば、より高品質のマネジメントが
可能となって来るはずです。
ソフトウェアの開発においては、私がこの業界に入る前から、
テンプレートによる開発、フレームワークを活用した開発、
開発ツールを用いた開発などが盛んに行われて来ています。
設計書もテンプレート化されているのは普通でした。
これらは、開発の難易度を下げ、開発効率を上げ、成果物の
品質を高くするのにとても貢献しています。
プロジェクトマネジメントにおいても同様の事が言えるのでは
無いかと私は思うのです。
つまり、マネジメント業務の目的・目標・責務・権限の明確化、そして
マネジメント業務のフレームワークによる定型化です。
決して独自方式を定型化するのではなくです。
そうすることで、Jr.クラスのマネージャでもSr.クラスのマネジメントに
近い成果を出すことが出来るようになりますし、教育・訓練、指導に
要するコスト、品質、が向上し、期間の短縮も図れます。
つまり、利益が出安くなる、伝家の宝刀となりうると私は思うのです。
管理する側がフレームワークによって定型化されたマネジメントを
一生懸命やっても、管理される側がいい加減だと期待する結果とは
なりません。私がマネジメントしている際も、
・協力的なメンバー <-> 非協力的なメンバー
・自己管理できるメンバー <-> できないメンバー
・マネージメント業務を知っているメンバー <-> 知らないメンバー
など、メンバーにもプロジェクトマネジメントを教育・訓練し、
マネージャの指示が理解でき、マネージャが欲する情報を適時提供
できれば、プロジェクトの一体化が図れる様になります。
マネージャだけが空回りしても良い結果は得られにくいと感じたのです。
つまり、プロジェクトマネジメントとは、ステークホルダー全員が
マネジメント業務を理解し協力して行くことがとても重要です。
お客様しかりです。
つづく