プロジェクトの本質(基本)

プロジェクトマネジメントの本質(基本)   【Nの流儀(極意)】 @NAMBU2017  H0807d

プロジェクトの本質は“不確実性”にあり
プロジェクトはリスクとの戦いであり、リスク管理の重要性を認識する必要がある
・・・ リスク管理とは、影響を最小限に抑える手を打っておくこととも言えます。
* 繰返しのない仕事である「プロジェクト」は、“計画が全て”です・・・「段取り八分」

・プロジェクトは 「不確実性があり、難しいもの」と認識することがポイント!
だから、うまくやれば ”価値(利益)を生み出せる” 面白いビジネスになるのです。 nambu

○プロジェクトの特徴である独自性の存在そのものが、 “リスクが存在する“ということ
ロジェクトは、特定の目的・目標を、期限内に、予算範囲内で、達成するための独自の活動(組織)であり、
基本的には “初めてヤル” 活動です。
未経験(初めて)の活動には、当然それに伴うリスクが必ず存在するものです
このリスクの存在を明らかにして、どのように対処するかが、プロジェクトマネジメント成功の鍵となります。

○未然防止は、まさに「リスクマネジメント」
PM(プロジェクトマネージャ)の仕事は、起きてしまった問題に対応して解決することではありません。
常に(毎日)、問題が起きないように未然防止策の立案と実行に努めていることが、まさに仕事をしていることです。
~ 必要なものは ⇒ 火種(ひだね)のニオイを嗅(か)ぐ “力量(りきりょう)” !

○ほころびを繕うことも、未然防止に
メンバーの士気が下がってきた時やその兆候を感じた時など、常に気をつけていることが大事なこと。
顧客や部外者との関係や、開発環境の不備や障害にも注意しなければなりません。

※プロジェクトマネジメントには、近代的な手法を理解し習熟することが欠かせませんが、現場の経験でしか身につかないマネジメント能力が多いことも事実です。
また、プロジェクトで直面する問題・課題・リスクはそれぞれの場合で異なり、経験で培われた判断力・指導力・実行力が要求されます。
これらは、暗黙知・経験知と言われるもので、「創造のプロセス」にも通じるところだろう (N)
【参考】 茂木健一郎が解く 先輩南部陽一郎のひらめき ~「ほがらかな探究」より

 

■プロジェクト成功の条件

・納期(期限内に)
・コスト(予算金額内で)
・技術(期待レベルの技術成果の元で)
また、資源を有効活用し、顧客が満足する状態で完了することとも言えます。

 

○プロジェクトマネジメントの活動

・企画
・リスク測定
・資源の見積り
・WBS(Work Breakdown Structure)の作成 ~“計画”が全て!
・(人的・物的)資源の確保
・費用の見積
・チームメンバーへの作業の割り振り
・進捗管理 ~実行されなければ意味がない!
・目的に沿った方向性の維持 = “監視と制御”
・結果の分析

○監視と制御(コントロール)・プロセス ~広い意味での“進捗管理”のこと
… チェックと是正をまとめて監視プロセスと言われる
・計画のずれを把握
・計画の修正活動
・利害関係者からの変化項目の受理と評価
・必要に応じたスケジュール変更
・必要に応じた資源量の変更調整

 

■プロジェクトにおけるトラブルや危機の(例) ・・・ リスクが現実となる時

(1) スケジュール遅延
・進捗が可視化されておらず、管理できていない
・上位工程の遅れに引きずられることも多い
特に要件定義~“業務仕様” に着目すること、基本設計が重要
・プロセス(WBS作業、工程)は絶対に省かない ・・・必ず品質の劣化として現れる!
(2) 仕様変更/追加
・変更管理ルール/ガイドラインが守られていない(無い場合は論外だが・・・)
特に、最終テストが完了した後での仕様変更は厳禁! … 致命傷になることもあるので要注意
・顧客の勝手な要求だったり、SEが要件を理解できていないことが多い
・要件定義を正確に記述しておき、不要な仕様変更を未然に防ぐ
・原点となる業務要件/スコープ/プロジェクト方針/契約内容に戻る
(3) オーバーフロー(作業量/工数オーバー)、士気低下
・早急に対策をうつ ・・・遅くなれば遅くなるほど傷が広がる
(4) メンバーの交代、人材不足(貢献できない要員)
・安易な新規メンバー投入は極力しない方が良い … 大きなリスク
(5) 利害関係者(ステークホルダー)のコミットメント
・文書化されているか ・・・あとで、言ったとか言わないとかの問題にならないように
(6) WBSの不備
・モレや未定となっている仕様が放置されたまま、開発が進んでいく
(7) 開発環境の不備 ・・・テストの段階になって、やっと気が付いたりすることがないように
(8) システム性能が出ない、サービスレベルが守れない
・事前の検証が必ず実施されているか ・・・ デッドロック問題などにも要注意
(9) データ移行は最難関  … 甘く見ないこと! (N)
・ベテランSE(業務に詳しい)が関与・投入されているか
現状のシステム/業務を詳細まで理解できていないと、稼働にたどり着けずに大へんなことになる

 

【附録】

□ITプロジェクト失敗の理由(原因) ・・・ 一般的に言われていることだが

・顧客からの情報不足 ? ・・・ 上級SEのコミュニケーション能力や業務知識不足
・要求仕様が不完全 ・・・ 顧客/開発側両者の能力不足
・要件定義の不備(正確に文書化できていなかったり、合意・承認されていない)
・要求仕様の変更 ・・・ 顧客/開発側両者の能力不足
・変更管理の不備 ・・・ 特に、テスト完了後の仕様変更は絶対しない ⇒ 部分的に稼働を延期するなども
・経営トップの支援欠如 ・・・ 顧客指導ができていない
・技術力の不足 ・・・ PM能力(マネジメント力)不足
・計画不備(予算不足、開発側の能力不足、技術習得が間にあわない、トレーニング不足なども)
・開発工数の不足 ・・・ 見積/計画不備
・非現実的な期待値?のまま開発が進んでいく ・・・ 契約時に夢のような甘い言葉は厳禁
・不明瞭な開発目的 ・・・ プロジェクト方針/スコープに立ち戻ることも必要
・非現実的な開発期間 ・・・ 出来ないことは、始まる前にハッキリ言う!
・最新技術への盲信 ・・・ 初めて導入する技術は、必ず事前検証をしておくこと