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

ITプロジェクトですといくつかのチーム、サブチームが存在すると思いますが、

例えばプロジェクトマネジャーがチームリーダーの了解を得ないでチームメンバに直接指示を

するような事を思わずしてしまったりする事があります。

が、

これは絶対避けなければなりません。

 

指示する人間が複数になると指示される側は作業の優先順位や作業ボリュームをコントロール

してもらえないという思いからフラストレーションを高めてしまいます。

モチベーションマネジメントにも必要な要素です

 

 

類似パターンで良くあるパターンが、庶務的な事を担当してくれる方に対する指示。

あれやこれや、様々な人が仕事を振ってきますが優先順位を決めるルールや

作業ボリュームの把握をする人がいないと、相当なストレスをためてしまう状況になります。

 

顧客、同僚に何かを頼む場合も同様です

あたりまえの事ですが、指示系統は気を配りましょう。

 

 

IT経営においてマスタデータの整理は非常に重要なミッションですが、

これは場合によってはとっても大変な一大プロジェクトになります。

製造業では様々な目的別BOM(部品表)の整理をいっぺんにやろうとすると、

かなり大変な事になると思います。

 

流通業でひとつの商品に対して売価情報を登録しようとしても店舗毎、地域毎、エリア毎、

キャンペーン毎、特価設定など様々な要素があるのです。

「わざわざマスタ管理が大変なのは、言われなくてもわかっている」

と言われそうですが。。。。

 

実はマスタ管理に関しては甘く見る方が多いのです。

要件を決めるのを後回しにする、経験の浅いメンバで取り組むなどのプロジェクトは

実に多いです。

 

 

何をいまさら、、、という感もありますが、「議事録」書いてますか?

打ちあわせを行い、議論した内容、決定事項を第三者が読んでも判るように書くのは

非常に大事です。

 

そして議事録の運営についてプロジェクト開始時に決めておきましょう

配布者は誰か、作成期限はいつか?

議事録に承認はもらっていますか?

議事録の承認は必要ですが、なかなかもらえません。

議事録配布後、1週間以内に異議、意見が無い場合は自動承認となるなど、

プロジェクトルールを決めておくと良いでしょう。

 

議事録はプロジェクト記録として非常に重要です。

要件がどういった経緯で変更になったのか、あるいは決まったのか

誰の責任で何をいつまでに行うのか明確に記載される事でプロジェクト推進に非常に

役立つ重要なツールです

 

 

 

規模にもよるでしょうが、ITプロジェクトの進捗状況を経営陣に定期的に報告するのは

どの企業でも行っている事だと思います。

 

ITプロジェクトは、進捗に遅延が発生する事は良くある事ですが、正直に遅延を報告しても

最後にはつじつまが合うように(例え無理だと思っていても)報告をするケースを良く見かけます。

経営者からすると、「順調と聞いていたプロジェクトがいきなり破たんした」という事も世の中には

たくさんあるわけです。

 

ベンダーと発注者の関係でも同様の事が発生します。

遅延状況を正直に伝えないベンダー、あるいは「何とかします」と言い、それを信じる担当者。

 

どのような状況でも解決策はあるものですが、状況を公けに出来ないと機能不全となり

状況はさらに悪化します。

状況を報告する際には「私」を置いて客観的視点から正確な報告をする事が大切です。

 

 

プロジェクトにおける課題管理は意外と奥が深いです

 

課題管理に自由に記述できるようにすると実に様々な事柄がのってくる

分類すると、現在起こっている問題、将来のリスク(備忘録的な)、未決定事項、ToDoList、

悩み、など

これらを一緒に管理するとマネジメントはうまくいかない。

いや、いかない事もないかもしれないが、やりずらい。

これを避けるためにも、どういった事を何で管理するのか、プロジェクトメンバに対して

ルールを定義し、示すことが重要です。

 

 

ITプロジェクトだけに限りませんが、実際にOne To Oneで話をする時間を意図的に作るのは

非常に大切です。

日頃から話せる距離にいるのであれば良いですが、あまり顔を合せることのないような

状況ですと、なおさらです。

部下は言いたい事があっても、本当に困った状況にならないと、なかなか上司に問題を

話さない事が多いものです。

日頃から部下の近くに行って声をかける、特に用事がなくても1対1で話をする時間をとる、

という事を意識的にする事が日ごろのコミュニケーションを円滑にし、社内・プロジェクト内の

空気を変えます。

実際、1対1で話すことにより、多くの情報を得られます。

プロジェクトの問題点、家庭の事情、希望している仕事内容・・・

 

メールだけでのコミュニケーションで済ませがちですが、あえてリアルなコミュニケーションを

意識的に行いたいものです。

 

 

ITプロジェクトを実行する上で非常に重要なのがコミュニケーションです。

コミュニケーションは事前にデザインするべき事項のひとつです。

例えば、定例ミーティング、報告会などの会議体の定義もコミュニケーションデザインのひとつです。

問題が発生した際に、どのように共有を行い、どのように解決するか、そういった事を事前に定義

しておくのはプロジェクト計画として必要です。

実際、プロジェクトのチームリーダーが集まる会議体を事前に設定せず、プロジェクトリーダーが

多忙になってしまうと、まったく会議が開催されなくなり、プロジェクト内の意思疎通が悪化し、

結果として各チームが個別最適に向けて動き出すというケースもありました。

 

 

 

 

このアーカイブについて

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

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

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

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1