プロジェクトマネジメント(PMBOK) | ミニミニ管理者(プロジェクトマネージャ/システム管理者/社内SE/CIO)の独り言

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > 世界一わかりやすいプロジェクトマネジメント ]
スポンサードリンク

世界一わかりやすいプロジェクトマネジメント

本書は当社での社内大学情報システム学部プロジェクトマネジメントコースのテキストや経験豊富なPMPホルダーによるプロジェクトマネジメント講習会でも必読書として紹介されている書籍です。





これまで、一般的な企業(事業会社等)では、ベンダにシステム構築を丸投げしていませんか?


また、自社で開発している企業でも、中小のITベンダでも、


「名ばかりのプロジェクトマネジメント」


ではありませんか?


これらにより、引き起こされるのは「開発したシステムが稼働しない・バグ多数」「要望通りの機能ではない・業務では使えない・機能要件にマッチしない」などです。


要は無駄な投資になる。ことです。


まだまだ、一般企業の情報システム部門では取り入れ出来ていない・受け入れ出来ていない・正しく活用出来ていないのは、プロジェクトマネジメントの必要性や使い方への理解が足りていないことです。ここで今一度、必要性について再認識してもらう必要があると思っています。


その点でも、この「世界一わかりやすいプロジェクトマネジメント 第4版」は、プロジェクトマネジメントの必要性を分かりやすく説いている優良書といえます。また、PMBOKガイドでは理解しにくい表現(英訳が分かりにくい)も多く読みにくい印象ですが、本書は読みやすい表現になっているため、PMBOKガイドを読む前に「PMBOKの概要」や「プロジェクトマネジメントとは」を理解するのに適しています。


これからPMBOKを勉強する人やプロジェクトマネージャを目指す人は必読・必携です!


なお、実践でも役立つ経験則やらヒューマンスキルなどもフォローしています。



以下、出版社(総合法令出版)のホームページより抜粋。

内容紹介

アマゾンジャパン「オールタイムベストビジネス書100」に選ばれた名著の最新版!

  プロジェクトマネジメントとは、「ヒト」「モノ」「カネ」を適切に管理し、プロジェクトを納期どおりに完成させ、かつ想定したどおりの利益を生み出す活動のこと。そのテキストとして世界中のプロから推薦を受けている「Idiot’s Guides, Project Management」の最新バージョンの日本語訳版がついに登場。
 プロジェクトマネジメントの各フェーズごとに、想定されるリスクを乗り越えて成功に導くための具体的ノウハウやツールを紹介。また、プロジェクト・マネジャーとしてチームを率いていくためのアイデアを実践的に提供する。
 プロジェクトマネジメントのデファクトスタンダードである「PMBOK」の最新第5版に完全準拠しているので、グローバルなプロジェクトにも対応。アマゾンジャパンが昨年10月に選出した「オールタイムベストビジネス書100」の中で、プロジェクトマネジメント関連で唯一選出された、プロジェクトマネジメントの基本中の基本書である。



目次

パート1 プロジェクトマネジメントの威力
パート2 プロジェクト定義フェーズ
パート3 プロジェクト計画フェーズ
パート4 プロジェクト実行フェーズ
パート5 監視とコントロール・フェーズ
パート6 プロジェクト終結フェーズ
付録
巻末資料





スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > RACI(レイシー)チャート/PMBOK ]
スポンサードリンク

RACI(レイシー)チャート/PMBOK

RACI図やRACIチャート、レイシーチャートをご存知だろうか。プロジェクト経験者なら感じていることだが、プロジェクトはある一定の期間にて独自の成果物を生み出す活動ですが、その間には工程が変わることでプロジェクトメンバーが交代/入れ替え、入場退場が繰り返されます。また、工程の切り替わりでチームの交代/引き継ぎ(企画から開発、開発から運用)なども、それにあたります。


このような状況での課題解決をイメージしてみて下さい。その都度、その都度で状況がかわり、「誰に何を聞いたら解決するか?」といった単純なことで時間を費やすことが多いです。その解決策として、RACI図(RACIチャート、レイシーチャート)は使えます。


