Самовчитель-MicrosoftProject2010 - Стор 12

Самовчитель «Управління проектами у Microsoft Project 2010»

9.9 АНАЛІЗ ПОТРЕБИ У РЕСУРСАХ

У проектах також корисно знати, коли які ресурси потрібні, скільки вони коштують і як вони працюють.

І тому необхідно сформувати звіт про потреби у ресурсах.

Виконаємо послідовно такі кроки:

1. Перейдемо до подання «Використання ресурсів»;

2. На закладці «Вид» в області «Уявлення ресурсів» оберемо «Інші уявлення – Зберегти уявлення»;

3. Введемо ім'я нового уявлення «Звіт про потребу в ІТП»;

4. По колонці "Група" відфільтруємо всіх, хто ходить до групи "ІТР";

5. Виведемо колонки «Стандартна ставка», «Трудовитрати» та «Витрати»;

6. Виведемо рядки «Трудовитрати» та «Витрати»;

7. Налаштуємо шкалу часу, як потрібно для звітності.

Результат побудови звіту про потреби в ресурсах наведено на малюнку

Малюнок 9.34 Звіт про потребу в ІТП

9.10АНАЛІЗ РИЗИКІВ У ПРОЕКТІ

9.10.1 Управління ризиками за стандартами PMI

Ризик проекту – це невизначена подія чи умова, яка у разі настання може вплинути на показники проекту.

Дослідження показали, що ймовірність успішної реалізації проекту, параметри якого визначені на базі того, як буває зазвичай, коливається в діапазоні, тому облік ризиків і невизначеностей має велике значення на всіх стадіях управління проектом.

Розглянемо теорію управління ризиками Рисунок 9.35.

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Рисунок 9.35 Управління ризиками згідно з PMBoK, 2008

За теорією потрібно виконувати такідії:

1. Спланувати, як у компанії вестиметься планування та управління ризиками.

2. Визначення ризиків та розробка реєстру ризиків. Необхідно провести аналіз проекту з метою визначення причин ризиків.

3. Провести кількісний (визначити ймовірності та розміри загроз) та якісний (побудувати дерево цілей) аналізи.

4. Розробити план реагування ризики.

5. Виконання плану із відстеженням ризиків. Необхідне планування антиризикових заходів та пошук нових ризиків.

Теоретичні поради, як бачимо, досить загальні, але з них випливають важливі висновки:

• план може і повинен зазнавати змін у результаті пошуку та усунення ризиків;

• реальні терміни закінчення проекту та реальна вартість проекту буде вищою за заплановану.

9.10.2 Оцінка значущості ризиків

Проект зазвичай схильний до дуже великої кількості ризиків, запланувати заходи по боротьбі з усіма практично неможливо. Що ж робити?

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Слід звернутися до статистики. Потрібно порахувати, які види ризиків викликають найбільше проблем. На малюнку 9.36 наведено графік дефектів продукції залежно від видів дефектів.

Рисунок 9.36 Графік дефектів продукції залежно від видів дефектів

Видно, що працює правило 80/20. Приблизно 20% ризиків утворюють 80% загрози. Саме на них слід привертати основні зусилля. У технологічних проектах зазвичай ризики запобігають навчанню, контролю та підтримці якості (тестуванням).

Для того, щоб ефективно боротися з ризиками, потрібно вести статистичний облік проблем, що виникають за видами ризиків. В даній якості можебути використана система обліку дефектів продукції. Якщо статистика відсутня як клас, рекомендується звернутися до експертів (компанії або зовнішніх)

Крім негативних ризиків, необхідно також враховувати позитивні можливості, які можуть виникнути під час виконання проекту

9.10.3 Методи обчислення реальних термінів завдань

Ризик проекту – це невизначена подія чи умова, яка у разі настання може вплинути на показники проекту.

Для моделювання ризиків у проекті потрібна розробка трьох версій реалізації проекту:

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

• оптимістичну, яка базується на оптимістичних оцінках параметрів проекту і включає найімовірніші події ризику (імовірність настання яких вище 90%);

• найбільш ймовірну, що включає просто ймовірні події ризику (ймовірність настання яких вище 50%) та звичайні оцінки параметрів проекту;

• песимістичну, що включає відібрані при якісному аналізі значущі події ризику (імовірність настання яких нижче 50%) та песимістичні оцінки параметрів проекту.

Так як це часто буває оцінки співробітників недостовірні, і дізнатися про повний склад робіт неможливо.

Виходом є використання статистичних методів прогнозування. Розглянемо типові прийоми:

1. У Microsoft Project просто додають 30% загальної тривалості планових завдань (Buffer time в 30%). Цей резерввитрачається покриття ризиків.

помножити на 2 – оптимістична оцінка;

помножити на пі - нормальний проект;

помножити на застосування нестандартних технологій.

3. Схема PERT обчислення реального терміну. Часто буває, різні оцінки дають різні терміни; у цьому випадку можна застосувати метод розрахунок реального терміну за такою формулою:

Коефіцієнти у цій формулі (4 та 6) отримані шляхом аналізу статистики великої кількості проектів. Слід зазначити, що схема PERT ефективна тільки в тому випадку, якщо є різні оцінки. Якщо менеджер хоче через PERT просто переконати себе, що його рішення єдино правильно, то припасування статистики не дасть нічого, крім позитивної відповіді

Крім зазначених теоретичних обмежень PERT також має обмеження щодо реалізації у Microsoft Project. Метод не вміє

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

оптимізувати бюджети, а також у документації Microsoft Project вказано на обмеження за результатами сумарного рівня: « Аналіз за методом PERT, що виконується додатком Microsoft Project, фокусується на рівні завдання. Дані сумарного рівня та загальні дані про проект недостовірні для аналізу за допомогою програми

