Just blogged

元SIerの今はWebビジネス中心なヒトが日々のトピックを綴ります。

プロジェクト管理は固いかっちり型から柔らかいアジャイル進行へ、ガンガン行こう

  • クラウドを使って、プラットフォームを作る。
  • または、そのプラットフォーム(箱)に要素(色)を乗せて行く。

そういった業務が昨今多くなっている事と思う。

こういったプロジェクト立ち上げ時は、以下を出来る限り作る。

  • プロジェクト計画書(チャーター)
  • WBS:後者の場合はひな形
  • 責任分担(RACI)マトリクス
  • プロセスフローダイヤグラムPFD

担当する案件は大概新規領域だったり、課題設定の難易度が高かったりして、 自分の頭をまとめるためにも、むしろそれらをフルコースで作る事が多いかもしれない。 また、最近クライアントの期待値と手段をマッピングさせるチャートである

  • 品質の家

というのを知ったのだが、これも良さそうだ。

ただ、特にWBSは必ず作るものの、常にそれを遵守する、という事は今はしない。 もちろん、自分達の会社マターの作業であれば、遅延するのは御法度だが、 クライアントマターの作業の場合は、のっぴきならない理由で遅延してしまうケースが多い。 それを攻めても何も始まらないし、まぁそれもプロジェクト管理の責任といえばそうだ。

例えば、複数の部署が絡むと複雑な利害関係が出来あがり、 大概セオリー通りには進まない。

と言う事で、WBSがあまりワークしないという結論に至った場合、 そのWBSは単に遅延したときのクリティカルパス上の最終のデッドラインを見たり、 そのデッドラインについてクライアントとコンセンサスを取るためのツール、 になったりする。

この日にこれが間にあわないと、後工程でどう頑張ってもローンチは2日遅延します。

といった具合だ。

アジャイル開発やリーン・スタートアップが持て囃されていたりするが、 プロジェクト管理の現場でも最早そういう状態なのかもしれない。

  • オールドな考え方は捨て、ワークする成果物とプロセスを考える。
  • リソースを固定的ではなく、フレキシブルに動かせるようにしておく。

そういった時代に合わせた柔らかいプロジェクト管理をいかに可能とするか、 プロマネの挑戦は続く。