PMサプリ209:リーダーシップの発揮とはリスクをとること
リーダーシップを発揮することは、当事者として新たなリスクをとることに他ならない(大島洋、IDL代表)
◆指示を待つことのリスクについて考えたことありますか?
◆指示待ちのリスクが大きい典型的な例
◆煽っておいて、スカートの裾を踏む
◆プロジェクトマネジャーは役割だという認識が必要
リーダーシップを発揮することは、当事者として新たなリスクをとることに他ならない(大島洋、IDL代表)
◆指示を待つことのリスクについて考えたことありますか?
◆指示待ちのリスクが大きい典型的な例
◆煽っておいて、スカートの裾を踏む
◆プロジェクトマネジャーは役割だという認識が必要
強い立ち位置を作る(田中愼一、コミュニケーション戦略コンサルタント)
◆強い立ち位置をつくる3つのステップ
◆顧客への立ち位置の取り方
◆上位組織への立ち位置の取り方
S・tretch、M・easurable、A・ccepted、R・esource、T・ime(新将命、経営コンサルタント)
◆元祖 SMART
◆新将命さんのSMART
◆ストレッチした目標を支える個人の納得と組織
◆プロジェクトSMART
「構えろ!」「ねらえ!」「撃て!」(ヘンリー・クラウド、精神科医)
◆インテグリティを備えた人間になる
◆構えているか?
◆構えることの意味
◆多面的に検討する
◆狙うとは
◆順番が重要
◆リーダーの人間力
最近、人のインテグリティについて体系かつ、分析的に述べれた名著、ヘンリー・クラウドの「Integrity」の翻訳が出た。ビジネス書の杜にも紹介記事を書いたが、プロジェクトに関わるすべての人にとって、とても大切なことが書いてある本なので、ぜひ、一読をお奨めする。
リーダーの人間力
https://mat.lekumo.biz/books/2010/02/integrity.html
さて、この記事で書こうとすることは、人のインテグリティの話ではない。人に人間性というインテグリティが必要であるように、プロジェクトにもインテグリティが必要である。プロジェクトをインテグリティという目で見ていると、インテグリティのないプロジェクトは「大きな失敗」をすることも多いし、失敗しないまでも大きな成果は得られにくい。
ヘンリー・クラウドの本の解説を借りながら、プロジェクトのインテグリティについて考えてみたい。
顧客満足は、事前期待と実績評価の相対関係で決まる (諏訪良武、ワクコンサルティング・エグゼクティブコンサルタント)
◆ディズニーランドではどうしてアトラクションを長時間、待てるのか
◆事前期待をマネジメントする
◆過剰な事前期待がないと、提案できない現実
◆風呂敷をたたむ事前期待のマネジメント
◆プロジェクトの状況を顧客に可視化する
◆マネジャーとリーダーの違い
PM養成マガジンを始めたころに、「プロジェクト管理とプロジェクトマネジメントは違う」、「プロジェクトマネジャーがすべきことはプロジェクトマネジメントであってプロジェクト管理ではない」と言い続けてきた。それは言葉の遊びだと指摘されることも少なくなかったが、僕の中では明確な区別があった。そろそろ、区別を明確にしたいと思う。
これに関連する議論で、マネジャーとリーダーはどう違うかという議論がある。この議論は、古くから行われている。この議論のベースラインができたのは、ハーバード・ビジネススクールの名誉教授アブラハム・ザレズニック氏の論文
「マネジャーとリーダー:その似て非なる役割」
という論文だ。この論文はハーバードビジネスレビューに1977年に掲載され、当年のマッキンゼー賞を受賞し、大変有名な論文である。ザレズニック氏はマネジャーとリーダーはまったく別の人種であるとして、以下のような指摘をしている。
修正や変更の生じないプロジェクトはない(平野暁臣、空間メディアプロデューサー)
◆平野暁臣さんのプロデュース論
◆プロジェクトの特徴
◆プロジェクトマネジャーの行動パターン
◆本質は何をみているかにある
◆構想・企画 → 売り込み・巻き込み → 実行 → 終結
プロジェクトマネジメントが定着するにつれて、プロジェクトライフサイクルに対する概念が曖昧になってきたように感じる。フェーズの並びがプロジェクトライフサイクルだという考え方にだんだんシフトしているような感じがする。
プロジェクトマネジメントでは、プロジェクトの開始(組織の承認)から終了までがプロジェクトライフサイクルである。プロジェクト側からみればそういうことなのだが、経営側から見れば、「プロジェクト立ち上げ」の準備というフェーズがある。プロジェクトの企画、あるいは構想である。
ガバナンス的にいえば、どんなプロジェクトでもこのフェーズはあり、重要である。
さらに、構想がまとまってきたら、売り込み、あるいは巻き込みのフェーズが必要である。プロジェクトメンバーとして、あるいは協力者としてステークホルダを巻き込んでいくフェーズである。このフェーズをきちんとやらないと、大きな成果を得ることは難しくなる。できる範囲でしかできないからだ。
そして、プロジェクトの実施のめどが立てば、プロジェクトは実行のフェーズに移る。ここでは、プロジェクトのプラニング作業を行い、策定した計画に従ってプロジェクトを進めて行く。
最後は、終結。プロジェクトの成果をしかるべき人に引き渡す。プロジェクトでやってきたことに意義を持たせるためにはここが大切である。IT業界では、「動かないコンピュータ」という言葉がある。せっかくシステムを作ったのに動かないのでは、それがいくらすばらしいシステムでも一文の価値もない。終結というのは終わりではなく、プロジェクトの成果が会社や顧客、世の中に貢献する「始まり」である。「始まり」はしっかりとする必要がある。
このようにプロジェクトライフサイクルは
構想・企画 → 売り込み・巻き込み → 実行 → 終結
が一般的である。
目の前の仕事を処理することは手段に過ぎない(柴田昌治、プロセスデザイナー)
◆仕事の最終目的は何か
◆解決策は「深く考える」こと
◆悪化するプロジェクト環境とその対応
◆プロジェクトマネジャーだけでは「考えは深まらない」
◆プロジェクトの目的を上司と一緒に考えよう!
好川哲人
技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。
最近のコメント