RACI図やRACIチャート、レイシーチャート


RACI図(英: RACI diagram)は、プロジェクトや何らかの工程をチームあるいは人々に役割分担させる際に使用される図の一種である。複数の組織が共同で行うプロジェクトマネジメントなどで、役割分担を明確化するのに特に有効とされる。RACIチャートとも。


プロジェクトの各タスクについて、関係者がどのような役割を担っているのかを明確にするために使われます。



RACI図は、タスクを4種類の参加者の責任型に分割する。また、プロジェクトや工程毎に各参加者には異なる役割が割り当てられる。この責任型の名称の頭字語が RACI である。

Responsible(実行責任者) - タスク達成のために働く責任者。複数のリソースについて責任を持つことがある。


Accountable(説明責任者) - タスクの正しい完了について外部からの問合せに対して責任を持って対応する。各タスクの窓口は1つでなければならない。


Consulted(協業先) - 意見を求められる者。双方向の対話。


Informed(報告先) - 進捗を常に把握している者。一方向の通信。


Consulted(協業先) - 意見を求められる者。双方向の対話。


Informed(報告先) - 進捗を常に把握している者。一方向の通信。


実行責任者と説明責任者は同一の人間に割り当てられることが多い。それ以外では、一般にプロジェクト管理の各タスクについて、各参加者が高々1つの役割を割り当てられるのが推奨されている。


しかし、企業や組織によっては、1人に複数の責任型を割り当てることもある。これは、役割が計画時点で決められないことを暗に示しており、各タスクにおける役割分担を明確化するというRACI図の価値を減じることになる。


RACI図は、タスクと参加者を並べた2次元の表の形式であり、各マスがタスクと参加者の組合せを表している。そして、各マスに R/A/C/I の責任型を割り当てていく。何も割り当てられないマスもあるし、1つのタスクに4つの責任型が揃わないこともある。

(Wikipediaより抜粋)









スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクト目標の設定基準 ]
スポンサードリンク

プロジェクト目標の設定基準

プロジェクト目標を設定する際に気を付けるべき基本的な基準をあげると次の6つがあげられます。

プロジェクト目標の設定基準


ゞ饌療である
現実的である
4限が区切られている
ぢ定できる
ス膂佞取れている
責任の所在が明確である


ここで、それぞれの基準について、具体的に掘り下げます。



設定基準 具体的である


プロジェクト目標は具体的に設定する必要があります。これは、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクト</a>が、ある程度の期間をようすなら、途中入場するメンバーがいます。途中入場するメンバーは、当然ですが、プロジェクト発足当初に行う目標設定に参加できません。それでも、彼らがそれぞれの役割(ロール)を引き受けることになった時に最初に確認するのが、プロジェクト計画書に記載される「<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクト目標</a>」になります。


そこで、彼らが自分たちの役割を正しく理解して行動するため、またプロジェクトを進行していくうえで迷った際の拠り所として、このプロジェクト目標が具体的であることで正しく判断するためにも具体的であることが大切です。


なお、補足ですが、プロジェクト目標は関係者にウォークスルーによるレビューしてもらい、指摘事項を反映することも必要です。


これは、読み手・受け取る側が、自分自身の思惑と違う解釈をすることもあり得るからです。


そして、レビュー結果を元に「万人に伝わる」文章や言葉を選びブラッシュアップすると、さらによい仕上がりになっていきます。

設定基準 現実的である


プロジェクトの目標は達成可能であるのか、努力すれば達成可能な範囲(ストレッチ目標)である必要があります。


たとえば、コストに関する目標で、開発コストが1億円かかると試算されているのに予算が8,000万円しかなかったらどうなるでしょう?


・スコープを削る(スコープアウト)

・予算の調達(増額)

・価格交渉する


といった活動が必要になり、実際の要件への活動に着手できません。

また、予算はプロジェクトマネージャ/PMが果たすべき責任(QCD)のうちC:コストに当たり、これが達成できないことはプロジェクトマネージャとして致命的です。


それにコストは制約事項となることも多く、簡単には予算調達は達成出来ないでしょう。


