BLOG

2014年3月27日/ システム, プロジェクト, プロジェクトマネージャー

プロジェクトマネージャなら必ず意識したい!炎上しないプロジェクトの進め方

 

システム開発のプロジェクトマネージャーなら必ずと言っても経験している「炎上」。  

projectmanagement

 

 

 

開発計画をたて、必要なリソースを配置し、進捗管理もやっているのにスケジュール通りに開発が終わらないのはなぜでしょう。

 

原因はたくさんありますが、多くの場合それはプロジェクトマネージャーが原因です。

 

 

原因① クライアントからの仕様変更要求

projectmanagement 

一番多いのがこのパターンじゃないでしょうか。

当初の仕様から開発を進めていくうちに、「あーでもない、こーでもない」とクライアントから仕様変更の要望が出てきます。

 

そもそも仕様検討がしっかりされて無いクライアントの責任でもありますが、すべてクライアントの要求を満たすことが正しいとは限りません。

システムはユーザーに使ってもらい、ユーザがすばらしい体験をして初めて良いシステムと言えます。

クライアントの要望に応えるのが必ずしも正しいとは限らないので、仕様変更には工数の少ない代替案や、類似システムの良い部分を提案して開発コストを下げる調整をマネージャーが意識する必要があります。

 

 

原因② 他部隊の開発遅延

projectmanagement

大規模開発になると自分のチームだけでなく、他チーム(他社も含め)との機能連携が必須となるため、APIの提供遅延や、結合試験の開始遅延が起こります。

この時に最終納期を調整できれば良いのですが、多くの場合ローンチが決まっているため、たとえ他責でもリスケジュールが出来ないのが通例でしょう。

 

ここでもプロジェクトマネージャーの手腕がとわれます。

こういった場合は他作業の前倒しなどで対応するケースが多いと思いますが、いまだウォーターフォールモデルの開発が主流の現場ではあまり意味をなしません。

 

ここで是非実行して欲しいのが、後行程の評価工数削減とドキュメントクオリティの削減提案です。

直接的にシステム仕様に関わらない部分なのでクライアントに納得してもらいやすく、最近ではオンラインでのアップデートが当たり前のシステムが多いのでバグがあっても後々フォローしやすいのです。

また、これはあまりドキュメントの簡素化によってクライアントが継続で発注せざるを得ない状況を作るだすこともできます。(ただし、チームメンバーがメンテナンスも継続し、仕様を熟知していることが前提です)

 

 

原因③ 想定外の機能実装

プロジェクトの開始前にヒアリングした要件定義や見積もりでは、話題にすら無かった機能が実はシステムに必須機能で、実装しないとシステムとして成立しないケースです。

クライアントには追加の工数やリスケジュールの交渉が必須ですが、これもまたクライアントの予算や納期を変更できず渋々対応せざるを得ない事があります。

 

この場合は、必須機能と付帯機能との実装トレードオフの交渉をしましょう。

そもそも機能には無くてもシステムが成立するものがたくさんあります。

 

仕様の詰め込み過ぎで使いにくくなったシステムをシンプルにして、ユーザーの使いやすいシステムに変更できる絶好のチャンスです!

 

 

いかがでしたでしょうか?

マネージャーの責務は重大でプロジェクト運営は非常に大変な業務ですが、トラブルがあってもマネージャーの手腕で炎上は回避できます。

是非、ストレスの無いプロジェクトライフを送って下さい!!

 

 

Resent Posts

Category