スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

状況対応型のリーダーシップ

今日はメンバーの状況に応じて使い分ける「状況対応型のリーダーシップ」について書きたいと思います。


プロジェクト等においてリーダーがメンバーに対してリーダーシップを発揮するとき、メンバーの状況に応じてリーダーシップのスタイルを使い分ける必要があります。ここでメンバーの状況とは次のようなことを指します。

① 未経験もしくはほとんどスキルがないメンバー
② スキルは多少あるが自分では実施できないメンバー
③ 自分でどうにかできるスキルがあるメンバー
④ 十分な経験やスキルがありモチベーションも高いメンバー

このように、メンバーによって状況が異なるにも関わらず、全て同じ方法でリーダーシップを発揮していてはメンバーがついてこなくなります。こういった場合は、次のように対応を使い分けます。






■Directing(ダイレクティング:指示型)
① 未経験もしくはほとんどスキルがないメンバーに対応したリーダーシップです。
何も知らない、スキルが無いというメンバーに対して、いきなり自分の力で作業をするというのは時間もかかり、ミスも多発します。こういったメンバーに対しては、方法を1から教え、理解してもらうようにします。


■Coaching(コーチング:コーチ型)
② スキルは多少あるが自分では実施できないメンバーに対応したリーダーシップです。
俗に言う「コーチング」が最も発揮できるのはこの分野です。メンバーに気づきを与え、自ら行動できるようにします。


■Participating(パーティシペイティング:参画型)
③ 自分でどうにかできるスキルがあるメンバーに対応したリーダーシップです。
ある程度できるようになったら、メンバーに任せてみます。ただし放任するのではなく、状況を見守り、サポートしてやる必要があります。


■Delegating(デリゲイティング:委任型)
④ 十分な経験やスキルがありモチベーションも高いメンバーに対応したリーダーシップです。
このレベルにいるメンバーはモチベーションもあり、何も指示しなくても動いてくれるので、プロジェクトの方向性だけずれないように認識を合わせておき、あとは作業を委任します。下手に指示を与えるとかえってモチベーションが低下してしまうことがあるので注意が必要です。


いかがでしたか?
場当たり的な指示だけでなく、メンバーの状況を把握して的確な指示を出してやることができれば、プロジェクトのパフォーマンスは飛躍的に向上すると思います。

スポンサーサイト

tag : リーダーシップ コミュニケーション プロジェクトマネジメント


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

プロジェクトを振り返る

今日はプロジェクトの振り返りについて書きます。

皆さんはプロジェクトが終了して、その振り返りのミーティングを行ったことがあるでしょうか?

おそらく休む間もないまま次のプロジェクトに移ってしまい、なかなかそういったミーティングを開けないというのが現状なのではないでしょうか?

プロジェクトマネジメントの知識体系をまとめたPMBOKというガイドがあります。
いわばプロジェクトマネジメントの標準書と言われるものです。
PMBOKによると、プロジェクトは「終結」というプロセスを経て終了するとなっています。

終結プロセスはさらに「プロジェクト終結」「契約終結」の2つに分解されます。

多くのプロジェクトは顧客との「契約終結」は行うのですが、社内での「プロジェクト終結」を行わないまま終わってしまうケースが多いようです。

プロジェクト終結では主に次のような作業を行います。

・プロジェクトの見積りと実績との差異分析
・プロジェクトの特徴から苦労した点、うまくいった点
・今後に向けての改善点

私は上記に加えて「プロジェクトメンバーの目標達成度確認」を行うようにしています。
これは先日の記事「プロジェクトの目標と自分の目標」に対する振り返りです。

プロジェクトの評価を行い、それをプロジェクト資産として今後のプロジェクトの見積りや計画などに有効活用するのです。

時間がなければ1~2時間でもかまいません。
これまでプロジェクトで無駄な会議を行ってきたと思えば、1~2時間くらいの時間は捻出できるはずです。

このフェーズを行うかどうかで、今後のプロジェクトに活用できるかどうかが決まります。
計画時に、予めプロジェクト終結を見込んだスケジューリングにしておくと、後であわてることがないので効果的です。


【結論】
プロジェクトの評価は、Q(品質)C(コスト)D(納期)+メンバーの目標達成度を確認し、今後のプロジェクトへの財産として残しておくために必要な作業です。


tag : プロジェクトマネジメント


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

プロジェクトの目標と自分の目標

昨日、アクセス数が1000ヒットを超えました!
いつも訪問していただいている皆様、本当にありがとうございます。


さて今日はプロジェクト立ち上げ時の活動について簡単な提案です。

プロジェクト立ち上げ時、プロジェクトメンバー全員を招集し、キックオフミーティングが実施されることがあると思います。このミーティングでは、プロジェクトの目的やシステム概要、顧客の情報やスケジュールなどが共有されます。