そのため、現実的な目標が必要となり、この例では開発コスト1億円に対し、予算も1億円であるべきです。

※得てして予算は足りなくなることも多いです。最初から足りてないのは危険です。

設定基準 期限が区切られている


プロジェクトとは、定常業務と異なり、期限≒有期性があります。


そのため、プロジェクト計画書にはマスタースケジュールがあり、ここには、明確な期限(プロジェクトの開始日と終了日)が設定されています。


ここで、よくあるのは、「無理な短納期を要求」されて、プロジェクトに無理に負荷をかけてしまうことです。


無理なスケジュール設定はリスクが高く、無理をした結果、期限を守れずリスケ(プロジェクトの延期)を招くことも多い。

設定基準 測定できる


プロジェクトの目標達成の度合いは測定できなくてはなりません。


プロジェクト活動は独自の成果物を作成することであり、進捗や品質、コストを測定出来ないと<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント</a>は出来ない。


以下の項目は順次更新します。

設定基準ァЧ膂佞取れている

設定基準ΑЮ嫻い僚蟶澆明確である


なお、実際に目標設定する際の手順について、次のポイントに注意して行います。


〔槁犬鯀瓦得い出す。
直接関係ない目標は外す。
最終目標でないものは外す。
ち綾劼泙任離廛蹈献Дト目標の6つの基準に合致・達成可能であるかを判断し、切り離し・除外する。


重要ポイント:

上記の行程で除外した項目をリスト化して、経営層に「何の項目を除外したのか?」を明確にして報告・判断を仰ぐ。











スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > 有能なPMに求められる7つの資質 ]
スポンサードリンク

有能なPMに求められる7つの資質

ある<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント(PMBOK)</a>に関する本に「有能なPMに求められる7つの資質」が記載されていたので当方の経験や解釈を含めて以下にまとめる。


PMBOKの10の知識エリアにコミュニケーションマネジメントがあるが、プロジェクト&プログラムマネジメントにおけるプロジェクトマネージャもプロジェクトメンバーも人対人の繋がりからくるもの。


最終的にプロジェクトマネージャに求められるものは、技術力ではなく「ヒューマンスキル」ではないだろうか。


勿論、リーダーシップを発揮するには経験や技術力などに裏付けられた、「為人(ひととなり)」によるところも大きい。

しかし、気を付けるべきポイントがあれば気にしておきたいもの。


有能なPMに求められる7つの資質


1プロジェクトへの情熱
2変更管理の能力
3曖昧さへの耐性
4チーム育成と交渉スキル
5顧客第一の志向
6ビジネス優先課題の堅持
7業界と技術の知識



資質1 – プロジェクトへの情熱


有能なプロジェクトマネージャは高い成果を目指します。プロジェクトマネージャの情熱はチームメンバーに浸透して、プロジェクトへの積極的な参画意識を高めます。

そのため、プロジェクトマネージャはプロジェクトメンバーはもとよりステークホルダーと接する際にも情熱を持ってコミュニケーションを取ることが重要です。

資質2 – 変更管理の能力


プロジェクトには変更がつきものです。顧客が最終成果物についての考えを変える、外的要因によりマネージャーがスコープ変更を決める、チームメンバーのスケジュール遅延により見直しが必要になるなどの変更が多々あります。プロジェクトマネージャは変更管理の手法を身につける必要があります。


変更を管理するため、変更の発生タイミングで変更管理簿に記録し、プロジェクトマネージャの承認により受領とする。


その後、実施に向けては、変更委員会やステコミ等の決定機関にて、スコープ外(予算外案件)に対する調査や実施の可否を上申し、判断/意思決定を申請します。この意思決定機関にて変更管理として起案されたスコープ外案件に対して、承認/合意を行い了承された案件を実施します。


<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクト管理</a>ではどんな小さなものでもサプライズ的な出来事がたくさんあります。このサプライズ的な出来事に対応する能力とその出来事がもたらす変更に対応する能力が必要になってきます。


しかし、プロジェクトスポンサへの報告でサプライズがあってはなりません。スポンサへは小まめな報告が肝要です。

