PMP：共通 のバックアップ(No.7)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PMP：共通 へ行く。
  • 1 (2018-03-17 (土) 20:03:05)
  • 2 (2018-03-19 (月) 20:36:26)
  • 3 (2018-03-26 (月) 19:42:46)
  • 4 (2018-03-28 (水) 21:38:09)
  • 5 (2018-03-29 (木) 21:39:07)
  • 6 (2018-03-29 (木) 22:05:51)
  • 7 (2018-04-03 (火) 16:11:20)
  • 8 (2018-04-03 (火) 19:24:32)
  • 9 (2018-04-04 (水) 18:16:22)
  • 10 (2018-04-04 (水) 19:34:02)
  • 11 (2018-04-05 (木) 19:31:12)
  • 12 (2018-04-06 (金) 20:27:37)
  • 13 (2018-04-10 (火) 21:22:07)
  • 14 (2018-04-16 (月) 20:46:58)
  • 15 (2018-05-07 (月) 21:02:21)
  • 16 (2018-05-24 (木) 12:59:38)
  • 17 (2018-05-24 (木) 17:08:24)
  • 18 (2018-05-24 (木) 19:26:38)
  • 19 (2018-05-24 (木) 21:33:35)
  • 20 (2018-05-25 (金) 16:13:36)
  • 21 (2018-05-25 (金) 19:47:26)
  • 22 (2018-05-30 (水) 15:58:54)
  • 23 (2018-05-30 (水) 20:03:05)
  • 24 (2018-06-01 (金) 22:01:41)
  • 25 (2018-06-05 (火) 19:32:26)
  • 26 (2018-06-06 (水) 21:58:41)
  • 27 (2018-06-13 (水) 18:52:14)
  • 28 (2018-06-13 (水) 21:46:28)
  • 29 (2018-06-15 (金) 21:06:05)
  • 30 (2018-06-20 (水) 19:14:39)
  • 31 (2018-06-21 (木) 09:04:50)
  • 32 (2018-06-25 (月) 13:29:06)
  • 33 (2018-06-30 (土) 20:38:59)
  • 34 (2018-07-13 (金) 19:34:24)
  • 35 (2018-07-14 (土) 15:52:04)
  • 36 (2018-07-14 (土) 21:14:13)
  • 37 (2018-07-18 (水) 00:51:12)
  • 38 (2018-07-20 (金) 21:11:50)
  • 39 (2018-07-30 (月) 20:17:23)
  • 40 (2018-07-31 (火) 23:14:11)
  • 41 (2018-07-31 (火) 23:17:28)
  • 42 (2018-08-01 (水) 20:36:48)
  • 43 (2018-11-06 (火) 16:30:24)
  • 44 (2018-11-20 (火) 19:40:59)
  • 45 (2018-11-25 (日) 21:36:41)
  • 46 (2018-11-29 (木) 20:46:00)
  • 47 (2018-12-18 (火) 18:53:34)
  • 48 (2018-12-22 (土) 20:11:39)
  • 49 (2018-12-23 (日) 15:56:57)
  • 50 (2018-12-23 (日) 21:11:51)
  • 51 (2019-01-22 (火) 13:06:43)
  • 52 (2019-01-22 (火) 14:32:02)
  • 53 (2019-01-24 (木) 13:38:24)
  • 54 (2019-01-27 (日) 15:51:38)
  • 55 (2019-02-10 (日) 19:20:09)
  • 56 (2019-02-10 (日) 21:54:20)
  • 57 (2019-02-11 (月) 17:33:39)
  • 58 (2019-02-11 (月) 21:19:10)
  • 59 (2019-02-27 (水) 12:37:35)
  • 60 (2019-02-28 (木) 15:30:06)
  • 61 (2019-03-10 (日) 16:37:18)
  • 62 (2019-05-10 (金) 14:15:04)
  • 63 (2019-05-20 (月) 10:01:46)
  • 64 (2019-06-18 (火) 17:56:21)
  • 65 (2019-08-03 (土) 14:06:10)
  • 66 (2019-08-04 (日) 18:51:52)
  • 67 (2019-08-10 (土) 15:25:26)
  • 68 (2019-08-12 (月) 16:21:15)
  • 69 (2020-01-18 (土) 20:37:00)
  • 70 (2020-03-12 (木) 10:01:45)
  • 71 (2020-12-11 (金) 14:22:20)
  • 72 (2021-10-01 (金) 16:29:25)
  • 73 (2021-11-15 (月) 17:06:47)
  • 74 (2022-01-09 (日) 15:15:14)
  • 75 (2022-04-26 (火) 10:20:53)
  • 76 (2022-06-15 (水) 19:57:50)
  • 77 (2022-07-22 (金) 11:02:30)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

