変更要求

サービス、システム、プロジェクトの成果物や計画（ベースライン）に対する変更を正式に申請するもの。変更の内容、理由、影響、リスクなどを記録し、変更管理のプロセスで評価・承認されたものだけが実施される。

承認済みのスコープ、スケジュール、コスト、成果物などに対する変更の申請。影響を分析したうえで変更管理委員会（CCB）などが承認・却下を判断し、承認されたものだけを計画に反映する。

プロジェクトの文書、成果物、ベースラインに対する変更の公式な要求。是正措置（パフォーマンスの調整）、予防措置（リスクへの事前対応）、欠陥修正、更新のいずれかの形で発生する。統合変更管理プロセスで審査される。

ITサービスやインフラストラクチャに対する変更を正式に申請するための文書。変更の内容、理由、リスク、影響範囲、実施計画、切り戻し計画などを記載する。

サービス、システム、プロジェクトの計画や成果物などに対して変更を求める正式な提案。ITサービスマネジメントではRFC（Request for Change）とも呼ばれ、変更管理で影響、リスク、費用を評価して承認の可否を決める。プロジェクトマネジメントでは、変更管理委員会などで審査してからベースラインを変える。

組織のリスクを体系的に管理するプロセス。リスクの特定、分析、評価、対応を行い、許容可能な水準にリスクを維持する。JIS Q 31000（ISO 31000）でリスクマネジメントの原則と指針が規定されている。

プロジェクトの文書、成果物、ベースラインに対する変更を特定、文書化、承認または却下、管理するプロセス。変更要求は変更管理委員会（CCB）で審議され、承認された変更のみが実施される。

ステークホルダのニーズと要求事項を特定し、文書化するプロセス。インタビュー、フォーカスグループ、ワークショップ、アンケート、プロトタイプなどの手法を用いる。要求事項トレーサビリティマトリクスで追跡管理する。

正式な変更管理手続きを経ずに、プロジェクトのスコープが拡大していく現象。ステークホルダからの小さな要求が積み重なり、スケジュール遅延やコスト超過を引き起こす。スコープ管理プロセスとCCBによる統制で防止する。

人間の行動に関する2つの対照的な仮定。X理論は人は本来怠惰で管理・強制が必要とし、Y理論は人は本来自律的で適切な条件下では積極的に貢献するとする。プロジェクトマネージャのリーダーシップスタイルの選択に影響する。

機密性、完全性、可用性を維持するための組織的な取り組み。プロジェクトにおいても、開発環境のセキュリティ、成果物のアクセス制御、機密情報の取扱いなど、情報セキュリティを適切に管理する必要がある。