資質3 – 曖昧さへの耐性


組織論の話になります。組織論と聞くと難しそうですが、一般的な会社を想定して例示して説明します。


一般的な事業会社を想定して例示


一般的な会社の組織構成は、中小規模であれば「機能別組織」が多く、社長の配下に本部/部といった部署が連なり、これらは営業や人事、会計などに機能別に配置されます。

このような、会社にてシステム構築プロジェクトが発足するとシステム構築対象となる業務の担当がアサインされプロジェクトメンバーとなります。


プロジェクトメンバーは、機能別組織での定常業務に加え、プロジェクトメンバーとしての仕事が発生します。


そのため、機能別組織での上司からの指示の他、プロジェクトマネージャやリーダーからのタスクの依頼に応えます。このように指示命令系統が2つに分かれる組織形態を「2ボスシステム」と言います。


ここで、一般的な会社でプロジェクトを推進することは、2ボスシステムが採用されることになります。


そのため、プロジェクトマネージャーの権限があいまいになってしまいます。


プロジェクトの真っ最中だとしても、プロジェクトメンバーには指揮命令を受ける上司が別にいて、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネージャ</a>に従ってくれないという場合もあります。大きなプロジェクトだとしても役割分担を明確に決めていることは、実際には少ないのが実情です。


メンバーの中に、プロジェクトマネージャーより職位の高い人がいたり、顧客がプロジェクトメンバーとしてしゃしゃり出てきたり、他部門がプロジェクトに特別な利害を持っていたりと様々なケースがあります。


有能なプロジェクトマネージャーは、こうした役割のあいまいさや、例外事項を適切に処理していかなくてはなりません。権限が全て明確になっていて、計画に一切変更がないのであればよいのですが、実際の世界ではそういうことはありませんし、変更のないプロジェクトはありえません。


ちなみにこの曖昧さを回避するには、プロジェクトオーナーを経営者(社長クラス)とし、トップダウンで進める会社の姿勢とプロジェクトメンバーの評価にはプロジェクトマネージャの意見を組み込む(目標管理の内容にプロジェクトの業務を組み込む)などの方策があります。


資質4 – チーム育成スキル


プロジェクトマネージャーは、プロジェクトを通じて得る経験を元にプロジェクトメンバーを育成していくことが求められます。


プロジェクトメンバーにとっては定常業務とは異なり、経営者や他の部門と一緒に仕事をしたり、現状の業務を掘り下げて効率化する策を講じたり、今までにない経験が出来ます。また、幅広いステークホルダー(経営陣、顧客、チームメンバー、サプライヤーなどのたくさんのステークホルダーとの連携)とのコミュニケーションによりスキルも磨かれるでしょう。


プロジェクトマネージャはプロジェクト目標にプロジェクトメンバーの育成を入れることをお勧めします。このプロジェクトに参加することで、どのようなスキル(IT技術だけでなく、会計・労務・販売・購買など)や経験(マネジメント・リーダーシップ、コミュニケーションなど)を身に付けることができ、またどのような業務知識や業界知識を得られるか。プロジェクトに参加する魅力を伝えることで、メンバーは前向きになり、能動的に活動してくれるようになるでしょう。



資質5 – 顧客第一の志向


有能なプロジェクトマネージャーは顧客を第一に考えて、顧客の見方を理解しようとします。それは、プロジェクトの成功の評価をするのは顧客だからです。そして、その顧客の評価はプロジェクトの成果に対する「顧客満足度」となります。


ここで、気を付けるべきは、「顧客が本当に必要だったもの」をキチンと見極める必要があります。


そのためには、広い経験や高いIT技術/スキルは最低限というか、当たり前の範囲であり、顧客視点にたつために以下のような知識を保有する必要があります。

※顧客視点≒経営視点


・経営管理

・財務、会計知識

・マーケティング

・経済

・ビジネス法務

・業界知識


IT風刺にある「顧客が本当に必要だったもの」のようにならないように注意しましょう!


そのためには「顧客第一の志向」を忘れずに!


資質6 – ビジネスの優先課題の堅持