プロジェクトの定義 †

プロジェクトか？定常業務か？ †

独自性 †

プロジェクトの存在理由は、今までなかった所産を産み出すこと。

• 所産

• プロダクト
  • コンポーネント

• サービス
  • コンサルティング
  • プロジェクトマネジメント
  • 組織を支える機能
  • 調査研究の結果

• 段階的詳細化
  • 初期段階：大まか
  • 完了に至るまで段階的に詳細化される。

有期的 †

有期的（開始日・終了日がある）。

• 完了
  • ステークホルダーの目的・目標の達成により完了する。
  • 目的・目標の達成が不可能な場合にも完了する。
  • 若しくは、必要性が無くなった場合にも完了する。

マネジメント・スキルの差異 †

• 定常業務
  • サポート
    • ライン監督
    • 小売部門
    • コールセンタ

• プロジェクト
  • プロジェクト・マネジメント
  • 人間関係
  • 計画・組織化

ライフサイクル †

• プロジェクトがプロダクト・ライフサイクルの終了段階までに及ぶ。
• プロジェクトが定常業務化するので、プロジェクトに定常業務の要員を入れる。

ステークホルダー †

• プロジェクトに利害関係を持つ人や組織
• ステークホルダーの特定は１回だけではなく、常に問い続ける。

例 †

• プロジェクト・スポンサー
  • 意思決定者
  • エスカレーションの受け手

• バリュー・チェーン
  • 顧客
  • コントラクター
  • サプライヤー

• プロジェクト
  • マネージャー
  • チーム・メンバ
• 定常業務要員

コンフリクトの解消 †

• 早期に主要ステークホルダーを特定しニーズと契約条件を理解する。
• 利害関係の不一致の解消に努める。優先順位は顧客を最大にしておく。

特性 †

独自性 †

期限 †

完了の判断材料 †

ステークホルダーの期待に応えたかどうか。

満足度を測る手段 †

ステークホルダーの期待は計画プロセス中で文書化される。

• 成果物
• 要求事項

マネジメントの定義 †

プロジェクト †

プロジェクト・マネジメント †

プロダクト、サービス、所産の引き渡し。

• 例 プロジェクト・アクティビティ（プロセス）の集合体を、
  PMI承認のプロジェクト・マネジメント・プロセスに従って
  • 記述・体系化する。
    プロジェクトとチームを体系化。
  • 監視する。
    知識・スキル、ツール・技法を適用。

プロジェクト・マネージャー（PM） †

• プロジェクトは有形・無形の所産を産み出し、この所産は事業に価値を高める。

• この所産を産み出すための要求事項を満たすために、
  プロジェクト・アクティビティ（プロセス）に、
  プロジェクト・マネジメントンの知識・スキル、ツール・技法を適用する。

• マネジメントの対象には以下が含まれる。
  • プログラム・マネジメント
  • ポートフォリオ・マネジメント

• 以下のようなスキルが必要になる。
  • マネジメントのスキル

• それ以外にも以下のようなスキルが必要になる。
  • 知識
    マネジメント技法に関する知識
  • 執行能力
    PMーとしての役割を遂行する能力
  • 人間性
    リーダーシップを発揮する能力/態度/倫理観などの行動特性

プログラム †

• 関連プロジェクト、サブプログラム、サブプロジェクト、作業グループ。
• 類似のプログラム・マネジメント技法を使って調和がとれるようにマネジメントされる。

例 †

生活・仕事・ショッピングが揃った職住一体型団地のプログラム

• プログラム
  • 各エリアの設計と設置
  • マーケティング
  • 施工管理

• 体制
  • ヘッド PM
  • サブ PM

プログラム・マネジメント †

• 領域
  • （プログラムの）相互依存関係
  • （プログラムの）集合体のマネジメント

• 例
  相互依存関係の規定と制約条件の調整
  によるプログラム間の問題の解決。

