Аналіз небезпек, які можуть виникнути при виконанні складеного плану, - один з найбільш цікавих і складних етапів планування проекту. Від того, як проведено аналіз, залежить, чи буде проект успішно завершено. У цьому уроці ви навчитеся визначати ризики за допомогою MS Project, описувати їх і розробляти стратегії їх пом'якшення. Для проведення аналізу ми задіємо всі наявні в нашому арсеналі засоби: поля, що настроюються, формули, стандартні і настроювані фільтри, сортування.
План складений, проект вкладається в терміни, бюджет відповідає очікуванням і завантаження ресурсів не перевищує їх доступність. Саме час замислитися: а чи вдасться виконати цей план, якщо, наприклад, захворіє співробітник з унікальними навичками, якого ніхто не може замінити, або автори не здадуть статті в строк, або в друкарню вчасно не привезуть фарбу, або відбудеться ще що-небудь непередбачене ? Відповіді на ці запитання можна отримати, аналізуючи ризики проекту.
Аналіз ризиків складається з декількох етапів. Спочатку потрібно визначити можливі ризики. Потім для кожного з них треба визначити стратегію пом'якшення впливу ризику на проект, тобто дії, що вживаються для запобігання ризику або в разі здійснення ризику для того, щоб проект був успішно завершений.
Визначення ризиків
Часто в процесі визначення ризиків неможливо детально проаналізувати весь план проекту в розумний час (наприклад, якщо план складається з кількох сотень завдань). У таких випадках в першу чергу потрібно аналізувати ризики у завдань, які знаходяться на критичному шляху проекту або можуть стати критичними. Щоб визначити, які завдання можуть стати критичними, можна скористатися оптимістичній і песимістичній діаграмами Ганта, отриманими в результаті аналізу методом PERT.
При визначенні ризиків інформацію потрібно заносити в план проекту. Для цього потрібно підготувати поля, що настроюються (файл 1.mpp). Ми перейменували поле для завдань Text2 (Текст2) у Опис ризику, а поле для задач Texts (ТекстЗ) - в Імовірність здійснення ризику, причому для останнього ми створили список значень: Висока, Середня і Низька, що дозволить швидко заповнювати це поле. Крім того, на підставі таблиці Entry (Введення) для задач ми створили таблицю Введення інформації про ризики і залишили в ній лише необхідний набір полів. І нарешті, на базі таблиці ми створили два подання: Ризики, в якому ця таблиця знаходиться поруч з діаграмою Ганта, і комбіноване уявлення Ріскі2, у верхній частині якого знаходиться подання Ризики, а в нижній - Task Form (Форма завдань). Тепер можна переходити до визначення ризиків.
Ризики визначаються для трьох аспектів проекту: розкладу, ресурсів і бюджету. Так виявляються події, здійснення яких може перешкодити завершити проект вчасно чи створити нестачу ресурсів або грошей у певний момент його виконання. Якщо при визначенні ризику стає ясно, як зменшити його, то потрібно відразу ж вносити відповідні зміни в план проекту.
Ризики в розкладі
Завдання, що стоїть перед керівником проекту при аналізі ризиків розкладу, полягає в тому, щоб зменшити ймовірність зриву термінів робіт. Зрив термінів робіт може відбутися в тому випадку, якщо тривалості завдань у плані не будуть відповідати тому часу, який буде потрібно на їх виконання.
Невідповідність запланованих тривалостей робіт фактичним може відбутися у двох випадках: якщо неточно складений план проекту і якщо несподівано виявиться, що та чи інша робота вимагає більше часу, ніж очікувалося. Оскільки кожен проект унікальний, то обов'язково трапиться так, що якась із завдань буде тривати довше запланованого часу, але чим точніше і детальніше план, тим менше буде таких завдань. Адже при неточному плані невідповідності виникають навіть тоді, коли їх могло б і не бути.
Тому зменшення ризиків в розкладі починається з деталізації плану робіт. Потім потрібно виявити завдання, у яких ймовірність зриву найбільш велика. Ці завдання можна виявити за деякими формальними критеріями, що розглядаються нижче.
Завдання з попередніми тривалостями
Один з найбільших ризиків представляють завдання, у виконанні яких у працівників немає досвіду. Наприклад, якщо б у нашому проекті за предпечатной підготовці журналу використовувалася нова для співробітників технологія, наприклад друк сріблом, або нове обладнання, то завдання, що передбачає використання нового обладнання або нових технологій, вважалася б ризикованою.
Головна проблема в плануванні таких завдань полягає в тому, що їх тривалість не відома заздалегідь, оскільки немає досвіду в їх виконанні. Тому зазвичай при плануванні тривалість цих завдань залишається попередньою (estimated). Такі завдання можна виявити в плані проекту за допомогою стандартного фільтру Tasks With Estimated Durations (Задачі з оцінкою тривалості).
У нашому плані таких завдань немає, але якщо б вони знайшлися, то довелося б змінити план проекту таким чином, щоб несподіване збільшення їх тривалості не позначилося на термінах закінчення проекту або на термінах виконання важливих завдань (наприклад, тих, у яких терміни виконання регламентуються договором ). Бажано збільшити плановану тривалість виконання цих завдань до песимістичною і розраховувати план з урахуванням цієї тривалості завдань. Крім того, можна додати до плану окреме завдання з освоєння нового обладнання або технології раніше того, як почнеться виконання завдання, де це обладнання або технологія буде використовуватися.
Дуже короткі завдання
Часто при плануванні проекту тривалість задач визначається на підставі оцінки майбутніх виконавців. Наприклад, керівник проекту просить співробітника оцінити, скільки часу йому буде потрібно на виконання певного завдання, а потім оцінка співробітника заноситься до плану. Співробітники ж часто дають занадто оптимістичні терміни, що призводить до того, що заплановані роботи не вдається виконати вчасно чи співробітникові доводиться працювати понаднормово.
Інше джерело завдань із занадто короткими термінами - самі менеджери, які виділяють на завдання стільки, скільки вважають за потрібне (виходячи з обмежень по термінах проекту), не радячись при цьому з потенційними виконавцями.
Щоб уникнути таких сдучаев, потрібно проаналізувати всі завдання плану проекту тривалістю менше одного дня (крім віх) і всі завдання, у яких при аналізі PERT очікувана тривалість збігалася з оптимістичною. Для цього створимо новий фільтр і налаштуємо його (рис. 16.1, файл 1.mpp). (Про те, як створювати і настроювати фільтри див. розділ «Створення фільтру».)
Фільтр відбирає завдання, у яких тривалість менше або дорівнює одному дню або значення настроюваного поля Durationl (Длітельность!) дорівнює значенню настроюваного поля Duration2 (Длітельность2). (Ці настроювані поля використовуються при аналізі за методом PERT для зберігання інформації про оптимістичній і очікуваної тривалості.) Серед завдань, відібраних по одному з цих критеріїв, фільтр відбирає ті завдання, у яких значення поля Milestone (Віха) дорівнює No (Ні), то є завдання, які не є віхами. Коротких завдань виявилося лише три, з них дві Редколегії, на які відведено по 3 години, і Остаточне складання журналу, на яку відведено 2 дні.
Після того як короткі завдання відібрані, визначимо реалістичність відведеного на них часу. У нашому випадку 3 години на редколегію - це цілком нормально. Два дні на складання журналу - термін оптимістичний, але враховуючи, що працювати будуть двоє, впоратися цілком можна. До того ж, вони задіяні на 25% (тобто за 2 дні відпрацюють всього 6 годин), значить, якщо вони не будуть укладатися в термін, то буде можливість збільшити завантаження і встигнути завершити завдання вчасно.
Якщо ми виявляємо в плані завдання, що мають невиправдано короткі терміни, то тривалість таких завдань потрібно додатково обговорити з майбутніми виконавцями. При цьому бажано запросити у них всі три можливі терміну виконання завдання, щоб внести їх у таблицю для аналізу PERT і розрахувати тривалість завдання.
Занадто довгі завдання та задачі з великим числом ресурсів
Ми вже говорили про те, що при складанні плану варто уникати занадто довгих завдань. Як правило, без деталізації робіт дуже складно точно оцінити трудовитрати для таких завдань і можливу завантаження ресурсів, тому, включаючи їх у план, ви підвищуєте вірогідність того, що він виявиться неточним.
Виявити в плані завдання з великою тривалістю дуже просто. Досить скористатися автофільтрів і відфільтрувати завдання по стовпцю Duration (Тривалість), відібравши завдання з тривалістю, що перевищує, наприклад, 5 - 10 днів (про використання автофільтра див. розділ «Автофільтр»).
Оптимістична тривалість може збігатися з очікуючою не точно, а з певним припущенням, наприклад розрізнятися на 1 або 2 години. Щоб такі завдання теж можна було виявити, у цьому ж файлі ми створили фільтр Дуже короткі завдання - 2, в якому можна внести це припущення.
А ось автоматично відібрати завдання з великим числом ресурсів не можна, оскільки в MS Project немає спеціального стовпця «внутрішньої» таблиці, в якому було б зазначено число ресурсів, призначених на завдання. Тому нам, як завжди, доведеться скористатися розширеним полем (файл 2.mрр). Перейменуємо поле завдань Number2 (Число2) у Число ресурсів і помістимо в нього формулу Len ([Resource Names]) (Len ([Назви ресурсів])) (рис. 16.3).
Функція Len визначає довжину рядка тексту, переданої їй як параметр. У нашому випадку цим рядком є значення поля Resource Names (Назви ресурсів). Чим більше ресурсів призначено на завдання, тим довше рядок і тим більше буде значення поля Число ресурсів.
Цей метод порівняння завдань досить грубий, оскільки не гарантує точного порівняння числа ресурсів. Точно визначити число призначених на завдання ресурсів можна лише за допомогою макросу (функції цього не дозволяють).
Після завершення настройки поля відсортуємо завдання по цьому полю. Для цього за допомогою команди меню Project до Sort> Sort by (Проект> Сортування> Сортувати по) відкриємо діалогове вікно сортування і виберемо створене поле в якості критерію. Сортувати завдання будемо за спаданням, щоб завдання з найбільшою кількістю ресурсів виявилися у верхній частині списку, і скинемо прапорець Keep outline structure (Зберегти структуру), щоб сортування здійснювалася в рамках всього проекту, а не в рамках окремих фаз (рис. 16.4, файл 2 . mрр).
На рис. 16.5 (файл 2.mрр) завдання у верхній частині подання відсортовані за кількістю ресурсів. У завданнях на початку списку задіяно по 4-5 співробітників, в задачах трохи нижче - по 2-3 людини. У нижній частині подання відображена Форма завдань (Task Details Form), в якій можна проглянути детальну інформацію про завдання, обраної у верхній частині подання.
Визначивши завдання з великими тривалостиями чи великою кількістю призначених ресурсів, потрібно розбити їх на серію більш коротких завдань або перетворити на фази, оскільки, як правило, в рамках довгого завдання вирішується кілька коротких. Ще одне підтвердження тому - багато призначень на завдання: як правило, над вирішенням одного завдання працює не більше двох осіб, а якщо їх призначено більше, то це означає, що завдання може бути розділена на кілька складових.
Список усіх попередниць завдання наведено в полі Predecessors (Попередники), причому номера задач-попередниць розділені крапками з комою (див. розділ «Редагування зв'язків у таблиці»). І якщо в цьому полі зустрічається хоча б одна точка з коми, значить, у завдання є як мінімум дві попередниці. Тому наш фільтр буде відбирати ті завдання, у яких в поле Predecessors (Попередники) міститься крапка з комою.
У результаті роботи фільтра важливо не тільки виявити завдання з декількома попередницями, але і зрозуміти, як ця задача пов'язана з іншими завданнями в плані проекту. Тому створений фільтр найзручніше застосовувати в режимі підсвічування, щоб завдання з кількома залежностями лише підсвічувалися серед всіх інших (про фільтрації в режимі підсвічування див. у розділі «Фільтри»).
Наприклад, на рис. 16.8 (файл 4.mрр) ми застосували новий фільтр в уявленнях Gantt Chart (Діаграма Ганта) і Network Diagram (Мережевий графік) і поєднали вікна з цими уявленнями в одному вікні. У верхньому вікні в таблиці рядки з завданнями, що підсвічуються фільтром, виділені блакитним шрифтом (14, 42, 43), а в нижньому кольором виділені блоки, що позначають завдання (на малюнку видно тільки блок 14).
Після того як завдання з кількома залежностями виявлені, потрібно визначити, як можна зменшити ризик їх затримки. Зменшити ризик можна, збільшивши тривалості однієї або кількох завдань-попередниць за рахунок більш раннього їх початку (якщо це можливо). Крім того, можна збільшити заплановану тривалість завдання, якщо строк тривалості проекту дозволяють це зробити.
Іноді одне з двох завдань починається набагато пізніше іншого, і тоді воно створює тимчасовмй резерв іншим. Наприклад, на рис. 16.9 (файл 5.mpp) у задачі Верстка обкладинки дві попередниці, одна з яких, Фотозйомка моделі, завершується за тиждень до планованого початку верстки обкладинки. У цій ситуації ризик затримки верстки через фотозйомки мінімальний, тому що в останньої є дуже великий часовий резерв.
Створювати такі резерви можна, коли дата початку однієї із завдань-попередниць пов'язана з іншим завданням або має обмеження, а в іншої задачі такого обмеження немає. Якщо перенести завдання, дату початку якої ніщо не обмежує, на більш ранній термін, то це створить їй тимчасовий резерв.
Завдання із зовнішніми залежностями
Іноді завдання залежать від зовнішніх по відношенню до проекту подій, і не піддаються плануванню. Наприклад, якщо організація виконує два взаємозалежних проекти, то в якості попередника завдання може виступати завдання з іншого проекту.
Визначити такі завдання за допомогою фільтра можна лише в тому випадку, якщо як попередників виступають завдання, що зберігаються в інших файлах проектів. У такому випадку для виявлення цих завдань потрібно налаштувати фільтр, створений нами для визначення задач з кількома попередницями (див. рис. 16.7), замінивши символ «;» на «\».
Буває й так, що у завдання немає попередниць в інших файлах проектів, але, тим не менш, зовнішні залежності у неї є. Зазвичай такі завдання може визначити лише менеджер при аналізі плану вручну.
Щоб ці завдання можна було визначити на формальній основі, під час створення списку завдань можна додати поле типу Flag (Прапор) і змінювати його значення для задач із зовнішніми залежностями.
У нашому проекті таким завданням є Статті надійшли до редакції, оскільки термін її виконання залежить від швидкості роботи авторів, що є зовнішньою (тобто позапроектній) залежністю. Ризик того, що автори здадуть статті пізніше терміну, досить великий. Оскільки відразу зменшити цей ризик ми не можемо, просто зафіксуємо його (рис. 16.10, файл б.mрр), заповнивши відповідні поля таблиці, щоб повернутися до нього трохи пізніше, коли будемо розробляти стратегію пом'якшення впливу ризиків на проект.
Ресурсні ризики
Мета аналізу ресурсних ризиків полягає в тому, щоб визначити ресурси і призначення, які збільшують ймовірність зриву проекту. Наприклад, ризиковано залучення нещодавно прийнятого на роботу співробітника, оскільки у нас немає досвіду роботи з ним і ми не знаємо, чи зможе він впоратися з поставленими завданнями. Інший ризик - використання одного співробітника в занадто багатьох завданнях, оскільки проект стає залежним від одного співробітника, і якщо він стане недоступним, то проект може провалитися.
Використання недосвідчених співробітників
Часто трапляється так, що для проектних робіт залучаються співробітники, що недавно вступили в організацію. Оскільки ще немає досвіду використання цих співробітників в проектах, це становить певний ризик. Потрібно визначити завдання, де задіяні ці співробітники, і описати ризик їх використання. При розробці стратегії пом'якшення ризиків ці ризики потрібно буде проаналізувати і визначити, як їх зменшити.
Щоб виділити співробітників без досвіду роботи, налаштуємо стовпець FlagZ (Флаг2), назвавши його Досвід є, і визначимо відображення червоного індикатора для тих випадків, коли значенням поля є No (Ні), і зеленого - коли значенням є Yes (Так). Додамо налаштоване поле в уявлення Resource Sheet (Аркуш ресурсів) і встановимо в ньому значення No (Ні) для тих ресурсів, у яких немає досвіду роботи. У нашому випадку в проекті задіяні тільки два ресурсу без досвіду: Тарасова і Жуков (рис. 16.11).
Тепер розділимо вікно, відобразимо в нижній частині подання Task Usage (Використання завдань) і відкриємо таблицю Введення інформації про ризики. Для того щоб в ній відобразилися тільки ті завдання, в яких задіяні недосвідчені співробітники, виділимо цих співробітників в списку у верхньому поданні, клацнувши на їх прізвищах, утримуючи клавішу Ctrl (рис. 16.12).
На рис. 16.12 видно, що в двох завданнях з трьох недосвідчені співробітники працюють разом з більш досвідченими, тому ймовірність здійснення ризику в цих випадках ми визначили як середню. І лише у того завдання, де задіяний один Жуков, ризик був оцінений як високий.
Ресурси з великим обсягом роботи
Іноді завантаження між учасниками проекту розподіляється нерівномірно, і деякі з членів команди роблять більший обсяг роботи, ніж інші. Якщо не проконтролювати розподіл роботи, то може виявитися, що деякі співробітники відповідають за виконання занадто великого числа завдань. Занадто висока відповідальність окремих співробітників небезпечна тим, що у разі хвороби такого «ключового» співробітника або недоступності його з іншої причини виконати всі завдання в строк буде неможливо.
Визначити ресурси з великим числом призначень можна за допомогою представлення Resource Usage (Використання ресурсів). Відкриємо в цьому поданні таблицю Work (Трудовитрати) і відберемо для відображення тільки людські ресурси, скориставшись фільтром Resources - Work (Ресурси - трудові). Потім відсортуємо ресурси за спаданням по колонці Work (Трудовитрати). Тепер учасники проекту з найбільшою завантаженістю відображаються на початку списку.
Для того щоб переглянути, яке місце в плані проекту займають призначення найбільш зайнятих співробітників, розділимо вікно і в нижньому поданні відобразимо діаграму Ганта. Тепер при виборі ресурсу у верхньому поданні в нижньому відображаються всі його призначення, як у таблиці, так і на діаграмі (рис. 16.13, файл 7.mрр, Представлення 1).
Критичні завдання виділені червоним, і чим у більшій кількості критичних завдань задіяний ресурс, тим більша небезпека зриву термінів проекту, якщо цей ресурс раптом перестане бути доступним. Оскільки в цьому випадку ризик, пов'язаний із залученням ресурсу, поширюється на всі завдання, в яких він бере участь, то немає сенсу заповнювати поля з описом ризику для задач - зручніше створити аналогічні настроювані поля для ресурсів і вводити інформацію в них.
Щоб внести в план інформацію про ресурсні ризики і використовувати її в подальшому при розробці стратегії пом'якшення ризиків, змінимо настроювані поля для ресурсів Text2 (Текст2) і Texts (ТекстЗ). Перейменуємо їх у Опис ризику і Імовірність здійснення ризику. Оскільки в другому полі можна використовувати список значень, вже складений нами в аналогічному поле для завдань, імпортуємо його з допомогою кнопки Import Custom Field (Імпорт настроюваного поля).
У полі Text2 (Текст2) можуть вводитися однакові ризики для різних ресурсів, тому налаштуємо список значень таким чином, щоб при введенні можна було вказувати значення, що не входять до списку, і вони автоматично додавалися б у нього для подальшого використання (про налаштування списку значень поля див. розділ «Створення настроюваних полів зі списком значень»). Створимо нову таблицю на базі ресурсної таблиці Entry (Введення), назвемо її Введення інформації про ризики ресурсів і додамо до неї налаштовані поля. Тепер відкриємо її у верхньому поданні і заповнимо її даними для ресурсів, що виконують великий обсяг роботи (рис. 16.14, файл 7.mрр, Представлення 2).
Найбільш «ризикованими» ресурсами проекту є Іванов, Петров і Сидоров, задіяні в самому великому числі завдань, більшість з яких лежить на критичному шляху. Відповідно, в полі Опис ризику введемо Зрив робіт через недоступність ресурсу, а в полі Імовірність здійснення виберемо значення Висока.
Ресурси з понаднормовою роботою
Співробітники, завантажені понаднормової роботою, з-за втоми можуть почати працювати повільніше, ніж зазвичай. Тому при плануванні варто уникати використання понаднормової завантаження. Якщо ж при складанні плану вам довелося запланувати понаднормову роботу, то при аналізі ризиків варто передбачити її можливі наслідки.
Для аналізу ми будемо використовувати те ж уявлення, що і в попередньому прикладі, але на діаграмі використання ресурсів відобразимо детальні дані про перевищення навантаження і понаднормових (про відображення докладних даних на діаграмі див. в розділі «Вибір типу відображається на графіку інформації та її форматування» ). Переглядаючи цю діаграму, можна швидко знайти ресурси з понаднормового навантаженням.
Рис. 16.15. Виявляємо у проекті ресурси з понаднормової завантаженням. На діаграмі у верхній правій частині екрана відображаються дані про понаднормової роботи (Ovt. Work) і перевищенні доступності ресурсів (Overalloc)
У нашому прикладі понаднормова завантаження є у Буркова, і тому вкажемо в описі ризику Зрив робіт з-за втоми ресурсу. Але оскільки обсяг понаднормової роботи невеликий, то ймовірність здійснення ризику оцінимо як середню.
Співробітники з унікальними навичками і матеріали з єдиними постачальниками…
Проект може опинитися під загрозою зриву, якщо несподівано стане недоступний співробітник, що володіє особливими знаннями чи навичками, оскільки тільки він може виконати певні завдання проекту. Крім того, ризик провалу проекту через несвоєчасне постачання матеріалів підвищується, якщо матеріали можуть бути отримані тільки від одного постачальника, оскільки в цьому випадку виконання проекту стає залежним від якості його роботи.
Щоб визначити такі ресурси та внести в план інформацію про ризики, пов'язані з їх використанням, відкриємо подання Resource Sheet (Аркуш ресурсів) та відобразимо в ньому таблицю Введення інформації про ризики ресурсів. Потім потрібно визначити ризики з унікальними знаннями і ввести в таблицю опис ризиків і ймовірність їх здійснення.
На рис. 16.16 видно, як ми заповнили цю таблицю у файлі 9.mрр. Оскільки Фарба для виведення плівок і Папір для друкарні поставляються нам єдиною компанією, то використання цих ресурсів ми вважаємо ризикованим. Але так як з компанією-постачальником ми працюємо вже давно і зривів у постачанні ніколи не було, ймовірність здійснення ризику оцінимо як низьку.
Серед співробітників тільки Лімонов має унікальні знаннями, і його відсутність може позначитися на термінах виконання робіт. Тому і для нього ми вкажемо відповідний ризик, оцінивши ступінь ймовірності його здійснення як середню.
У нашому проекті задіяно не так багато ресурсів, і тому переглянути весь список і внести інформацію про ризики можна досить швидко. Якщо ж проект, в якому ви оцінюєте ресурсні ризики, містить велику кількість ресурсів, то при їх аналізі варто скористатися стандартними фільтрами Resources - Material (Ресурси - матеріальні) і Resources - Work (Ресурси - трудові), за допомогою яких можна відібрати для аналізу тільки співробітників або тільки матеріали.
Бюджетні ризики
У результаті здійснення ризиків можливе збільшення обсягу роботи за проектом, що призведе до зростання витрат на нього. Ризик збільшення бюджету проекту варто розглядати тоді, коли проект має обмежені бюджетні рамки.
Наприклад, у нашому проекті задіяні в основному штатні співробітники організації, регулярно одержують зарплату, і бюджет проекту не має великого значення. Бувають і інші випадки: наприклад, проект може виконуватися на замовлення, і замовник може виділяти на виконання робіт певну суму, яку не можна перевищити.
У тих випадках, коли витрати на проект обмежені, важливо передбачити ризик збільшення бюджету в результаті тих чи інших обставин. Для оцінки можливого збільшення бюджету можна застосовувати різні методики. Ми продемонструємо тут оцінку можливої зміни вартості проекту на підставі даних, отриманих в ході аналізу PERT.
Наш аналіз виходить з припущення, що при збільшенні тривалості завдання обсяг робіт усіх призначених ресурсів і, відповідно, ціна зростають пропорційно. Наприклад, якщо завдання триває 2 дні і коштує $ 100, то при збільшенні тривалості до 4 днів вартість зросте до $ 200. Цей метод оцінки не дуже точний, але він і не претендує на точність. Адже при плануванні ризиків складно передбачити, як саме будуть задіяні ресурси при збільшенні тривалості призначення. Завдання аналізу - визначити можливий бюджет проекту за несприятливого розвитку подій і завдання, ціна яких сильно збільшиться при здійсненні ризиків.
Перейменуємо таблицю PA_PERT Entry (Введення PA_PERT) у Бюджетні ризики. Потім на основі фільтра Milestones (Віхи) створимо фільтр Not Milestones, змінивши умова у вихідному фільтрі на протилежне. Після його застосування на плані не будуть відображатися завдання з нульовою тривалістю.
При аналізі PERT програма автоматично поміщає значення оптимістичній, очікуваної і песимістичній тривалості у поля Durationl-З (Длітельность1-3). Якщо розділити тривалість кожного з типів на тривалість, внесену в план проекту (поле Duration (Тривалість)), то в результаті ми отримаємо коефіцієнт, який можна використовувати для розрахунку вартості. Наприклад, якщо тривалість завдання в плані становить 2 дні, а песимістична тривалість становить 4 дні, то коефіцієнт буде дорівнювати 2. Відповідно, песимістична вартість завдання буде дорівнювати вартості, помноженої на цей коефіцієнт, і у разі несприятливого розвитку подій буде в два рази більше запланованого.
Набудуємо три поля типу Cost (Витрати) для розрахунку вартості кожного з типів за цією формулою. На рис. 16.17 (файл 10.mрр) представлена формула для поля Cost3 (ЗатратиЗ), перейменованого в Opt. Cost. У формулі використовується поле Durationl (Длітельность!), що зберігає оптимістичну тривалість завдань.
Видно, що в разі несприятливого розвитку подій вартість проекту може збільшитися більш ніж на $ 15 000 (віднімаємо з песимістичної вартості плановану вартість), що становить лише 15,5% від загальної вартості проекту. Але в окремих завдань або фаз відхилення ціни може бути значним, і потрібно проаналізувати план, щоб зрозуміти, у яких завдань у разі здійснення ризику вартість може суттєво змінитися. Для цього розрахуємо для кожного завдання відсоток відхилення песимістичній вартості від запланованої.
Перейменуємо полі Numbers (ЧіслоЗ) у Різниця вартості (файл 11.mpp) і введемо в нього формулу, подану на рис. 16.19. Спочатку визначається різниця між песимістичній ціною і запланованої, для чого з поля Cost5 (Затрати5), де зберігається песимістична вартість, розрахована в попередньому прикладі, віднімається планована вартість, що зберігається в полі Cost (Витрати). Потім ми визначаємо, який відсоток від запланованої вартості становить отримана різниця. Для цього отримане в результаті віднімання число ділиться на заплановану вартість і результат множиться на 100.
Щоб отриманий результат було легше обробляти, налаштуємо відображення індикаторів для поля (рис. 16.20). Ті завдання, у яких відхилення при несприятливому розвитку подій складе більше 50%, пометим червоним індикатором. Завдання з відхиленням більше 25% пометим жовтим, а з відхиленням більше або рівним 10% - зеленим. Завдання з відхиленням менше 10% пометим прапорцем (ця настройка не видно на рис. 16.20, файл 11.mpp). Встановимо прапорець Show data values in ToolTips (Показувати значення даних у підказках), і тоді значення поля буде відображатися при наведенні курсору на індикатор.
Визначення кількісних характеристик відхилень (щоб вирішити, яке відхилення вважати дуже високим, а яке прийнятним) залежить від прийнятих в організації стандартів. У нашому випадку будемо вважати відхилення менше 10% прийнятним, а більше 50% - занадто високим і потребують корекції.
На рис. 16.21 (файл 11.mpp) представлена таблиця Бюджетні ризики після того. як налаштування поля завершена. До таблиці застосовано фільтр Not Milestones для відбору всіх завдань, крім віх. Завдання плану, помічені червоним індикатором, потребують корекції: потрібно або зменшити песимістичну оцінку вартості для них, або збільшити плановану вартість.
Після завершення корекції потрібно визначити песимістичну вартість проекту, узгодити її з керівництвом і враховувати при плануванні фінансування проекту. Якщо події будуть розвиватися за несприятливим сценарієм, організація повинна бути готова до виплати необхідного проекту бюджету. Песимістична вартість проекту вказана у колонці Pes. Cost в рядку сумарною завдання проекту (перший рядок на мал. 16.21).

Розробка стратегії пом'якшення ризиків
Після того як ми виявили проектні ризики, потрібно визначити заходи, що пом'якшують їх вплив на проект. Це можна зробити двома шляхами: розробити план їх стримування чи план реакції на них.
План стримування ризиків (mitigation plan) складається з робіт, які включаються в план проекту і, будучи виконаними, істотно знижують вірогідність здійснення ризику. План реакції на ризики (contingency plan) визначається в плані проекту, але не оформляється у вигляді завдань до здійснення ризику. Якщо ризик здійснюється, потрібні завдання додаються до плану проекту.
Визначаючи стратегію пом'якшення ризиків, слід завжди порівнювати витрати на запобігання ризику з витратами, які будуть понесені, якщо ризик здійсниться. Наприклад, якщо у разі здійснення ризику бюджет зросте на $ 100, то вартість робіт зі стримування не повинна перевищувати цієї цифри. Коли важливіше терміни проекту, слід порівнювати тривалість плану у разі здійснення ризику з тривалістю плану, що враховує завдання на його пом'якшення.
План стримування ризиків
Для стримування ризиків у план потрібно включити роботи, виконання яких знизить ймовірність здійснення ризику. Наприклад, у завдання Статті надійшли до редакції є високий ризик затримки через те, що автори здадуть статті пізніше терміну. Щоб знизити його, додамо до плану завдання Перевірка стану статей, виконуючи яку редактори розділів зв'яжуться з авторами і нагадають їм про терміни здачі текстів (рис. 16.22, файл 13.mpp). При цьому тривалість проекту не збільшилася.
Аналогічно можна запобігти і ресурсні ризики. Наприклад, щоб уникнути ризику зриву робіт через несвоєчасну постачання матеріалів, додамо до плану робіт завдання Оформити попереднє замовлення матеріалів для друкарні, яка повинна бути виконана за три дні до завершення верстки журналу (рис. 16.23, файл 15.mpp). Додавання цього завдання теж не вплинуло на тривалість проекту.
Зазвичай більшість ризиків можна запобігти, провівши відповідні роботи, але іноді це не виходить або ж вважається недоцільним. Для таких завдань потрібно розробити план реакції на ризики.
План реакції на ризики
Багато ризики часто мають дуже низьку або невідому ймовірність здійснення. Крім того, для деяких ризиків не можна визначити момент їх настання. Наприклад, є ризик, пов'язаний з використанням Лимонова, оскільки той володіє унікальними знаннями, і всі чотири завдання, де він задіяний, не можуть бути виконані без його участі. Але точно визначити момент настання ризику не можна, оскільки він не пов'язаний з календарем проекту. У подібних випадках потрібно розробити план реакції на ризик, який буде застосований в той момент, коли ризик здійсниться.
План реакції на ризики зберігається в плані проекту у вигляді текстової інформації, пов'язаної з певними задачами або ресурсами. Для зберігання інформації про реакцію на ресурсні ризики налаштуємо ресурсне полі Text4 (Текст4), перейменувавши його в План реакції на ризики (файл 14.mрр).
Навіть після того, як план проекту проаналізовано, багато ризиків виявлено та розроблено стратегію пом'якшення їх впливу на проект, все одно зберігається ймовірність, що в ході виконання проекту може статися щось непередбачене. Іншими словами, цілком можливо, що якісь ризики не були виявлені або їх існування не можна припустити на нинішньому етапі планування проекту. Тому в план потрібно закласти часовий і фінансовий буфер, що дозволяє відреагувати на виникаючі ризики і знизити ймовірність збільшення тривалості проекту.
Фінансовий буфер можна створити простим збільшенням вартості проекту на коефіцієнт, який прийнято використовувати у вашій організації в таких випадках. Наприклад, якщо бюджет проекту становить $ 100 000, а песимістичний бюджет - $ 120 000, то з урахуванням буфера бюджет проекту може дорівнювати $ 130 000. Формування тимчасового буфера розглянемо більш докладно.
Формування тимчасового буфера
У гарний план проекту має бути закладена певна ступінь стійкості до виникаючих ризиків. Тому що ризики призводять до затримок у виконанні робіт, то стійкість до ризиків на увазі в першу чергу можливість розпочати виконання деяких завдань пізніше дати, зазначеної в плані, і при цьому закінчити проект в строк.
Якщо у завдання можна перенести дату початку на більш пізній термін або збільшити тривалість, значить, вона не є критичною. Тому чим менше в плані проекту критичних завдань, тим більше він підготовлений до виникаючих ризиків. Якщо план складається тільки з критичних завдань, то він навряд чи буде виконано в строк, оскільки в такому плані будь-яка затримка приводить до зміщення дати закінчення проекту. У залежності від стандартів планування, прийнятих в організації, в плані проекту має бути певний відсоток некритичних завдань.
Для аналізу існуючого в плані тимчасового резерву зручно скористатися поданням Gantt Chart (Діаграма Гангу) і таблицею Schedule (Календарний план), у якій відображається інформація про існуючий тимчасове запасі. Для того щоб ця ж інформація відображалася і на діаграмі, налаштуємо її за допомогою майстра Gantt Chart Wizard (Майстер діаграм Ганта).
На першому кроці майстра (визначення типу інформації для відображення на діаграмі) виберемо перемикач Custom Gantt Chart (Налаштувати діаграму Ганта). На наступному кроці виберемо перемикач Yes (Так) для відображення інформації про критичних і звичайних завданнях різними способами. Після цього пропустимо всі діалогові вікна з настройками квітів відрізків і дійдемо до п'ятого, в якому визначаються типи додаткових відрізків, що відображаються па діаграмі (рис. 16.25, файл 15.mpp).
У цьому діалоговому вікні виберемо перемикач Total slack (Загальний тимчасової резерв). Дані про існуючий у завдань резерв будуть відображатися у вигляді тонких відрізків. На зразку в області попереднього перегляду видно, що часовий резерв може бути тільки у звичайних завдань (вони більш темні), оскільки у критичних його не буває. Тепер самі важливі настройки завершені і можна натиснути кнопку Finish (Готово) прямо в цьому діалоговому вікні. Представлення налаштовано, і можна почати роботу з тимчасовим буфером (рис. 16.26, файл 15.mpp).
Таблиця Schedule (Календарний план) містить декілька колонок, з допомогою яких можна визначити ступінь стійкості до ризиків як розклади проекту в цілому, так і його окремих завдань. У колонці Total Slack (Загальний тимчасової резерв) міститься інформація про час, на яке виконання завдання можна відкласти, щоб тривалість проекту не змінилася. Колонка Free Slack (Вільний тимчасової резерв) містить інформацію про час, на яке можна відкласти виконання завдання, щоб не затримувати наступні завдання. A в колонках Late Start (Пізніше початок) і Late Finish (Пізніше закінчення) утримуються самі пізні дати, коли можна почати і закінчити завдання, щоб не змінити дату закінчення проекту.
УВАГА
Поле вільного тимчасового резерву або загального резерву зазвичай містить значення від нуля і більше. Якщо загальний тимчасової резерв завдання дорівнює нулю, то вона є критичною (Якщо не змінені стандартні налаштування (див. розділ «Аналіз критичного шляху проекту»). Однак при розрахунку тимчасового резерву враховуються крайні терміни завдання та обмеження (див. приклад нижче), тому якщо закінчення завдання заплановано пізніше крайнього терміну, то її тимчасової резерв буде негативним. Це означає, що її не тільки не можна відкласти, а навпаки, треба прискорити. Якщо хоча б у однієї задачі проекту тимчасової резерв менше нуля, то тимчасової резерв всього проекту (сумарною завдання проекту) також буде менше нуля.
На діаграмі інформація про загальний тимчасове резерв завдання (Total Slack) відображається за допомогою тонких відрізків. Наприклад, у задачі 21 на рис. 16.26 (файл 15.mpp) значення поля Total Slack (Загальний тимчасової резерв) становить 31,87 дня, і поряд з відрізком, що позначає завдання, розташований тонкий відрізок такої ж тривалості.
MS Project розраховує загальний і вільний тимчасової резерв завдання, виходячи з її обмежень і положення в плані проекту. У нашому прикладі, виходячи з положення завдання Перевірка стану статей у плані проекту, тимчасової резерв склав більше 30 днів, хоча насправді це завдання має бути виконано за кілька днів до початку завдання Статті надійшли до редакції, що починається 21.02.02. Оскільки ми не вказали таке обмеження, програма розрахувала резерв неправильно. У файлі 16.mрр ми вказали в якості крайнього терміну закінчення завдання Перевірка стану статей дату 18.02.02, і часовий резерв відразу зменшився до 1,87 дня.
Після того як ви переглянете файл проекту і переконайтеся, що часовий резерв у кожного завдання відповідає дійсності, потрібно спробувати знайти в проекті незбалансованості. Наприклад, може виявитися, що в однієї пз фаз занадто великий резерв, а в іншої його немає або він зовсім негативний. У такому випадку варто перенести частину завдань з фаз з маленьким резервом в ті, де він значно більше.
У плані не повинно бути завдань або фаз з негативним резервом, тому що наявність таких завдань свідчить про помилки в плані проекту. Негативний тимчасової резерв може утворитися, якщо завдання закінчується після крайнього терміну, або якщо порушені дати обмежень у сусідніх з нею завдань. Щоб швидко знайти завдання з негативним резервом, можна відсортувати таблицю за спаданням по полю Total Slack (Загальний тимчасової резерв).
Якщо завдання з обмеженнями мають попередниць, що закінчуються занадто пізно для того, щоб обмеження було задоволено, у наступних завдань утворюється негативний резерв. Щоб завдання з обмеженням і з негативним резервом поміщалися в розкладі у відповідності зі зв'язками, а не з датами обмежень, в діалоговому вікні Options (Параметри) на вкладці Schedule (Планування) потрібно скинути прапорець Tasks will always honor their constraint dates (Для завдань завжди дотримуються задані для них дати).
Додати резерв на завдання критичного шляху можна, збільшивши їх тривалість або вставивши завдання-буфери. Тоді при виконанні проекту тривалість буферів потрібно буде зменшувати, і після завершення проекту їх тривалість буде дорівнює нулю.
Якщо резерв завдань можна огранізувати за допомогою таблиці, то тимчасовий резерв проекту можна визначити з додаткових індикаторів. Наприклад, можна запланувати закінчити проект раніше реально потрібного терміну. Або ж, як ми зробили, додати крайній термін на останню завдання плану. У такому випадку час між закінченням задачі та її крайнім терміном і буде тимчасовим резервом проекту.
Аналіз розподілу трудозатрат
Коли план проекту готовий і в нього закладені буфери та тимчасової резерв, слід проаналізувати розподіл трудовитрат в проекті. Ця інформація часто виявляється корисною: наприклад, можна помітити, що в певні періоди в проекті настає перерва, який можна заповнити роботами. Крім того, керівник проекту зможе оцінити, в які періоди його очікує більш інтенсивна робота, а в які навантаження буде спадати.