プロジェクトマネジメントする際に重要なこと
プロジェクトが大きくなるほど
関わる人の認識が異なることが多いし
異なる利害の衝突が生じる
ISO等の業界標準があるので
そのプロセスについては踏襲するとして
個人的に重要だと思うことを記載する
背景/目的/現狀/現狀課題の明確化
何故それをやるのかというモチベーションに相当する内容を解消しなければ、現場への展開以前に周囲を巻き込むことは難しい。この場合、「周囲を巻き込む」とは「周囲を課題認識させアクションを起こさせる」ことを指している。
課題を第三者に認知し、すべき対応であること、さらには優先度高い事象であることを認識させることが重要なポイントである。
アプローチ方法の仮説検討
マスト要素ではないが、課題解消のため既に対応方針が見えるのであれば記載しておくと具体的なイメージが他者にもわかり、勝手に対応方針をイメージしてくれるトリガーになるかもしれない。
ただし、how(手段)の検討よりも重要なのは、何を何故するのかに対して明確にすることであることはしっかり意識する必要がある。
そうでなければ、手段ばかりの議論になってしまい、例えば既存ツールの流用で事足りたことを0から考えてしまい工数が無駄になることも出てくる。
目的を満たすならば、工数がかからない方法で最短をいったほうが良い。
役割分担の明確化
課題からタスクに落とすためには、誰が何をいつまでにやるかの3点を明確化することが必要になる。
課題を認識した後は、例えば、Aさんが叩き台を作り具体的な方針を○月○日議論するとなるまで落とし込む。
ステークホルダーへの展開前ヒアリング
展開する前に現場(展開する先)のメンバーからフィードバックを取得する。内容次第では、フィードバック内容を踏まえた検討を実施する。
そうならないために理想であれば、議論しながら並行して早めに現場メンバーとタッチポイントを設けてヒアリングしておくと検討し直しにかかる工数を最小限にすることができる。
このステップをスキップすると、展開した後、現場の腹落ち感がないまま実行してもらえずフォローに時間がかかってしまう。
展開後のトラブルシュート
展開して終わりではなく、運用する上で、「予想以上に工数がかかる」「品質が悪い」などQCDに関わる問題が発生する。
その課題を要素分解し、それに対して対応方針を検討する。
検討する際は、これまで述べた順序を繰り返す。