ご注文はプロジェクトマネージャですか？

いや、違うんだ。プロジェクトマネージャは「誰」ですか、なんだ。そんなプロジェクトにしないための話。

そのプロジェクトは結果的に次のことをプロジェクトマネージャに据えたかったシステムエンジニアにすることがなかった。だから、誰ひとりプロジェクトマネージャとして振る舞うことがなかったのです。

・役割の意義づけ
・予想される困難の説明
・再度の役割の確認
・システムエンジニアの決意を引き出す

それではプロジェクトマネージャをアサインするマネージャはどのように振る舞えばよいのでしょうか。

役割の意義づけ
プロジェクトは成果物を有期限の時間軸の上で必要なリソースを手当てして完了させる業務活動だから、プロジェクトにアサインされたシステムエンジニアは、何かしら役割を割り当てられ、そしてその役割を果たすことをアサインした側のマネージャは期待するのです。

では、その期待をアサインしたシステムエンジニアに伝えていなかったら、マネージャが期待する役割をしてくれるのでしょうか。

マネージャがどのような期待をしているか頭の中から出して言語化し伝えることがなければ伝わることはありませんよね。だって、表現していないのですから。

例えばプロジェクトはコストを最重視して、スコープを削ってでも黒字を確保して欲しいのであれば、そう伝えなければプロジェクトマネージャになるシステムエンジニアはそれに沿うように行動することはありません。プロジェクトマネージャとしてQCDのQである品質＝スコープを最優先するかもしれません。もしかしたら、D＝納期を最優先することもあるでしょう。どちらにしてもマネージャの期待は実現されません。

それが嫌ならマネージャはプロジェクトマネージャをになって欲しいシステムエンジニアに

・プロジェクトでプロジェクトマネージャを担って欲しいこと
・期待していること

を伝えなければなりません。一見、当たり前そうなことを当たり前にしているマネージャはどれだけいるのでしょうか。

予想される困難の説明
そのプロジェクトの見積もりや事業計画をプロジェクトマネージャにアサインするシステムエンジニアが携わっていないとしたら、それを知っているマネージャが説明しなければなりません。

この説明で重要なことは、このプロジェクトで予想される困難なことを説明することです。

今、プロジェクトマネージャにアサインする腹積もりのシステムエンジニアはプロジェクトに関する情報が圧倒的に不足している状態です。マネージャ＞システムエンジニアと情報の不均衡が成り立っているのです。

やることは提案書や企画書に書いてありますが、それに至る経緯の中で揉まれていたことについては記載されていないものです。それを知っているマネージャは自分の観点で予想される困難なことを伝える必要があります。

再度の役割の確認
マネージャの期待が１回きりの説明で表現した言葉のとおりに伝わっていると考えるのは思い込みにすぎず、独りよがりすぎます。このプロジェクトをプロジェクトマネージャとしての役割を果たすには幾つかの困難なことがあるけれど、それでもプロジェクトマネージャとしてプロジェクトをキャリーして欲しい、と期待している役割を再度説明する必要があるのです。

これは相手が伝えたいように表現した言葉を同じ意味合いで理解しているかを確認しているのです。決して、言いっ放しにならないようにしましょう。

システムエンジニアの決意を引き出す
マネージャの期待は説明を一方的にするだけではこれからプロジェクトマネージャになってもらうシステムエンジニアの能力を最大限にパフォーマンスを発揮してもらうことは難しくなります。それは単なる押し付けでしかないからです。

プロジェクトでプロジェクトをリードするプロジェクトマネージャが最高のパフォーマンスを発揮してもらうためにもシステムエンジニアの決意を引き出します。

期待する役割を全うするには幾つかの困難があるけれど、それを乗り越えるためにはチームのパフォーマンスを最大限に引き出すために、まずプロジェクトマネージャ自身が最高のパフォーマンスを発揮することの決意を引き出せるようなプロジェクトが終わったときのゴールのイメージを伝えましょう。

そして決意を引き出すことでプロジェクトのリーダが誰であるかを意識付けするのです。