ビジネスの課題を解決出来ないプロジェクトは実施する意味がありません。


予算やコストはビジネス志向から見たらほんの一部にすぎません。それ以外のビジネスの優先課題としては、ビジネスの有効性、競争優位性の確保、プロジェクトの組織全体への統合、ステークホルダーの課題解決、プロジェクトの進捗状況に沿った生産性の向上などが挙げられます。


資質7 - 業界と技術の知識


プロジェクトマネージャに求められる知識に業界知識と技術知識があげられます。


これは、顧客第一の志向でも述べましたが、技術知識は持っていて当たり前です。プロジェクトマネージャは専門家ですから。


また、顧客視点≒経営視点で考えることが出来ないと顧客が本当に必要だったものがわかりません。


そこため、顧客と同等の業界知識と、専門性のある技術知識を併せ持つプロジェクトマネージャは顧客からの信頼を得ることができ、顧客の経営層からも評価されるでしょう。







スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトマネージャに求められる品質管理とは ]
スポンサードリンク

プロジェクトマネージャに求められる品質管理とは

品質管理は、プロジェクト&プログラムマネージャ(P2M/PM)の使命であり、QCDを果すのにプロジェクトマネジメントが必要ですね。


このQCDを果すとは、「納期通り、与えられた予算内で、要求される品質を達成する」ことです。


また、余談ですが、このQCDにSをつけた「QCDS」だとScope/スコープが追加され、「設定したスコープを納期通りに与えられた予算内で、要求される品質を達成する」となります。


ここでは、QCDの「Q:品質」について掘り下げてみます。


プロジェクトにおける品質マネジメントとは



PMBOKでは、プロジェクトにおける品質マネジメントについて、プロジェクトのニーズを確実に満足させるためのプロセスであり、品質方針、目標および責任を定め、それら達成するために、品質計画、品質保証、品質管理、および、品質改善を実施していくことと定義しています。


また、品質という言葉を言い換えると、「ある品物を使う人が、その品物に対して持っている期待に応える割合」とも言えます。


とすれば・・・

 

良い品質とは、この期待に応えている割合が高いことを意味することに成ります。


逆に、悪い品質とは、その割合が低いことを意味する。

 

ゆえに・・・


「期待に応える割合」をプロジェクト目標に定義することが肝心です。


前述しましたが、PMBOKにおける品質マネジメントとは、「品質方針、目標および責任を定め、それら達成するために、品質計画、品質保証、品質管理、および、品質改善を実施していくこと」と定義しています。


とすると、プロジェクト目標に品質に関して達成基準などの方針とその責任を定め、以下に記載する品質計画・品質保証・品質管理といったPDCAのマネジメントサイクルを回していくことが、「期待に応える」ことに繋がります。


1)品質計画
主要成果物:品質マネジメント計画書など
説明:

プロジェクトの計画プロセスにおいて品質を保証し改善していくための組織構造、責任、手順、プロセス、および、経営資源を定義したもの


2)品質保証
主要成果物:品質改善の実施
説明:
プロジェクトの実行プロセスにおいて、プロジェクトの成果物とプロセスが適切な品質かどうかを保証するために行う活動。例)品質監査など


3)品質管理
主要成果物:品質改善(検査に対する)受け入れの決定プロセスの調整など
説明:
プロジェクトのコントロールプロセスにおいて、プロジェクトのあらゆる活動結果が適正かどうかを判断するために、結果をモニタし問題があれば必要に応じて対応していくこと。




 最後に品質管理の項目を分類すると以下となる。


・機能性

合目的性

正確性

相互運用性

セキュリティ

機能性標準

適合性

 

・信頼性

成熟性

障害許容性

回復性

信頼性標準

適合性

 

・使用性

理解性

学習性

操作性

魅力性

使用性標準

適合性

 

・効率性

時間効率性

資源効率性

効率性標準

適合性

 

・保守性

解析性

変更性

安定性

試験性

保守性標準

適合性

 




スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > 10の知識エリアと5つのプロセス、3つのパートの関係性について(PMBOK) ]
スポンサードリンク

