本格的リニューアル構想中のため、一部表示に不具合があります m(_ _)m

プロジェクトの計画を作ってみる

プロジェクトマネジメント(基礎編) プロジェクトマネジメント(基礎)
この記事は約6分で読めます。

■ プロジェクト計画について

プロジェクトマネジメント(基礎編)
前回」は、プロジェクトの進捗が思わしくないとき、「プロジェクト憲章」の準備の効果と、これを使っての対応策の検討方法を簡単に説明しました。今回は、「プロジェクト憲章」をつくった後、プロジェクト計画を作成するときの、留意点について、老婆心ながら筆者の心構えをお伝えしたいと思います。
前回も言及しましたが、「コンティンジェンシー・プラン」を用意しておくと、様々なプロジェクト進行に対する障害への耐性がつきます。

山登りの比喩を使わせてください。
PM(基礎編)_山頂の目指し方

登りたい山の頂上はひとつです。しかし、登るペースや、パーティ・メンバ、登山道については選択肢がいろいろあります。登る時期や登る楽しみ(目的)も様々です。雪山・夏山は、いつ山に登るかで違ってきます。眺望を楽しむのか、山頂に辿り着いた達成感を味わうのか、途中の草木を愛でるのか、メンバの懇親を深め、よりよきチームワーク形成を望むのか、登山計画の立て方は、入念に、かつ楽しんでやるものと(勝手に)想像しています。

プロジェクト計画の立案も同じです。山頂(プロジェクトのゴール)を目指して、既に登山用のシューズやらザイルやらを品定めするところから、登山は始まっているのと同じように、登る山を決めて、メンバを決めて、スケジュールを組む。そして、途中で天候に変化が現れた時、どこで荒天を回避するか、予めバックアッププランを考えているはず。まったく、同じではありませんか。

 

■ ゴール(山頂)への最短ルートの探索

山登りは、必ずしも最短ルートで最速で頂上を目指すとは限りません。しかし、企業経営におけるプロジェクトは、最短期間(それが最小コストにつながることも多い)で完遂することを心がけるケースが圧倒的に多いです。
ここで(かなり大幅に)横道に逸れます。

決して、プロジェクトの完了だけが、プロジェクト実行の目的とは限らないケースがあります。終わらなくても許されることもあるプロジェクト。何かキツネにつままれた感じがするかもしれませんが、それは実在します。会社は、通常は「Going concern」を前提にしています。つまり、何世代にもわたって経営を続けていく必要があります。そのためには人材の教育が必要になります。プロジェクトはヒトを育てます。類似テーマで、大規模プロジェクトを定期的に実施していかないと、世代を超えた「ノウハウ」の継承、「リーダー」の育成ができないケースがあります。

特に、筆者が関与することが多い、管理会計制度・システムの変革プロジェクトは、テーマが「管理会計」なので、その会社独自の経営管理のノウハウの塊であることが多々あります。決して、教科書や社外の教育機関から学べないことも多いため、OJTでないと身につかないモノが比較的多いのです。その場合は、人材育成ができれば、プロジェクトは半分失敗しても、会社としてはプロジェクト遺産が人材という形で残り、それでOKということです。失敗の経験も立派な財産です。そういう意味では、筆者にも財産が多く。。。(^^;)

閑話休題。

プロジェクト計画を練り上げるときには、まずゴールをイメージしてください。登山の場合は、山頂からの絶景のように。ゴールの一歩手前では何をやっているでしょうか? エベレスト登山の場合は、ベースキャンプで、山頂アタックの準備をしているはず。管理会計システム構築プロジェクトの場合は、UAT(User Acceptance Test)を実施しているはず。UATの開始のためには、システムテストの完了と、UATのための、テストシナリオ、テストデータ、テスト環境の準備、ユーザトレーニングが完了しているはずです。時計を逆回しして、想像を巡らせてください。

 

■ 効率的なプロジェクト計画の立て方

詳細は、専門書や専門家のブログで確認して頂きたいのですが、筆者から言えることは、ただひとつ。
「ゴールから計画をつくること」
です。

先程は、登山の例を絵にしましたが、計画をつくるための意識の向きは、今度は下記のようなイメージになります。
PM(基礎編)_山頂から登り方を考える

20X6年4月に、管理会計システムを本稼働させる。そのために、UATは、20X6年2月に開始しておかないといけない。そのために、システムテストは、20X6年1月には開始しておかないといけない、、、、、そのためには、20X4年4月には、基本構想策定に着手しておかないといけない。

スケジュールだけではありません。管理会計システムを本番稼働させる。そのためには、マスタデータがセットされていなければならない。ユーザマニュアルを整備しておかないといけない。過去データを新システムに移行させておかなければならない、、、、、、業務要件とシステムの基本機能を決めておかなければならない。

やるべきタスク(To DO リスト)も、ゴールから考えます。
後ろから考えると、自然に最短時間で作業計画を作ろうという意識になります。現在時点からスケジュールづくりを始めると、
「○○部署の○○さんはこの時期忙しいから協力を仰げない。依頼時期を遅らせよう」
「○○のタスクは少なくとも○○ヵ月はかかるはず」
「海外関連会社の説得には最低でも○○ヵ月はかかる見込みだ」
など、障害や課題ばかりに目がいって、そうした安全策を積み重ねると、とんでもない時間とコストを必要とするプロジェクト・プランになってしまいがちです。

ゴールから考える。そうすると、自然とプロジェクトタスクが整然と「クリティカルパス」となって並ぶハズです。
皆さんは、小学生の時に、夏休みの宿題を片付ける計画を、学校の先生からの指示で1学期の終わりに作ったことはありますか? 筆者は、必ず、7/24から計画を立て始めました。そうすると、夏休み期間内に宿題に充てる時間がどんどん足りなくなってしまい、8月下旬には無謀な量のドリルの消化ページが割り当たってしまいます。しかも、お盆の頃には、やれ花火だ、やれ縁日だ、家族旅行だ、映画だ、プールだと、行事に明け暮れ、計画は破たんしてしまっています。そこから、元々捌ききれない量のドリルが待っている、、、生涯で、夏休みの宿題をすべてやり終えたことは一度もありません。

夏休みの宿題程度なら、先生に怒られておしまいですが(教育関係者の皆様、ごめんなさい)、ビジネスとなると話は別です。どんな小さなプロジェクトでも、ルーチン業務でも、一度ゴールから計画を作ってみてください。これまで自分が作ってきた作業計画とは見違えるくらい実行可能性が高い計画になっているはずですから。
(もし、実行できなくても決して苦情のメールを筆者に出さないでください。相談になら事前に乗りますから)
ここまで、「プロジェクトの計画を作ってみる」を説明しました。
PM(基礎編)_プロジェクトの計画を作ってみる

コメント