[第 16 章] プロジェクト変更管理
1章関連
1.1 試験関連
この部分は通常、午前中に 1 ～ 2 点が採点され、ケース ペーパーが含まれる場合があります。これは、レビューの重要な章です。
2 変更管理の基本概念
1. プロジェクト変更管理とは、情報システム工学構築プロジェクトの実施中に、プロジェクト環境その他の理由により、プロジェクトの機能、性能、構造、技術指標、統合方法、プロジェクトの進捗状況などに加えられる変更をいう。 .
2. チェンジマネジメントの本質は、プロジェクトの推進過程でますます豊かになるプロジェクト認知に応じて、不断调整项目努力方向和资源配置プロジェクトのニーズを最大限に満たすことです提升项目价值。
3. 変更の一般的な理由: ① 製品の範囲 (結果) の定義における過失または過失; ② プロジェクトの範囲 (作業) の定義における過失または過失; ③ 付加価値の変更; 一貫性のないベンチマーク要件による受動的な調整; ⑥ 外的要因。
4.変更の分類：
◆ に従って变更性质：重大変更、重要変更、および一般変更。通过不同审批权限控制
◆によるとに变更迫切性分けることができます:紧急変更、非紧急変更します。◆ その他: 変更の分野と段階に応じて、さまざまなカテゴリ通过不同变更处理流程进行
に分類できます; 5. 変更管理は、プロジェクトの変更をプロジェクトと一致させるために対処する一連の管理方法です。2 つの可能な結果は、 またはです。进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更项目基准项目实际执行情况拒绝变化调整项目基准
プロジェクト変更管理の 3 つの原則
1. 変更管理の原則は、プロジェクトのベンチマーキングと変更管理プロセスの標準化です。含む：①基准管理、②变更控制流程化、③明确组织分工、④评估变更的可能影响、⑤妥善保存变更产生的相关文档
(1) ベンチマーク管理: ベンチマークは変更の基礎です。プロジェクトの実装中、ベースライン計画が決定されてレビューされた後 (通常、ユーザーはレビューの一部に参加する必要があります)、最初のベースラインが確立されます。
此后每次变更通过评审后，都应重新确定基准.
(2) 変更管理プロセス: プロジェクトのニーズを満たす変更管理プロセスを確立または選択し、すべての変更はこの管理プロセスに従って管理する必要があります。
(3) 明確な組織分業:至少应明确变更相关工作的评估、评审、执行 的职能.
(4) 変更による影響の可能性を評価する: 変更の原因はさまざまであり、結果や納期などの顧客に見える変更操作と、顧客には見えないプロジェクトの内部作業の変更を完了する必要があります。顧客。
(5) 変更によって生成された関連文書を適切に保存し、それらが完全で、タイムリーで、正確かつ明確であることを保証します适当时可以引入配置管理工具。
4 変更管理の組織構造とエンジニアリング手順
1.プロジェクト管理委員会または構成管理委員会 (CCB)、または関連する機能を持つ同様の組織は、プロジェクトの所有権の代表者です负责裁定接受哪些变更。CCB はプロジェクトの関係者で構成され多方人员共同、通常はユーザーや実装側の意思決定者が含まれます。CCB は决策机构，不是作业机构; 通常、CCB の作業は評価手段を通じて行われます. 决定项目基准是否能变更，但不提出变更方案
2. プロジェクト マネージャーは、プロジェクトの運用プロセスに責任を負うように所有者から委託され、その正式な権利は项目章程当局によって取得されますが、リソース スケジューリングの権限は、通常、ベンチマークで指定されます。基准中不包括的储备资源需经授权人批准后方可使用.
変更におけるプロジェクト マネージャーの役割: 响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施即调整基准。确保项目基准反映项目实施情况. –暗唱
3. 変更された作業手順: 1.提出与接受变更申请2.对变更的初审3.变更方案论证4.项目管理委员会审查5.发出变更通知并组织实施6.变更实施的监控7.变更效果的评估8.判断发生变更后的项目是否已纳入正常轨道–暗唱
変更テスト:
1. 一部の変更は小さく、顧客は急いでいます. 変更手順を経ずに直接変更できますか? 2. プロジェクト マネージャーは変更を承認できませんか? 3. プロジェクト マネージャーまたはチーム メンバーは変更を提起できません。 4. スコープの変更は
スコープのみを評価できます 5. 変更が承認された後、ベンチマークまたはドキュメントを更新してから実装する必要がありますか?
6. 承認されていない変更、チーム メンバーはできるだけ早く実装しますか? 8. プロジェクト マネージャーは通常、CCB のチーム リーダーです? 9. すべての変更は CCB によって承認されなければなりませんか? 10. 変更管理システムは、管理できないソフトウェア システムでなければなりません
。手動で
4.1 変化応答分析
変更管理の作業手順:
1. 変更申請の提案と受理
2. 変更の事前審査
3. 変更計画のデモンストレーション
4. プロジェクト管理委員会の審査
5. 変更通知の発行と実施の整理
6. 変更実施の監視
7. 変更効果の評価
8 . 審査変更されたプロジェクトが通常のトラックに持ち込まれたかどうか...
事例の短い回答または論文作成で、変更管理作業手順について質問された場合は、ここをクリックして直接回答してください。 P509-510
4.2 変更プロセス
5 プロジェクト変更管理の業務内容
1、在项目整体压力较大的情况下，更需强调变更的提出、处理应当规范化，可以使用分批处理、分优先级等方式提高效率。
2、项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效，但关于小项目变更仍应注意以下几点：
①对变更产生的因素施加影响：防止不必要的变更，减少无谓的评估，提高必要变更的通过效率。
②对变更的确认应当正式化。
③变更的操作过程应当规范化。
3、变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过则此处的严格便毫无意义；但应根据变更的影响和代价提高变更流程的效率。
4、变更管理，是项目整体管理的一部分，属于项目整体变更控制的范畴。涉及范围、进度、成本、质量、人力资源、合同管理等多个方面。
5、变更管理与配置管理为相关联的两套机制，变更管理由项目交付或基准配置调整时，由配置管理系统调用，变更管理最终应将对项目的调整结果反馈给配置管理系统，以确保项目执行与对项目的账目相一致
6 版本发布和回退计划
1、项目变更就必需做相应的版本发布，并制订相应的应急回退方案。为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案。
2、为确保版本发布的成功，在版本发布前应对每次版本发布的风险做相应的评估，对版本发布的过程Check list做严格的评审。在评审发布内容时对存在风险的发布项做重点评估，确定相应的回退范围，制定相应的回退策略。为确保每次版本发布风险的可防可控，特准备回退方案。
3、回退步骤：
（1）通知相关用户系统开始回退。
（2）通知各关联系统进行版本回退。
（3）回退存储过程等数据对象。
（4）配置数据回退。
（5）应用程序、接口程序、工作流等版本回退。
（6）回退完成通知各周边关联系统。
（7）回退后进行相关测试，保证回退系统能够正常运行
（8）通知用户回退完成。
7 练习题
【例1-17下】依据变更的重要性分类，变更一般分为（）、重要变更和一般变更。
A.紧急变更 B.重大变更 C.标准变更 D.特殊变更
【例2-18上】关于变更申请的描述，不正确的是（）。
A.实施整体变更控制过程贯穿项目始终
B.变更请求可能包括纠正措施、预防措施和缺陷补救
C.变更请求必须由CCB来负责审查、评价、批准或否决
D.实施整体变更过程中涉及到的配置管理活动包括配置识别、配置状态记录、配置核实与审计
【例3-18下】 A公司承接了某海外信息系统集咸项目，项目进行中，项目经理获悉因天气和汇率原因，预计设备到场的运费比预算高出30%。接下来他应该首先（）。
A.项目还没有结束，暂时不做处理
B.给主管领导打电话，汇报情况，寻求解决方案
C.填写项目变更申倩，启动变更流程
D.寻找新的承运商，评估变更影响，提交合同变更申请
【例4-18上】做好变更管理可以使项目的质量、进度、成本管理更加有效。关于变更工作程序的描述，不正确的是（）。
①及时，正式的提出变更，且留下书面记录
②变更初审的常见方式为变更申请文档的格式校验
③变更方案论证首先是对变更请求是否可行实现进行论证
④审查过程中，客户根据变更申请及评估方案，决定是否变更项目基准
⑤发出变更通知并组织实施
⑥变更实施的工程监控，配置管理员负责基准的监控
⑦变更效果评估中的首要评估依据是项目的基准
⑧基准调整后，需要判断项目是否已纳入正轨
A.②③⑤ B.②④⑥ C.①②③④ D.⑤⑥⑦⑧
【例5-19上】项目执行期间，客户提出增加一项功能，但它并没有包括在项目预算之内。不过对于一个几百万美元的项目而言，该项工作涉及的开发工作量较小。作为项目经理应该（）。
A.拒绝用户请求，原因是该项工作不在项目预算之内
B.同意并免费完成这项工作，帮助维护客户关系
C.同意增加新功能，但是需要客户承担相应的费用
D.评估新功能对项目的影响，提交变更申请
【例6-19下】某公司接了一个小型软件研发的项目，测试过程中，程序员发现某处算法需要进行更改，则（）。
A.项目经理可决定是否进行变更
B.研发人员可直接进行更改
C.项目不大，变更只需口头提出即可
D.变更处理要力求简化，操作无需规范
【例7-19下】关于变更管理的描述，不正确的是（）。
A.每次变更通过评审后，都应重新确定基准 B.必须采用变更管理工具
C.明确变更工作中评估、评审、执行的职责 D.评估变更的可能影响
【例8-19下】关于变更管理工作程序，正确的步骤是（）。
①变更实施监控与效果评估②发出变更通知并组织实施③提出与接受变更申请④对变更的初审和方案论证⑤CCB审查
A.③①②④⑤ B.④③⑤②① C.③④⑤②① D.④⑤③②①
【例9-20下】 （）的目的是确认变更的必要性,确保变更是有价值的。
A.提出变更申请 B.变更效果评估 C.变更初审 D.变更实施
【例10-21上】变更管理是为了使得（）与项目实际执行情况相一致，是应对项目套管理方法。
A.项目资源 B.项目报告 C.项目基准 D.项目目标
【例11-21上】关于变更管理工作程序描述，不正确的是（）。
A.项目的干系人都可以提出变更申请
B.CCB是执行机构，负责提出变更申请
C.变更实施的过程监控，通常由项目经理负责基准监控
D.涉及项目目标及交付成果的变更，客户意见应放在核心
【下の例 12-21】 プロジェクトの変更は、変更の性質に応じて、大きな変更、重要な変更、および一般的な変更に分けられ、異なる () によって実現されます。
A.変更処理の流れ B.変更内容 C.承認権限管理 D.変更事由の取り扱い
【下の例13-21】管理組織の業務手順を時系列に変更してください。正しいのは()です。
①変更効果評価 ②プロジェクトエンジニアが変更申請書を提出 ③プロジェクトマネージャが変更申請書を承認 ④変更通知を発行し、実施を整理 ⑤変更申請書のレビューと回覧 ⑥変更計画のデモンストレーション ⑦プロジェクト管理委員会のレビュー ⑧プロジェクトマネージャと監督ユニットが実施を監視 A.②⑤③④⑥⑧⑦① B .②⑤④③⑦①⑥⑧⑧ C.②③⑤⑦⑥④①⑧
D. ②③⑤⑥⑦④⑧①
[例 14-22] プロジェクト変更管理の本質は () です。
A. 当事者 A のマネージャーの要件を満たす
B. プロジェクトのベンチマークまたはリソース割り当てを調整して、プロジェクトの価値を高める
C. プロジェクト マネージャーの経験不足に効果的に対処する
D. プロジェクトの進捗をリアルタイムで理解し、監視する
【上記例15-22】 作業手順の変更の記述について、正しいものは()です。
A. プロジェクトの変更申請は、プロジェクト チーム メンバーが提案する必要があります
B. 監督部門は、主な変更結果と変更の進捗状況のマイルストーンを監視できます
C. プロジェクトの目的と成果物に関する変更は、専門家の意見に基づく必要があります
D. 変更前プロジェクト実施ベンチマーク調整の公表
参考回答
