これまで様々なプロジェクトを経験し、ある程度プロジェクトの進め方は把握しているつもりでも、契約前やプロジェクトの立上時/終了時に何をすべきかなどの細かな点はPM(プロジェクトマネージャー)を経験していない方にとっては想像しづらい物があります。
そこで当記事ではプロジェクトの始め方～実行中～終わり方までをわかりやすく解説します。
本記事の執筆者
当記事では次のことがわかります。
プロジェクトが始まるまで
PMの仕事はプロジェクトが成立する前から始まっています。
「明日からプロジェクトが始まるから、ちょっと君PMよろしくね。」とはなりません。
顧客からRFP（提案依頼書）を受け取り、提案書の作成および提案内容に対する見積りを行う段階からPM候補が立てられます。
PM候補が前の案件が終わらずどうしても別のPMを用意しないといけないと言いう理由がなければ、そのまま候補者がPMを担当します。
無事にプロジェクトを受注できた場合は、PMと営業で顧客のところへ挨拶に行くことでしょう。
そして、実際のプロジェクトが始まるまでには下記のような準備が作業があります。
- プロジェクトルームの確保
- プロジェクトメンバーの確保
- プロジェクトで利用する機器の調達
- プロジェクト憲章の作成
- プロジェクト実行計画書の作成
プロジェクトルームの確保
初めにプロジェクトを実行する場所が必要です。
総括部などにプロジェクトを実行するための人数を伝え、部屋を貸し出してもらいましょう。
プロジェクトの規模が大きくメンバーも20名を超えるとなった場合は、複数の部屋の壁を取り除いて1つのプロジェクトルームにするといった改築工事が必要な場合もありますのでプロジェクトルームの確保は早めに実施すべきです。
プロジェクトメンバーの確保
提案書を作成する段階でプロジェクトを一緒に実行するパートナー会社の選定も実施します。
晴れてプロジェクトを受注できた場合は、パートナー会社への発注作業が必要です。
「明日から10名来てください。」という訳にはいかないため、こちらも遅くとも1週間前には発注をかけるようにしてください。
プロジェクトで利用する機器の調達
パートナー会社を利用する場合、プロジェクトで利用するPCは発注元が用意する場合が多いです。
PCの初期設定が必要なため、1週間前には総括部に何台のPCが必要か、それはいつまでに必要かを伝えるようにしましょう。
プロジェクト憲章の作成
プロジェクト憲章とはプロジェクトの企画書に当たる資料です。
プロジェクトの全体概要とゴールを明記して、顧客や社内経営層などのステークホルダーと合意することで、今後何を実施すべきかを明確にします。
プロジェクト憲章を作成することで「言った言わない論争」を防ぐことができます。
プロジェクト実行計画書の作成
プロジェクト実行計画書はプロジェクトを進めるうえでの計画書になります。
プロジェクト憲章でプロジェクトのゴールを定めましたが、今度はそのゴールまでどうやってたどり着くかを計画します。
旅行に行く際にも計画を立てるはずです、プロジェクトを実行する際にも必ず計画を立てましょう。
プロジェクト実行中
プロジェクトルームを用意し、プロジェクトメンバーが集まったらいよいよプロジェクトの開始です。
プロジェクトが始まったら下記のような作業があります。
- キックオフ会議
- 定期的な進捗会議と顧客への報告
- 各種フェーズ
- 仕様変更対応
キックオフ会議
初めにキックオフ会議を実施します。
キックオフを実施する目的は主に3つあります。
- メンバー全員で同じ目的に向かうためのインプット
- メンバーのモチベーションアップ
- チームの団結力アップ
定期的な進捗会議と顧客への報告
PMは定期的にプロジェクトの進捗を把握し、計画と実績の間に差異がないかを確認しなければなりません。
差異があれば、その差異を埋めるための施策を考えていくことになります。
各リーダにチーム別の進捗を確認させ、進捗会議の場で報告を受けるという方法が一般的です。
進捗会議の開催頻度は1週間に1度の実施が適切です。
毎日だと管理負荷だけがのしかかりますが効果が薄いです。逆に1か月に1回だと問題が起きていても気づくことができず、進捗会議の場で遅延を把握しても手遅れになる可能性があります。
- 週1回の頻度で定例進捗会議を実施する
- 会議では各リーダにチーム別の進捗を報告させる
- 各チーム同じフォーマットを利用させる(PMやPMOが用意する)
PMが進捗を把握したらそれで終わりではなく、進捗状況はステークホルダー(顧客や上司などプロジェクトに少しで関係している人達)に共有するようにしましょう。
進捗状況を共有することで、計画通りに進捗している場合にはステークホルダーに安心感を与え、問題が発生している際にはどのような対策をとっているかを伝えることでPMに対するステークホルダーからの信頼が厚くなっていきます。
各種フェーズ
プロジェクトには要件定義や基本設計、詳細設計など各種フェーズが存在します。
フェーズ間の対応はV字モデルで表現されます。
一般的には前段階で決めた仕様をもとに次のフェーズに進む手法がとられており、これをウォータフォール型と呼んでいます。
WBSとガントチャートからなる工程表を作ると、実際に水が上から下に落ちていくようなスケジュールが現れます。ウォータフォールという名はここからきています。
- メンバーが基本設計中にPMは詳細設計書のルールを決める。
- メンバーが製造・単体試験中にPMやPMOは結合試験の計画書や試験仕様書を作成する
というように、前フェーズで次フェーズの準備を済ませましょう。
仕様変更対応
プロジェクトを進めていくと高確率で仕様変更が発生します。
ある日、顧客から「この機能も必要だから追加してほしい」と言われて、「はい、わかりました」とそのまま受けてしまうと、スケジュール遅延やコスト超過が発生することは目に見えています。
このような状況を避けるために、あらかじめ顧客と変更管理の基準を定めて置き、プロジェクト実行中にも例えば設計書の承認をもってベースラインとし、それ以降の変更は仕様変更として追加費用を請求するようにコントロールしていきましょう。
プロジェクトの終わり方
- 成果物を顧客に納品し無事にプロジェクトを終了させた。
- 今回はプロジェクト中断という結果に終わってしまった。
どのような結果であってもプロジェクトが終了となる際は、プロジェクト終了書またはプロジェクト結果報告書を作成しましょう。
プロジェクト終了書を作成する目的は主に2つあります。
- プロジェクトの後片付けをする人への引継ぎ
- プロジェクトで得た教訓を次のプロジェクトに活かす
顧客への納品だけでなく、社内手続きおよび後続プロジェクトへの引継ぎがすべて終わって、初めてPMの仕事は完了します。
まとめ
今回は、プロジェクトの全体像を解説しました。
◆プロジェクトメンバーが集まる前からPMの仕事はある。
◆プロジェクトの初めにはメンバーのモチベーションを向上させよう。
◆プロジェクト実行中は適切なタイミングで進捗を把握しよう。
◆仕様変更の発生は避けられないが、炎上しないように適切な対処が必要。
◆成果物納品したらプロジェクト終了ではない、後片付けも意識してプロジェクト終了書を作ろう。
◆プロジェクトの教訓を残して、次のプロジェクトに活かそう。
では、今回はここまで。
最後まで読んでいただきありがとうございました。