Підсумок з основних недоліків PERT:

1. Низька точність розрахунків PERT

2. Недостовірність результату при зміні вагових коефіцієнтів

3. Характерно заниження термінів PERT, т.к. PERT відточено для ймовірності всього 50% для виконання проекту. Такий рівень ризику зазвичай неприйнятний.

4. PERT у MS Project не вміє оптимізувати бюджети, лише терміни

5. Реалізація методу PERT у MS Project обмежена, коректні результати лише на рівні завдань

УMicrosoft Project 2010 метод розрахунку PERT не використовується.

6. Методика Монте Карло. Системи моделювання ризиків на базі Монте Карло точніші за PERT (точність вище приблизно на 10%), плюс такі засоби дозволяють задавати рівень ризику в проекті. Прикладом такого засобу для Microsoft Project є Turbo Risk Manager,

який ми розглянемо нижче.

орієнтовними. Необхідно накопичувати свою власну статистику щодо ведення проектів для того, щоб отримати специфічні для даної технології та даних виконавців калібрувальні коефіцієнти

9.10.4 Розрахунок трьох версій проекту методом

Для розрахунку трьох версій проекту скористаємося програмою Turbo EPM Light (http://microsoftproject.ru/turbo/TP2010.zip).

Після її встановлення створимо нову виставу «Ризики – розклад» на основі діаграми Ганта.

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Малюнок 9.37 Створення нового уявлення «Ризики – розклад»

Спочатку виведемо шість колонок та колонку «Тривалість». Всі інші стовпчики приховаємо.

«Тривалість1» перейменовуємо на «Оптимістична тривалість»;

«Тривалість2» перейменовуємо на «Очікувана тривалість»;

«Тривалість3» перейменовуємо на «Песимістична тривалість»;

«Тривалість4» перейменовуємо на «Тривалість з урахуванням ефекту сумарних завдань»;

«Тривалість5» перейменовуємо на «Стандартне відхилення тривалості»;

«Тривалість6» перейменовуємо на «Тривалість до розрахунків».

Для перейменування колонок потрібно виділити шапку колонки і натиснути на ній правою кнопкою миші, в меню вибрати «Поля», вибрати поле і натиснути «Перейменувати».

Далі, за формулою, прирівнюємо колонку «Тривалість» колонці «Тривалість».

Для розрахунку сумарних рядків завдань та груп вибираємо «Використовувати формулу», Рисунок 9.38.

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Малюнок 9.38 Налаштування колонок типу «Тривалість

На закладці TurboProject натискаємо на піктограмі Управління ризиками. Метод і налаштовуємо TurboRiskManager,Малюнок 9.39 і натискаємо «Запуск».

Рисунок 9.39 Установки TurboRiskManager

Графік та бюджет проекту залежать від прийнятного рівня ризику. Тільки метод PERT не має залежності результатів від того, наскільки ми готові ризикувати.

Скорочення графіка та бюджету зазвичай збільшує ризики. Якщо ми не хочемо сильно ризикувати, то нам потрібно більше часу та грошей для реалізації проекту.

Метод дозволяє розрахувати графік та бюджет для бажаного рівня ризику.

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Turbo Risk Manager дозволяє задати такі рівні ризику для розрахунку у відсотках ймовірності проекту вкластися у планові показники:

50% - дуже високий ризик (рівень ризику аналогічний PERT)

75% - помірний ризик (рекомендується як типовий баланс терміни/гроші/ризик)

85% - низький ризик

90% - дуже низький ризик

Після вибору рівня ризику ще до розрахунку ви можете побачити, який рівень додаткових резервів вам знадобиться. Значення виводиться у полі «Стандартне відхилення тривалості «Тривалість5».

Для експертів знайомих з поняттям критерію Стьюдента допустиме завдання рівня ризику шляхом вказівки розміру резерву дисперсії. Для експертів зазначимо, що у цьому випадкуйдеться про односторонній критерій Стьюдента

Результат розрахунків зображено на Рисунок 9.40.

Малюнок 9.40 Розраховані тривалості проекту методом

9.11АНАЛІЗ ПРИБУТКУ 12

У проекті ми передбачили матеріальний ресурс із негативною стандартною ставкою «Дохід від реалізації» для планування прибутку проекту.

12 Забули написати про це раніше

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

Для моделювання прибутку проекту ми призначаємо ресурс «Дохід від реалізації» на завдання «Оплата за договором» етапу «Реалізація об'єкта» у розмірі 150 тис. одиниць (USD). Рисунок 9.41.

Малюнок 9.41 Планування прибутку

Як видно на Рисунку 9.41, витрати у вікні «Призначення ресурсів» перерахувалися за курсом, заданим для даного матеріального ресурсу.

Негативне значення у колонці «Загальні витрати» для сумарного завдання проекту свідчать, що проект дає прибуток.

Олексій Просніцький, MVP, PMP

Самовчитель «Управління проектами у Microsoft Project 2010»

10 ВИКОНАННЯ ПРОЕКТІВ

10.1 УЗГОДЖЕННЯ ПЛАНУ РОБОТИ

Після розробки плану проекту, план проекту потрібно узгодити з підрозділами, відповідальними за виконання етапів та досягнення цілей проекту.

Існує кілька варіантів узгодження плану проекту:

1. Надіслати на погодження план проекту для ознайомлення. Перед тим як надсилати файл проекту, рекомендується захистити файл від редагування, меню «Файл – Зберегти як – Сервіс», Рисунок 10.1, та обов'язково від небажаного доступу недоброзичливців;

Рисунок 10.1 Визначення параметрів збереження

2. Скопіювати фрагмент файлу проекту та надіслати його електронною поштоюпоштою, Малюнок 10.2;