Виявлення ієрархії робіт, визначення їх виконавців дозволяє описати систему підпорядкування членів команди проекту, розподілу відповідальності між ними. Для цього можна використовувати матрицю відповідальності.
При розробці матриці відповідальності виходять з наступних визначень:
Відповідальність - зобов'язання, яке людина повинна виконувати;
У наведеному вище прикладі ми маємо дві великі групи стовпців: «Дії і обов'язки». Стовпець «Активність» підрозділяється на опис фази і фази, а стовпець «Відповідальність» підрозділяється на необхідні дії. На перехрестях згадуються члени команди, відповідальні за ці дії.
Проекти з деяким розміром зазвичай включають кількох учасників, які несуть відповідальність за створення і затвердження результатів. Є результати, чия відповідальність за розвиток відносно проста; наприклад, коли визначено, що хтось несе відповідальність за складання документа, і інша людина його схвалює. Однак, якщо виробництво документа пов'язано із зусиллями кількох людей, необхідно визначити кілька рівнів схвалення. Інструмент, який допоможе вам у цьому типі ситуації, називається матрицею обов'язків.
Сфера відповідальності - коло завдань, за успішне вирішення яких відповідає людина в даному проекті;
Повноваження - право на прийняття рішень в рамках виділеного кола завдань.
Покрокове побудова матриці відповідальності проводиться в такому порядку:
Складається список основних результатів проекту (в їх число включають і продукти проекту, і проектну документацію);
У матриці різні люди відображаються у вигляді стовпців, а результати відображаються в рядках. Перетин вказує відповідальність кожної людини в кожному з результатів. Нижче представлена проста матриця з описом пропонованих обов'язків. У попередній таблиці Статут проекту створюється керівником проекту і схвалюється спонсором проекту, директором проекту і Керівним комітетом. Проектна група консультується при створенні Статуту.
Вимоги до проекту створюються командою проекту, які розглядаються керівником проекту і директором проекту і схвалені спонсором проекту і Керівним комітетом. Метою матриці підзвітності є забезпечення ясності і згоди щодо того, хто що робить, щоб стовпці могли бути визначені як можна більш детально в міру необхідності. Наприклад, в попередньому випадку команда проекту могла бути розділена на кожного з її членів, з конкретними іменами в окремих стовпцях. Потім особа, відповідальна за створення вимог до проекту, може бути зазначено у відповідній колонці.
Складається список учасників проекту;
Будується таблиця, на початку кожного рядка якої вказують будь-якої результат проекту, а на чолі колонки - конкретного учасника проекту;
В осередку, утвореної рядком і колонкою, вказують функцію або роль, які закріплюються за даними учасником проекту для отримання бажаного результату.
Після того, як матриця буде завершена, вона повинна бути поширена для затвердження, щоб підтвердити, що кожен розуміє і погоджується з їх ролями та обов'язками в проекті. Якщо це зроблено на етапі визначення проекту, воно може бути включено в проект.
Групи процесів управління проектами
Здатність матриці чітко повідомляти про це є вирішальною для її ефективності. Він повинен відображати очікування і обов'язки окремих осіб, організацій чи організацій, що беруть участь в проекті, і уникати будь-двозначності, якщо це можливо. Методологія управління проектами, прийнята Регіональним судом 7-го регіону, заснована на 5 взаємопов'язаних групах процесів, які визначають, як керувати проектом. Це: ініціювання, планування, моніторинг та контроль, виконання та закриття.
У матриці відповідальності використовують наступний перелік функцій або ролей учасників проекту:
- « Про - відповідає »- той, хто несе відповідальність за даний результат (зазвичай це хтось із числа членів команди, які безпосередньо забезпечують отримання даного результату);
- « У - стверджує "- той, хто стверджує результат (вибирається з числа осіб, які беруть остаточне рішення про виконання роботи і як результат);
Нижче перераховані основні документи, підготовлені в кожній з груп процесів. Він формалізує вимоги проекту і підтримує аналіз його здійсненності. . Опис продукту: В цьому інструменті продукт уточнюється і узгоджується між сторонами. Інформація записується про те, що буде згенеровано, в якому секторі, технічні характеристики, основних джерелах, результатах і технологіях, зокрема, важливі.
Матриця комунікації: документ, який ідентифікує людей і організації, які впливають або залежать від проектів - зацікавлених сторін, що означає зацікавлені сторони, - і визначив комунікаційний підхід з ними. Список ризиків: документ, в якому перераховані і проаналізовані всі ризики, пов'язані з проектом. З огляду на, що ризик є як потенційну загрозу, так і потенційну можливість, мета управління ними за допомогою інструменту полягає в збільшенні ймовірності і впливу позитивних подій і зменшенні ймовірності і впливу негативних подій на проект.
- « До - консультує »- той, хто дає додаткові орієнтири для своєчасного отримання якісного результату (в цій ролі виступають досвідчені в цій галузі люди, які не входять до числа осіб, що приймають остаточне рішення);
- « І - інформує »- той, кого обов'язково треба інформувати про отриманий результат (це ті члени команди проекту, дії яких залежать від якості і часу отримання даного результату).
Протокол засідання: документ, в якому підсумовуються випадки, резолюції, резолюції і рішення нарад або зборів. Запит, аналіз і контроль змін: документ, який реєструє ідентифікацію, документацію, твердження або відхилення і контроль змін, внесених в базові показники проекту. Журнал подій: дозволяє консолідувати непередбачені події при плануванні проектів в одному інструменті для кращого контролю. Термін поставки: реєструє, які продукти були доставлені, і час їх затвердження типу. Витягнуті уроки: моменти, зарезервовані для оцінки дій, проблем, успіхів і відображення досвіду, отриманого в проекті. Ці уроки записуються на зустрічах з Бюро по проектам. Терміни омологації: документ, що підтверджує повне чи часткове прийняття заявником заявки, зазначеної в терміні поставки. Документи, створені в цій групі процесів, такі ж, як в групі виконання.
При розподілі ролей і функцій намагаються не призначати більше одного відповідального за даний конкретний результат для того, щоб уникнути ефекту колективної безвідповідальності. Також стежать за тим, щоб не залишилося такого результату, за який ніхто не несе персональної відповідальності. Прагнуть також уникнути численних тверджень, щоб не затягувати цю частину роботи. В якості консультантів вибирають тих, хто дійсно має ті якості експерта з даного кола завдань.
Витягнуті уроки Остаточний: документ, складений з урахуванням всіх засвоєних уроків, записаних під час виконання проекту. Заключний звіт проекту: консолідує остаточну інформацію про проект, таку як: цілі проекту, продукти, поставлені в ході проекту, загальний час, витрачений на проект з моменту його створення до видачі заключного терміну прийняття та інвестицій, зроблених в проекті. Чому управління ризиками в проекті важливо?
По-перше, будь-яке рішення проекту, командна діяльність або новий етап має вбудований рівень ризику, незалежно від того, хочете ви цього чи ні. Тобто існує ймовірність того, що проблема буде реалізована і створить негативний ефект для кожного виду діяльності, доставки або етапу вашого проекту.
Нижче показаний приблизний вигляд матриці відповідальності проекту.
Знаючи перелік і порядок робіт, маючи список відповідальних за їх виконання, можна скласти календарний план-графік проекту. У плані-графіку проекту вказуються планові дати початку і завершення всього проекту, його окремих фаз, пакетів робіт, окремих робіт і конкретних операцій. Наявність такого розкладу допомагає контролювати терміни виконання робіт, будувати прогноз про своєчасність завершення проекту в цілому.
Коли наслідки малі, вони зазвичай навіть не створюють головний біль, але уявіть, що втратите все віртуальні документи компанії, не маючи резервної копії в проекті для впровадження нової системи або не маючи запасний частини для обміну частинами дефекти прототипу, які будуть представлені. Ці ефекти можуть бути катастрофічними, і тому управління ризиками набуває все більшого значення в управлінні проектами.
Крім того, відстеження та відстеження ризиків можуть допомогти вам в оцінці вашого проекту, щоб уникнути проблем, які можуть мати великі шанси на успіх. Щоб отримати цей результат, важливо зрозуміти трохи більше про самому управлінні ризиками. Планування управленіяРіск-ідентіфікаціяРеалізація кількісного аналізу Проведення якісного аналізу Планування ризику Відповідні ризики. Перш ніж йти на крок за кроком на практиці, давайте трохи докладніше про те, як працює матриця ризику і як вона може допомогти вам в основному з етапами аналізу ризиків.
Порядок розробки плану-графіка проекту включає наступні кроки:
Визначення взаємозв'язків між роботами (операціями) і контрольними подіями проекту;
Оцінка ресурсного забезпечення робіт (працівники якої кваліфікації потрібні, коли, на який період);
Оцінка тривалості робіт (іноді робиться кілька варіантів оцінки: для сприятливого розвитку подій і окремо для несприятливого);
Як працює матриця ризиків
Матриця ризиків, як сама назва говорить, є матрицею, яка допоможе краще оцінити ризики, пов'язані з вашими проектами. Він формується двома основними осями, ймовірністю виникнення ризику і впливом ризику в проекті. Тепер давайте трохи докладніше розглянемо, як працюють відповіді цих двох осей. Майже правильно: практично неможливо запобігти ризику виникнення, тому він платить, щоб думати про пом'якшуючих діях впливу ризику після його виникнення. Високий: ймовірність виникнення ризику велика, і часто це відбувається насправді. Як і раніше варто планувати розгортання, але не з такою ж великою стурбованістю, як в попередніх випадках. Низький: мало шансів на виникнення проблеми, що виникає в зв'язку з цим ризиком. Рідко: малоймовірно, що ризик буде мати місце, тільки варто турбуватися про випадки серйозного впливу або дуже серйозно для вашого проекту. Суворе: це може привести до скасування проекту або до того, що завдані йому збитки є незворотнім. Просто зверніть увагу, якщо цей ризик відбувається майже напевно і з високою частотою. В принципі, для кожного проаналізованого ризику ви дасте оцінку, яка коливається від майже певного, від того, що відбувається до рідкісного і від будь-якого впливу до дуже серйозного.
Оптимізація розкладу проекту шляхом вбудовування найкращих з можливих варіантів поєднань робіт, ефективного завантаження виконавців.
Важливе завдання в управлінні проектом, та й взагалі в менеджменті - чітко визначити, хто за що відповідає. Саме для цього і застосовується інструмент «Матриця відповідальності» (Responsibility matrix).
Ця оцінка генерує перетин, яке класифікує ризик. Давайте розглянемо приклад ризику втрати важливої інформації для проекту. Припускаючи, що люди оцінюють ймовірність цього ризику в середньому і серйозний вплив, ми отримаємо результат екстремального ризику.
Використання матриці ризику в проекті
Таким чином, стає можливим диференціювати ризики, щоб полегшити процес прийняття рішення про те, де діяти в першу чергу і що найбільш важливо для вашого проекту. Тепер, щоб побачити на практиці, як матриця ризику буде працювати в управлінні ризиками проекту, уявімо собі проект по впровадженню нового програмного забезпечення в компанії. Подивимося, як буде виглядати крок за кроком.
Крок 1 - Перелічіть основні ризики
Нижче наведено короткий список ризиків, які можуть виникнути у всьому цьому проекті.За своєю суттю він дуже простий і являє собою таблицю, де в рядках зазвичай перераховують роботи проекту, а в колонках - проектні ролі. Роботи беруть з структурної декомпозиції робіт (WBS), ролі - з оргструктури проекту (OBS).
Як роботи, так і ролі можна вказувати з різним ступенем деталізації. Так, можна написати «фахівці компанії», а можна розписати всіх поіменно. На ранніх стадіях життєвого циклу проекту зазвичай будують укрупнену матрицю відповідальності, На більш пізніх - детальну.
Зробіть матрицю ризику кожного ризику
Пожежа в центрі обробки даних Втрата суттєвої інформації Система моніторингу нових реалізацій помилкова Відсутність сумісності між старими даними і новою системою Відсутність якості обслуговування, що надається контрактної компанією Скарги користувачів на помилки Пізніше попередження користувачам про зміни Система виходить з ефіру Параметри не виконаних протягом періоду Розрив контракту з новою компанією. Коли ви робите матрицю ризику для кожного з перерахованих елементів, ви створите рівень ризику для кожного з них і можете згенерувати оцінку також відповідно до вагами, які ви задали для кожної ноти.
На перетинах робіт і ролей позначають, чи має відношення дана людина до цієї роботи, і, якщо має, то яке. У літературі можна зустріти безліч позначень, наприклад, такі як «генератор ідей». Однак, на наш погляд, це створює зайву плутанину і ускладнює застосування інструменту. Практика показує, що досить наступних понять:
Крок 3 - Аналіз найбільш релевантних ризиків в рейтингу
Важлива турбота - не витрачати час на ризики, які не дуже важливі для вашого проекту.
Крок 4 - Намалюйте заходи для запобігання ризиків від матеріалізації
З цього моменту ви можете показати, до якого кроку відноситься кожен ризик, а також перерахувати ряд рішень, які можуть бути зроблені для мінімізації ймовірності виникнення ризику або зменшення його впливу, якщо ризик дійсно матеріалізується.Для ризику відсутності сумісності між старими даними і новою системою простим рішенням є узгодження зустрічей між компаніями, щоб всі важливі моменти були охоплені міграцією. В кінці кожного кроку проекту ви можете переконатися, що ви виконали цю частину проекту і наскільки це пов'язано з ризиком.
- Відповідальний. Для кожної роботи обов'язково повинен бути вказаний один і тільки один відповідальний.
- Виконавці. Їх може бути кілька, а може бути так, що сам відповідальний є і виконавцем. Тобто в одній комірці може бути більше одного позначення.
- Який стверджує. Та людина, яка стверджує деякий документ (якщо дана робота пов'язана зі створенням документа). Він може бути тільки один.
- Узгоджувальний. Та людина, яка бере участь в узгодженні деякого документа (якщо дана робота пов'язана зі створенням документа). Їх може бути кілька.
|
Вище керівництво |
куратор проекту |
проектний офіс |
Менеджер проекту |
команда проекту |
Організації-підрядники |
|
|
Бізнес планування |
||||||
|
Розробка статуту проекту |
||||||
|
Випуск наказу про запуск проекту |
приклад
Зауважимо, що матриця відповідальності може застосовуватися не тільки в управлінні проектами, але і в інших сферах:
- У процесному управлінні, там її називають матрицею відповідальності за бізнес-процесу.
- При описі роботи підрозділу може будуватися матриця відповідальності по ньому, де з одного боку перераховують посади, що входять до підрозділу, а з іншого - функції цього підрозділу.
Багато керівників, які знайомляться з матрицею відповідальності на наших тренінгах або під час консалтингових проектів, вважають її одним з найбільш ефективних управлінських інструментів завдяки її простоті і наочності. Як сказав один з учасників тренінгу, керівник з більш ніж 10-річним стажем: «Намалював в своєму підрозділі матрицю відповідальності - вперше зрозумів, хто чим займається! »Зауважимо, що якщо творчо підійти до застосування матриці відповідальності, То можна знайти і інші вигоди від її використання.
Навчитися розробляти ефективні організаційні структури компанії і проекту, підбирати і мотивувати персонал, керувати командою співробітниками ви можете на наших тренінгах по
