If (виникла проблема) then

Перегляд технічних або організаційних параметрів проекту

End if

End loop

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

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

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

План проекту

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

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

1. Вступ. Короткий опис цілей проекту і проектних обмежень (бюджетних, тимчасових і так далі), які важливі для управління проектом.

2. Організація виконання проекту. Опис способу підбору команди розробників і розподіл обов'язків між членами команди.

3. Аналіз ризиків. Опис можливих проектних ризиків, вірогідність їх прояву і стратегій, спрямованих на їх зменшення.

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

5. Розбиття робіт на етапи. Процес реалізації проекту розбивається на окремі процеси, визначаються етапи виконання проекту, приводиться опис результатів ("виходів") кожного етапу і контрольні відмітки.

6. Графік робіт. У цьому графіку відображуються залежності між окремими процесами (етапами) розробки ПО, оцінки часу їх виконання і розподіл членів команди розробників по окремих етапах.

7. Механізми моніторингу і контролю за ходом виконання проекту. Описуються звіти, що надаються менеджером, про хід виконання робіт, терміни їх надання, а також механізми моніторингу усього проекту.

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