]追加された行はこの色です。削除された行はこの色です。.NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。[#w0587d6b]&color(red){プロジェクトを承認し、資源をプロジェクトに割り当てる権限をPMに与える。[#k0a71413]以下を公式に承認する。-新規プロジェクト、既存プロジェクトの次フェーズが開始されること。-資源を上記の開始されたプロジェクトに投入する必要があること。[#e72ce6ef]プロジェクトが実行可能であるかどうかを判断する。-目的~成功する確率を求める。--市場性はあるか?--ヒットするか?--技術面で---実現可能か?---信頼性は高いか?---既存体制への組み込みが可能か?-実施~義務付けている組織もある。--タイミング---別プロジェクトとして実施---サブ・プロジェクトとして実施---第一フェーズで実施--実施チーム~プロジェクトに携わらない(偏見の無い)チームが実施する。役割に含まれないが参加することはある。)※&color(red){「初めての試み」などの場合は、特に重要になる。[#r6fddbae]選定プロセスは、[[フィージビリティ・スタディ>#e72ce6ef]]と同様に、-PMの責務は無い。[#w0592a6c]-組織の大半は、選定、優先度付けに関する~公式、準公式の評価プロセスを持っている。-例--会計年度の始まる前の予算立案時期に~選定委員会はプロジェクト案の提出を求める。--書面には、以下が記載される。所産)>PMP:共通#d2910c2d]]の導入日---プロジェクトにより組織が得るもの。~(影響を受ける機能部門リストと、費用便益分析)--[[評価>#yfc28cd7]]~[[会議>#v3fe5609]]を実施---顧客---スポンサー---専門家---PM(※役割に含まれないが参加することはある。)--優先度付けされる。---重要性---利益--プロジェクト・リストに追加される。---正式に文書化される。---選定委員会に、月次進捗報告を行う。[#yfc28cd7]下記の要因でプロジェクトによって[[評価手法>#ff8eda21]]は異なる。[#ff8eda21]-以下を測定して選定する。所産)>PMP:共通#d2910c2d]]---の価値---が組織に与える利益--測定の軸~経営者の戦略的目標とのマッピンク---マーケットシェア---金銭的利益---投資収益率---顧客維持率---顧客忠誠度---社会通念-プロジェクト選定手法~プロジェクト選定手法には、以下の2つ区分がある。以下のアルゴリズムを使用する。所産)>PMP:共通#d2910c2d]]の利点・利益を検討する。---大半のプロジェクトでは(、数学的モデルではなく)、こちらを採用する。---費用便益法、得点モデル、キャッシュ・フロー分析手法などがある。---大規模・複雑なプロジェクトでは複数の利益測定法を組み合わせて使用する。[#qd970b89]-&color(red){ビジネス・ニーズを理解し投資に価値があるかを判断するための文書。};-[[ビジネス・ニーズ>#v8223a8d]]を理解し&color(red){投資に価値があるかを判断するための文書。};-承認--[[プロジェクト憲章作成>#wa46db3f]]プロセス開始のきっかけになる。--承認アクティビティは、プロジェクト外部で行われる。[#p4282ffe]ニーズ評価を行い、[[ビジネス・ニーズ>#v8223a8d]]評価を行い、-目的-目標-課題-好機などをまとめる。[#x6db94af]&color(red){経済的な実現可能性検討を文書化したもの。};-ビジネス・ニーズ:[[プロジェクトの発生>#zbf63f65]]の内容が記載される。[#n380f90b]プロジェクトから得られるベネフィットを-創出-最大化-持続させるための、プロセスを定義した記述書。[#wa46db3f]-[[プロジェクト憲章>#c6b11201]]は、プロジェクトを承認するPMの名前入りの書面。[[立上プロセス群の目的>#k0a71413]]-予算10億超え位の案件から作成されだす(小規模プロジェクトでは作成されない)。所産)>PMP:共通#d2910c2d]]-考慮内容--戦略計画を考慮する。~企業の戦略計画とプロジェクトの関係--ビジネス・ニーズを考慮する。---国家の規制---技術的進歩---市場の需要---法的要件--[[ビジネス・ニーズ>#v8223a8d]]を考慮する。範囲#y5e2a127]]を考慮する。[#od6165e3]-プロジェクトの意図を定義した=合意書が、~実施条件や、期間、作業、などの記述のために利用される。-合意書には以下のものがある。[#d35a4437]-多数のフェーズ、プロセス群でも、ツールと技法として使用される。-主に、インプットの評価を行う。[#r75e21eb]多数のフェーズ、プロセス群でも、ツールと技法として使用される。[#a13cd7b9]主要なステークホルダーを早期に特定して、~プロジェクト憲章作成に参加してもらう。-プロジェクトマネージャー--プロジェクトの成功に対して責任を負う人。--できるだけ早い段階で特定すべき。~(プロジェクト憲章作成には参画すべき。)--ただし、プロジェクト憲章の作成に参画しても、作成者の欄に、~記名しない(作成者が自身に権限付与することになるため)。--プロジェクトの計画後に各作業を実行しマネジメントする。---プロジェクトの標準と方針を設定し、プロジェクト・チームとステークホルダーに伝える。---コミュニケーションと文書に習熟し、関係者に情報を絶えず提供する。~文書:要求事項、コスト、アクティビティ、パフォーマンス評価の尺度~関係者:プロジェクト・スポンサー、プロジェクト・チーム、その他。--&color(red){機能部門マネージャ};に協力して支持を得る。-プロジェクト・スポンサー--プロジェクト・スポンサーも一般的なスポンサーと同様に、~ステークホルダーと経営陣の支持を取り付け、強力な推進者となる。--また、プロジェクトの最終的な権威者および意思決定者である。--突き詰めるとPMと同じく、プロジェクトを成功に導く責任を負う。--プロジェクト・スポンサーは、---通常は、組織内の論争や対立に決着をつける権力・権限を持った経営幹部。---プロジェクト位置付けの向上のため、プロジェクトの宣伝活動を継続的に行う。---プロジェクトにスポットライトを当てて、プロジェクトの一切を取り仕切る(資金、成果)。--フェーズ毎の関わり---立上・計画フェーズには積極的に関わる。---実行、監視・制御フェーズでは関わりは減り、問題発生時の意思決定を行う。-&color(red){機能部門マネージャ};--組織の管理業務に従事する。資源#df22cece]]る。その他#d20ba7ed]]を行う。--以下の機能部門マネージャは、~プロジェクト憲章作成で特定しておいた方がイイ。---プロジェクトのタスクに携わる。---プロジェクトの責任が割り当てられている。[#c6b11201]-プロジェクト憲章には、経営陣やステークホルダーが読める、~[[ハイレベル概要>PMP:共通#ce555cad]]の[[ニーズと要求>#v8223a8d]]が文書化される。[[ハイレベル概要>PMP:共通#ce555cad]]の[[ビジネス・ニーズ>#v8223a8d]]が文書化される。制約条件---リスク---承認要求事項~成否の判断材料(事項)と、成否を判断する人、受け入れの承認者。所産)>PMP:共通#d2910c2d]]>に反映することができる。-プロジェクト憲章は、--プロジェクトを依頼する組織--プロジェクトを遂行する組織>との間に、協力関係を形成すると書かれている。-このため、必ず計画プロセス群を開始する前に実行する。-また、反復プロセスにより署名含め内容を改訂する事も可能。プロジェクト憲章に反映。[#c6b11201]プロジェクトの存在は承認済みのプロジェクト憲章という公式な書面によって承認/確認される。-承認プロセス--(キックオフ・ミーティングなどで)~プロジェクト憲章の内容に合意後、署名してもらう。--この後に、プロジェクト憲章が公式文書として発行される。組織)---プロジェクト・スポンサー-承認の結果--組織にプロジェクトを紹介するために利用できる。--組織の資源をプロジェクトに割り当てる権限をPMに与える。--プロジェクトの諸作業を組織の定常業務に結び付ける。[#sef143a0]-プロジェクトの成功はステークホルダーの期待に応えること。故に、--早い段階でステークホルダーとの協力関係を築けば、プロジェクトが遂行しやすくなる。--ステークホルダーの役割を理解することがプロジェクト・マネジメントに重要になる。-このため、ステークホルダー特定を行う。--できるだけ早い段階で行う。