4つのMの変更への注意を怠るべからず。
品質を確保するためには、品質、コスト、納期の3つの条件を考慮し、生産の4つの要素(4M:マン・マシン・マテリアル・メソッド)の最適条件を設定する必要がある。
ねらい:品質
キーワード:4M、変更管理
4Mは一度決定しても変更時の管理を怠ってはならない
■第一のマン(Man)
人そのものだけでなく、人のモラールも含まれる。品質を確保するためには人のモラール、つまりは意欲、問題意識を持つことが重要となる。
■第二のマシン(Machine)
設備、治具、工具などが含まれる。ここでは不良品をつくらないための設備でのつくり込みが大切である。
■第三のマテリアル(Material)
不良品を入れないための原材料、加工品の取扱いが重要。
■第四のメソッド(Method)
良い品質をつくり出すための加工条件、作業方法、測定方法を最適化する。
品質トラブルは、4Mが変更になったときに発生することが多い。たとえば、作業手順に変更がある場合、生産ラインに急遽1名欠員が生じ、別のラインから1名応援を呼ぶ場合、熟練者であってもしばらくぶりに生産する製品である場合などがあげられる。
4Mが変更になる場合は、あらかじめ変更内容、変更時期、注意事項などを文書化し、関係する部署に伝えることが重要である。
4Mの変更管理によって、品質のバラツキを抑制しよう
第一線監督者は4Mの変更に関する情報を事前に把握し、変更時期までに対応する必要がある。変更後は、たとえば作業手順であれば、新しい作業手順の遵守状況、作業者の理解度を確認。その結果が不十分であれば、作業者への再教育を行う。
4Mの変更管理が適切に行われない場合、不良が発生し、ムダな材料費、労務費、加工経費が発生する。4Mを適切に管理するためには、誰もが同じ方法で作業できるように標準化し、第一線監督者がその標準に基づき作業指導を行う必要がある。
プロジェクトは組織が計画した戦略目標を達成する手段として活動する。プロジェクトの上位がポートフォリオであれば、ポートフォリオの目標に貢献するようにマネジメントし、上位がプログラムであればプログラムのベネフィット(便益や価値)。
プロジェクトを発起する理由
1)市場の需要
市場調査の結果から、新製品を開発する。
2)戦略的機会
新しいビジネス分野(多角化)へ挑戦する。
3)ビジネスニーズ
市場の変化に合わせて改革すること。
4)顧客要求
営業活動による受注プロジェクトを開始するなど。
5)技術的進歩
クラウド利用によるコスト削減など。
新技術による製品開発。
6)環境への影響
環境負荷の低減をはかる。
7)法的要件
規制緩和や撤廃に応じてビジネス範囲を拡大する。
プロジェクトでは、日常的に様々な変更が発生します。理想的には計画した内容から変更なくスムーズに進められる事が望ましいですが、現実的にはビジネスの環境変化に伴い変更が発生します。
様々な変更や変化に対応することをPMBOKでは、段階的詳細化といい、3つの考え方がある。
なお、これらの項目はデミングサイクル(PDCA)の概念基づきPDCAを回して詳細化していく考え方。
1)ローリングウェーブ計画法
直近の計画は詳細に記載し、先の計画は時期が近づいたら詳細化する計画法。次工程や次年度計画は、時期がきたら詳細化する。
2)継続的改善
作業時に不具合が生じてプロセスを改善して、それを計画書に反映することで教訓とする。次は反映した教訓を元にした手順を採用すること。
3)変更への対応
顧客からの仕様変更要求があり、それをプロジェクトで定めた手続きにて承認されると計画書に反映します。計画書に反映すれば、これに基づき作業され、変更が実施される。
ステークホルダーマネジメント
PMBOKにおけるステークホルダーマネジメントは下記のプロセスに従って実施することとされています。
ステークホルダーの特定
前述の主なステークホルダーをもとにプロジェクト関係者の洗い出しです。自社および顧客、さらに供給業者などのプロジェクトに関連する企業の体制図を描き、そこにできるだけバイネームで登場人物を記します。このとき大切なのが、単なる参加者の羅列ではなく、役割も記載しておきます。この体制図をもとに「ステークホルダー登録簿(一覧)」を作成して管理し、プロジェクト関係者全員で共有します。
ステークホルダー登録簿
ステークホルダー登録簿では、以下のような情報を管理します。
・識別情報:氏名、職位、所属/部署、役割、担当するシステムや工程など
・評価情報:プロジェクトへの期待、プロジェクトから受ける影響など
・分類:関心度と影響度など
例えば、個々のサブシステムの仕様は誰と打ち合わせるか、それらの仕様決定権は誰が責任をもっているのか、プロジェクト全体に関わる重要な問題は誰が方針決定するのか、など必要な役割をすべて洗い出すことでステークホルダー登録簿は「RACIチャート」の基礎情報にもなります。
次に各人物がプロジェクトに対してどのような立ち位置にいるかを「-1〜0〜1」として定量化します。
指標:
次にこの定量化した立ち位置を4象限のポートフォリオにまとめます。4象限のポートフォリオは、縦軸に影響度・横軸に関心度として表します。
縦軸:影響度
横軸:関心度
ここで、右上の象限(影響度が大きく、関心度も高い)に位置するステークホルダーを重点的に管理します。
次に、左上の象限や右下の象限に位置するステークホルダーを右上の象限に引き上げる活動を行います。
ステークホルダー・マネジメント計画
◎インプット
・プロジェクトマネジメント計画書
・ステークホルダー登録簿
・組織体の環境要因
・組織のプロセス資産
◎ツールと技法
・専門家の判断
・会議
・分析技法
◎アウトプット
・ステークホルダー・マネジメント計画書
・プロジェクト文書更新版
そして、ツールと技法の「分析技法」では、ステークホルダーの関与度の分析について紹介しています。
その中で、ステークホルダーの関与度を、次のように分類しています。そして、その分類結果を、ステークホルダー登録簿に記載することとなります。
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・中立:プロジェクトを認識しているが、抵抗も支持もせず、中立である
・支持:プロジェクトを認識し、積極的に支持する
・指導:プロジェクトを認識し、積極的に関与する
クリティカルパスを表す図式はアローダイヤグラムを利用することが多い。
なお、前回ご紹介した「プロジェクトスケジュール管理技法」のうち、ファストトラッキングは、「敢えて、クリティカルパス上の工程で、前の工程が完了する前に次の工程を開始すること。」という高度なスケジュール短縮テクニックです。
プロジェクトマネジメントでは、マスタースケジュール(大日程)や中日程でガントチャートを利用することが多い。
WBS
【Work Breakdown Structure】
別名:作業分解図,作業分割構成,ワークブレイクダウンストラクチャー
WBSとは、プロジェクトマネジメントで利用される計画手法の一種で、プロジェクトにおける作業を細かい単位に分割し、階層構造などで管理する手法のことである。
WBSでは、最初に必要な作業の洗い出しを行い、可能な限り(アクティビティレベル)細分化し、それぞれの作業について必要なコストや人員配分を割り出す。これによって、作業全体の把握や各作業の体系的つながりの把握を行うことができ、進捗管理や計画の調整に関する精度を向上させることができる。
WBSにおいて細分化された、作業の要素は、ワークパッケージなどとよばれている。
また、WBSとワークパッケージから作成されたプロジェクト遂行のための組織関係図がOBS(Organization Breakdown Structure)と呼ばれている。
【参考文献:IT用語辞典】
特に進捗報告において、「遅延が発生したから・・・」となると、そのリカバリにかかる工数は大きいです。
進捗の遅れを出さないためには、WBSで管理するワークパッケージごとに進捗を管理します。これを報告先に合わせた粒度で上長や関係者、ステコミなどに定期的に報告します。
この間には様々なビジネスにおける環境の変化が起こるのは当たり前のこととして捉えるべきです。
何故なら、ビジネスは生き物のように日々変化しているからです。このビジネスにおける環境の変化といっても外的要因もあれば内部要因もあります。
そのため、これらの事象をリスク管理として行うわけですが、QCDの観点から、おざなりになりがちではないですか?
※リスクの顕在化が少ないと整理しているのも含まれます。
英国商務象省の公認の<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント資格</a>である「PRINCE2」には、
「ビジネス・ケースの有効性が消滅したら、理由が何であれ、プロジェクトは中止すべし。」
とあります。
これは当たり前のことではあるものの、これまでの投資額が無駄となりますし、更なる対応には追加コストが発生することもあるため、判断に迷うこととなります。
投資額の回収期間によっては、中止しない判断もあり得ますが、一端中止が決まると、責任問題に発展する可能性もあるので慎重にことを運ぶ必要があります。
CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)という管理手法をご存知だろうか。
この「CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)」とは、「不確実性を管理するため、実作業を伴わない工数をバッファとして確保する。バッファはプロジェクトの各タスクの予算やスケジュールをギリギリに抑え、それをプロジェクト・バッファと合流バッファ(フィーディングバッファ)いうかたちで確保し、プロジェクトバッファはマスタースケジュールの最後尾に設け、リーディングバッファは工程の合流ポイントに設ける」管理手法です。
すなわち、プロジェクトの各タスクの予算やスケジュールを各工程から10〜20%を抑えて、その分をプロジェクト・バッファや合流バッファ(リーディングバッファ)という余裕を設けておくことで、例えばある工程で「工数不足が発覚したら後からバッファを割り当てる」ことや、「あらかじめ工程の合流ポイントにリーディングバッファとして設ける」などにより、遅延を回避します。
通常、これらの工程はある程度余裕を含んでいます。各工程で見ている余裕を20%とした場合、それらを取っ払ってぎりぎりで計画します。
CCPMの注意
プロジェクトバッファはコストとスケジュールの両方に対して抑制しますが、スケジュールについては「クリティカルパス」を考慮してバッファを設けることをしてください。
なぜ、このような管理手法が必要なのだろうか。これはパーキンソンの法則を活用しています。
それは人は目の前の目標に向かって進む習性があるので、余裕を含んだ計画値を与えたらその計画通りに作業をしてしまいがちだからです。
これを回避する考え方を取り入れたマネジメントがCCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)という管理手法です。
バッファを捻出する
? WBSを展開する
? 個々のタスクの工数を精緻に見積り、合計を正規の計画とする
? 個々のタスクの余裕分を取り除き、合計をぎりぎりの計画とする
コストの余裕分は、一律10〜20%
日程の余裕分は、クリティカルパスを除く工程で10〜20%で、且つ削減後でもクリティカルパスより短くならない数値とする
? 正規の計画―ぎりぎりの計画=バッファとして準備する
このようにして捻出したバッファですが、誰が消費しても問題にはならないことを全員が共有することです。つまり、バッファがマイナスになって初めて予算オーバーとなります。
・利用者/業務担当者、業務管理者、部署長
・ベンダ(納入業者)やサプライヤ(供給業者)
こうした幅広いプロジェクト関係者と良好な関係を築きプロジェクトを円滑に進めていくことがプロジェクト管理には求められます。
ステークホルダーマネジメントの実施
PMBOKにおけるステークホルダーマネジメントは下記のプロセスに従って実施することとされています。
ステークホルダーの特定
前述の主なステークホルダーをもとにプロジェクト関係者の洗い出しです。自社および顧客、さらに供給業者などのプロジェクトに関連する企業の体制図を描き、そこにできるだけバイネームで登場人物を記します。このとき大切なのが、単なる参加者の羅列ではなく、役割も記載しておきます。この体制図をもとに「ステークホルダー登録簿(一覧)」を作成して管理し、プロジェクト関係者全員で共有します。
ステークホルダー登録簿
ステークホルダー登録簿では、以下のような情報を管理します。
・識別情報:氏名、職位、所属/部署、役割、担当するシステムや工程など
・評価情報:プロジェクトへの期待、プロジェクトから受ける影響など
・分類:関心度と影響度など
例えば、個々のサブシステムの仕様は誰と打ち合わせるか、それらの仕様決定権は誰が責任をもっているのか、プロジェクト全体に関わる重要な問題は誰が方針決定するのか、など必要な役割をすべて洗い出すことでステークホルダー登録簿は「RACIチャート」の基礎情報にもなります。
次に各人物がプロジェクトに対してどのような立ち位置にいるかを「-1〜0〜1」として定量化します。
指標:
次にこの定量化した立ち位置を4象限のポートフォリオにまとめます。4象限のポートフォリオは、縦軸に影響度・横軸に関心度として表します。
縦軸:影響度
横軸:関心度
ここで、右上の象限(影響度が大きく、関心度も高い)に位置するステークホルダーを重点的に管理します。
次に、左上の象限や右下の象限に位置するステークホルダーを右上の象限に引き上げる活動を行います。
ステークホルダー・マネジメント計画
◎インプット
・プロジェクトマネジメント計画書
・ステークホルダー登録簿
・組織体の環境要因
・組織のプロセス資産
◎ツールと技法
・専門家の判断
・会議
・分析技法
◎アウトプット
・ステークホルダー・マネジメント計画書
・プロジェクト文書更新版
そして、ツールと技法の「分析技法」では、ステークホルダーの関与度の分析について紹介しています。
その中で、ステークホルダーの関与度を、次のように分類しています。そして、その分類結果を、ステークホルダー登録簿に記載することとなります。
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・中立:プロジェクトを認識しているが、抵抗も支持もせず、中立である
・支持:プロジェクトを認識し、積極的に支持する
・指導:プロジェクトを認識し、積極的に関与する
企業(Enterprise)内の活動をすべてプロジェクトとして捉えて管理するものです。たとえば人事部門であれば、新卒採用、中途採用、給与計算、目標管理、年末調整などさまざまな業務がありますが、こうした業務をそれぞれプロジェクトとして管理することで、業務効率が高まり、無駄な作業を減らすことができます。また、単に組織内の複数プロジェクトを束ねて管理/見える化することを指すこともあります。
そのため、ここではEPMを以下のように定義します。
EPM(Enterprise Project Management)の定義
・企業内の全ての業務をプロジェクトとして管理する
・組織/企業/機関/団体のレベル内で発生する複数プロジェクトを束ねて見える化する
ここで、プロジェクトマネジメントを学んでいるかたなら不思議に思うのが、「EPMで管理する業務には定常業務を含むのか?」だと思います。
そう、定常業務といったルーティンワークをプロジェクトとして捉え管理することで、惰性や慢性を排除して、常に改善策や最善策を検討するように意識改革することで、業務効率化され、生産性が向上し、筋肉質な企業として鍛えられます。
EPMの重要性
近年、EPMの重要性が叫ばれています。これまでのように1つ1つの業務をマネジメントしていない状況は言わば「どんぶり勘定」も同然の管理されていない状況です。これでは、業務改善も掛け声ばかりでままなりません。WBSで対象業務のタスクを洗い出し、ガントチャートで進捗をトラッキングし、工数管理でかかったコストを定量化する。業務をプロジェクト化することにより、初めてこうしたプロセス改善が実現して企業の競争力を高めることができるのです。
これまでプロジェクトとして捉えていなかった業務をもプロジェクトマネジメントの対象として管理するEPMを実践することは有効だと考えます。管理部門や営業部門など非開発部門におけるコストとスピードの改善までメスを入れることができるからです。
定常業務をプロジェクト管理するイメージ
例えば、ある定常業務を担う部門での年間計画で以下のような活動をすることでプロジェクトマネジメント(QCD)のうち、スケジュール管理を実施します。
・期初に部門のアクションプランを策定する
・アクションプラン別に今期の取り組みをWBSに分割する
・各たすくに担当者をアサインする
・ガントチャートにスケジュール登録する
その後はWBSをもとに進捗率を週1回程度の進捗報告にて確認し、遅延があればリカバリプランを提示します。
EPMの課題
EPMを実現するにはシステム(ツール)が必要です。管理のための負担が増えたり、見える化するために余計な作業が増えたりするようでは、効率化と情報共有というメリット以上に管理コスト増となり、やる意味が薄れます。
EPMを実践するには、効率的にプロジェクトとして管理できる仕組みに加えて、余計な手間をかけずに自動的に情報が組織で共有される仕組みが必要です。
変革趣意書のポイント
なお、プロジェクト憲章と変革趣意書をベースにプロジェクト計画書を作成します。
➡目標に沿った品質
➡開発規模に応じた適正なバグ件数を検出することを目標とする。
➡バグ分析時の横展開による類似バグの撲滅
➡構成管理の重要性、設計思想からの品質管理など
➡試験シナリオが適切でないため、バグを検出できていないと考えるべき。
※追加試験は品質向上(Q↑)のために、期間延長(D↓)、コスト増加(C↓)となることに留意します。
そのため、このプロジェクトでは「QCDのうち何が最も重要な指標」であるかをプロジェクトスポンサに確認しておき、変革趣意書にまとめておくのも良いと思います。
<a target="_blank" href="https://www.amazon.co.jp/gp/product/4817192631/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4817192631&linkCode=as2&tag=miniminiadmin-22&linkId=9d5f071a80cf7739c3f8e40526ff8db0"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&MarketPlace=JP&ASIN=4817192631&ServiceVersion=20070822&ID=AsinImage&WS=1&Format=_SL110_&tag=miniminiadmin-22" ></a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=miniminiadmin-22&l=am2&o=9&a=4817192631" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />
ステージゲート法
ステージゲートは、新規事業や新製品のアイデアが生まれてから、事業化・製品化されるまでに必要なステップと作業ロードマップを与える考え方です。特徴は、開発プロセスの途中の過程で経営判断を行う「ゲート」によってステージに分けていることです。
この方法では、機能組織に合せたステージはなく、ステージは基本的に組織横断的なプロジェクトで構成され、ゲートに進むために必要な作業は並行して行われます。
また、ステージでは技術、市場、資金、オペレーションなどのリスクの管理をするために、必要な情報が収集されていきます。
ゲートのもっとも重要な役割は、評価の低いプロジェクトを中止し、そのリソースを見込みのあるプロジェクトに再配分する。ゲートにおける評価は、ステージで生まれた成果の質、経済合理性などに注目し、それぞれのプロジェクトがどの程度の成功をおさめるかを評価します。イノベーションでは、この評価とリソースの再配分が成功の分岐点になるのです。
このステージゲート法をITにおきかえて考えます。ステージ≒工程やフェーズとすると、「プロジェクトフェーズ/工程の1つが終了したら、そこまでの成果物とパフォーマンスを検討して、プロジェクトを先に進めるかどうかを判断」することになります。
このステージゲートは品質管理や調達マネジメントの観点からも重要なポイントです。
このステージゲートのイメージを工程別に記載します。
システム構築工程別のステージゲート
要件定義工程
要件定義書を作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。その結果、要件定義書へのユーザー側の権限者による押印などの承認行為。
設計工程
基本設計書(外部設計にあたる画面定義や画面項目定義、インターフェース定義など)を作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。その結果、基本設計書への開発実施責任者などの権限者による押印などの承認行為。
会社によりPMOも参加する。
開発工程
単体試験や結合試験結果報告書に開発実施責任者などの権限者による押印などの承認行為。
会社によりPMOも参加する。
試験工程
システム試験結果報告やシステム間連携試験、接続試験、受け入れ試験などによる機能要件やシステム環境、業務フローによる業務継続性の検証などの結果報告と開発実施責任者などの権限者による押印に加え、受け入れ側による承認行為。
会社によりPMOも参加する。(実際に独自のシナリオにて試験を実施することもある。)
本番移行工程
UAT(受け入れ試験)結果報告と共に本番環境への摘要是非を問う本番環境リリース判定や、システム切替などのタイミングにて実施する移行判定や初回稼働確認による移行完了確認など。
これまで、一般的な企業(事業会社等)では、ベンダにシステム構築を丸投げしていませんか?
また、自社で開発している企業でも、中小のITベンダでも、
「名ばかりのプロジェクトマネジメント」
ではありませんか?
これらにより、引き起こされるのは「開発したシステムが稼働しない・バグ多数」「要望通りの機能ではない・業務では使えない・機能要件にマッチしない」などです。
要は無駄な投資になる。ことです。
まだまだ、一般企業の情報システム部門では取り入れ出来ていない・受け入れ出来ていない・正しく活用出来ていないのは、プロジェクトマネジメントの必要性や使い方への理解が足りていないことです。ここで今一度、必要性について再認識してもらう必要があると思っています。
その点でも、この「世界一わかりやすいプロジェクトマネジメント 第4版」は、プロジェクトマネジメントの必要性を分かりやすく説いている優良書といえます。また、PMBOKガイドでは理解しにくい表現(英訳が分かりにくい)も多く読みにくい印象ですが、本書は読みやすい表現になっているため、PMBOKガイドを読む前に「PMBOKの概要」や「プロジェクトマネジメントとは」を理解するのに適しています。
これからPMBOKを勉強する人やプロジェクトマネージャを目指す人は必読・必携です!
なお、実践でも役立つ経験則やらヒューマンスキルなどもフォローしています。
以下、出版社(総合法令出版)のホームページより抜粋。
アマゾンジャパン「オールタイムベストビジネス書100」に選ばれた名著の最新版!
プロジェクトマネジメントとは、「ヒト」「モノ」「カネ」を適切に管理し、プロジェクトを納期どおりに完成させ、かつ想定したどおりの利益を生み出す活動のこと。そのテキストとして世界中のプロから推薦を受けている「Idiot’s Guides, Project Management」の最新バージョンの日本語訳版がついに登場。
プロジェクトマネジメントの各フェーズごとに、想定されるリスクを乗り越えて成功に導くための具体的ノウハウやツールを紹介。また、プロジェクト・マネジャーとしてチームを率いていくためのアイデアを実践的に提供する。
プロジェクトマネジメントのデファクトスタンダードである「PMBOK」の最新第5版に完全準拠しているので、グローバルなプロジェクトにも対応。アマゾンジャパンが昨年10月に選出した「オールタイムベストビジネス書100」の中で、プロジェクトマネジメント関連で唯一選出された、プロジェクトマネジメントの基本中の基本書である。
パート1 プロジェクトマネジメントの威力
パート2 プロジェクト定義フェーズ
パート3 プロジェクト計画フェーズ
パート4 プロジェクト実行フェーズ
パート5 監視とコントロール・フェーズ
パート6 プロジェクト終結フェーズ
付録
巻末資料
このような状況での課題解決をイメージしてみて下さい。その都度、その都度で状況がかわり、「誰に何を聞いたら解決するか?」といった単純なことで時間を費やすことが多いです。その解決策として、RACI図(RACIチャート、レイシーチャート)は使えます。
RACI図やRACIチャート、レイシーチャート
RACI図(英: RACI diagram)は、プロジェクトや何らかの工程をチームあるいは人々に役割分担させる際に使用される図の一種である。複数の組織が共同で行うプロジェクトマネジメントなどで、役割分担を明確化するのに特に有効とされる。RACIチャートとも。
プロジェクトの各タスクについて、関係者がどのような役割を担っているのかを明確にするために使われます。
RACI図は、タスクを4種類の参加者の責任型に分割する。また、プロジェクトや工程毎に各参加者には異なる役割が割り当てられる。この責任型の名称の頭字語が RACI である。
Responsible(実行責任者) - タスク達成のために働く責任者。複数のリソースについて責任を持つことがある。
Accountable(説明責任者) - タスクの正しい完了について外部からの問合せに対して責任を持って対応する。各タスクの窓口は1つでなければならない。
Consulted(協業先) - 意見を求められる者。双方向の対話。
Informed(報告先) - 進捗を常に把握している者。一方向の通信。
実行責任者と説明責任者は同一の人間に割り当てられることが多い。それ以外では、一般にプロジェクト管理の各タスクについて、各参加者が高々1つの役割を割り当てられるのが推奨されている。
しかし、企業や組織によっては、1人に複数の責任型を割り当てることもある。これは、役割が計画時点で決められないことを暗に示しており、各タスクにおける役割分担を明確化するというRACI図の価値を減じることになる。
RACI図は、タスクと参加者を並べた2次元の表の形式であり、各マスがタスクと参加者の組合せを表している。そして、各マスに R/A/C/I の責任型を割り当てていく。何も割り当てられないマスもあるし、1つのタスクに4つの責任型が揃わないこともある。
(Wikipediaより抜粋)