ポートフォリオ †

• 事業ポートフォリオ（その会社のやっている事業の集合体・一覧）のプロジェクト版
• プロジェクトに関連する事業（定常業務）・プロジェクト・プログラムの集合体・一覧。

例 †

• 事業（定常業務）・プロジェクト・プログラムの部分
• 会社の部分（部署、事業部）
• ステークホルダーの部分（・・・）

これらが、ポートフォリオ全体の戦略的目標を達成することが目標。

ポートフォリオ・マネジメント †

ポートフォリオ全体の戦略的目標を考慮した事業・プログラムの集合体のマネジメント

• 領域
  • 目標達成の効率性（範囲）
  • 時間、原価/資源、リスク

• 例
  • プログラムの評価、取捨選択、リソース確保などによるバランス調整。
  • プログラムが全体の戦略的目標を順守しているかの監視。

PMO：Project Management Office †

• 組織のプロジェクト、プログラムのマネジメントを監督する集権的な組織。
• COE（Center Of Excellence）とも呼ぶ。

目的 †

• プロジェクト・マネジメントの方法論・手順などの標準を確立・維持する。
• OPM：組織プロジェクトマネジメントの枠組みを確率。
  • プロジェクト、プログラム、ポートフォリオが一貫性を持ってマネジメントさせる。
  • また、これが組織全体の目標を支えるものになっていることを保証する。

• パフォーマンス向上と競争上の優位性維持のため、組織的実務敢行を横断する。
  • 人的資源（調達）
  • テクノロジー（生産技術）
  • 文化（スキーム再検討）

• PMの支援

• 確立されたプロジェクトマネジメント方法論の提供
  • 標準
  • フォーム
  • テンプレート

• PMに対する
  • 助言
  • 指導
  • トレーニング

• プロジェクト内・外のコミュニケーションの促進
• 資源のマネジメント

スコープ・責任 †

• 傘下のプロジェクトの
  • 文書の維持・保管
  • 目標と進捗のパフォーマンス監視
    • 目標のマネジメント
    • 是正措置を提案
    • チームやステークホルダーにフィードバック

• プロジェクト横断の
  • 資源のマネジメント
  • 依存関係のマネジメント
  • 戦略的目標に合わせた調整

• 完了後の評価
  • 期限内に完了したか？
  • 予算を超過しなかったか？
  • 品質は適正だったか？

PMOの組織タイプ †

PBO：Project-Based Organization †

• プロジェクト作業実施のための一時的な体制。
• 組織の政治力や地位などの体制上の影響を無視できる。
• 最終的な所産の成功の度合いをPBOが測定する。

マネジメントのスキル †

• スペシャリストではなくジェネラリスト、問題解決者。
• スペシャリストをチームに入れ、必要に応じてスペシャリストに頼る。

一般的スキル †

• 会計
• 戦略的計画
• 監督
• 人事管理

適用分野のスキル †

分野 †

• 業種（自動車、医療、日式SI）
• 部門（会計、マーケティング）
• 技術（ソフトウェア開発、工業技術）
• マネジメント専門分野（調達、研究開発）

関係 †

適用分野のスキルは以下に関係する。

• プロジェクト
• （特定の）ニーズ
• 顧客・業界の規範・法規

例 †

• 調達規則（政府系 <---> 建築系）
• 法規　　（医薬品 <---> 自動車）

人間関係スキル（ソフト・スキル） †

コミュニケーション †

• 方法
  • 書面
  • 口頭

• プロジェクト・コミュニケーション
  以下を明確/明瞭/完全なものとして作成・管理
  • プロジェクト文書
  • 会議の議事録
  • 状況報告書

組織化/計画スキル †

• 組織化

• トラッキング
  • プロジェクト文書
  • 要求事項情報
  • メモ
  • プロジェクト報告書
  • 人事関連の記録
  • 業者の見積書
  • 契約書
  • その他の情報

• その他
  • 会議の開催
  • チームの編成
  • メディア発表のスケジュールの作成・管理

• タイム・マネジメント・スキルと関連

• 計画

タイム・マネジメント・スキル †

物事を整理された状態に保つため優先順位を決定する。

• 問題
• 突発的作業
• 定常的業務

コンフリクト・マネジメント・スキル †