10の知識エリアと5つのプロセス、3つのパートの関係性について(PMBOK)

PMBOK(Project Management Body of Knowledge)とは


PMBOKとは、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント</a>に関するノウハウや手法を体系立ててまとめたものであり、知識エリアとプロセスから構成されています。


知識エリアは第5版よりステークホルダーマネジメントが追加され「10の知識エリア」となり、プロセスは5つあります。


プロジェクトマネージャとは


まず、プロジェクトを実践していくうえで、プロジェクトマネージャに求められる人物像とは、IPAのプロジェクトマネージャ試験では、次のように定義しています。


「プロジェクトの責任者として、プロジェクト計画を立案し、必要となる要員や資源を確保し、計画した予算、納期、品質の達成について責任をもってプロジェクトを管理・運営する者」


つまり、独自の成果物を期限内に、与えられた予算内で、顧客の求める品質で提供することであり、これを達成するために、計画・実行・管理する。


誤解を恐れず、超大雑把に言うと「成果物を達成すべく、QCDを守るためにPDCAのマネジメントサイクルを活用する」ことでしょうかね。


これから記載するPMBOKの10の知識エリアと5つのプロセスに共通する部分があります。それもそのはず、情報処理技術者試験の高度区分(ITスキル標準レベル4)に位置するプロジェクトマネージャ試験はPMBOK第5版を試験範囲とすることをシラバスに明記しています。


10の知識エリアとは

<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント</a>において、10の知識エリアで求められているのは、Q(品質管理)、C(原価管理)、D(スケジュール管理)いわゆるQCDを管理して達成することである。

これに加えて、そこにいたるまでのプロセスとして「スコープ管理」、「要員管理」、「コミュニケーション管理」、「リスク管理」、「調達管理」、「ステークホルダー管理」という6項目の管理項目を実践し、さらに全体をトータルに管理する「統合管理」を含めた10の知識エリアで構成されています。


■知識エリア/PMBOK第5版、第6版

覚えやすいように、頭文字の一文字だけ取りだしました。繰返し復唱するなどして覚えましょう。「す」「こ」は二回ありますが、重要な項目(QCD)が先に来ると覚える工夫が必要かも。


と:統合マネジメント

す:スコープマネジメント

た:タイムマネジメント※1

こ:コストマネジメント

ひ:品質マネジメント

じ:人的資源マネジメント※2

こ:コミュニケーションマネジメント

り:リスクマネジメント

ち:調達マネジメント

す:ステークホルダーマネジメント

※1 スケジュールマネジメント(第6版)

※2 リソースマネジメント(第6版)


5つのプロセスとは


プロジェクトの最初から最後までの流れを「立ち上げ」、「計画」、「実行」、「監視・管理」、「終結」という5つのプロセスに分割したものです。知識エリアとのマトリクスにより、どのプロセスでどのような成果物を作成・管理すべきかということが定義されています。


ここで、定義されているものは最大限必要な事であり、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクト管理</a>の規模や要件により、必要となる定義を活用します。これをテーラーリングといいます。


なお、5つのプロセスのうち、「立ち上げ」「終結」については、始まりと終わりに利用するプロセスですが、中間にある「計画」「実行」「監視・コントロール」については、PDCAのサイクルのように繰返し行うプロセスです。


3つのパートとは


最後に3つのパートとは、知識エリアとプロセスの交わる「引出し」には奥行きがあり、「入力」、「ツールと実践技法」、「出力」という3つのパートに分かれています。


PMBOKの定義は、「何をもとにして、どんなツールを使ってどんな風に、何を作成するか」というフレームワークを提供しています。








スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトとプログラムの違い ]
スポンサードリンク

プロジェクトとプログラムの違い

プロジェクトとプログラムの違いとは


IT関連のお仕事してるかたならよく知っている「プロジェクト」という用語。これと対比する用語として「プログラム」と言われるとイメージが湧かない。この業界の方であれば、プログラムとは単に言語のことであり、Javaとか、C言語等をイメージする。


ここで取り上げている「プログラム」は言語のプログラムではない!


