リスク: 2007年9月アーカイブ

プロジェクト途中の管理者の仕事の多くは、不測の事態に対処するために一種類のスラック（余裕）を他の種類のスラックと交換することなのだ。

「ワインバーグのシステム変革法」

リスクアセスメントはリスク管理ではなく、リスク管理の第一ステップにすぎない。第二ステップはリスク低減計画作業、すなわち予測不可能な環境下で予測可能な結果を得るための計画作業である。

「ワインバーグのシステム変革法」

ある程度、リスク管理担当者は「誠実な野党」である。つまり、その人物とは、（プロジェクト管理者を含む）プロジェクト・チームの全員が、物事がうまくいくと必死に信じようとしているのに、なぜ物事がうまくいかないのかの理由を冷静に識別し、評価し、追跡し、そして体系づける人だからである。

「プログラマーの復権」

予測できたはずの問題で驚くようなはめに陥ってはならない。

「デバッギング ザ デベロップメント プロセス」

惨事はありえないと言う考えは、しばしば考えられない惨事を引き起こす。

「コンサルタントの秘密」

問題解決にはどれくらいのコストがかかるかを考える時には、別の問題も考えたほうがいい。道路を直すには、たしかに大変なコストがかかる。しかし、道路を直さなかった場合のコストはどう考えるのか。

「大逆転」

リスクが現実になる前の初期の兆候を予測せよ。

「デッドライン」

それぞれのリスクの実現する確率と予想コストを評価せよ。

「デッドライン」

リスクを除こうとすることが無駄な努力であり、リスクを最小化できるかどうかも不確かなら、そのリスクこそは真のリスクである。

「ラピッド デベロップメント」

積極的にリスクを攻撃しなければ、リスクのほうが積極的に攻撃してくる。

「ラピッド デベロップメント」

スケジュールの遅れというリスクを最小限に抑えるには、計画に残業時間を組み込まず、プロジェクトの開始時に人的、物的資源を確保しておくべきである。

「ソフトウェア　プロジェクト　サバイバル　ガイド」

プロジェクトのコストに対する影響が、上流と下流でかなり違うことを考慮すると、ソフトウエアプロジェクトに関する悪い知らせは、早い時期に受け取るに越したことはない。

「ソフトウェア　プロジェクト　サバイバル　ガイド」 

成功する組織は、わずかな負担で大幅なリスク回避ができる方法を積極的に捜し求めている。

「ソフトウェア　プロジェクト　サバイバル　ガイド」