● （ベンダ）プロジェクトマネジメントの対象と実務能力
１．プロジェクト・コントロール
| |
１．方針、運営とルール
プロジェクト案件には様々な人たちが関わりをもちます。経験・技術・知識・立場・文化など
が異なる人たちを同じ目的に向かって、ベクトルを合わせることが大切です。そのために
は、プロジェクトの方針・運営・ルールなどを関係者に周知徹底をすることです。
① 「方針」の作成
・ ユーザの方針 －－ パッケージ導入の目的達成と期待効果の実現
・ ベンダの方針 －－ a．ユーザの状況/弱さ/課題への留意点・力点
（例：メンバーに兼務多い、大量データの取扱）
b．ベンダの重点事項への対応
（例：多岐に亘る作業項目、協力会社、品質管理）
② 「運営」の条件
・ 情報流通 －－－－ プロジェクトの基本情報、ユーザ情報（資料、決定事項）、
ベンダ情報（作業情報、成果物）
・ 作業環境 －－－－ 作業場所、ベンダ内連絡方法（メール、打合せ、掲示板）、
ユーザとの連絡方法
・ ユーザ連携 －－－ 役割分担、会議体、成果物レビューと承認
③ 「ルール」の徹底
・ 社会的モラル －－ 出勤、時間厳守、個人情報の取扱、機密厳守、約束実行
・ コミュニケーション－ 「報告・連絡・相談」、情報伝達と確認
【参考】 ダウンロード資料 ＜590 「プロジェクト運営」チェックリスト＞
|
| |
2．リーダ/メンバー
リーダとメンバーがその役割に応じた作業品質とスケジュールを消化することはプロジェク
ト活動の生命線です。リーダのスキル向上への観察、支援、アドバイスも大事です。
① リーダ
・ リーダの役割と責任範囲及び権限（WBS)の明確化
・ WBSでの問題発見と問題解決策の具体化と実行
・ ユーザとの協力関係及び信頼関係の土壌作り
（チェックポイント）
・ メンバーの中間成果物を適宜、チェックをしているか
・ メンバーへのスキル向上支援/疑問解消/指導をしているか
・ メンバーが目標/作業方法/成果物を理解し行動しているか
・ 他チームとのチームワークがうまくいっているか
・ プロジェクトマネジャーとの情報交換を行っているか
・ メンバーから信頼されているか
② メンバー
・ メンバーの役割と作業範囲の明確化
・ WBSの理解と作業条件の明確化
・ 他メンバー、ユーザとの協力関係の土壌作り
・ 「疑問・不明」発生への対応手順とルール
（チェックポイント）
・ リーダに対して、「報連相」と「不明点への質問」を行っているか
・ 作業の中間成果物に対して、チェックを求めているか
・ 成果物を理解し、必要な行動をしているか
・ 他メンバー/ユーザとの情報交換と作業確認を行っているか
【参考】 ダウンロード資料 ＜585 「プロジェクト体制の組閣」チェックリスト＞
|
| |
３．品質/進捗/コスト管理
プロジェクトを成功させるために必要なマネジメントです。品質・進捗・コスト管理は互いに
密接な関係にあり、一つが崩れると他の管理に無条件に跳ね返ります。プロジェクト活動
をトラブルなく行うためには、この３つのマネジメントを確実に行うことです。
① 品質管理
ａ．品質の特性
・ 品質は後からとってつけたように追加/更新ができない。
・ 先行作業の成果物の品質がそのまま次作業に引き継がれます。
・ 品質はドキュメントなりシステム機能として表現され評価されます。
・ 目的達成に貢献するニーズをシステム機能に転換したものです。
ｂ．品質確保の条件
・ 上流フェーズの重視（課題解決、要件定義、ＦＩＴ＆ＧＡＰ）
・ 必要資源の投入（スキル・知識を有する要員、ユーザ、専門家）
・ 作業の進め方（ユーザ参加、具体的資料による検討、レビュー実施）
② 進捗管理
ａ．進捗の見方
・ 「品質」抜きの進捗管理は意味がありません。
・ 成果物/作業の進め方に対して、担当ＳＥのスキル・姿勢を見極めます。
・ 「３ Ｖｉｅｗｐｏｉｎｔ（ゴール・重点管理・事実）」からの進捗管理を行います。
ｂ．管理の向上
・ ＷＢＳの内容（「５ Ｂｏｘ」の理解）と手順を確認します。
・ 成果物への支援と指導、作業途中でのチェックとアドバイスをします。
C．協力会社の管理
・ 管理とチェックの立場でなく、プロジェクト協力者で臨みます。
・ 協力会社にとって、プラスになる点（スキル習得・利益）を踏まえます。
・ プロジェクト方針/運営/計画/ルールなどの浸透度を確認します。
【参考】 ダウンロード資料 ＜620 協力会社の調査報告（サンプル）＞
③ コスト管理
・ 作業フェーズ終了時点でのチェック
－ システム対象の範囲/深さと作業工数の差異
－ スキル/業務知識/技術要件の適性
・ コストチェックの視点
－ ユーザの協力/能力/責任感の評価
－ 「品質」「進捗」の実態と差異の評価
|
| |
４．スタッフ機能、責任組織
プロジェクト活動にプロジェクトマネジャーとともに責任を負うのがスタッフであり責任組織で
す。多くのベンダ/メーカにおいて、このスタッフなり責任組織が曖昧でプロジェクトマネジャ
ーのみに責任を負わせる形になっています。ここに失敗する原因があります。プロジェクト
活動に対する支援とともに共同責任としてのスタッフ機能であり責任組織とすべきです。
① スタッフ機能（PMO)
・ ユーザという現場に足を運び「生の情報」を得て、スタッフ機能を果たします。
・ 必要な技術/経営/業務知識を明らかにし、SE要員の組閣とその活動をサポ
ートします。
・ 品質/進捗/コスト管理を受け身でなく、「何が問題か」「リスク要因は」「これか
ら生じる問題は何か」の観点からプロジェクトを観察し問題提起を行います。
・ 「口頭」のみの評論家的スタッフは害があって益なしです。
＊ PMO=Project Management Office
② 責任組織（経営者）
・ プロジェクトマネジャーの支援要請には即時に対応します。
・ スタッフの要請にも臨機応変に応えます。
・大きな リスク要因と問題点を把握し、定期的にチェックを行います。
・ プロジェクトマネジャーに必要な権限移譲を行います。
・ 力量不足が生じた場合、プロジェクトマネジャー交代の判断をします。
③ レビューの重視
・ 「事実」に基づいて、品質/進捗/コストの確認と問題有無を確認します。
・ 問題に対する解決策を合意し、アクション計画を立てます。
－ 問題に対する原因の明確化（関係者からの意見・ヒントを入手）
－ 原因排除を含めた解決策の立案と 「５W1H」での計画作成
・ ユーザ/リーダ/メンバーに関する問題有無を確認します。
（成果物品質、作業スケジュール、チームワーク・・・・）
・ 前回レビューでの要アクションの結果報告を受け、内容を確認します。
・ レビューのアジェンダと資料は事前に配布し、レビュー開始とします。
・ 「４－５－３」視座からレビュー（確認・検証・提案）を行います。
・ 抽象的な意見/提示は意味がなく時間の無駄です。具体的な指摘/意見/提
示/対案/行動にレビューの意味があり、価値があります。
|
| |
５．WBSの整理と管理
プロジェクト活動に必要な作業を洗い出し、整理します。その整理の仕方が作業品質と進
捗に影響を与えますので要注意です。また、その整理されたWBSを管理することがプロジ
ェクトマネジメントの中心になります。
（ＷＢＳ＝Ｗｏｒｋ Ｂｒｅａｋｄｏｗｎ Ｓｔｒｕｃｔｕｒｅｓ、作業項目とその作業分類・作業順序）
【参考】 ダウンロード資料 ＜575 「ＷＢＳ」の作成要領と管理＞
【整理の要点】
① 作業フェーズの成果物を明らかにして、その成果物を作るために必要な作業
を洗い出します。
② 作業の必要性はあるが詳細まで具体化できない作業項目はその旨を明示し
ておきます（具体化時期を明記）。
③ ユーザ負担の高い作業はユーザの了解と合意を得ます。
④ 工数換算が容易な作業と難しい作業に識別します。後者は開始時期・スケジ
ュール・担当SEを考慮します。
（例：未経験分野、新技術、調査、試作、ユーザの未確定事項）
⑤ 工数、日程などの予備を考慮します。
⑥ アサインされたSE要員のスキルと実績を考慮して、作業項目とスケジュールを
決めます。
【管理ポイント】
① WBSの完了時期前に、作業チェックを入れ作業品質を確認します。
② 後の作業に影響の大きい作業を注視し、重点管理とします。
③ 完了確認はその成果物の品質確認をもって、完了とします。その成果物の品
質チェックの担当を決めておきます。レビューでの確認と承認もあります。
④ スキル・知識の不足による品質劣化と遅延はＳＥ交代を行い、成果物の作業
スケジュールと品質を優先させます。
⑤ ユーザが関連する作業項目の問題は、ユーザの責任者に伝え改善策を実行
します。
|
| |
【 情報共有・自発的活動・コミュニケーション 】
プロジェクト活動に携わる人にとって、プロジェクトの基本情報とコミュニケーション土壌は
必要不可欠です。これなくして作業品質・納期順守などの責任ある仕事はできません。こ
れらの基盤の上に、メンバー・関係者の創意と工夫のある自発的行動がプロジェクト活動
を質的に高いものにします。また、この自発的活動があって、プロジェクト活動の抜け/漏
れ/重複などを防止できますし、問題発見も早く行えます。
計画があって、全てその計画通りにやればできるのがプロジェクト活動ではありません。想
定外の作業項目、作業パス（連携）やスケジュールの差異が発生するのがプロジェクトの
実態です。「情報共有・自発的活動・コミュニケーション」の基盤はプロジェクトマネジメント
の基本的な仕事です。
【 観察→問題発見→対応 】
プロジェクトマネジメントの軸に、この「観察→問題発見→対応」サイクルがあります。
問題発生への対応を「より早く、より被害少なく、より低コスト」で行い、プロジェクトをユー
ザとともに成功に導くのがプロジェクトマネジャーの力量になります。
（参考） 「トラブルの早期発見と兆候・現象・原因」ページ
（参考） 「トラブル（問題）の解決策と予防策」ページ
【参考】 ダウンロード資料 ＜620 協力会社の調査報告（サンプル）＞
① 観察＝「何をみるか」
・ プロジェクトの動き（SE作業、ユーザ作業、進捗、打合せ、成果物）をつぶさに見
ることです。作業スケジュールの２割進捗の段階で、その作業スケジュール・作
業計画をチェックすることです。必ず、問題点はあります。問題点なしの判断はあ
り得ません。このことが観察の一つの大事なポイントです。
・ 個人なりチームの動きを連続的時系列で捉え、その傾向（問題有無、約束励行
、作業品質、発言）を把握します。
・ チームワーク、情報の共有と連携、自発的活動（前向きか後向きか）、コスト意
識などの組織活動のあり方を見ます。
・ ＳＥがWBSに必要な技術、知識を持っているかを見ます。
② 問題発見＝「何が問題か」
・ 作業の成果物が品質を満足しているかどうかです。この成果物の品質は全てに
優先する大事なチェックポイントです。
・ 作業に関する進捗度合を見ます。最終完了時期に間に合うかどうかです。作業
計画の適正、担当SEの技量、ユーザの協力具合などをチェックします。
・ 発生した費用の積算に注意をします。計画内かオーバーかをチェックします。特
に、WBSの最終完了時期をみて想定される総コストの判断です。
・ リーダ/ＳＥ/ユーザプロジェクトの動きと力量を見ます。情実を排して客観的にク
ールに見ることです。
③ 「対応」＝「的確性の重視」
・ 支援、指導、交代などの対応基準を明確にして行います。中途半端な対応はメ
ンバー/関係者が不安を持ち効果が上がりません。
・ WBSの場合は、その原因と反省点を整理しWBSの詳細を作り直します。
・ 約束したプロジェクト計画の基本（納期、品質、費用）が狂う場合は、責任組織
（経営者）に上げて抜本的な対策を行います。真の原因は何かを明確にします。
この本質を抜きにした対策は砂上の楼閣になり、同じ対策に見舞われます。
【参考】 ダウンロード資料 ＜630 「ベンダ向けプロジェクト・コントロールの要点＞
|
２．ユーザとの共同・連携
| |
中堅・中小企業におけるパッケージ導入は、ベンダとユーザの信頼に基づく共同作業なしには成功へと結びつきません。この共同作業はベンダのユーザへの支援と指導が必要不可欠です。「ユーザとの共同・連携」作業はベンダのリーダシップがあってこそ可能になります。
【参考】ダウンロード資料＜565 ユーザプロジェクトとの関係＞(Acrobat 9.0作成）
|
| |
【 経営者の参画/プロジェクト体制 】
経営者の関心と参画の高さがユーザのプロジェクト活動の活発さに比例します。ベンダ
のプロジェクトマネジャーはこの経営者参画とユーザプロジェクト活動を常に観察します。
|
| 情報共有 |
- ユーザとの検討、合意、成果物レビューなどの会議体と参加メンバー 及び開催ルールを決めます。
- 経営者（最終意思決定者）が参加する会議体を決め、実質的な意志決定の場にします。
- メンバー/関係者へオープンするプロジェクト基本情報（成果物、議事録、打合せ資料など）を決め、提供媒体と手順を決めます。
- 「問題管理、品質管理、進捗管理」に関する情報管理は、ベンダとユーザの役割を明確にして運営します。
|
| 支援・指導 |
- ユーザプロジェクトの組閣、運営（意志決定・会議体・情報共有）に関してアドバイスを行います。
- メンバーの個人作業、打合せなどの時間確保に留意します。
- メンバーの資料作成と情報収集にサンプル提示や具体的アドバイスを行います。
- 必要に応じて、ユーザ内打合せに参加し「進め方、問題点と解決策の提起、情報提供、整理の仕方」の支援をを行います。
- プロジェクト活動の開始前に「プロジェクトとは何か、セッション、事例紹介、業務改善の方法」などの情報提供を兼ねて研修を行うのも一つの方策です。
|
| 問題解決 |
- ユーザプロジェクト内の問題は、上記「支援・指導」を通しての発見とユーザ作業の結果に出ます。傷の小さいうちに手を打ちます。
- SEの成果物/作業の進め方/ユーザ指導などに対するユーザの疑問/指摘/要望に耳を傾け、問題点の解消に努力します。
- ベンダとユーザ間の情報共有・コミュニケーションに関して、常に関心を払いプロジェクト活動の充実を図ります。
|
３．管理手法
| |
ベンダ・メーカは少なからずプロジェクトマネジメントとしての「管理手法（技法）」を標準化として用意しています。プロジェクト活動の安定化のためのプロセス管理、数値把握と評価基準としてです。問題点の早期発見と有効な解決策実施が行えてこそ「管理手法」の意義があります。
|
| |
● 「時系列・評価基準による傾向・分析の重視」
① 作業フェーズの目的と特性に応じた指標を時系列で把握し、その傾向分析をし
ます。その指標の中に、目安として重要度ランクを設けます。
【例】 要件定義フェーズ（未確定仕様の「質」管理）
・ 管理基準未定仕様、取引条件未定仕様 －－－ Aランク
・ 業務処理未定仕様、例外処理未定仕様 －－－ Bランク
・ 出力画面・帳票/データの連携出力 －－－ Cランク
② 作業フェーズの進捗管理と品質管理においては、基準から見ての遅れ・劣化を
把握できる傾向分析が重要です。また、SE担当者の力量判断がポイントです。
【例】 プログラムテストフェーズ（問題管理の指標管理）
・ テストケースの消化率が一向に上がらない
・ 新たなテストケースが頻繁に発生する
・ 次のテストケースになかなか進めない
③ 指標などの「量」の管理とともに、難易度・重要度からの「質」からの分析も大事
です。
【例】 プログラムテストフェーズ（質の管理）
・ 先頭入力の画面、マスタ画面（登録・修正） －－－ 高い
・ その他のデータベース更新系プログラム －－－ 普通
・ 帳票系、データ活用系、照会系プログラム －－－ 低い
→ テスト効率と品質向上の視点からは上記ランクが全てではない。
● 「現在から見て、先々への影響評価を基準」
① 現在の問題点とともに重視すべきことは先々への悪い影響度合です。放置する
ことによるプロジェクト活動への影響大の事象発見です。
【例】 ・ SEが一向に仕様が固まらない、 ユーザの要件仕様が固まらない
・ 問題点は了解しているが、その解決の糸口が見つからない
・ テストにおいて、プログラム品質が改善されない
・ いつも作業スケジュールが予定通りに進まない
② 起こっている現象にとらわれず、それを生んでいる真の原因を究明して評価する
ことが先々への影響を食い止める方法です。真の原因への正しい評価です。
【例】 ・ ユーザの仕様が固まらない原因は、ユーザ体制が貧弱か経営者の
参画が弱い、又は無理な要求仕様を考えている
・ SEが作業を予定通りに消化できない原因は、担当SEの能力不足か
知識不足、又はユーザの協力が弱い
・ 問題解決が進まない原因は、ベンダのプロジェクトマネジャーの力量
不足、ユーザのプロジェクトマネジャーの力量不足、又は経営者の参
画不足に関連している
③ 先々を見ての評価と改善は、技術面・知識面・人間面・チームワーク面に係わっ
ており、クールで客観的な判断が必要になります。
（参考） 「トラブル（問題）の解決策と予防策」ページ
● 「レビュー・リスク回避・ユーザ支援への有効活用」
① レビューにおいて各指標が報告され、その問題有無を確認します。このとき、前
回レビューで問題を指摘された事項を確認します。
② 指標管理の情報とプロジェクト活動の問題/リスク意見などの情報を突き合わ
せて、リスク検討を行います。指標情報だけでは的確な判断は出来ません。
③ 指標評価と日常の観察でユーザの問題点を抽出し、ユーザへの支援と指導をタ
イミング良く行います。
|
● プロジェクト活動とプロジェクトマネジメント
| |
プロジェクト活動の局面によりプロジェクトマネジメントの対象と役割は異なります。その局面を「検討・準備、作業フェーズ、稼働準備」に分け、その特性に応じたマネジメントが必要になります。
|
| 検討・準備 |
- プロジェクト活動の開始前に確認すべきことは、ユーザとの契約内容です。
－ 作業フェーズの内容と成果物
－ スケジュール、納期、付帯条件
- ユーザプロジェクト体制の情報収集と実態把握です。
－ 責任者と経営者の参画度合
－ 責任者への権限移譲と責任者の力量
－ メンバーの作業時間（兼務実態）への考慮
（参考） 「ユーザのためのプロジェクトマネジメント」ページ
- ベンダプロジェクト体制の組閣です。
－ 必要技術と知識に応じたリーダ/SEのアサイン
－ プロマネの権限範囲、スタッフ要員の位置付け
- 実行計画書の作成をします。
－ リスク・不明事項の洗出しと対応方法
－ ユーザとの確認事項の整理と役割分担
－ 作業フェーズの組立て、作業内容、成果物の決定
【参考】 ダウンロード資料＜550 「実行計画書」構成モデル＞
|
作業
フェーズ |
【 共通 】
- 必要とするスキル/知識/経験のSE担当
- 成果物の明確化と品質確保の条件整理と実行
- 必要作業のWBSの具体化と詳細化
- 進捗/品質/問題管理の手順とルール化
【 要件定義・FIT＆GAP 】
【 テスト 】
|
| 稼働準備 |
- ユーザプロジェクトの支援として行います。この稼働準備はシステムの切替えとシステム稼働に多大な影響を与えますので、細大漏らさず支援することです。
- 対象としては、ユーザ社内/対取引先/現行システムになります。この中で、本番稼働に必要な作業を整理します。担当を「ベンダ/ユーザ/ベンダとユーザの共同」に分類し、役割を決めます。
- 稼働準備のためのプロジェクト体制を確立します。
（参考） 「大切な稼働準備と稼働品質」ページ
【 参考 】
プロジェクト終了時点で、ベンダとしての「プロジェクト反省レビュー」を
行うことを薦めます。メンバーを含めた率直な話し合いの場が多様な
反省材料を生みます。それがベンダの財産になります。
|
● プロジェクトマネジャー・リーダに必要なスキル
| |
マネジャー・リーダは、あらゆる資源（人・もの・金）を効果的に使うためのリーダシップの発揮と各種計画の立案能力とともに、プロジェクト活動を「４－５－３の視座」から捉え、「観察・把握→問題発見→評価・判断→行動・対策」の一連のサイクルを回すコントロールスキルが必要です。
【参考】 ダウンロード資料＜570「４－５－３」視座＞(Acrobat 9.0作成）
|
| |
コントロールスキルはプロジェクト活動の次のような側面を観る能力です。これらの側面の現象から真の問題点なり原因を探り、関係者の協力を得ながら本質的な解決策を導き出せることです。
１．観察・把握（「４ Relation」）
① リーダ・SEの行動 －－－ WBSの理解と計画（５ Box）、チームワーク、質問内容、
ユーザとの連携、情報入手、社会常識
② ユーザの行動 －－－ WBSの理解と計画（５ Box）、約束の履行、作業進捗、
疑問・不明の提示、担当SEとの連携
③ 成果物（中間含む） －－ 作成ドキュメントやシステム機能の的確性/分かり易さ/
/論理性、他WBSとの関連性/整合性、問題点の提示
④ 全体 －－－ クリティカルパスからのリスクの高いWBS、ユーザプロジ
ェクトのチームワーク、経営者の参画度合
（参考） 「トラブルの早期発見と兆候・現象・原因」ページ
２．問題発見（「５ Box」）
① リーダ・SEの行動 －－－ 作業遅延、成果物の品質不良、後向き/マイナス思考、
他SEとの協調性欠如、モラルの欠如
② ユーザの行動 －－－ 作業遅延、情報提供の弱さ、約束事項の不履行
③ ベンダ/ユーザの連携 － 情報共有/コミュニケーションの不足、チームワーク欠如
SEのリーダシップ不足、信頼感欠如
④ 全体 －－－ プロジェクトマネジャーの力量不足、計画の甘さ、ユーザ
責任者の力量不足、経営者の参画欠如
３．評価・判断（「３ Viewpoint」）
プロジェクト活動の作業進捗と成果物品質への影響から評価と判断を行います。問題を
発生させた真の原因を洗い出し、正しい評価をします。真の原因の多くは、「計画・スキ
ル・指導・工数・モラル・・・」などに求められます。
① 評価基準・決定 －－－ ・ 計画・品質基準からの評価実施
・ 到達点と先々への影響も考慮
・ 問題有りの場合はその問題発生の原因究明
② 代替・補強 －－－ ・ プロジェクトマネジャー/リーダ/SEの交代/補強
・ 成果物作成への支援、指導の強化
・ ユーザプロジェクトへの改善要望の提示
③ 再設定・修正 －－－ ・ 成果物内容の見直し、作業スケジュールの修正
・ WBSの変更・修正
４．行動・対策
① 評価・判断した内容（作業進捗・成果物・・）に基づき、改善策を関係リーダ/SEに
伝え徹底します。
② ベンダの責任組織に問題点/改善策を報告し了解を得ます。ユーザにも同様の行動を
とります。
③ 担当リーダ/SEへ変更事項を伝え、理解と了解を得ます。
④ 必要に応じて、全プロジェクトメンバーにも伝達します。
【参考】 ダウンロード資料 ＜595 「プロジェクトマネジャーのスキルと能力＞
【参考】 ダウンロード資料 ＜070 「プロジェクトマネジャーの評価方法＞
（参考） 「トラブル（問題）の解決策と予防策」ページ
|
プロジェクトマネジャーの資質と育成
| |
【 資質 】
プロジェクトマネジャーはプロジェクトマネジメントとリーダシップという両方のスキルと知識が必要です。これらのスキルと知識は形式的な机上のものでは役に立ちません。あくまで、実践的で実務的なものが要求されます。実践的に使えるためには本人の持っている資質も左右します。この資質を一つでも多く持っていることが望ましいです。
- 仕事に対して、プラス思考を持ち前向きな姿勢で臨む 。
- 好奇心が旺盛で、新しい仕事に興味と関心を持って入り込む。
- どんな問題発生にもその原因を究めて解決策を考えることが好き。
- ユーザの立場を考慮しながら、少しでもユーザに貢献する仕事への行動力。
- ユーザ/他SE/コンサルから常に学べることを探しながら、自分の作業責任を全う。
- 「言葉の理解」に敏感であり、曖昧な言葉使いには必ず質問を励行する習慣。
- 分かりやすいドキュメント作成を苦もなく、期限までに実施。
【 育成 】
プロジェクトマネジャーはキャリアパスなり研修受講で自然に育成が可能とは言えません。プロジェクトマネジャーはプロジェクト案件の実践という経験の中で鍛えられ育成されます。キャリアパスなり研修受講は一つの手助けにすぎません。実践での育成を行うための参考情報です。
- プロジェクトが終了した時点で、失敗点/成功要因/反省点を洗い出し整理を行います。
- 失敗点の場合は、その原因を徹底的に究明し真の原因を見つけます。ユーザの立場/相手の立場/プロジェクトマネジャーの立場/組織責任者の立場からの思考回路です。
- 業種と規模の異なるプロジェクトを経験させ、その違いと同じ点を気づく機会を作ります。
- 経営知識/心理学/組織論など学ぶ機会を設けます。
- トラブル案件に対して、責任ある立場で参加させトラブル復旧の経験を積ませます。
- ある程度、プロジェクトを経験したら、頭の整理のために研修を受けさせます。
- ユーザとの業務改善と問題解決の場を作り、ユーザとともに経験する機会を作ります。
- ベンダ社内の問題点を提起し認識させ、その問題解決の場と時間を提供します。ベンダ社内の問題を解決できない人がユーザの問題解決はできないです。
- 自分の「プロジェクトマネジメント教科書」を自分で創ります。（ノート/パソコンに）
－ 担当したプロジェクトの反省点/失敗点/成功要因
－ 業界動向、経営知識、業務知識、情報技術、組織論、人間心理
－ コンサル、ユーザ、SEなどから学んだこと、その他
【参考】 ダウンロード資料 ＜635 「プロジェクトマネジメント向上のために」＞
|
● プロジェクト活動における問題の発見と現象、又は問題発生の原因に関心
のある方は次ページを！
（参考） 「トラブルの早期発見と兆候・現象・原因」ページ
● プロジェクトマネジメントとしての問題解決策と予防策に関心のある方は
次ページを！
（参考） 「トラブル（問題）の解決策と予防策」ページ
● プロジェクトを成功させるために必要なプロジェクト管理の知識とスキルに
関心のある方は次ページを！
（参考） 「プロジェクト管理に必要な知識とスキル」ページ
