IT戦略立案後のプロジェクト計画書はベンダーが作るプロジェクト計画書とは全くの別モノ

若手はすぐにフォーマットを欲しがる

「プロジェクト計画書をレビューしてもらえますか？」

ある現場では、IT戦略を立案し、承認されました。

今後はその戦略にもとづき、それぞれのプロジェクト計画を立てていきます。

そこで情シスの若手メンバーが「プロジェクト計画書」を作ることとなり、いったん完成したため、レビューの依頼がきました。

そして、見た瞬間に全面的な作り直しを覚悟しました…。

なぜでしょうか？

プロジェクト計画書はベンダーと社内でまったく別モノ

そのプロジェクト計画書は、昨年に導入した「パッケージシステム」のベンダーが提示してきたものをアレンジして作られたものでした。

アクの強い計画書は、見ただけでそれとわかってしまいます（苦笑）。

一般的に「新システム導入」のプロジェクトであれば、プロジェクト計画書には一定のフォーマットがあります。

（目次例）
・背景、現状の課題
・目的と目標
・プロジェクト概要（概要図、スコープ、コンセプト、目指す姿等）
・基本方針
・プロジェクトスケジュール
・プロジェクトの体制と役割
・プロジェクト管理方針（進捗管理、課題管理、会議体、成果物等）

ベンダーが作成するプロジェクト計画書であれば、それで良いでしょう。

なぜなら、システム導入自体が大きな視点で「定型的」だからです。そのため、システム導入やシステム開発の観点でフォーマットを定めやすく、論点は明確です。

一方で、その遥か上流の「社内でプロジェクトを立ち上げる」段階では、システムは単なる手段であり、目的ではありません。

プロジェクトによっては、システムを導入しないものや、小さなツール活用にとどまり、「組織変革」や「働き方改革」、「規定の変更」や「新規ビジネスの創出」など、様々な形があるでしょう。

そのため、システム用に特化したベンダーと同様の体裁では、ストーリーに矛盾が生じます。虫食い問題のように、テキストだけ書き換えても、断片的であり、局所的であり、社内への説得力もありません。

ストーリーを中心に組み立てる

そもそも、プロジェクト計画書は何のために作るのでしょうか？

大きく3つあります。
①上層部にプロジェクト立ち上げの承認をもらうため
②社内関係者に周知し、協力してもらうため
③プロジェクトメンバーの認識を統一するため

この3つに共通して、最も重要となる項目があります。

「背景」です。

この背景で関係者全員がプロジェクトを自分事としてとらえ、「このプロジェクトは必要だ」と感じてもらうことが重要です。

そのためには、この背景に全力を注いで、課題をリアルに描写しないといけません。

この背景が深刻であればあるほど、またはワクワクするような夢があるほど、プロジェクトの重要性・緊急性が増していきます。

プロジェクト計画書は、この出だしが勝負です。

背景さえうまく書ければ、その後の目的、概要、方針は書きやすく、関係者も受け入れやすくなります。背景が変われば、その後の展開も変わります。

そのためには、フォーマットをあまり鵜呑みにしてほしくありません。

プロジェクトには、それぞれ個別の背景があり、課題があります。

それを適切に説明するには「ストーリー」が重要です。

このストーリーに合わせて、資料を組み立ててほしいのです。

変にテンプレートがあると、そこに当てはめようとして、表現に制約ができてしまい、わかりにくくなります。

そのため、先にフォーマットを提示すると、担当者のイメージがそこに引っ張られ、無意識のうちにイメージが固着してしまいます。

おそらくゼロベースで、白紙に手書きをさせると全く別のイメージが書けることでしょう。

それをベースにしたいのです。

最初にフリーハンドでストーリーを描き、後からテンプレートを見て足りない部分を補っていく。

自分のストーリーを軸とし、テンプレートは参考程度で十分なのです。

テンプレートは、時間効率的には最速で仕上げることができます。しかし、思考停止しかねません。

作成者の思いも入れ込めていなければ、その計画自体が自分ごととして認識できていないかもしれません。

計画フェーズでは「生みの苦しみ」を味わいながら、誰よりも深く考え、時間をかけて表現することが避けては通れません。

自分のかなりの時間を投入し、ダメだった場合は全て無駄になるというリスクを背負って作るからこそ、そこに作成者の魂が宿ります。

その過程で、誰よりも強い当事者意識が芽生え、周囲にも刺さる資料に昇華していくと考えます。

ゼロベースこそが最も効率的に仕上がる

若手メンバーには、作った資料はいったん忘れて、まずストーリーをテキストで作ってもらいました。

テキストベースで何度もレビューをして、納得いくストーリーとなってから、そこに肉付けをしていきます。

この段階では、見栄えや表現方法などのビジュアルの工夫に注力でき、結果として効率的に仕上げることができました。

その後、ドラフト版をプロジェクトオーナーに見せたところ、ストーリーは共感していただいた上で、多くの指摘をいただきました。

それらをすべて計画書に反映することで、プロジェクトオーナーもかなりの当事者になりました。

この時点では「隙だらけ」だったのがよかったかもしれません。

貴社のIT部門・情報システム部門では、IT戦略策定後のプロジェクト計画書は、ストーリーをきちんと作りこんでいますでしょうか？