見出し画像

プロジェクトが一時ストップした、さあどうする?

プロジェクトがストップする理由

 今まで何度か「プロジェクト一時停止」の憂き目にあったことがあります。1週間とか1か月とか。

画像1

理由はさまざまですが、ざっくりいうと下記のような問題に集約されると思います。というか、集約すると、いずれも意思決定の問題ですかね。

・意思決定の問題
・コストの問題
・ベンダーとの契約の関係

さんざん話をして、要件も整理できて、後はGOを待つだけとなったときにこのGOがいつまで待っても出ずに幾星霜。。。みたいになっちゃうこと、ありませんか?

意思決定が先送りされる問題

 よくあるのは「とりあえず先送り」となって放置されるケースだと思います。決められないの。誰かボールを持っているようで、だーれもボール持ってない。

 こういうのを放っておくとメンバーの士気も下がりますし、ベンダー側も人のアサインの問題がありますから、困っちゃう。

画像2

止めるときに期限を決める

 問題の多くは、大なり小なり「止めるときに期限を決めていない」ということがあります。

 「1か月後に様子をお聞かせいただきます」じゃないですよ?こんなことしても何の意味もないです。1か月後に「うーん、まだきちんと相談できてないんだよね」なんて話に陥りがちです。
 そうではなくて、「最低限ここまでにお返事をもらわないと案件として止めざるを得ない」という期限を現場ではなく、決定権のある人と合意しておくことが必要となります。で、それをすぎたらいったんプロジェクト解散。

 残念ですが、ゲームオーバーです。

画像3

期限を決めないと、ユーザ側も困るという事実

 こういうこと書くと情シス内で「ひどい!」とかいろいろ言われるんですけど、ユーザ側の気心の知れたマネジメント層と話をすると「きちんと期限を決めてもらったほうがありがたい」という意見の方が多いですね。

画像4

 「こんな案件に時間を使ってるの?ムダ、ムダ」「決められない案件なんてどうせ現場が(説明用の資料が出せないとか、現場の合意が取れないとかで)止めてて大した案件じゃないんだから、一定のところでばっさり切ってもらって結構」という話もありました。

 じゃあ、遠慮なくやりますよ。

期限はもめる前に決めておこう

 なのでこれです。ちなみにもめてから期限を決めると結構な確率でトラブルになりますのでご注意を。「ちょっと止めてよ」と言われたときに期限を決めて、さらにそこでデッドラインとして「この期限を超えるとそもそも期限での対応が難しくなります」という「第二の期限」をさっと言ってあげるのがよいです。
 だいたいここで「うっ。。。」となって、「がんばらないといけませんね」といったことを言ってくれれば、中規模の案件までならさほどもめることはなくなります。

画像5

 あとは、決裁権のある人との話の機会をもって「〇〇まででってお約束しているので、それを超えると本当に間に合わなくなっちゃうので心配なんです」といった話をしておくことですね。

 しかし、そうはいかない案件もあります。

アンコントローラブルな遅延は、あらがうより、再開時に備えた動きを取ることが大事

 それがこれです。「社運をかけたビッグプロジェクト」なんていうものがあったりしてですね。トップが止めちゃったりすると、これはもうどうにもなりませんよシスター・・・!

 こういうときは素直に止めるしかありません。抗ってもムダ。

画像6

ここで大事なのは、内部での検討を止めないことです。こういったものは決まると「じゃあ明日から再開」なんてなりがちなので、少なくとも社内ではホットな状態に保っておく必要があります。

 だいたいこういったプロジェクトは「決めなければならないこと」を大量に抱えているものです。それを順番に課題化して検討をしていくことが必要になりますが、トップが止めると、全部これを理由づけにして止まっちゃうという恐ろしい事態が発生いたします…!

 こんなときには、ユーザとどれだけ信頼関係を築けているかがカギになってきます。全体で話すより、リーダーとサシで話す機会を持ちながら進めていくしかない。

 こうなってくると技術より人間関係とか工程管理とか、そんな世界になってくるわけですが、これは誰かに教えられるものではなく(教えられることもあるけど)難しいものだなあと思っています。

この本、大分前に買ったけど良い本だと思います。そのうちレビュー書く。

これも持ってます。ときどきパラパラやっている。しかし日経は高い。

こちらはストーリー形式ですが、結構以前になってきましたが「あるある」を感じる内容がたくさん。

これは興味がある本。そのうち読む。



この記事が気に入ったらサポートをしてみませんか?