こういったミーティングを行う際、プロジェクトメンバー間で共有して欲しい情報があります。

それは、「プロジェクトメンバー個人の目標」です。

こういったミーティングでは、プロジェクトの目標(予算1000万円以内、粗利益率30%以上など)が共有されることはよくあります。ところが、プロジェクトメンバー個人の目標をシェアしているプロジェクトはそんなにないのではないでしょうか。

私はキックオフミーティングを行う際、プロジェクト計画書というドキュメントを作成しますが、その中にプロジェクト全メンバーの目標を書くようにしています。

それをキックオフミーティングで共有することで、全プロジェクトメンバーが自分の目標を宣言したことになります。

「私はDB担当になったのを機にオラクルマスターゴールドに合格したいと思います」
「私は要件定義フェーズを通じて、顧客の前でしっかりと説明できるようになりたいです」
「私はこれまでJavaを経験したことがなかったので、今回Javaをマスターできるようになりたいです」

私はプロジェクトメンバーの目標はSMARTでなくても構わないと思います。
このプロジェクトで自分が成長するぞという意思表示ができたことに意義があると考えているからです。

これをやるだけで、プロジェクトメンバーは結構能動的に動いてくれるようになります。

プロマネの方は一度試してみてはいかがでしょうか。

tag : プロジェクトマネジメント


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

マイナスの情報は伝えるべきか?

今日の記事は「マイナス情報」の報告についてです。
この記事は、部下の立場と上司の立場に立ってそれぞれ書かれています。

前半が部下、後半が上司の立場だと思って読んでみてください。



仕事をしていて失敗したり、間違えたり、期限に間に合わなかったりすることはよくあります。
そんな時、それらの情報をどれだけ上司に伝えるでしょうか。

「上司に報告すると怒られるかもしれない」
「人事考課に悪い影響を与えるかもしれない」
「今週の遅れは来週取り戻せば挽回できる」

このような考えを持ち、結局上司に報告しない人が多いのが現状なのではないでしょうか。
でも上司に報告しないままでいるとどうなってしまうでしょうか。

幸い後日失敗を取り戻せたため事なきを得る場合もあります。
ところがその失敗が傷口となり、担当者では手に負えなくなってしまう場合もあります。
こうなっては既に手遅れです。

マイナスの情報は時にプロジェクトや経営に大きな影響を与える場合があります。
そういった情報は未然に防ぎたいというのが上司やマネジメント層の考えです。

「マイナスの情報であっても包み隠さず報告しましょう」

これが問題を未然に防ぐ最良の策なのです。



ところが・・・



こういった話をいくらしても現場は改善されません。
朝礼などで上司が「問題が発生したらすぐに報告するように」と言っても、部下は問題を隠してしまいます。

部下が報告しない現場というのはいくつかの問題が潜んでいる場合があります。
ここでは典型的な3つの問題と改善策を挙げてみます。


■アナウンスが部下に十分伝わっていない

部下がマイナス報告を避ける理由は2つあります。それは「上司の怒り」と「評価」です。
部下が躊躇することなく報告行うようにするには、マイナスの報告に対するこれらの誤解を解く必要があります。

マイナスの報告に対する誤解を解くには次の2つのポイントに着目してアナウンスする必要があります。
① マイナスの報告を評価とは直接結びつけないと宣言すること
② 報告をしないことによるプロジェクトへのインパクトを理解してもらうこと


■報告に対する上司の態度を見直す

部下が上司への報告をためらう要因の1つに、上司の態度が挙げられます。
報告に対して高圧的に振舞う上司に対して部下はなかなか報告しづらいものです。
これは何もマイナスの報告に限った話ではありません。
部下がなかなか報告してこないと思っている方は、自分が部下に対して高圧的に振舞っていないか、自分の意見だけを言っていないかを見直す必要があります。

またマイナスの報告をしてきたときに、「誰が悪いのか」を突き詰める上司がいます。
マイナスの報告で着目すべきは「どのようなことが起きているのか」であって、犯人探しをするのではありません。
わかっていてもついつい犯人を捜したくなるものですが、部下の前ではそういった話は慎むべきです。

これらの問題に対しては、これらの改善策が効果的です。
①普段から部下とコミュニケーションを取り、報告しやすい環境を築いておくこと
②部下の報告に対して感情を見せないこと。むしろ「よく報告してくれた」と感謝すること


■定量的な報告管理をしていない

部下が「来週頑張れば取戻せるかも」という妙な希望を持たせないためにも、部下の作業を定量的に管理する必要があります。
曖昧な管理を行っている場合、部下はどのくらい進んでいるのか、あるいは遅れているのかを理解せず自分の感覚だけで作業を行ってしまいます。

