オーナーのプロジェクトマネジメント【第21回】
前回に引き続き検証ステージのプロジェクトマネジメントについて記載する。
25. 検証ステージ【その4】
参考 以前に記載した記事の目次
1. はじめに
2. プロジェクトステージの概要
3. 何をマネジメントするか
4. プロジェクト計画に関連する主要な問題点
5. プロジェクトマネジャーの役割と責務
6. プロジェクトマネジャーの資質
7. プロジェクトで使用することば
8. 外部への依頼範囲
9-10. FS(Feasibility Study)ステージ
11-13. 基本計画(概念設計)ステージ
14-16. 基本設計ステージ
17. 発注方式
18-19. 詳細設計ステージ
20-21. 製作・施工ステージ
22-24. 検証ステージ【その1~3】
1. はじめに
2. プロジェクトステージの概要
3. 何をマネジメントするか
4. プロジェクト計画に関連する主要な問題点
5. プロジェクトマネジャーの役割と責務
6. プロジェクトマネジャーの資質
7. プロジェクトで使用することば
8. 外部への依頼範囲
9-10. FS(Feasibility Study)ステージ
11-13. 基本計画(概念設計)ステージ
14-16. 基本設計ステージ
17. 発注方式
18-19. 詳細設計ステージ
20-21. 製作・施工ステージ
22-24. 検証ステージ【その1~3】
25. 検証ステージ【その4】
(1)テストスケジュール策定の留意事項
テストスケジュールの作成にあたり、文書化と実施という2つの重要な活動について、それぞれ、計画、リソースの確保、スケジュール作成を行う必要がある。
テストスケジュールの作成にあたり、文書化と実施という2つの重要な活動について、それぞれ、計画、リソースの確保、スケジュール作成を行う必要がある。
・文書化活動 - 現場実施に対するテスト計画の準備、 レビュー、および承認。
・現場実施活動 - テスト計画の実施、立会い、レビュー、 および承認。
・現場実施活動 - テスト計画の実施、立会い、レビュー、 および承認。
通常、テストにはリソースの増強や日々のスケジュールの労働時間延長では期間短縮することのできない、固定時間(充填時間、殺菌時間など)を有する作業が存在する場合がある。これらの作業を特定しておくことが重要である。テスト作業は、テスト順序通りに「適切なタイミング」で実施なければならず、先行作業の遅延や未実施があると、テスト作業に影響を及ぼす。プロジェクトスケジュールを作成する際に、テストの実施や承認の前に完了すべき、事前に必要な作業あるいは先行作業の要否を認識しておくことが重要である。そして、スコープと必要なテスト順序を検討することによって、リスクの高い作業、すなわち遅延した場合に後続の作業に重大な影響をもたらす作業を認識することが可能となる。プロジェクトスケジュールのクリティカルパスと、そのクリティカルパス上のテスト要素(計画、準備、実施)を理解することが必要となる。
テストスケジュールにおける外部あるいは第三者に依存する項目も把握し調整管理しておく必要がある。例えば、外部によるサンプル分析のような項目があり、プロジェクトの努力により期間を短縮できるものではないことを認識しておく必要がある。
テストは、不測の事態に対処するためのプロジェクトのコンテンジェンシープラン(コスト、スケジュール、技術)を作成するべきである。また、検証ステージにおいてスケジュールと予算の両面で余裕を持たせる必要性もあり、プロジェクトスポンサーとプロジェクトチームにこのような相関関係がよく見えるようにすることが重要である。失敗への対処にかかる時間を見積もることは、(そのプロジェクトが過去のプロジェクトに酷似している場合を除き)未知の事項があまりに多いため、非常に困難である。致命的な失敗は、テストの中止、一部のテスト作業のやり直し、場合によってはプロジェクトの完全な中止につながる可能性もある。特に、新技術、あるいはまだ実証されていないプロセス、装置、手法、あるいは制御機能が検証の対象となる場合に、失敗や不具合が発生する可能性が高い。この場合、スケジュールだけでなく、予算および品質に影響を与えることにもなるため、テスト失敗のリスクについてあらかじめ分析し、スケジュールやその他への影響に対する対策を持っておくことが重要である。
テスト計画の作成とテスト文書の作成は、プロジェクトライフサイクルのなるべく早い段階で開始するのがよい。システム、プロセス、あるいは手法が運転のためのすべてのインフラストラクチャーとプラットフォームを備え、適切に設置され安全に安定した方法で運転できることがレビューされ検証された後に、設計意図と規制要件について検証するテスト活動は初めて開始することができる。計画されたプロジェクトには、予定されたスケジュールよりも実際には時間がかかるというリスクがある。一方、スケジュール上のコンテンジェンシーは、検証ステージ以前に使用されている場合が多い。もっとも多いのが設計ステージに使用されていることが多い。即ち、プロジェクトの初期の段階では「後はなんとかなる」といった調子で進められ、施工や検証にその皺寄せがくることが多い。予定されたスケジュールよりも実際には時間がかかるというリスクレベルは非常に高い。そして、このような課題に直面した場合は、品質を犠牲にすることはできないということを常に念頭に置き、そのリスクの軽減はスコープの変更によってのみ可能である。それには、プロジェクトから削除可能な項目はあるか、あるいは先延ばしが可能な項目はどれかを評価することが必要となる。リソースを追加しても単純に解決できない場合があるので、リソース追加策を実行する場合は、コストの増大に特に留意する必要がある。
テストスケジュールにおける外部あるいは第三者に依存する項目も把握し調整管理しておく必要がある。例えば、外部によるサンプル分析のような項目があり、プロジェクトの努力により期間を短縮できるものではないことを認識しておく必要がある。
テストは、不測の事態に対処するためのプロジェクトのコンテンジェンシープラン(コスト、スケジュール、技術)を作成するべきである。また、検証ステージにおいてスケジュールと予算の両面で余裕を持たせる必要性もあり、プロジェクトスポンサーとプロジェクトチームにこのような相関関係がよく見えるようにすることが重要である。失敗への対処にかかる時間を見積もることは、(そのプロジェクトが過去のプロジェクトに酷似している場合を除き)未知の事項があまりに多いため、非常に困難である。致命的な失敗は、テストの中止、一部のテスト作業のやり直し、場合によってはプロジェクトの完全な中止につながる可能性もある。特に、新技術、あるいはまだ実証されていないプロセス、装置、手法、あるいは制御機能が検証の対象となる場合に、失敗や不具合が発生する可能性が高い。この場合、スケジュールだけでなく、予算および品質に影響を与えることにもなるため、テスト失敗のリスクについてあらかじめ分析し、スケジュールやその他への影響に対する対策を持っておくことが重要である。
テスト計画の作成とテスト文書の作成は、プロジェクトライフサイクルのなるべく早い段階で開始するのがよい。システム、プロセス、あるいは手法が運転のためのすべてのインフラストラクチャーとプラットフォームを備え、適切に設置され安全に安定した方法で運転できることがレビューされ検証された後に、設計意図と規制要件について検証するテスト活動は初めて開始することができる。計画されたプロジェクトには、予定されたスケジュールよりも実際には時間がかかるというリスクがある。一方、スケジュール上のコンテンジェンシーは、検証ステージ以前に使用されている場合が多い。もっとも多いのが設計ステージに使用されていることが多い。即ち、プロジェクトの初期の段階では「後はなんとかなる」といった調子で進められ、施工や検証にその皺寄せがくることが多い。予定されたスケジュールよりも実際には時間がかかるというリスクレベルは非常に高い。そして、このような課題に直面した場合は、品質を犠牲にすることはできないということを常に念頭に置き、そのリスクの軽減はスコープの変更によってのみ可能である。それには、プロジェクトから削除可能な項目はあるか、あるいは先延ばしが可能な項目はどれかを評価することが必要となる。リソースを追加しても単純に解決できない場合があるので、リソース追加策を実行する場合は、コストの増大に特に留意する必要がある。
コメント
/
/
/
コメント