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

企業向け情報システム構築プロジェクトは建築プロジェクトなどに比較しても予算やスケジュールの観点から測る成功率は低いのです。

様々な要因があるのですが、要因のひとつにコストに対するプレッシャーがあると思います。

担当者、ベンダーに対する経営からのコストに対するプレッシャーが、無茶な提案につながり、結果としてトラブルを招くというケースがけっこうあります。

こんな提案、無茶だなぁ、という提案書を何度も見た事があります。

提案者の経験不足・想像力不足に起因するケースも多々ありますが、受注プレッシャーから無茶な提案につながるケースも多いように思います。

 

ITは単なるインフラという位置づけで投資をするとシステム構築の提案は金額が安い方がいいという事になり、金額に対するプレッシャーが強くなります。

逆にIT投資が企業にとって大きなメリットを生み出す場合、金額の妥当感が問われるので、単なる値下げプレッシャーにさらされずに済みます。

要は付加価値のあるシステム化の企画が大事です。

 

 

ITプロジェクトの成功率は、様々な調査結果がありますが、30%弱というものが良く目にする数字です。

ここでいう成功とは当初予算、納期、品質が守れるという意味ですが、500人月を超えるようなプロジェクトでは、10%に満たない可能性もあります。

そもそも「当初予算」というのが曲者で、予算を決定する際には細かい仕様まで明確になっているわけではありません。
(特に大規模なシステム案件の場合は)

IT化の責務を負う部門は経営からの圧力があり、ベンダーは受注のための圧力があります。
当初予算を大きく出せばプロジェクト実行自体にGOが出ない可能性が高いため、当初の予算から大きく予備予算を持っておくのはなかなかできません。

当初予算内でプロジェクトを実行するためにはプロジェクトのすべてのフェーズにおいて予算に対するマネジメントの意識を持たなければなりません。

では、全体予算に収める努力はプロジェクトにおいて、誰が行っているのでしょう?

システム化を行う際にユーザ要求をどの程度応えるのかという点などがマネジメントされていないと予算はいくらでも膨らみます。

ユーザが要求した事をどんどんシステム要件に加え、最後に全体予算を見積もったベンダーが大幅な予算追加を要求してきた場合、誰が責任をとれるのでしょう?

ユーザが過度な要求をしたからユーザ部門が悪い?

見積もりの精度が悪かった?

 

一度出した予算に対するマネジメントを誰の責任で、どのように行うか、これは請負契約の開発プロジェクトなら当然に行われる事ですが、委任契約時には曖昧になりがちな部分です。

 

全体予算の管理に関しては委任契約時でも実施するべきで、その進め方についてはプロジェクトの実行計画策定の際に織り込むべき事項です。

 

実際、委任契約時に最終的なアウトプットで揉めても、発注者側はとても不利です。

企業のコンプライアンス意識が高まる中、プロジェクト実行時に第三者のプロフェッショナルがプロジェクトの進め方や品質を客観的に評価するというのは大規模なプロジェクトにおいては、今後益々、必要であると認識しています。

 

ITプロジェクトの標準化というのは、IT企業であれば当然通る道かと思います。
私も前にいたコンサルティング会社で標準モデルの策定に携わったことがありますが、意外にも世の中は標準化は一応はされているものの、細かいレベルで話をすると人それぞれの解釈があったりします。

いわゆる「メソッド」というものですが、これについての考え方自体が会社によってマチマチです。
つまり「標準化」で定義された内容に従うのが必須なのか、あくまで「標準型」なのか。
私は後者派です。
標準化はバックグランドが違う人間が共有する言語としての役割を果たしますが、
プロジェクトの進め方を杓子定規に定義して、これを絶対守るというマネジメントをしていても
大変なコストが発生しますし、おそらくうまくいかないでしょう。
標準がどうで、今回はこういう理由があるから、こう変えるという事が説明できる事が大事です。
(そうはいってもイレギュラーを認めない社風というのも、大きな壁としてあるのですが。。。)

某企業の標準化を進める作業に関与していた際、経営陣は「この通りやったら必ずうまくいく」という魔法を望んでましたが、
そのようなものは今のところ誰も開発できていませんし、できたらコンピュータがマネジメントをやってくれる時代になるでしょう。

 

マスタスケジュールについて


スケジュールの中のどこにバッファがあり、どこがクリティカルパスなのか理解せずに、やみくもに進捗の遅れを非難するマネジメントが行われたらプロジェクトは悲惨ですよね。

どこにクリティカルパスがあるかを意識できれば、各チームはそこにフォーカスをおいたマネジメントが可能となります。

見やすく、わかりやすいマスタスケジュールの作成を心がけたいものです。

論理的に階層のあっていないスケジュール、レベル感のあわないスケジュールは理解しずらく、スケジュールの抜けがあるのかどうかも把握しずらくなってしまいます。

あなたのプロジェクトのマスタスケジュールはわかりやすいですか?


 

 

このアーカイブについて

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

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

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

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1