プロジェクトとプログラムの違いについて理解し、キチンと使い分けできるようにしたい。


まず、一般的に使われるプロジェクトとは以下のように定義される。


■プロジェクト

プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する「有期性」のある業務のこと。


また、対になる定常業務とは、開始と終了の期間が定義されていない業務のことで、継続的な運用管理、あるいは改善活動などを指す。


ここで、ポイントはプロジェクトの対極に定常業務があること。


次にプロジェクトマネジメントとは、有期性のある仕事を管理する。具体的には、以下となる。


■プロジェクトマネジメント

プロジェクトの要求事項を満足させるために、知識、スキル、ツールと技法をプロジェクト活動へ適用すること。


誤解を恐れず、超大雑把に言うと、PMBOKの10の知識エリアと5つのプロセスをツールとして活用し、プロジェクトの規模により必要となるプロセスを取捨選択(これをテーラーリングという。)することで、必要十分な監視・コントロールを実践し、スコープベースラインを必達(いわゆるQCDSを守る)すること。


これまではプロジェクトとはをおさらいして来ました。さて、ここからが本番です。


このプロジェクトに対して、プログラムとは。用語としては認識していなくても、プロジェクト経験者なら実はプログラムも経験済みかもしれません。


■プログラム


プログラムとは、複数のプロジェクトを戦略的ミッションの下に総合的に扱うための管理単位で、P2Mでは「プログラムとは、全体使命を実現する複数のプロジェクトが有機的に統合された事業である」と定義している。


また、P2Mの対象範囲は「プロジェクトの計画・遂行(システムの構築)」だけではく、その前工程である「プログラムの構想、プロジェクトの創造・評価・選択」、後工程である「システムの運用、価値の付加」などが含まれる。


と定義しています。


ここで、プロジェクトとプログラムの相違点を比較する。


・プロジェクトは業務を対象とし、プログラムは事業を対象とする。

・プロジェクトは有期性があるが、プログラムにはない。

・プログラムには定常業務が含まれる。

・複数のプロジェクトを束ねるとプログラムとなる。


プログラムマネジメントでは、プロジェクトの定義に当てはまらないような定常業務も含まれていることが注目点です。

なぜならば、プログラムマネジメントは、価値創造を使命とする活動であり、定常業務による回収を含めての価値と考えられるからです。となると、プログラムマネジメントは経営管理そのものですね。

例えば、ITシステム構築プログラムの場合、いくつかのプロジェクトにて、システムを構築していきますが、そのシステム構築プロジェクトでは、価値自体を創出できず、システム構築後のシステムを利用する定常業務にて、価値が創出されているからです。

そこで、P2Mでは、この定常業務をサービスプロジェクトと位置付け、そこで創出される価値をプログラムの中に含めて、投資・回収、技術、市場などの統合的に評価したプログラムの計画を立てていきます。


プログラムとプロジェクトの違いについて理解できれば良いです。





スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトの失敗と成功の黄金率 ]
スポンサードリンク

プロジェクトの失敗と成功の黄金率

プロジェクトマネジメントで大切なこと集。

■プロジェクト成功の黄金律

プロジェクトを成功させるのに必要なこと・気を付けることなどの「やるべき」集。

\果物について合意を得る
∈芭匹離繊璽爐魄蕕討
プロジェクト計画書を作り更新を怠らない
に榲に必要な資源を判断する
ジ充妥なスケジュールを作る
Δ任る以上のことはやらない
Ь錣某佑鯊臉擇砲垢
┠弍朕悗筌好董璽ホルダーの支援を取り付ける
変更を躊躇しない
現状を周知させる
新たなことに挑戦する
リーダーとなる
 
■プロジェクト失敗の主原因

これが出来ないとプロジェクトが失敗する傾向にある「べからず」集。

.廛蹈献Дトやプログラムマネジメントのやり方がまずい
経営陣からの支援が不足している
ビジネス戦略に結び付かない
ぅ瓮鵐弌爾離好ルが不足している
ゥ廛蹈献Дト成功の判断基準がない
Ε螢好戦略がない
変革をマネジメントしできない





スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン