プロジェクト管理?の手始め

   

プロジェクト管理の知識が無くても今の状況がまずいことが分かりました。

 

初歩の初歩とも思えるレベルから整理し始めます。

 

①プロジェクト名称がバラバラ
 →ネーミングルールを決める。

②体制表が無い
 →無いなら作る。

③資料が一元管理されていない
 →資料作成媒体を統一。保管場所を決める。

 

これでシステム部門が関与しているプロジェクトの基礎情報が揃いました。

 

まずは単に揃っただけです。

 

A:「次に何しようか。」

 

B:「スケジュールの見える化じゃない?終わりがいつか分からないよ。」

 

C:「スケジュールの情報も最初に聞いておくべきだったね。」

 

D:「資料の保管場所決めたからそこに行けば分かるでしょ。」

 

E:「じゃ、俺が保管場所の資料を見て全体スケジュール一覧作ってみるよ。」

 

一同:「助かる!頼んだ!」

 

翌日、Eからメールが届きました。

 

E:「システム部門にまともなスケジュールを立てているプロジェクトなんて無かった。有っても何が何だか分からないスケジュールでさ。俺だから分からないのかな?って不安になっちゃってさ。誰か見てみてくれない?」

 

という助けを乞う内容だったので、すぐさま添付されていたスケジュール資料を見てみました。

 

A:「え~っと、この線でこのタスクの開始終了は分かるな。内容は分からないな。担当だったら分かるんだろう、担当者は...書いてないな。だれがこのタスクの担当なんだ?なんだかこのスケジュールが書き方の粒度が適切なのかどうか分からないな...。」

 

もう一つ添付されていた別のプロジェクトのスケジュールを見てみました。

 

A:「う~ん、さっきのスケジュールと比較すると、やはり書き方の粒度が全然違うな。こっちのスケジュールは明らかに粗すぎるな...。」

 

 

スケジュールの書き方もルールを決めないといけないのか...。

 

本で読んだWBSというものをちょっと勉強してルール案を決める事としました。

 

ルールに正解は無いと思います。開発現場さえ納得してくれるルール、誰でも分かりやすいルールであれば良いと思います。

 

こうしてルールを決め、PM/PMOと議論を重ね、ルールを確定しました。

 

そのルールに基づき、全プロジェクトにスケジュールの書き直しを依頼し、出揃うまでに1か月程度要しました。

 

ポイント
スケジュールの書き方に正解は無いと思います。その企業の個性が現れるところだと思います。
スケジュールを作る現場に分かってもらえる、スケジュールを管理する人にも分かってもらえる粒度のスケジュール作成のルールを作り、そのルールを守らせることが大切です。

 - プロジェクトマネジメント, プロジェクト管理