株式会社クイックのWebサービス開発blog

HAPPYなサービスプランナー・エンジニア・デザイナーのブログです。

残念なプロジェクト管理を見てきたので誰かに伝えたかった話

こんにちは。 システムアーキテクトを担当している「こってぃ」でございます。
4月に入り、重度の花粉症に悩まされておりますが、
この時期はお花見とか外でビールを飲む機会も増えてくるので嫌いになれません。

さて、最近お笑いのライブに行ったところ、
リズム良く「あるあるネタ」を披露しているコンビがまだ頑張っておりました!
ブームは過ぎ去ったものの、観客は彼らの登場にとても喜んでおり、拍手喝采でした。

そんな彼らにあやかって、
今回はシステム導入プロジェクトにおける残念な「あるあるネタ」をお届けします!

弊社内のプロジェクトではなく、私個人が今までに見てきたものをお話します!

お仕事の合間に「あるよね~」と共感いただいたり、
「こんなプロジェクト嫌だ」と反面教師にして頂けると嬉しいです:D

このプロジェクトって美味しいの?

f:id:aimstogeek:20180412165903j:plain
あまりにもメンバの入れ替わりが激しかったり、
色んな開発会社が参画している場合、
プロジェクトの目的を共有出来ていないことがしばしば見受けられます。

そうなると、プロジェクトチームの熱量も下がってきて、
消極的なプロジェクト参加になってしまいがちです。

メンバが単一のプロジェクトのみに携わっている場合は別ですが、
そうでない場合、優先度の低いプロジェクトになってしまいますよね。

自分がメンバとして参画している際に、
とりあえず仕事を投げて終わりみたいな事されたら嫌ですよね。

メンバあってのプロジェクトです。
きちんとプロジェクトの目的を共有して、
成功へ導いていきましょう。

課題共有会が課題解決報告会に

f:id:aimstogeek:20180412165941j:plain
共有されるのは解決済み課題や、解決方法が明確になっている課題のみ。。。

新たに発見されて、解決の目処が立っていない課題は公表されません。

そんな課題共有会に出たことがある方もいらっしゃるのではないでしょうか。

「何か解決してたら前進している感でるし良いや。」って空気になっていますよね。

これ最悪です。

隠蔽している問題が表面化した際に生じる影響を考えるよりも、
その場を上手く乗り切ることを優先させている典型的な例ですよね。

そんな会議に出会ったら、
何のための会議なのかをもう一度問い直しましょう。

「この会議って課題潰した自慢大会でしたっけ?」

また、報告を受ける側としては、報連相をしやすい環境づくりは大切です。

常日頃、不都合な報告があった場合に詰めまくる姿を見せていては、
報告することをためらってしまうこともあるかもしれませんね。

永遠の「90%」

f:id:aimstogeek:20180410172046j:plain
開発のチームから提出されたWBSを見ると全部オンスケ、進捗率はいつ見ても90%になってます。

でも皆帰りは遅いんですよね。なんでかなー。

確認すると、報告されているWBSとは別のより細かいWBSがあって、
それを見ると実は遅延になっているという事もあります。

管理する側が正確な状況を把握出来なければ、何も手を打ちようがありません。

とはいえ、プロジェクトマネージャだけでなく、
報告をあげてくれるチームリーダも往々にして多忙を極めています。

そんな時にPMOのように遊軍的な人が、
プロジェクト管理の手助けをしてあげると上手く回るのではないでしょうか。

日はまた変動を繰り返していく

f:id:aimstogeek:20180412165828j:plain
計画時のスケジュールと比較すれば明らかに遅延しているのに、
報告資料ではなぜかオンスケになっています。

進捗ごまかしのテクニックで使われがちなんですよね。
合意無いリスケ。(テクニックでも何でもないですが)

報告側の人間性に問題があると言えばそれまでですが、
異変に気付く力も管理者には求められているのかもしれないですね。

ミイラ取りがミイラになる

大規模なプロジェクトになると、複数の開発チームが立ち上がります。
そこで、チーム毎にバラバラなドキュメント管理やプロジェクト管理にならないよう、
横串で開発チームを管理するチームが立ち上がることがあります。

ただ、開発が進むにつれて、テスト事務局のように、横串で管理するチームが複数出来てしまうことも。。

横串管理チーム同士が連携を取れていないと、毎週開発チームに似たような報告をさせることになり、
結果、開発チームの工数を圧迫するという事態が起きます。

そうなると、複数存在する横串管理チームを横串で管理するチームが発足されるわけですね。

横串管理するチームが自分たちを横串管理出来ずに横串管理される。 図にするとこんな感じかな。

f:id:aimstogeek:20180412150319p:plain

うん、よう分からん。

最後に

今まで見てきて残念だなって思った事例を書いてみました。

実は色んなプロジェクトで同じような事象が起きている様を見てきました。

中には、1つのプロジェクトで全て発生させているものもありました。
結局そのプロジェクトは遅延に遅延を重ねて残念なプロジェクトとして多くの工数を飲み込んでおります・・
(弊社のプロジェクトではないですよ!)

プロジェクトマネージャーやプロジェクトリーダ、
PMOを経験した方なら目にした事があるのではないでしょうか。

そもそも、世の中ではそうならないための色んな施策も紹介されております。

今回話した事例は反面教師として今後に活かしていきましょう。

ほなの。



\\一緒に『明日のはたらくを創る』仲間を募集中です!! // 919.jp