Webサイトのリニューアルや、マーケティングオートメーションによる商談数の増加など、すべて「プロジェクト」です。プロジェクトには予算管理、納期管理、スケジュール管理とマネジメントする必要がありますが、見積より以前に、「大前提」として、このプロジェクトは何のために行うのかを整理するのが、「プロジェクト定義書」(Project definition)です。
WhyとWhat
お客様は、多くの場合、「Whatが欲しい」と依頼してきます。しかし、そのプロジェクトは、本当にWhatを生み出すだけで良いのか、そこにあるWhy(なぜそのプロジェクトを行うのか)まで考えなくて良いのか？事前にコンセンサスを取らないと、トラブルの元です。
実際に、プロジェクトがうまく行かないのは、このWhyとWhatの整理ができていないから、と考えています。 例えば、こんなことがありました。「社員紹介をWebサイトで行いたい」というご依頼で、これは、「社員を掲載したページが欲しい」という”Whatが欲しい”です。ここで、社員紹介ページというWhatを制作することは問題ではありません。
しかし、Why？なぜ、社員紹介のページが必要なのでしょうか？とお聞きすると、「社員のモチベーションをあげたい」でした。 この場合、本当にそのWhatで、whyは達成できるのか？を、考える必要があるのか、ないのか、確認しなければ、「社員ページを作ったけれど、社員のモチベーションがあがらないよ」「えっ、それが目的だったのですね」ということになります。
社員のモチベーションをあげるためであれば、福利厚生の充実かもしれませんし、表彰制度の導入というWhatの方が「効果が高い」可能性があります。What→Whyではなく、Why→Whatと考える必要があります。
思い込みの見える化 また、「前提条件」を整理することはリスク管理の一部です。前提条件というのは、「当たり前のようにそう考えている」ことです。 例えば、「3年後に月間アクセス数が10万になり、広告収入シミュレーションを行った結果、月に20万の収入になる」という試算を行っていた場合、「3年後に月間アクセス数が10万になる」ということを「前提」としています。
どうしてその前提が生まれたのかを考えると、過去、同じようなWebサイトを3年後に10万アクセスにできた人材を採用し、その担当者が言ったことであれば、「彼のノウハウが現在も通用する」ということを前提としています。 プロジェクトにおける問題は、「無意識の前提条件」から多く発生します。プロジェクトの初期段階で、そのような「思い込み」をできるだけ見える化することが重要です。 などなど、プロジェクト定義書は、プロジェクトを始める以前に、その案件を整理するためのものです。コミュニケーションのミスマッチを減らすことに役立ちます。