コンフリクト・マネジメントでは問題を解決する。

• 問題の定義

• 二段階プロセス
  • 症状を見る。
  • 原因を特定する。

• 定義の方法
  • 内部 or 外部の問題か？
  • 技術的な問題か？
  • 人間関係の問題か？
  • マネジメントの問題か？
  • 影響や結果の大きさや範囲

• 対策の決定・実行

交渉力/影響力スキル †

• 交渉力スキル
  • スコープ定義
  • 予算交渉
  • 契約交渉
  • 資源関連の交渉
    • 獲得
    • 割り当て

• 影響力スキル

• 人の手を借りるスキル

• 影響力の行使
  以下の理解が必要になる。
  • 組織の公式的な構造
  • 組織の非公式的な構造

• 権力/政治力
  • 権力は人に否応なく何かさせる能力。
  • 政治力は利害関係（対立・混乱）を創造的に協力させる能力。

リーダーシップ・スキル †

• ビジョン、意欲、合意、方向性の確立

• リーダーとマネージャー
  • リーダー≠マネージャー
  • リーダー <---> マネージャー（切り替える）

チーム形成/動機付けスキル †

• チーム形成
  • 方向性
  • 発達段階の手助け

• 動機付けスキル
  • 長期、障害が多いプロジェクトで重要になる。
  • 配下に無いチームメンバの動機付けも必要になる。
  • 方法
    • 機能部門マネージャに依頼してプロジェクト・チーム・メンバの
      パフォーマンス・レビュー（ = 評価の事）に参加させてもらう。

組織構造 †

理解する意味 †

影響 †

組織構造に依存する

• スタイル
• 文化
• コミュニケーション

がプロジェクトの実行・結果に影響を与える。

見極めの方法 †

上級管理職がPMへ権限委任する度合い。
（様々なレベルのマネジメント層とのやり取りによって決まる）

• 権限
  • 権限レベル、役割
  • リソース利用可否
  • 予算管理
  • チーム編成

• 以下の影響を受ける
  • 組織の構造
    連略レベル、中間レベル、定常業務レベルのマネージャーと連携
  • 組織のプロジェクト・マネジメント成熟レベル

機能型組織 †

• 最古、伝統的手法
• 専門分野（機能）で形成（グループ分け）
• 階層型構造を持つ（CEO -> 部長 -> 課長 -> 担当）
• 命令系統が存在、逸脱しないように注意が必要になる。

人的資源 †

• 似通ったスキルと経験
• 効率的で簡単
• キャリアパスが明確

欠点 †

• PMにとっての欠点
  • 公式の権限をほとんど持てない。
  • プロジェクト・リーダー / 調整者 / 促進者のレベル
  • 実際の権限を持っているのは、部長

• 対人関係スキルが重要になる。
  • コミュニケーション・スキル
  • 交渉力/影響力スキル

マネジメント †

特徴

• 分離型の手法でプロジェクトが遂行される。
  • 例えば、プロジェクトがマーケティング ---> 製造という工程を持つ場合、
  • プロジェクトの工程は、マーケティング部から製造部へリレーされる。
  • 各工程は、以下のように（部門毎に）呼ばれる。
    • マーケティング・プロジェクト
    • 製造プロジェクト

• プロジェクト全体ではなく、機能部門の階層に忠実
  • 機能部門のマネージャーにパフォーマンス・レビューの責任があるため。
  • 経験を積む機会はプロジェクト・チームではなく自機能部門にあるため。

• リーダーシップを駆使
  • 共通のビジョンの形成、プロジェクト・チーム・メンバの意欲をかき立てる。
  • 機能部門マネージャに依頼してプロジェクト・チーム・メンバの
    パフォーマンス・レビュー（ = 評価の事）に参加させてもらう。

プレッシャー（資源） †

資源とプロジェクトの優先度を巡る競争が激化することがある。

• 例：複数の部門が同じ資源を奪いあうプロジェクト要求を出す。

• 対策：外交能力
  • ステークホルダーの賛同を得る
  • 問題を避けるためコミュニケーション

プロジェクト型組織 †

• 機能型組織の対極にある。
  • 組織の中心は機能部門ではなくプロジェクト。
  • 組織の資源は、プロジェクトとプロジェクト作業にのみ投入される。

