プロジェクトを成功させるための7つのルール

とても久しぶりに「プロジェクトを成功させるための7つのルール」というお題で書いてみました。これは現在のsalesforceに関わらず、前職でやってたERP導入においても共通で気をつけていたことです。

１、提案するスコープをSaaSにフィットするゾーンにする

いきなり「そりゃそやろ」というルールです。

ただ炎上するプロジェクトって選択したSaaSがフィットしてない、ちょっと頑張ったイレギュラーな使い方というケースがとても多いです。

「いやいや、誰もやってないプロジェクトをやるのが俺様の生き甲斐なのだ」という方以外、イレギュラーな使い方だなーと思ったらSaaSではなくPaaSとかIaaS使って作った方が良いです。

これは選択する側だけではなく、提案する営業もとても気をつけて欲しいところ。過去に事例が無い、プロダクトとしてまだ未成熟、などの場合は通常以上に強力なインプリパートナーを指名する、設定作業費用にリスクを積んでおくなどリスクヘッジをしておく必要があります。

２、プロジェクトを舐めてかからない

色んなプロジェクトを見てきてますが、何故か「比較検討」とか「決裁するまで」は慎重だったのに、いざプロジェクトがスタートするとみんな謎の楽観視をしているケースが多いです。

どんなに簡単に見えても、やっぱり一筋縄でいかないのがプロジェクト。これは導入するお客様だけではなく、提案した営業やベンダーも楽観的になってるケースが多い。

Googleで「システム導入の成功率」って検索すれば過去記事いろいろ出てきます。だいたい成功率は50%くらいですね。舐めずに気合いを入れてスタートしましょう。

３、必ずキックオフを実施する

これは石井さんがノート書いてましたね。まさにその通りだと思います。流れや注意事項も完全同意です。

４、プロジェクトの成功・失敗を定量的に判断可能なKPIをセットしておく

キックオフの時、「このプロジェクトはこれを目標にする！」って気合いは良いのですが、それが本当に達成できたのかどうか定量的に判断可能なKPIを用意しておきましょう。「商談時間増やす」とかじゃなく、「1週間で2時間増やす」みたいな感じです。イメージじゃなく、メジャメントできる状態。

そして絶対に「いつまでに？」ということを設定する。例えば「1週間で2時間増やす」としても、それが3ヶ月後なのか1年後なのかでやることがかなり変わってきます。また仮に1年後だとした時、その1年後の目標に向かってオンペースなのかを測るためにも、中間地点でのKPIもセットしておいたほうが良いです。

1年後に「1週間で2時間増やす」、半年後に「1週間で1時間増やす」、稼働した直後は「過去2週間でのユーザーログイン率80%以上キープ」みたいに。ダイエットとか英語学習と同じですね。

５、KPIはプロジェクトメンバーだけではなく、決裁者と事前合意しておく

先ほど定量的で日付入りのKPIをセットしましたが、これをちゃんと決裁者と合意しておくことが大事です。決してプロジェクトメンバーだけで「これでいいか」だけでは駄目。

キックオフに決裁者が出てくることがベストですが、出ないとしたら尚更この事前にKPI合意しておくのは重要です。プロジェクトメンバーは良かれと思ってセットしたKPIでも、1年後に「達成できましたー！」と報告した時、「いやこんな成果期待してたのと違うんだけど」と言われたらゲームオーバーです。

この時、繰り返しになりますが関係者はみんな楽観的になってます。KPIの設定は可能な限り悲観的で「えー、こんなKPIなんて余裕過ぎてハードルになんないっすよー」くらいに設定しましょう。特に最初の方のKPI。1年後とか3年後は真のKPIにしておいて良いですが、稼働後は「過去2週間でのユーザーログイン率80%以上キープ」くらいにしましょう。

そんなのクリアしても成功じゃないと思うかもしれませんが、偉大な成果も地味なことからスタートするのです。ここで決して決裁者のプレッシャーに負けてKPIをオーバーコミットしないように注意しましょう。

６、炎上する前に飲み会開いて距離縮めておく

これまでとは打って変わって昭和的、義理人情的な話。ここまでのルールをちゃんと守っても、先進的で大規模なプロジェクトは大小様々なトラブルを抱えながら進むことになります。

どうしても当初予定していなかった追加コスト、プロジェクトスケジュールの延期、希望していた機能を諦める、みたいな瞬間が出てきます。その時、どんなに論理的にメリットのある選択だったとしても、プロジェクトメンバーの仲が悪いとうまく着地しません。

「なんか気に食わない」

そんなことで会社全体のプロジェクトを判断していいの？と思った時もありましたが、人間は全て論理の世界で生きてる訳では無いというのがお兄さんになって理解できるようになりました。

炎上する前提では無いですが、やはりトラブルを抱える前に飲みにいって距離を縮めておくことが極めて大切だと思います。その人がなんでその会社で働いているのか、家族構成、趣味。そういった人としてのつながりを持つ。そのチャンスは期待値が最高潮になっているプロジェクトキックオフの前後がベストだと思います。まぁ今はこの手は使えないので要検討ですね。

７、稼働したらキックオフで集まったメンバーで集まって「祝 稼働会」

いろんな山谷を超え、ようやくリリースの時を迎えます。その時、もう一度キックオフの時に集まったメンバーで「祝 稼働会」をやりましょう。これは前職の時、「キックオフ」と対比させて「タッチダウン」と称して実施していました。

タッチダウンを開催すると、もちろんその瞬間で100点満点！みたいなプロジェクトはレアです。少なからず何かの残課題を抱えているケースがほとんど。けどそれをそのままにせずにいつまでに誰が解決するのか確認し合う。

そして何より「ここまではできたよね」ということをプロジェクトメンバーで確認し合う。日本人は全員とは言わないまでも、カイゼン思考ともったいない精神が強すぎて「使いきれてない」ということが口癖になっていると思います。

たとえ使いきれてなかったとしても、プロジェクトの目的、当初に設定したKPIがオンペースであればいいじゃないかと思います。ここを設定せず、ぼんやり「使いきれてない」という結果でフワフワ終わるプロジェクトにさせないよう、タッチダウンで締めるというのはお勧めです。

最後に

まだ他にも以下のようなことに注意しています。
・1ヶ月に1回ステコミを実施する
・炎上した場合は現場だけで解決しようとしない
・稼働後の3ヶ月は週1くらいで定例ミーティングする

なんでこんなことを営業が書くのかというと、「プロジェクトに入ったらカスタマーサクセスや導入チームの責任」というスタンスでは決してプロジェクト成功しないという想いがあるからです。

こういったところまで介入すると自身のスキルアップにつながりますし、何よりタッチダウンの後でお客さんから「本当にsalesforce選んでよかったよ」と言われると個人的には売れる以上にやりがいを感じます。