プロジェクト計画をPMひとりで作る時代は終わった
とあるゆるゆるな会合で相談を持ちかけられたというか、あなただったらどうする的な感じでネタを振られたんですね。
どうやら、おかしくなっているプロジェクトがあって第三者の立場で見てレポートするのがお仕事だったらしい。
あなただったらどうするとは、よく聞いてみると２つあって、
- 第三者の立場でレポートに何を書くか
- もし立て直すならどうするか
それが上の２つ。
トラブルプロジェクトのレポート
必ず書かなければならないのは、依頼者が知りたいことですね。まず、大前提に第三者レポートが必要になるということは、組織の中で正確な情報がレポーティングされていない、という背景があるかもしれないということ。
正しい客観的で定量的なレポートが上がっていれば経営者はそれで判断できるものだし、それがあるべき姿です。
得てして、中間管理層だったり現場のPMが（根拠なく）まだ大丈夫だと思っていたり、そもそも（鈍感で）気づいていなかったりと原因は色々あるけれど、レポーティングされないという結果は同じですがそう言った正式なルートでは上がらずに、間接的に耳に入るとそりゃもう、疑うわけです。大丈夫か、と。
そこで何をしりたいか。
経営者であれば見通しです。あとどのくらいコストがかかるとか、いつリリースするのかとか。そのあとの運用はどうなんだとか。
もし立て直すなら
会合の場ではこっちが主題でしたね。自分なら、あれこれとしようと思うんだけどあなたなら、と。
そのあれこれが手法、技法のことばかりで、そうなのかなーと。
例えばペアプロでとか、テスト自動化云々とか。
それはそうなんだけど。
それはプロシージャや道具の話で細かすぎると思うんですよ。あちらこちら傷を負っているのに絆創膏を持ってきてどうするんだ、と。
その対処で80％のギズが完治しそうならそれでもいいのでしょうけれど、多分、それではまた別の傷を作ってしまうのでは、と。
チームに聴く
チームに聴きますね、と。どうやってこの先、ゴールまでたどり着くのか、と。それを具体的に、詳細に聴かせてください、と。
おかしくなるプロジェクトは、目先のタスクしか考えていないことが多いです。あと、メンバが言われたことをやるチーム。
作るのはチームなのにね。
つまり、プロジェクトのプランがメンバのものになっていないんですよ。これではちょっと時間を作るとわかる、作業の手順や成果物の構成の欠落に気づかないままに進めてしまって手戻りややり直しでの不満を自分たちも一緒に作っていることになるんですよ。
もうね、プロジェクト計画はプロマネ一人で作る時代じゃない。作ってもあくまでも案です。たたき台。それを回すチームが、自分たちで回すために使えるプロジェクト計画にバージョンアップしないといけない。
もう、今はそんな時代なんです。だって、システム開発の手法やマインドセットはそっちに移り掛けているんですから。
まとめ
実を言うとそのプロジェクト計画書はもうダメです。
突然こんなことを言ってごめんね。
でも本当です。
プロジェクトが開始すると
PMが作ったプロジェクト計画書が出てきます。
それが終わりの合図です。
チームはそのプロジェクト計画書に関心を持ったり
見たりしません。
程なく小さなトラブルが起きるので
気をつけて。
それを対処している間に、少しだけ間をおいて
デスマがきます。
