2008年11月アーカイブ

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

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

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

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

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

 

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

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

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

 

 

ITプロジェクトは予期せぬ事態が発生するのが常です。

何度経験しても常に条件は異なり、対応していかなければなりません。

PMBOKなどのプロジェクトマネジメントに関する知識の普及は良いことですが、

PMBOKを勉強してもそれだけではプロジェクトマネジメントは到底できません。

余談ですが、プロジェクト監査にITプロジェクトをマネジメントをした事の無いコンサルタントが指摘事項を並べる事があるようですが、私はプロジェクトの監査はプロジェクト実行者にとって有益な気づきを与える事ができなければ十分ではないと考えています。

プロジェクトを実行するリーダーはプロジェクトマネジメントに関する知識や経験も重要ですが、あえて言うなら私はマインドが重要であると言いたいです。

プロジェクトを責任持ってデリバリーする、その強い意志がまず大事です。

そして顧客、ユーザー、プロジェクトメンバなど様々な人に対して成功をコミットする姿勢です。

契約範囲など色々ありますが、イザという時に

「契約してないからやりませんでした。言われてなかったので、やりませんでした。」

なんて報告するようなリーダーはリーダー以前の問題かもしれませんが。。。

 

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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


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

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

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

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

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


 

 

コンサルタントとして様々な企業に入らせていただく機会がありますが、いつも思うのは日本のほとんどの大企業はいくらでも利益を出すポテンシャルを持っているということです。

 

革新的な新製品がなくても、今の製品を製造するコストや生産効率、業務効率をあげる余地がたくさんあるのですが、なぜか毎日目にしてしまうと「あたりまえ」になってしまい、改善するのは自分の仕事ではないと行動を起こさない。行動を起こしても煙たがられる。

ITプロジェクトでも問題だと思っていても自分の責任範囲でなければ黙っている、そういう雰囲気でプロジェクトが進むと問題の早期発見ができません。

 

問題というのは明らかになれば知恵を絞って解決できますが、問題をほっておくと、それはどんどん成長し、やがてはモンスターになってしまいます。

問題には目をそむけず、そして問題を認識した人が口にできる環境をつくっていくのがマネジャーの大事な仕事だと思います。

 

 

 

 

このアーカイブについて

このページには、2008年11月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年10月です。

次のアーカイブは2008年12月です。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1