投稿

ラベル(ビジネス)が付いた投稿を表示しています

[ITコンサル]実務における課題管理のコツ

プロジェクトマネジメントにおける「課題管理」。 PMBOK等を見れば正解が載っているはずだが、PMBOKを勉強したことのない私が実務レベルにおいてPMOの視点で気を付けていることを纏めてみる。 課題管理の目的 課題管理を行う目的として思いつくのは以下の通り。 プロジェクトの中で上がった検討事項(課題)がもれなく検討完了する 検討状況を明らかにする、チームで共有する 課題によるプロジェクト影響を最小化する 課題のオーナを明らかにする 課題の完了時期を明確にし、タスクを明確化する 粒度感をなく挙げるといくらでも出てきそうなのでこの辺で。 課題管理で気を付けるべきこと 各課題の影響範囲を気を付けるのが重要。QCDの何に影響するのか、最悪の場合に発生するインパクトはどの程度か。多くの場合D(プロジェクト進捗)に影響を与えることが多いので、WBSのどのタスクに影響するのか、いつまでに課題が解決しているべきなのか意識しておくことが必要。影響範囲が不明であれば早急に明らかにすべき。課題検討している中で影響範囲の大きさに手戻りが発生したりというのはよくあること。 完了条件を意識するのも重要。各課題において何が完了したらクローズできるのか。課題が長期にオープンになっていると段々と論点が変わってしまい、結局何を議論してきたかわからなくなることがある(PMOがダメだと)。 各課題の責任者を明らかにするのも重要。誰も検討している認識がなくて放置されてしまうことがあるため。 課題管理表 管理に割り当てられる工数とプロジェクトのリスクを加味して管理項目を設計すべきだけども大抵の場合に設ける項目は以下の通り。 No 起票日 起票者 課題タイトル 課題内容 対応期限 対応者 対応履歴 ステータス(未対応/対応中/承認待ち/完了) 完了日 カスタマイズの例としては、例えば、完了条件が不明瞭になりがちなPJメンバーが多いようであれば、「完了条件」を管理項目に追加して起票ごとに記載させることも有効。 課題対応を促す方法 予定通りに課題対応が進まないことも多く、PMOの立場ではこの点が実務的には一番手間がかかるところ。相手が他社(協力会社やベンダ)であれば期限を切って実施させれば良いが、社内でチームを作っていたりすると、なれ合...

新しいクライアント先へ赴くときの準備

コンサルタントという仕事をしていると、定期的に新しいクライアント先へ赴くことになるのでその時のチェックリスト。 ・業界の勉強(書籍を2、3冊読み込む) ・案件の理解と案件に関連した実務経験の整理  → 自己紹介時に説明することになる ・提案書の内容を覚える  (会話ですぐ出せるように音読するくらいがいい) ・仮説を持っていく  → どう考えますか?って聞かれたときに何かアウトプットできるように   (最初はクライアントの状況は当然わからないので仮説で良い) ・身なりを小綺麗に  - スーツ、ワイシャツをクリーニング  - しっかりとしたペン、ノートを用意  - 髪を散髪・セッティング  → 第一印象が大事 ・名刺を確認 ・ティッシュ・ハンカチを確認  → 緊張すると汗かいたり鼻水が出る、、、 あと、キックオフミーティングがあるなら、、、、 ・資料印刷が必要か(プロジェクタがあるか)、必要なら何部必要か確認 ・スピーカー(喋り手)確認 とりあえずこんなもんかな。。。

会議開催時に気を付けること

イメージ
ビジネスをしていれば必ず実施する会議。 開催時に気を付けることをまとめる。 会議の目的を定める(明確にする) 基本的だがこの点が会議開催において一番重要。 会議開催するに至ったのであれば、何かしら目的があるはずだが、人によって意外と認識がずれているもので、明確にする・明文化することが重要。 また、目的を明確にすることで、参加者の意識が揃い、議論等が脱線しづらく、会議の長時間化を防ぐ効果も期待できる。 大きく分けて、目的は以下に分類される。 ・承認/合意を得る ・報告の実施 ・議論の実施 ・情報の共有 1点目であれば、だれに何を承認/合意を得たいのかを明確にする。 2点目であれば、だれに対して何を知らせたいのかをめいかくにする。また、報告内容を聞いた相手に対して、知ってもらうだけでなくアクションして欲しいなど有れば、その点も明確にしておく必要がある。(例えば、顧客を怒らせてしまったため、上長に経緯を理解してもらいたい、理解してもらえ たら、謝罪に同行して欲しい、等) 3点目であれば、論点を明確にする。何かしらの結論を導きたい場合は論点と共に検討の観点も事前に整理しておいた方が良いだろう。(例えば、次期のオフィスプリンターを選定する、という論点であれば、観点としては例えば価格と印刷スピード等があげられる) ブレストしたい場合は、論点だけ明確にしておけば良い。 4点目であれば、なぜ情報共有が必要なのかを明確にする。 例えば、新しいプロジェクトが開始されるが、今後各担当にお願い事項が発生するので事前にスケジュール感を情報共有したい、等。 因みに、1点目と2点目が会議の目的の場合、議事録は必須。3点目の場合で何かしらの結論を導く場合は、決定事項だけは議事録(議事メモでも良いかもしれない)として作成しておくのが望ましい。 アジェンダのサンプルを載せておく

可視化 情報共有(編集中)

イメージ
組織で仕事を効率に進めるためには 情報共有が重要だと思う。 同じ穴には落ちない。 成果を積み重ねる。 うまく情報共有が出来たチームには、 個々の強みを組み合わせることができ、 1+1=3の状態が作り出せる。 私なりのフレームワークを作ってみた。 まずは、情報共有に必要なアクション ・Make   情報共有するには情報を共有できる形にしないといけない。   俗人化しがちな情報・ノウハウをアウトプットすることが必要。 ・Share   アウトプットされた情報・ノウハウを他人が見れる状態にして、   初めて情報共有が可能となる。 ・Use   共有された情報・ノウハウを使って初めてその意味が生まれる。 そして、情報・ノウハウを付加価値の高いものとするMakeと進む。 これらアクションはなんら制御が無い場合循環しない。 その理由は、情報共有は組織のパフォーマンスを向上する手法であって、 個々人からすればどのアクションもオーバーヘッドに感じるからである。 これらをうまく循環させる要素が「motivate」、「system」、「organize」である。 ・motivate   俗人化しがちな情報・ノウハウをアウトプットさせるためには個々人の同期付けが必要。   例えば、   - 情報共有を当然とする社風   - 情報共有により仕事が効率化された経験   - ... ・system   アウトプットした情報・ノウハウを共有させるためには、仕組みが必要。   例えば、   - 情報共有用Webシステム   - メンバー皆がアクセス可能な共有ディスク   - メンバー皆が閲覧可能なキャビネット   - ... ・organize   共有された情報も必要な時にアクセスできなければ利用が進まない。   そのために情報の整理が必要。   例えば、   - フォルダ整理   - キャビネット整理   - 全文検索可能なWebシステム ただし、上記の循環要素もある程度情報共有が進んだ時に効果のある要素。 導入時期では各アクションを起こさせるための仕組みが必要。 <編集中>