読者です 読者をやめる 読者になる 読者になる

Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

PMとはカーナビのようなもの

♪去年のブクマ、...しつこいのでやめておきます。

プロジェクトマネジメントとは何をすることなのか。
スケジュール引いて、それを守るようにする、
単にそれくらいの意識でなんとなくやってることもあるのではないか...。
進捗会議(確認)して、対策を考えて、上司/顧客に報告して、やることいっぱいでいつも大変! PM なんてうんざり!
なんてこともあるのでは...。

今日はこちらを読みました。

プロジェクトマネジャーのための「プロセス設計術」:ITpro

やってることが同じようでも、
「何のために」とか「何がゴールか」を意識するだけで、
ずいぶんと「結果」が違ってくるように思います。
対策や報告は、目的でもゴールでもないのだけど、それをすることに追われてしまうと、
そこを小手先でこなしてやり過ごしてしまうようなやり方になってしまうこともあります。

さて。ここにうまい喩え話が出ていたのでご紹介します。

私はプロジェクトマネジメントをよく「カーナビ」に例えて話をします。結果のマネジメントはカーナビでいうなら、交差点を過ぎてから「さっきの交差点、左折でした」と指示されるようなものです。そんなナビなら必要ありませんね。
(...)
プロジェクトをマネジメントするときに必要なことは、出てしまった結果に対して文句を言うことではなく、カーナビと同じように結果が出るまでの「プロセス」に働きかけることなのです。現在地を常に確認し、ここまま進めばどうなるのか、見通しを立てながら「案内」をする。プロジェクトマネジャーにはこうした役割が求められます。

進捗は管理できないより引用)

「前もって案内する」ということが、ちゃんとできているでしょうか。
報告も対策もどちらも後からの手当てでしかありません。
ちゃんとナビができるよう、余裕と冷静さを持ち続けていたいものです。

それから、後半には CCPM のバッファ管理のお話しが。

バッファーマネジメントとモニタリングシート

クリティカルチェーンや優先順位の話は置いといて、なのですが、
プロジェクト管理のやり方のひとつとして、
バッファというものどう捉えてどう扱おうとするのか、という観点では、こういう説明もアリですね。
こういう話、自分の会社でもいっぺんしておきたいなってつねづね思ってます。
(でも優先順位の見極めは TOC/CCPM のキモの部分なので外せません)

それから。

要するに「プロセス」が分からなければ、機能するWBSを書くことはできないということです。(...)
プロジェクトマネジメントが機能するためには「プロセスが設計されていること」が必要だということなのです。

プロジェクトマネジメントの前提より引用)

これは PM の立場としてプロセスを知っておけという話ではあるのですが、
この何気ない一文からいろいろ考えさせられました。

チームのメンバは WBS をイメージできているのか、意識しているのか?ということを。

PM が示す WBS をベースに、チームメンバに対して「詳細スケジュールを自分で組み立てて作業して下さい」と言うだけでは、
期待するスケジュールや作業内容が得られないことがあります。
プロセスとか WBS とか、ソフトウェアエンジニアにとって基本的基本的なことだと思うのですが、
各自が実際にどう理解しているかは、やはり経験に基づくものなのだと思います。

周知のこと・既知のことと思わずに、このあたりから言葉の共有を図りながら、
どこまで自分の担当作業を把握できていて、どこまでブレークダウンできているのか、
そういうことも確認しながら進めていかないといけないな、と思いました。
(合わせて、チームを作る(=ひとを見極める)期間と、プロジェクトの期間と兼ね合いも
よく考えて舵取りしないといけないですね)

私はこれまであまりたくさんの人と仕事をしてなかったのかな、と思いました。
「ひとにまかせる」ということを意識し始めてからの経験が浅いのかな、とも思いました。
いろんな人といっしょにうまく仕事をしていくということは、毎回毎回が勉強だな、と思いました。

広告を非表示にする