ただし、これは、すべてのプロジェクトに当てはまるわけではない、とハルバーティ氏は警告している。「例えば、既に何度も扱ったことのある、決まりきった給与支払いシステムを実装するプロジェクトであれば、投資対効果的に非常に高い成功率を期待できるのが当然だ。そうした場合には、失敗は許されない」

　一方、海底掘削プロジェクトを動画で視覚化するシステムを開発し、それをWebで公開して世界各地のユーザーが利用できるようにする、といったプロジェクトであれば、ある程度のリスクを覚悟すべきだ、と同氏は続けている。

　「これまでにまだ誰も成し遂げたことのない取り組みだし、うまくやり遂げられるかどうか、自分でも自信がない状態のはずだ。つまり私が言いたいのは、もし目標としているのが非常に革新的なことであり、大きな差別化をもたらすことであり、これまでに成し遂げられたことのないことであれば、結果については、ある程度の不確実性を覚悟すべきだ、ということだ」とハルバーティ氏。

　コンサルティング企業のMidwest Consulting GroupのCIO、ジョン・F・コール氏も、CIOは時折の失敗は覚悟しておくべきだ、という意見に賛成している。

　「仕事のパートナーにも、あまり期待を抱かせすぎないようにしなければならない」と同氏。「掘ってみたら、空であることが判明した鉱泉」の数と比較するというハルバーティ氏の話をほのめかし、コール氏は次のように語っている。「小売業であれ、銀行業であれ、そうした考え方を採用するといい。そして、より多くのリターンを望むのであれば、より多くのリスクを負わなければならない、という事実を皆に認識させることだ」

　一方、コール氏は、CIOはプロジェクトの成功についてもしっかり伝えるべきだ、とも指摘している。

　この「失敗を恐れない」という原則は、プロジェクト管理のもっと早期の段階にも適用すべきだ。つまり、プロジェクトが失敗へと向かっているのであれば、CIOはためらうことなく早目に手を引き、プロジェクトの損失を最小限に食い止めるようにすべきだ。

　ハルバーティ氏は次のように語っている。「例えば、“初めてのポータルを構築しよう”といったプロジェクトだったとする。そうした場合、まずはプロジェクトを計画し、査定を行い、基盤とする製品を選ぶ。そして、その後、その製品ではうまく目的を果たせないことが分かったとする。それでも、多くの企業はその製品を使い続け、何とかその製品で事態を収拾しようとするだろう」

　ハルバーティ氏自身、プロジェクトをいったん中止し、そのプロジェクトで使っている製品がなぜうまく機能しないのかを明確にした上で、ベンダーに全額払い戻しを求めた経験がこれまで何度もあるという。その後、ときには、プロジェクトを打ち切らずに済む場合もある。別のベンダーを使って、もう一度最初からやり直すことも可能だからだ。ただし、同氏によれば、そのためには誤りを認める勇気と企業内弁護士によるサポートが必要となる。

　企業はハイリターンの可能性を秘めた取り組みについては、進んでリスクを負うべきだ、とハルバーティ氏は指摘している。ただし、CIOはそのための行動を起こす前に、まず自社の状況をよく把握しておく必要がある。特に、その会社に入ってまだ間もないCIOが直ちに革新をリードしたいと意気込んでいるような場合は尚更だという。

　CIOは「CEOやそのほかの経営幹部らが会社に対して何を達成するよう望んでいるか」の把握に時間を費やす必要がある。そして、社内でIT部門が置かれている状況も把握しなければならない。

　「IT部門は信頼されているか、それとも、嫌われているか？　尊敬されているパートナーか、それとも、スケープゴートか？　確かな基盤を備えているか？　強力なインテグレーターか？　原価作用因は明確か？　そういった点を把握しておく必要がある」とハルバーティ氏。

　また、コール氏は次のように語っている。「まずに理解しなければならないのは、会社がIT部門をどのように認識しているか、そしてIT部門が自らをどう認識しているかだ。その点を理解しなければならない。なぜなら、それによって、どのくらい大胆に行動していいかが違ってくるからだ。もし、IT部門がただの御用聞きと思われているのなら、ERPシステムを実装するといった戦略的な取り組みは提案しない方がいい。革新を提案する前にまず、信頼できるビジネスパートナーとしての評判をしっかりと確立する必要があるからだ」

　IT部門が事務管理部門ととらえられているような場合には、リスクの高い革新的なプロジェクトを打ち出すのは難しいだろう、とコール氏は指摘している。そのような場合には、IT部門はあまり積極果敢な目標は掲げず、一部のCIOが自らの責務と感じているように、「100％の成功率」を達成する必要があるだろう。

　ただし、CIOは社内でハイリスクなアイデアのアピールも続けていくべきだ、とコール氏は指摘している。またCIOは、いざハイリスクなプロジェクトへ移行する機が熟したときに、そのためのチーム体制が整っているよう、日ごろから、危険を冒せるタイプのスタッフを手厚くケアしておくことも必要という。