プロジェクトが頓挫する。そういった事態はなるべく避けたいが、もしなってしまったらどうリカバリーすればいいのか。プロジェクトが頓挫する原因とその回避方法について解説する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
これまで、DX(デジタルトランスフォーメーション)プロジェクトを立ち上げるまでの注意点や勘所について解説してきました。第4回では、DXのプロジェクトを立ち上げたのはいいが「早くも頓挫してしまいそう」「既に頓挫している」「思ったような結果が出ていない」といったDXプロジェクトのトラブル回避方法を解説します。
プロジェクトが頓挫する原因は、多かれ少なかれ「想定したコストを超過した」ことに集約されると著者は考えます。コストが超過することでスケジュールも遅延し、当初立てた計画は一瞬で破綻してしまうからです。著者の経験では、コスト超過の起きる原因の多くがプロジェクト立ち上げの前段階、ベンダーによる概算見積もりにあります。
DXプロジェクトに限らずプロジェクトの立ち上げ時には、全体の予算感を計るために開発ベンダーに概算見積もりを依頼することがあります。見積もりを出すためには、ベンダーが対象のシステムについて、「何を(何の機能を)」「どのくらいのレベルで作るか」といった、システムの「広さと深さ」を理解している必要があります。
広さと深さを知るためには、要件や要望が見積もり可能なレベルで細分化され、理解できる状態になったドキュメントや指示がなければなりません。ご存じの通り、こうした要件や要望をまとめたものを一般的に「RFP」(提案依頼書)といいます。ですので本来であれば、RFPがない状態で正式でも概算でも見積もりはできません。
RFPは見積もり以外にも活躍します。RFPを作成することで企業側の目指すゴールが明確になり、要件に対する企業内の合意形成がとれた状態になります。コンペ形式でのベンダー選定にも役立つでしょう。ただ、このRFP作成の作業そのものをベンダーに丸投げをしている企業があるようです。ここに「1つ目のワナ」があります。
お手伝いをしてもらうこと自体はいいのですが、少なくとも企業側として目的やゴール設定、対象範囲、スケジュールの指示をすべきです。RFPは事業会社の魂そのものですから、その意思を他人にゆだねると当然、後のプロセスにおいてさまざまな不具合が出てきます。
とはいえ、要件が明確ではなく曖昧な表現が多く残る、いわば「レベルの低いRFP」を作ってしまうのも問題です。レベルの低いRFPしか作れないということは、企業内でのゴールが合意形成されておらず、ステークホルダー間でゴールの期待値がバラバラになっているということです。
こうしたRFPでベンダーに見積もりを依頼すると、そもそもRFPに回答できない、回答するまでに何度もヒアリング会を開かなければならない、といった事態を招き、プロジェクト自体が立ち上がらない可能性もあります。
ベンダーに見積もりを依頼する際には、企業内できちんと合意された要件や要望を記載した「レベルの高いRFP」が必要です。ただ、それだけではまだリスクがあります。
一般的に、RFPに対する企業からの問い合わせに対し、ベンダーは無償で対応します。企業側は「無償だから、できるだけ調整してもらおう」という発想になり、ベンダー側は「できるだけ簡潔に、手早く終わらせたい」という発想になります。そうなれば企業とベンダーの関係性や利害がいつまでもすり合わず、双方にとって良くない状態になります。これが「2つ目のワナ」です。
こうした状態では、ベンダーはできるだけ顧客の希望に沿った、仕事を受注しやすい調整をしようとします。つまり、顧客のコスト(予算感)とスケジュールから逆算した見積もりを作成します。企業側からすると、想定通りの規模感で見積もりやプロジェクト計画が提案されるので、一瞬完璧なプロジェクトが立ち上がったように見えます。
しかし、それはベンダーが企業に合わせているわけですから当然です。実際のプロジェクトが始まれば、ちょっとした想定違いで簡単にスケジュールが超過し、当初の計画から乖離(かいり)してしまうでしょう。
プロジェクトの頓挫はそもそもはRFPが不完全なことに起因していますが、それに対して受注ありきで調整を進めるベンダー側にも責任があります。予測不可能な作業量があることは最初からリスクとして考えるべきです。そして、そのリスクを顧客(企業側)に説明することはベンダーの責務であると著者は考えます。
ただ、実際はそんなことをすれば受注が危ぶまれるので、リスクには目をつぶり、「お任せください」「社運をかけて支援します」などの精神論でプロジェクトをスタートさせてしまうのです。
Copyright © ITmedia, Inc. All Rights Reserved.