プロジェクトオーガナイザの吉田聖書です。
今回は、プロジェクトの変更管理について
書いてみたいと思います。
プロジェクトは変動要素が多いもの。
ですので、変更管理を行って
それらを捌いていかないと
プロジェクトが破綻しかねません。
私がIT業界に入ったばかりの頃は
まだプロジェクトマネジメントが
今ほど成熟していなかったせいもあるでしょうが、
上からの、あるいは顧客からの
仕様変更は絶対命令の扱いでした。
その上、予算もスケジュールも変更なし。
残業と休日出勤で対応するということが
当たり前に行われていました。
ところが、無理やりやらせたところで
今度は品質の問題に発展します。
予定通りリリースしたは良いものの、
運用が始まるとトラブルが多発。
それはそうでしょう。
作業が増えてもリリース日が変わらないので
テストをおざなりにやるしかないわけです。
それはバグもいっぱい出ますよね。
某銀行の二重引き落としとか
覚えておられる方も多いのでは。
そういう経緯が直接的な引き金を
引いたかどうかは知りませんが、
ある時から「変更管理」というワードを
よく耳にするようになりました。
つまり、変更に対する要求を
受け入れるのか受け入れないのかを
きちんと定義されたプロセスに従って
処理をすることの重要性が
認識されてきているということです。
ということで、変更管理を実施する際の
3つのポイントを考えてみたいと思います。
(1) 変更管理プロセスは計画フェーズで定義しておく
これは、社内標準があれば
それを採用することで全く問題ないですが
このプロジェクトでの変更管理ルールは「これ」
というものを予め決めておくということです。
変更管理台帳のフォーマットがあれば
細かい条文はなくても対応できると思いますが、
泥縄で気分でルールを決めてしまうと
声の強い人の要求ばかり通る
ということになりかねませんので、
言葉で表現しておく方が良いです。
(2) 原則すべての変更要求を1か所に記録する
「原則すべて」というのは
実施するかしないかに関わらず、
すべてを一旦台帳に記録したうえで、
採否を決定する手順を踏むということです。
「1か所に記録」というのは
Jiraなどのクラウドサービスを使うか
Excelで管理する場合はバージョン管理を
徹底してロスがないようにするということです。
少なくとも、口頭でのやり取りだけで
済ませないことが一番重要です。
(3) 変更要求の優先順位を明確にする
予算が無尽蔵にあって、
期限をいつまでも延伸できるのであれば
全ての変更要求を受け入れれば良いですが
そのようなプロジェクトはまずないので、
どの変更要求を受け入れるかどうかを
以下の項目に基づいて選別することになります。
- その変更を実施する場合の追加のコストとスケジュール
- その変更を実施しなかった場合の影響
- その変更を実施しなかった場合に取りうる代替手段
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。