2008_05_21－進捗遅れの予測。

２００８年５月２１日発行

分割ラインです

　★　進捗報告編　★

　　
　　進捗遅れの予測
　　
　　
　　ユーザー側からみても、今後進捗が遅れると予測できることがあります。
　　
　　
　　それは、以下のような状況を目の当たりにした場合です。
　　　・中核メンバーが突然抜ける
　　　・開発要員が揃っていない。
　　　・各工程の開始に当たって準備資料が整っていない。
　　　・製造・試験などの統一規約がない
　　　・品質や生産性の目標値未決定
　　　・スケジュール未作成
　　　・連絡の周知不徹底がつづくとき
　　　・開発時点になって、Ｑ＆Ａが多い
　　　・開発時点になって、大きな仕様変更があった
　　
　　
　　
　　
　　私もお客様に合うなり、「遅れているんやろ」って言われたことがあります。
　　なぜわかったのですか？と聞くと
　　　　顔色と頭を見ればわかると言われました。
　　　　
　　　　そのときは仮睡眠時間が３時間程度で
　　　　　　目に覇気が無く、目やにいっぱい、頭ぼさぼさでは、
　　　　　　　　誰もが気づきます。
　　
　　
　　
　　しかし、プロジェクトリーダーにとっては、遅れが取り戻せるうちは、
　　なかなか公表しないリーダーも多いのです。
　　
　　そんなときに、ユーザーに向かって遅れていますを
　　　　　　　　　　　　　　　　言わせる方法は無いものでしょうか？
　　
　　　１．進捗報告内容の中で完了分について抜き打ちチェックを行う。
　　　２．故障の発生件数や対応件数が、目標値と大きくずれている理由を
　　　　　確認する。
　　　３．Ｑ＆Ａ件数が多い場合は、理由を尋ねる。
　　　４．Ｑ＆Ａ内容について吟味を行い経緯を聞く。
　　　５．大きい仕様変更の場合は、対応スケジュールと状況確認をする。
　　
　　早く公表することで、ユーザー・開発側の責任者を含めた
　　　　　　　　　　　　　　全員の意識を変えなくてはならないのです。
　　
　　
　　
　　
　　被害を想定してユーザー側にとっても
　　　　　　　　　可能な対応を早く打っておきたいものです。
　　非常事態の時ほど、状況の見える化は非常に大事になってきます。
　　
　　　・スケジュール遅れの対応内容と取り戻しスケジュールを確認する。
　　　・不可能な場合における追加要員対応など案も提出してもらう。
　　　・要員計画と対応スケジュールを提出してもらう。
　　
　　
　　
　　
　　
　　ユーザー側がとれる対策は？
　　
　　　今現在について
　　
　　　　・残課題のできるだけ早く無くす。
　　　　・未解決項目も早急な解消に努める。
　　　　・懸案事項の中で、現実化しそうなものは、早急に対策を講じる。
　　　　・故障内容と件数を確認する。
　　
　　
　　　後工程に向けて
　　
　　　　・仕様変更に伴う試験工程のガイドライン設定に変更がないか
　　　　　確認しておく。（試験の確認範囲なども）
　　　　・故障内容から強化試験に追加する項目を洗い出しておく
　　
　　
　　
　　
　　ユーザー側から見ても、
　　　　お任せではなく、積極的に介入して支援可能なところは
　　　　　　態度で応援してほしいものです。
　　
　　当然、クレームも言って構わないのですが、
　　　　　行動もお願いしたいのです。
　　
　　そんな行動がプロジェクトを成功させる原動力なのです。
　　　　ユーザーが積極的に行動するプロジェクトほど
　　　　　　いろいろ紆余曲折もありますが、
　　　　　　　　結果は予定通りうまく稼動します。