そのため、最終期限に間に合うように勝手にペース配分を行うようになります。
そうなると、現時点で遅れていても「最終的に間に合えばよい」と考えるようになり、マイナスの報告をしないようになります。(そもそも遅れているかどうかも把握していない場合もあります)

そうならないためには、作業を定量的に管理し、報告を定量的に受ける必要があります。
定量的に管理するには、作業を定量的に管理できる単位に分割します。
例えばドキュメント枚数やプログラム本数、訪問件数などです。

その管理単位を母数とし、現在どこまでできているかを確認するのです。

よく「現在80%の進捗状況です」という報告を受けますが、管理単位が不明確である場合、部下の属人的な報告となってしまいます。

「40件のチェックリストの内、32件の検証が完了しましたので、現在80%の進捗状況です」という報告形態に変えれば、現在の状況が定量的に把握でき、予定との乖離を確認することができるのです。



【結論】
マイナスの報告ができないのは、部下に問題があるわけではありません。
どんな報告でも包み隠さず言える職場環境づくり、つまり職場の「カイゼン」が必要なのです。

テーマ : マネジメント
ジャンル : ビジネス

tag : コミュニケーション プロジェクトマネジメント リーダーシップ


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

プロジェクトを構築する ~タックマンモデルとは~

今日は私の本職であるプロジェクトマネジメントについて少し触れてみます。

今回は「チームビルディング」のお話です。


プロジェクトが立ち上がる際、様々な部署からプロジェクトメンバーが召集されます。

まだお互いを知らないプロジェクトメンバー同士が、いくつかの段階を経て成果の出るチームへと成長していきます。

チームビルディング理論ではこれらの段階を4つに分けています。

これは心理学者タックマンという人が提唱したことから「タックマンモデル」といわれています。



■第1段階:Forming(フォーミング)

フォーミングとは日本語で「形成」という意味があります。

つまり、プロジェクトが立ち上がったばかりでお互い何も知らず、様子を伺っている状態のことを指します。

この段階ではプロジェクトはパフォーマンスを上げることはで着ません。



■第2段階:Storming(ストーミング)

次のステップはストーミングです。

Stormとは日本語で「嵐」つまりお互いの意見がぶつかり合い、対立する状態のことを指します。

プロジェクトが成功するためには、このストーミングというステップが欠かせません。


プロジェクトがこうなっているとき、経験の浅いプロジェクトマネージャーは、「プロジェクトが混乱している。どうしよう」と戸惑ってしまいます。

しかし、意見が対立するのは仕方のないことです。

プロジェクトがこのような状態になっていたら、「よしよし、成長し始めたな」と喜ぶのがセオリーです。



■第3段階:Norming(ノーミング)

お互いの意見が対立した後、「この人はこういう考え方なんだ」と理解を示すようになります。

考え方の違いを認め合い、関係が安定してくる状態がノーミングというステップです。

ノーミングとは、Norm、日本語で「基準」や「標準」などと訳されます。



■第4段階:Performing(パフォーミング)

最後のステップはパフォーミングです。

これは、Perform、日本語で「機能する」と訳されるとおり、お互いが認め合い、長所を伸ばし合う事で、プロジェクトのパフォーマンスが上がる状態のことをいいます。



プロジェクトチームが成長するには、このモデルを意識して「今このプロジェクトチームはどこにいるのか?」というポジションを共有することが重要です。

また、チームの混乱を避けて通るのではなく、混乱をいかにうまくまとめ統一したパフォーマンスを発揮するか、これがチームビルディングには重要です。

テーマ : マネジメント
ジャンル : ビジネス

tag : チームビルディング プロジェクトマネジメント


最後まで読んでいただきありがとうございます。
もしこの記事から「気づき」を得られたら、
ランクアップへの応援お願いします!
↓ ↓ ↓
過去最高38位!≫ ブログランキング(資格・スキルアップ)
過去最高1位!≫ にほんブログ村(ビジネススキル)

プロフィール

Okamura Shuichi

Author:Okamura Shuichi

ご連絡はこちら:
shuichi.okamura@gmail.com
(@を小文字にしてください)

某外資系コンサルティングファームに勤務しています。

主にITプロジェクトのマネジメント業務を通じて仕事や人間関係の難しさ、大切さを勉強しています。

将来はハワイでのんびり暮らしたいと考えている一児の父親です。

どうぞよろしくお願いします。

メールマガジン
smart.fm(無料総合学習サイト)
リンク
最新コメント
最新トラックバック
検索フォーム
カレンダー
08 | 2017/09 | 10
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
FC2カウンター
タグクラウド

私のチャレンジブログです!
『自分★ブランディング計画!』へジャンプします
↑ ↑ ↑
私のもう一つのブログです。
このブログともども
応援よろしくお願いします!
(Wordで作りました)
最新記事
人気記事ランキング
月別アーカイブ
RSSリンクの表示
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。