アンチパターンについて おことわり
以下は私が参加した幾つかの失敗プロジェクトに基づいたアンチパターンの覚書です。
実際には同様のケースでも成功する場合もあるかもしれません。１エンジニアの単なる経験則なのでご了承ください。
なお、増える場合があります。
パターン１：上司がマネジメントを行っている
通常業務時の直属の上司がマネージャとしてプロジェクトマネジメントを実施している場合、通常業務のマネジメントとPJのマネジメントを混同します。
PJ実施中にもかかわらず、上司は通常業務の割り込み案件を差し込む余地があることを自ずとわかってしまうため、担当者の状況によらず作業の割り振りを行ってしまいます。
またPJメンバとの力量関係も自ずと生じますので、重大事項が報告されなかったり、隠されたります。
パターン２：PJ開始前に水面下での決定事項がある
PJメンバー以外のステークホルダー間のみでPJ開始前に物事が決定していると、大抵の場合PJメンバーに共有されず、忘れ去られた頃にひょっこりと顔を出して遅延の原因となります。そして往々にして重要な決定事項であったりするのでプロジェクトは破綻します。
パターン３：WF開発プロセスで開始時に非決定な案件がある
非決定な事項は大抵の場合重大事項で、決定するのはテスト時です。
パターン４：見積もり工数に＋αのバッファを取った
バッファは使い切られ、見積もりエラーが発生します。
パターン５：リスク管理表に「納期遅延の場合」
リスクマネジメントできていません。納期遅延の原因となる事項の洗い出しが必要です。
パターン６：PJメンバーが３名のみ
すなわち、課長、主任、担当。パターン１と同様ですが、ステークホルダーの洗い出しもできていませんし、この場合すべての作業が担当者１人にのしかかる事になります。
悪い例えですが、担当が事故にあった時点でこのプロジェクトは失敗します。
パターン７：PJメンバーが他PJにも参加している
マネージャ間の連携が必要となる場面ですが、大抵の場合連携できず、担当者のキャパシティ以上の作業を任せてしまい、結果見積もりエラーとなります。他部署との連合PJをしている場合によく発生します。
パターン８：手の空いている担当をPJメンバーにした
マネージャが上司の場合よく発生します。納期、品質を考慮 対 個人の力量を考慮せずアサインすると見積もりエラー発生の原因となります。
パターン9：PJの振り返りが行われない
プロジェクト開始後の振り返りが行われないと、各事案に対してなぜ成功した・失敗したかに関するノウハウは次回プロジェクト発起時には忘れ去られています。
しかし、ノウハウはあると思い込んだまま、前回プロジェクトよりも低い工数で見積もった次回プロジェクトを開始してしまうため、予想よりも多くの工数を同一問題で消費してしまい、結果見積もりエラーが発生します。
プロジェクトの成果物は、ソフトウェアだけではないのです。
パターン１０：パターン１０は欠番である
終わりに
失敗するプロジェクトは開始前から独特の『ニオイ』がします。
『ニオイ』のもとを指摘できるかどうかでアサインされたメンバーの生死が決定します。