• CEO直属のPMに絶対的な権限がある。
  • 内・外の資源の獲得と割り当て

• プロジェクトに関する決定
  • ・・・
  • 制約条件の代替案

人的資源 †

• チームが形成されると、コロケーション（同床化）される。
  • 機能部門のマネージャーではなくPMの配下に置かれる。
  • 支援機能部門もPMに直属することがある。

• 忠誠心は機能部門ではなくプロジェクトを中心に形成される。
  • PMにパフォーマンス・レビューの責任があるため。
  • 経験を積む機会はプロジェクト・チームにあるため。

欠点 †

• プロジェクト完了後に解散する。

• このため、人的資源の活用に非効率性が存在する。
  • 仕事がない期間がある。
  • 解雇 / 再雇用は容易ではない。

• 計画時に非効率性（遊休時間）を最小化するよう、
  プロジェクト・メンバのスキル / 能力の把握が必要になる。

マトリックス型組織 †

• 機能型組織とプロジェクト型組織の、
  利点の最大化、欠点の最小化のために誕生した。

• 機能部門に干渉されずに、プロジェクトとプロジェクト作業に専念できる。
  • プロジェクト・マネージャ
  • プロジェクト・チーム

人的資源 †

１人の機能部門のマネージャーと１人以上のPMの配下に置かれる。

• 機能部門のマネージャー
  • プロジェクトに対する人的資源の
    • 見積
    • 配属
    • 作業監視。
  • パフォーマンス・レビューの責任を持つ。

• PM
  • 人的資源の見積・配属を機能部門のマネージャーに依頼する。
  • プロジェクト・アクティビティに対する人的資源の割り当てを行う。
  • パフォーマンス・レビューの責任を持つ。

力の均衡 †

強いマトリックス型 †

• 横串にPM専門組織がいて、プロジェクトをPMが纏める。
• マトリックス型だが、PMが強い。

パランス・マトリックス型 †

• 横串に機能部門が立って、中心となる機能部門の担当がPMを務める。
• 機能部門のマネージャーとPMが均衡している。
• 人的資源はニーズによって配属される。

弱いマトリックス型 †

• 横串に機能部門が立って、中心となる機能部門の担当がリーダー / 調整者 / 促進者を務める。
• 機能部門のマネージャーに権限があり、リーダー / 調整者 / 促進者にはほとんど権限が無い。

ライフサイクルとプロセス †

プロジェクト・ライフサイクル（フェーズ） †

概要 †

• プロジェクトには段階的詳細化など、フェーズがある。

• 基本的には、以下の形で構成される。
  • 開始：プロジェクトの開始
  • 計画：組織編成
  • 実行：作業実施
  • 終結：プロジェクトの終結

• ITでいえば、要件定義 -> 設計 -> 実装 -> テスト

• フェーズの集合がライフサイクルになる。

ライフサイクル区分 †

• 予測型サイクル（完全計画駆動型手法、ウォーターフォール型）

• スコープ
  • 開始時の早い段階で定義され、スケジュール・予算も決定される。
  • 変更は、入念に監視される。変更の際は、
    プロジェクト・マネジメント計画書の見直しと承認を行う。

• フェーズ
  • フェーズ作業は明確に区分され、繰り返されない。
  • 各フェーズでは、プロジェクト・アクティビティの異なる部分が強調され、
    それぞれ、異なるプロジェクト・マネジメント・プロセス群が実行される。

• 反復型、漸進型ライフサイクル

• 成果物
  • 開始時の早い段階で定義される。
  • 段階的詳細化により、次第に完成度を増す。
  • これに伴い、スケジュール・予算も詳細化される。

• フェーズ
  • フェーズ作業は繰り返される。
  • 各フェーズでは、全プロジェクト・マネジメント・プロセス群が実行される。

• 適合するプロジェクト
  • 大規模、複雑
  • 目標やスコープが不明確
  • 成果物の段階的引き渡しが必要

• 適用型ライフサイクル（アジャイル手法、変化駆手法）
  • 成果物
    • 反復型、漸進型ライフサイクル的
    • より短い期間（2-4週間）で成果物を生成する。

• フェーズ
  • 成果物の審査・承認を通して、フェーズ作業を繰り返すか次へ進むか判断する。
  • 各フェーズでは、全プロジェクト・マネジメント・プロセス群が実行される。

