こっそりスタートさせたプロジェクトですが、多くの部門を巻き込んでの全社プロジェクトの様相を呈してきました。プレイヤーが多数存在するプロジェクトマネジメントほど厄介な仕事はありません。今日はプロジェクトマネジメントの進め方について考えてみたいと思います。
プロジェクトマネジメントが何故難しいのか
通常のマネジメントに比べてプロジェクトマネジメントは格段に難易度が上がります。その理由は、多くのプロジェクトは前例がないからです。ラインマネジメントは、経験則からAを投入したらＢになるという関係が明らかな場合が多いです。このマーケットに何人営業を投入すれば売上がいくらになるとかのように。もっとも、コロナでその前提自体が崩れているのでラインマネジメントも苦労すりわけですが。。。一方、プロジェクトはやってみないと分かりません💦 特に人数が増えたり、部門をまたいだりするとさらに複雑性が増します。
みんな良かれと思って頑張るが
プロジェクトがスタートしたら、誰が何をいつまでにするかを、WBSに書き起こします。WBSはWork Breakdown Structure の略です。ただ私は書き起こしはするのですが、これを運用しよとはしません。理由は私の大雑把な性格💦ですが、もう一つ理由があります。それは、現場の状況は刻々と変化するので、WBSが現場に即さないことが多々あるからです。この業務を任せようと考えていたメンバーが実はスキルも経験も乏しかったとか。設備や材料の制約条件が実はあったとか。メンバー間の関係性が悪くて作業が進まないとか、メンバーの1人がギックリ腰をやってしまったとか💦 初めてのプロジェクトですから、想定外のことはつきものです。
そして、プロジェクトを進めるために計画されたWBSはかえってプロジェクトを遅延させるものにもなります。計画通り進まないことでメンバー間、部門間の不信感を醸成する場合もあるからです。みんなそれぞれの持ち場で、良かれと思って進めた仕事がかえってプロジェクト不全を起こす経験を持っていませんか？ だからWBSの計画までは落とし込みますが、計画通り詳細に運用しようとはしません。制御できないものは制御しません。私がWBSと計画を立てる目的はプロジェクトに必要なリソース（特に人）と、全体スケジュールの目算を立てるためだけです。扱っているものが、Human Resource Management やHuman Resource Development のような無形だから、こんな進め方でも成り立つと理解しています。自動車やロケットなどメーカーではあり得ない仕事の進め方ですよね。
全体像を共有する
ではどうやってプロジェクトを進めるんだ？って話ですよね。必ず実施している事は、最初にプロジェクトの全体像に関して、各担当部門毎の少人数のグループと対話をします。ポイントは対話と少人数です。プロジェクトに関わるメンバー全員を集めて一回で説明した方が効率良さそうですが、だいたい聞いていない。それより少人数で企画書見せながら、企画のゴールや内容について対話するほうがよっぽど共有できる。相手の頭の中に全体像がインプットされるのは大事。全体像が理解できていれば、プラスアルファの創意工夫が出てきます。そうすると、企画は私が考えていたものより数段よくなります。スタート時から対話することで、参画意識も高まりますしね。
「言われた通り仕事しましたけど何か？」とプロジェクトメンバーから言われたたら、そのプロジェクトは失敗だと思います。仕事だけどワクワク感を感じてもらって、自ら主体的に関わってもらうことがプロジェクトを成功させるコツだと思います。
