PMIはプロジェクトの方法論の標準化団体であると同時に、プロジェクトの普及団体でもあります。

世界的にプロジェクトが増えれば、PMBOKを参照する人が増え、PMPの需要も高まるというわけです。

という企みを反映してPMBOK®ガイドにはプロジェクトの方法論だけではなく、プロジェクトそのものの効用が説かれています。

その一つが
management by project、プロジェクトによる管理です。

Management By Project

マネジメント・バイ・プロジェクト。

要はプロジェクトマネジメントでしょ？
こう思うかもしれませんが、ちょっと違うんです。

マネジメント・バイ・プロジェクトは、業務をプロジェクトによってマネジメントすることです。

この業務というのは当然ながらプロジェクト以外の業務を指します。
プロジェクト以外というのは、すなわち定常業務。

例えば、IT部門は会社のWEBサイトを定常業務として管理します。
WEBサイトの訪問者を継続して分析しアクセス数を向上させるわけです

これでも悪いことはないんですが、以下のような課題に気がつきます。

・どれくらい上げればいいかわからない
・なので、戦略が立てられない
・仕事の評価もできない

基幹業務をサポートするいわゆるスタッフ部門が抱えがちな共通の課題と言っていいかもしれません。

では課題を解決しようとすれば、どうすればいいのでしょう？

訊くまでもありませんね。
プロジェクトにするわけです。

例えば、
「半年後にアクス数を１０倍にする」

半年という有期性、
アクセス数１０倍という独自性。
つまり、二つの特性をはらんで業務はプロジェクトになりました。

日常の管理業務をこのように再定義すると、先の3つの課題はこう変わります。

・目標の精査が行われる
・計画が必要になる
・結果の評価、教訓が資産となる

会社におけるサイトの位置づけを明確にし、あるべきアクセス数を目標とします。

目標がステークホルダーと合意できれば、次に必要なのが計画。
目標を具体的な作業に変換します。
どういう作業を完了すれば目標が達成できるのか？

それが決まれば、あとは期限から逆算して、３ヶ月後に何が達成していなければいけないのか？
一ヶ月後は？
明日何をすべきか？
どんどんブレイクダウンンしていくわけです。

あとはプロジェクト・マネジメント。
実行結果を計画にフィードバックしつつ目標を達成します。
達成できなくても、反省が次のアクションに繋がります。
何が原因か？
目標にムリがあったのか？
作業の方向性が違ったのか？

こんなイメージです。
定常業務と思われていた業務でも、プロジェクトに再定義することで成果を上げやすくなり、ノウハウも蓄積されていくということです。

「今期の売上目標は前期の20％増！」
こんな号令が掛けられたとき。
単なる叱咤ではなく、本当に目標を達成しなければならないのであれば、それはプロジェクトにすべきかもしれません。

こう言うと、あらゆる定常業務をプロジェクトにした方がいいのかと勘違いする人がいますが、そんなことはPMBOKも言っていません。

プロジェクトにすべき業務がそうなっていない場合があるということです。

また、そこまでの極端な勘違いはなくても、定常業務よりプロジェクトの方が優位性がある。
この勘違いは結構多いようです。

ですが、それも間違い。
両者に優劣なんてありませんし、PMBOKだって一言もそんなことは言っていません。

組織には、定常業務に相応しい業務があり、プロジェクトに相応しい業務もある。
マネジメント・バイ・プロジェクトは、担当部署や慣習で思考停止になっていないか？という問題提起に過ぎません。

その証拠に、PMBOKは、定常業務をプロジェクトにするだけではなく、その逆のアプローチだって推奨しています。
逆。すなわち、プロジェクトを定常業務に近づけることです。

プロジェクトを定常業務に近づけるとは？

定常業務をプロジェクトに仕立てることは出来ても、プロジェクトを定常業務にすることはできません。

だって、有期性と独自性を失くせるなら、それは、はなからプロジェクトじゃありませんし。
これ以上言うと禅問答みたくなってしまいますので止めましょう。
あくまで、近づける。

どうするかと言うと、独自性を減らせとPMBOKは言うわけです。

本当は減らすというのは語弊があります。
正しくは余計な独自性を足さない。

別の記事で、独自性とは画期的な新規性を意味するのではなく、経験の有無に過ぎないと説明しました。
「プロジェクトの独自性。人や組織によって異なるものさし」

さらに、経験の有無はオール・オア・ナッシングではないということです。

例えば、チェーン店が新規出店しようとしてます。
これがプロジェクトであることに異論はないでしょう。
出店場所もステークホルダーも独自のもので、そこには経験したことのない不確実性をはらんでいるからです。

でも考えてみれば、チェーン店ですから、店舗の仕様は同じです。
出店のプロセスだってきっと同じでしょう。

つまり、かなりの部分が反復性を帯びているわけです。
おそらくこうした企業は、出店場所という独自性だけを残し、他の反復的要素は、マニュアル化したりして再利用できるようにしているハズです。

これがプロジェクトの定常業務化です。

ありがちなのが、一旦プロジェクトとして定義されたが最後、そのすべてをゼロベースでやろうとするプロジェクト。

プロジェクトの難しさが独自性にあるとするなら、それを減らすことでプロジェクトが成功する確率は高まります。

PMBOK®ガイドの全編を通じて随所で出てくる組織のプロセス資産は、この考え方に基づくものです。

「組織のプロセス資産。お決まりのインプットだからって環境要因との違いは歴然」

定常業務化を別の言葉で言い換えると？

プロジェクトと定常業務。
プロジェクトマネジメントによって定常業務のレベルアップが図られ、定常業務を取り入れることでプロジェクトは成功しやすくなる。

お互いの問題解決の答えを、相手が持っているということです。
組織がこのことに気づけは、プロジェクトと定常業務は近づいていきます。

エンジニアリング会社やITベンダー、コンサルティング会社など、プロジェクトが商品となっている企業が普通に取り組んでいることです。

この取組みのこと、何と言うでしょう？
プロジェクトを定常業務に近づけることの言い替えです。
すごく定着している言葉です。

そう。
標準化。

プロジェクトは独自性の産物である一方、プロジェクト間で共通化できるものが多々あるということです。
それが同一の企業内であればなおさら。

標準化はプロジェクトの定常業務化の別称として押さえておいてください。

もっとも、一プロジェクトで出来ることでもありません。
プロジェクト化はともかく、プロジェクトの定常業務化は、PMOを始めとする母体組織の取り組みが必要です。

「PMO。プロジェクトを属人化させないプロジェクトマネジメント・オフィス」