プロジェクトは計画し過ぎてはいけないのか？

最近、はてなブックマークのランキングにこちらの記事がランクインしていました。

「プロジェクトを計画しすぎてダメにする方法」というタイトルで、目を引くタイトルです。

この記事の内容は当たっていると思います。記事では「登るべき山の頂が明確なら、アプローチの経路を地図の上にひき、どこまで登ったかを進捗率で測ることができる」と書かれているように、プロジェクトには二つのタイプがあります。

ゴールが明確な場合と不明確な場合です。ゴールが不明確「山の頂がどこにあるか分からない」な場合は、「まずやってみよう」というアプローチが正解だと思います。いわゆる、POCというものもこれに含まれるでしょうか。

山の頂が不明確な案件

ゴールが不明確な案件で、「計画をしっかり立てようとすると、其れなりの計画書ができるかもしれませんが、プロジェクトを始めてみると計画通りには全く進まず、計画したこと自体が無駄になってしまいます。まずやってみて、山の頂を出来るだけ具体的にしてから、計画を立てた方が良いと思います。

最近のDXに関連する案件は、この山の頂が不明確な案件に相当するものが多いと思います。このような分野は時間の流れも早いので、計画に時間をかけていたらスタートダッシュで遅れてしまうというデメリットもあります。

また、このような案件はいきなり何億円もの予算が必要になることも少ないでしょう。「まずやってみる」、「試してみる」という範疇であれば、数十万円から数百万円で済むことも多いでしょう。

従来型の事業に長けたとても役職が上の方の人が承認するようなルールだと、承認をもらうだけでも嫌になってしまうので、できれば権限を信頼できる人に委任して身近な上司が承認できるようにすると、デジタル化が進展しやすくなるかもしれません。

例えば、手作業でやっているあの一連の運用をシステム化する等の山の頂が明確な案件は、計画をしっかりと立てて、リスクを適切に洗い出して、石橋を叩いて渡るような従来型のマネジメントが合っています。

「プロジェクトを計画しすぎてダメにする方法」のようなタイトルだけを鵜呑みにして、本来はしっかりと計画すべき案件の計画で手を抜くとあとで火を吹く原因になります。

一つ言えることは計画に対してどの程度の力をかけるかは、その案件の特性次第です。頂は明確であってもリスクが高い案件はいくらでもありますので、最初の案件に対する目利きが大事です。

お客様が仕様を真の意味で理解していて、きちんと決めるべきことを決めてくれるか、入力となる仕様は整理されているか、未知の製品や方式を使う予定はないか等、勘所は多くありますので、自分がよく分からないことは知っている人の話を聞いてリスクを洗い出すことが大事です。