本ブログは移転しました。こちらをご覧ください。
◆機能しないデシジョンゲート
前回はプロジェクトマネジメントにおける意志決定のイメージを共有するために、リスクマネジメントに焦点をあて、意志決定をするとはどういうことかを説明した。今回は、前々回のライフサイクルにおける意志決定の議論に戻る。
意志決定の観点から重要なことはデシジョンゲートであることは、前々回に述べたとおりだ。ゲートと意志決定の関係をもう一度、整理しておく。ゲートとは意志決定が適切に行われているかどうかは判断するものであり、ゲート通過時点で必要な意志決定が行われていない、あるいは不適切であると判断すれば、プロジェクトはストップして意志決定を行わなくてはならない。
従来、プロジェクトの運用においては、（プロジェクト）マネジメントより作業が重視されてきた。ほとんどの管理は、作業の（品質）管理として行われ、全体のマネジメントは行われてこなかった。その名残は今でもある。それが、ゲートの位置づけである。
ゲートがゲートとして機能していない。これがいろいろな弊害を生んでいる。
本ブログは移転しました。こちらをご覧ください。
◆分析と決定は違う
前回は、プロジェクトライフサイクルの中でどのような意志決定が必要になってくるかを整理した。前回の記事に対して、「決定ではなく、分析ではないかという質問を戴いた。今回はこの点について述べておきたい。
このような誤解が生じやすい典型例はリスクである。どのようなリスクがあるか分析して出てくるものであって、決定するものではないと思う人が多いと思う。あるいは、分析結果＝決定だと思っている人が多い。
これは半分正しく、半分正しくない。正しい部分は、リスクの候補（「不安事」）は情報収集や分析によって発見されることが多いということだ。分析の方法は、過去の事例であったり、プロジェクトのＳＷＯＴ分析やステークホルダ分析（現在）であったりする。そのプロジェクトのシナリオ分析（未来）であったりする。そして、発見されたものの一部がリスクとして識別される。そして、それらについては分析され、対応が決定される。
本ブログは移転しました。こちらをご覧ください。
◆プロジェクトマネジメントライフサイクル
前回までプロジェクトマネジャーやプロジェクトスポンサーの意志決定の重要性を説明してきたが、では、具体的にどのような意志決定をする必要があるのだろうか。今回が概要を説明する。
プロジェクトにおける意志決定はプロジェクトマネジメントのライフサイクルと密接な関連がある。ここではＰＭＢＯＫのような複雑なフェーズモデルは考えずに、もう少し、単純にプロジェクト全体に対するモデルで考えていきたい。PMstyleでは、プロジェクトマネジメントライフサイクルを
（１）構想
（２）実現性分析
（３）計画
（４）実行
（５）統制
（６）終結
の６つのフェーズで考えている。（３）～（６）は基本的にはＰＭＢＯＫのプロセス群と同じものなので説明は省略する。（１）と（２）は併せて、ＰＭＢＯＫのプロセス群でいうところの立ち上げプロセス群に相当する。
本ブログは移転しました。こちらをご覧ください。
◆知識労働者はエグゼクティブ
管理者がプロジェクトを管理する際にもっとも考えるべきことは、ＲＲＡＡ（Role,Responsibility, Accountability,Authority）ではなく、自分たちの仕事はどういう仕事かということである。プロジェクトマネジャーも、プロジェクトメンバーも、プロジェクトスポンサー（管理者）もプロジェクトにかかわる仕事をする人たちは、例外なくピーター・ドラッカーのいうところの「知識労働者」である。すなわち
知識をもって何事かを成し遂げることを欲する労働者
である。そして、ドラッカーは、知識労働者はすべてエグゼクティブであると指摘している。
エグゼクティブとは、仕事の目標、基準、貢献を自ら決定し、仕事をしている人たちのことである。肉体労働が労働の主体であった時代には、エグゼクティブとして仕事をするのは組織のトップ階層の人たちだけであった。しかし、知識労働においては、知識による権威は、地位による権威と同じように「正当かつ必然」のものであるといえ、だれもがすべての知識労働者はエグゼクティブであるとみなすことができる。
本ブログは移転しました。こちらをご覧ください。
◆プロジェクトは問題解決の手段
プロジェクトは問題解決の手段である。社内プロジェクトであれば事業や組織の問題解決である。受注プロジェクトであれば、自社にの問題解決であると当時に、顧客の問題解決であることが多い。商品を開発するときには、その商品開発を課題（解決策）とし、課題を実行することよって解決される問題がある。受注したシステムを開発するときには、その案件の受注によって解決したい自社の問題（例えば、売上げの拡張）があり、また、顧客はそのシステムによって解決したい問題を抱えている。
では、問題とは何か？目標（あるべき・ありたい姿）と現実のギャップである。つまり、プロジェクトはあるべき姿と現実のギャップを埋めるために行う活動であるということができる。
本ブログは移転しました。こちらをご覧ください。
前回の続き。
◆阿久根市のブログ市長
もう一昨年になるが、鹿児島県阿久根市で、市議会を開かず専決処分を繰り返してきた竹原信一市長が、「議会が不承認でも専決は有効である」という話を聞き、ついに議会を開き、話題になった。この話、結構、日本社会の合意形成の本質的な話かもしれない。
新聞情報に基づき、もう少し、正確に説明しておくと、法律に則り正しく専決された事項は、議会の承認に優先するということらしい。法律に則る専決であるための要件はいくつかあるが、その一つが「緊急性」の有無とのこと。ただし、これは災害時の迅速な意思決定とか、議長が議会を開催せず市長提案を審議しない場合を想定しているルールで、市長が議会の開催を拒否して専決することは想定しておらず、合法かどうか微妙だというのが総務省の見解だという。
ここで興味深いのは、専決（決定）と承認の関係である。阿久根市の事例で分かるように、決定されたものは、承認されなくても有効である。おそらく概念的にはこれが一般的である。もちろん、決定は公式権限を用いて行われる。
一般的な議会の運営は市長提案に対して、議会が審議するというものだ。この場合、提案であるので否決されれば実施できない。この場合は否決であり、議会が決めるのだ。
興味深いのは、専決であれば不承認になっても、有効であり、実行できるという点だ。つまり、決めることは承認することより強いのだ。
そして、この阿久根市の事例ではあまりはっきりしていないが、専決事項のアカウンタビリティ（説明責任、成果責任）もレスポンシビリティ（実行責任）も決定者の市長（行政組織）にある。これは議会の承認を受けても受けなくても変わらない。議会は市長の専決事項の実施をモニタリングする立場にある。議会が決定をする場合には、アカウンタビリティは議会にある。そして、決定事項のレスポンシビリティは市長を長とする行政組織にある。
本ブログは移転しました。こちらをご覧ください。
◆戦略の読み取りと戦略コミュニケーションの関係
第１１回で戦略は読み取るもという指摘をし、また、前回は戦略コミュニケーションの重要性を指摘した。この２つの指摘は、一方でちゃんと伝えよ、一方で考えよといっているようで、矛盾する。今回はこの謎解きをしたい。
最初にＰＭＢＯＫを見たときに関心をもったのは、統合マネジメントとプロアクティブという考え方である。プロアクティブという英語は、日本語でいえば、
・率先する
・先を見越す
といった意味である。ＰＭＢＯＫで統合マネジメントをうまく行うには、プロアクティブという考え方がキーになる。ＰＭＢＯＫを導入していても、統合マネジメントをうまく実現できている企業は決して少なくない。理由は、統合マネジメントがリアクティブになっているためである。
リアクティブは「反応的」、「反作用的」という意味だ。統合マネジメントをリアクティブに行うと、単なる問題解決に過ぎなくなる。ベースラインに何らかの問題が起こったときに、「反応的に」対処することに過ぎなくなる。
本ブログは移転しました。こちらをご覧ください。
◆ドラッカーのコミュニケーションの四原則
まず、ドラッカー。コミュニケーションについても多くの指摘をしているが、その一つにコミュニケーションの４原則というのがある。これが実に有用である。
原理１：聞くものがいなければコミュニケーションは成立しない
原理２：知覚を期待しているもののみを知覚する
原理３：受け手に対して何かを要求する
原理４：コミュニケーションと情報は別物である
本ブログは移転しました。こちらをご覧ください。
◆戦略はありますか？
セミナーなどでよく見かける光景。
講師「御社には戦略はありますか」
受講者「たぶんあると思います」
講師「例えば、どんなことですか」
受講者「あまり、明確に聞いたことがありません」
受講者は新入社員ではない。プロジェクトマネジャーやチームリーダーだ。
本ブログは移転しました。こちらをご覧ください。
◆はじめに
予定よりだいぶ遅れたが、やっとこの連載も復習モードから、新しい内容へと移っていく。
これまで、主に戦略整合など、ガバナンスの話をしてきたが、まず最初のテーマとして戦略的にプロジェクトを行うことの意味を考えてみたい。
◆問題提起
まず、最初に問題提起をしたい。あなたは、ＳＩプロジェクトの収益責任者（プロジェクトスポンサー）だとしよう。入札により新規顧客のシステム開発の案件を受託した。顧客が契約の際に、ＲＦＰに提示した以上の仕様の実現を要求してきた。さて、あなたはどういう対応をするか。
（１）開発予算を変えないことを前提に要求を受け入れる
（２）見積もり提案を楯にとって、拒否する
（３）顧客の意向に沿う再見積を提案し、仕様に見合う契約額を求める
（４）事業責任者の意向に沿う
（５）事業戦略に沿う
講演・研修でよくやるショートエクスサイズなのだが、どこの企業でも（３）と（４）が多い。メーカの場合には、ＳＩプロジェクトを商品開発に変える。
あなたは事業計画で承認されている新商品開発プロジェクトのプロダクトマネジャーである。事業計画では、商品の簡素化による新規市場の開拓を戦略として開発が承認されている。ところが、開発プロジェクトが始まると、営業部門が既存顧客への配慮を求めてきた。平たくいえば、既存顧客にも売りたいので、従来の機能を残したままで、新規の機能を追加した商品にすることを求めている。さて、あなたはどういう対応をするか？
（１）原価を変えないことを前提に営業の要求を受け入れる
（２）事業計画を楯にとって、拒否する
（３）営業の要求を聞き入れることを前提に予算の調整を行う
（４）事業責任の意向に沿う
（５）事業戦略に沿う
こちらの場合、（１）が多い。意図的には、ＳＩプロジェクトの場合と対応しているのだが、（４）はある程度いるが、（３）はほとんどいない。現実的にそうはならないからだろう。
最近のコメント