システム開発においてさまざまな成果物を作成しますが、きちんと評価しているでしょうか？
もしも、きちんと評価していなければ、その成果物は子供が書いた落書きと何が違うというのでしょうか？
現実に、いろんなプロジェクトでドキュメントを作りっぱなしにしているケースをよく見かけます。
その理由は様々だと思いますが、これまでのケースを以下に整理してみます。
【ドキュメントの必要性】そもそも作成する必要 . . . 本文を読む
公共事業で無駄使いがよく指摘されます。でも、計画した時には本当に必要な公共事業だったかもしれません。
問題なのは当初計画された公共事業を再評価していないということではないでしょうか？
プロジェクトもよくそんな状況があったりしませんか？
例えば、システム開発のプロジェクトの最初に「システム計画書」を作成しますが、その「システム計画書」の見直しをきちんと必要なタイミングで行っているでしょうか？（ . . . 本文を読む
よく、期待値で比較して大きい方を選択肢として採用するというやり方でどうすべきかを決めることがあります。
システム構築プロジェクトに当てはめて考えていくと、完成した場合の期待値としては、
期待値＝システムが完成する可能性×システムがカットオーバーすることによる顧客のメリット（効用）
というような計算式でしょうか？
一般的に、規模や機能を縮小することによりカットオーバーの可能性を大きくする . . . 本文を読む
病気にかかったかなと思えば、病院にいって医者に診てもらういますよね？
システム開発プロジェクトでも同じではないでしょうか？
「なぜかプロジェクトがうまくいっていない」「本来できるものができなくなってきた」「スケジュールが遅れてきている」等々の問題が発生した場合、どうしますか？
病院に行けば医者がまず病状を診察してくれます。その後、症状に応じて処方箋を書いてくれるわけですが、プロジェクトも同じ . . . 本文を読む
システムが完成する可能性はプロジェクトを開始した時点が最も大きく、納期に近くなれば近くなるほど、小さくなっていきます。
システムの稼動直前になって、問題が発生したらほとんどの場合は対処不可能です。（問題の内容にもよりますが・・・）
目をつぶって先に進むか、プロジェクト自体を断念するかの二者択一ではないでしょうか？
①少しでも可能性があればトライをしてみて、結果カットオーバーできない場合は仕方 . . . 本文を読む
