プロジェクトマネジメント: 2008年10月アーカイブ

今まで多くのプロジェクトに携わってきたので、
プロジェクトがうまくいくかどうか、良い状態かどうかというのは
理屈よりも先に肌で感じられます。

前に勤めていたコンサルティング会社のプロジェクトレビューアとして
様々なプロジェクトを見た経験もあるのかもしれません。

プロジェクト監査というのがありますが、私自身がマネジメントをする
プロジェクトも監査を受けた事があります。

しかし、実際にITプロジェクトのプロジェクトマネジメントを行ったことが
無い方が監査をするケースが多く、実質的なレビューにならないという印象を受けました。
もちろん、何もしないより、リスクは低下するのでしょうが、監査を受けるプロジェクト側に
負担がかかる事なので、「わかりきっている指摘」より、「気づきをもらえる指摘」が
欲しいところです。


私自身がプロジェクトマネジメントの支援を行う際には、実質的なマネジメントの
改革を心がけるようにしています

 

ウォーターフォールでプロジェクトを進めて行くと、ほぼ間違いなく仕様の変更や追加などで
前のフェーズの成果物に影響のある修正が発生すると思います。
例えば基本設計書の内容に変更を加えないとならないような場合、基本設計書をバージョンを
あげて変更するかどうか、その場合、誰が行うのかという議論はあらかじめ行っておくと
後々トラブルになるのを防ぎます。
システム開発において設計書のメンテナンスはかなり工数がかかるため、設計書のメンテナンスを
開発ベンダーに委託するとシステムコストの増加の原因にもなります。

プロジェクトによっては、基本設計書と詳細設計書の不整合を防ぐために「システム設計書」という
ひとつの成果物にしてしまうケースがあります。
この方が設計書のメンテナンス漏れや整合性確認などの手間が省けるというメリットがあります。

設計書については、各企業で求めるものがあるので、どうあるべきかを一概には決められませんが、
変更がある事を前提に、どのような方針で進めるかを予め決めることは大事ですが、意外に忘れがちな
ポイントかもしれません。


 

前にも書きましたが、部分最適を追求すると必ず全体最適からはずれます。

プロジェクトを実行する上で個別のチームスケジュールの最適化を優先すると全体スケジュールは

伸びます。

大規模なプロジェクトで複数の会社が関わるようなプロジェクトの場合、各企業は各契約の中で

最適なスケジュールを組むため、プロジェクト全体の最適化は、ほっておくと実現しません。

 

プロジェクトマネジメント側が意識的に全体最適のための調整や指導を行っていく必要が

あります。お金が関係してくるので、早めに意識的なマネジメントが必須です。

 

 

このアーカイブについて

このページには、2008年10月以降に書かれたブログ記事のうちプロジェクトマネジメントカテゴリに属しているものが含まれています。

前のアーカイブはプロジェクトマネジメント: 2008年9月です。

次のアーカイブはプロジェクトマネジメント: 2008年11月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1