• 適合するプロジェクト
  • 要求が不明確で変化する場合。
  • ステークホルダーの積極的参加が必要な場合。

フェーズの完了 †

成果物を生成し、検証・承認する。

• 成果物
  • 独自かつ検証可能なもの。
  • 有形 or 無形のもの。

• 例
  • 予算
  • スケジュール
  • 設計書
  • プロトタイプ

• 検証・承認（フェーズ終了時レビュー）
  • レビューにて誤りを発見し是正処置を実施する。
  • 次のフェーズへ進むかどうか判断する（引き渡しと別？）。
  • 別名（PMBOK?）
    • フェーズ・レビュー
    • フェーズ・ゲート
    • ステージ・ゲート
    • マイルストーン
    • 中止点

引き渡し（技術移管） †

• フェーズ間の繋ぎの部分。
• 成果物を見て次フェーズに進むかどうか判断する。

• 例：開始フェーズでフィージビリティスタディ（PoC）
  実行可能性調査 / 企業化調査 / 投資調査 / 採算性調査（概念実証 / 実証実験）
  • プロジェクト遂行の価値があるかどうか。
  • 組織に利益をもたらすかどうか。
  • 所産が業界の標準や法規を満たすかどうか。

マルチフェーズ・プロジェクト †

• 複数のフェーズから構成されるプロジェクト

• フェーズ間の関係
  • 直列関係：フェーズ完了後に次フェーズが始まる。
  • 重複関係：フェーズ完了前に次フェーズが始まる。

• ファスト・トラッキング
  • 重複関係により期間を短縮する。

ライフサイクルの特徴 †

• 段階的詳細化
  • チーム・メンバとコスト
    • 開始時点では、チームメンバも少なく、低コスト。
    • 進行するにつれて、チームメンバ、コストが増加。
  • 成功率とリスク
    • 開始時点の成功率は低いが、進行するにつれ成功率が高まる。
    • 開始時点のリスクは高いが、進行するにつれリスクが減少する。

プロジェクト・マネジメント・プロセス †

概要 †

• プロセス群
  プロセスの作業を体系化するPMBOK?ガイドに記載された5つのプロセス群

• 立上
  • プロジェクトの開始時や、大規模プロジェクトのフェーズ開始時
  • 開始の承認：リソース投入の承認、PMによる作業開始の許可。
  • アウトプット：プロジェクト憲章、ステークホルダー特定

• 計画
  • 各プロセス群のプロジェクト・マネジメント計画書の作成
  • 各知識エリアを考慮し、要求事項の明確化、最適な代替措置の選択、ステークホルダーの特定を行う。
  • アウトプット：各プロセス群のプロジェクト・マネジメント計画書
    テーラリング：小規模プロジェクトなどで、プロジェクトに適合するプロセスを判断し、実際に実行するかどうかを決める。

• 実行
  • 目標達成のためプロジェクト・マネジメント計画書に従いリソースを調整・分配。
  • 最も多くの時間と資源を使用する。対立の経験。承認された変更の実施。
  • アウトプット：プロダクト、サービス、所産

• 監視・制御
  • 計画どおりか作業を追跡（トラッキング）し、パフォーマンスを測定・分析する。
  • 「問題の特定」と「是正措置の実施」（アクティビティを再計画、再実行する）。
  • アウトプット：是正措置の実施

• 終結（中止された場合にも実行される）
  • 省略されることも多いが、プロジェクト情報の収集は重要。
  • ステークホルダーの公式の承諾・承認が得られる。
  • アウトプット：収集されたプロジェクト情報の文書

特性 †

※ 1, 2のリソースは実行時が最大
※ 3, 4, 5は、立上 → 終了に向けて大きくor小さくなる。
※ 5のステークホルダーの影響力は、要求事項を決める迄が最大。

フロー †

※ 監視・制御によって計画・実行が反復的に行われる。
PMBOK?では「反復的なプロセス」と呼ぶ。

※ IPECC : Initiating, Planning, Executing, Controlling, Closing.

その他 †

コミュニケーション †

量 †

業務全体の90%

スキル †

• PMに最も重要なスキルとされる。
• 交渉力、影響力、問題解決より重要
• 上記の全てのベースとなるため。

制限があった場合 †

それを覆さず、別の選択肢を模索

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.261 sec.