スケジュール管理の最近のブログ記事

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


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

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

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

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

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


 

 

データベースが大容量になるようなケースだと特にテスト環境のマネジメントが必要になります

データ移行用、アプリケーションテスト用、バッチテスト用、総合テスト用等のテスト環境をプロジェクト

スケジュールに遅延なく用意されるように計画しなければなりません。

この計画をおろそかにすると、プロジェクトのスケジュールにダイレクトに影響します。

 

小規模なプロジェクトでは、あまり重要視されないのですが、規模が大きくなると特に影響が

大きいタスクなのでタスクの定義をきっちりと行いたいものです。

WBSの説明をするのは今更な感じがあるので、しませんが、、、

 

WBSをせっかく作っても個々のワークパッケージの内容が不明瞭であると混乱を招きます。

WBSを作成したら主要なプロジェクト当事者と内容の共有を行い、

合意をするというタスクを入れましょう。

 

WBSに利用する言葉は誰でも同じようなイメージを抱きやすい言葉を使うように心がけるのも

ポイントです。

 

 

 

 

マスタスケジュールを作成する際にクリティカルパスを意識するのは非常に重要です。

スケジュールを共有する際にも、これを意識してもらえるように明示的にする事で

プロジェクト運営に大きなインパクトがあります。

クリティカルパスの遅延はすなわち、プロジェクトの遅延に直結します。

このパスの遅延を避けるために各チームはマネジメントを行い、結果各チームの個別最適

スケジュールを避ける運営が可能になるとも言えます。

 

 

企業システムを構築するにあたり、WBSに記入し忘れないようにしたいのが、ユーザ教育です

当たり前の事ですが、システムを構築する事に集中すると優先度が低くなったりしがち

なので、あらかじめ計画をし、要件定義を行う際にラフな実施内容、スケジュール、体制などを

想定しておくと良いでしょう。

特にコスト面に影響するので注意したいのが、

誰がユーザ教育用の資料をつくるのか、誰が教育を行うのか

教育環境を用意するのか等明確にしておくことです。

 

ユーザ教育はなるべく現場の業務がわかっているリーダークラスの方に担当いただくと

スムーズです。

 

 

業務アプリケーションを導入するにあたり、現場の業務担当者

あるいは責任者にプロジェクトへ参画してもらうのは、とても重要です。

 

場合によっては「現場の意見は聞かない」というプロジェクトも存在しますが、

よほど業務に精通している方が主導している場合でないと、

「使われない」「業務負荷の高い」システムになるリスクを高めてしまいます。

 

現場の方はたいてい、自分の利用しているシステムが改善されるなら

積極的に時間を作っていきたいと考えています。

しかし、単純に時間が無い、評価の対象外、過去のITプロジェクトへのネガティブなイメージなど

様々な理由から業務側の主体的な参加を求めるのが難しい場合があります。

 

このような場合、ひとつのテクニックとして、業務側の責任者を明確にし、

プロジェクトの全体スケジュールの中で業務側のタスクを明示的に示し、他タスクとの関連を明確にする事です。

 

プロジェクトの進捗を業務責任者と共有し、業務側の遅延がプロジェクトの遅延理由になりそうな場合に、業務責任者にとってのプロジェクト関連のタスク重要度が自然と上がるはずです。

 

 

今更ですが、このタイトルが適切なのか、ちょっと悩みます。。。

 

さて、予算設定時の前提となる軸の話ですが、まず受注側も発注側も何を前提とした金額なのか明確にするということです。

これは仕様を詳細に決めるという話ではなく、大きな要件を明確にし、受注金額の前提となるものは何かを共有する事です。

例えばユーザ要求の定義を行う必要がある場合、実際にかかる工数はユーザが打ちあわせ等の時間をとれるかどうかでスケジュールに大きな影響を受けます。

また、企業によっては要件を決めるのに様々な承認行為が必要となり、企業体質がスケジュールに大きな影響を与えます。

これらの事に対しても前提として、どのようなスピード感や現場の協力を得られるかを明示的にする事は大事なことです。

 

また、後々、このあたりの事は書いていきたいと思います

 

簡単すぎる目標も、無理だと思うようなスケジュールも人間にとってはモチベーションを高くする要素にはなりません。

がんばったらなんとかなりそう、よし、がんばろう!

くらいのスケジュールがベストです。(モチベーションを高めるという観点だけで述べると)

 

ITプロジェクトにおいて、ゆるいスケジュールというのは、あまり経験がありませんが、無理と思われるスケジュールは良く目にします。

これはプロジェクトの実行計画が法律改正、企業計画、あるいは予算等様々なプレッシャーにさらされ、決定されるからでしょう。

プロジェクトリーダーは、スケジュールを実行するための策を練り、メンバが実行可能だと信じ込ませなければなりません。リーダーについていけば、何とかなると。

実行可能だと思いこませられれば、本当に実行可能になります。

それがモチベーションの力です。

 

このアーカイブについて

このページには、過去に書かれたブログ記事のうちスケジュール管理カテゴリに属しているものが含まれています。

前のカテゴリはコンサルティングです。

次のカテゴリはプロジェクトマネジメントです。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1