Ми реалізуємо кожен проект для досягнення результатів, визначених компанією. На практиці це означає, що проект має дати конкретні результати. Ми повинні точно знати, які субпродукти і кінцеві продукти ми хочемо створити, перш ніж почати працювати над створенням графіка проекту. Це перший і фундаментальний крок у створенні практичного календарного плану проекту. Необхідні результати мають бути названі та коротко визначені, щоб особи, відповідальні за їх створення, знали, що саме вони повинні надати. Такий перелік визначених продуктів наведено на ілюстрації нижче:
Аналогічно до визначення переліку продуктів, ми повинні з великою точністю і ретельністю підійти до побудови WBS. Розробляючи структуру завдань проекту, варто почати з визначення колективних завдань і прив’язки їх до продуктів, які ми визначили раніше. На практиці ми можемо або прив’язати продукт до конкретного колективного завдання, або наприкінці кожного колективного завдання визначити віху проекту, яка призведе до створення необхідного продукту. Після того, як ми визначили основні завдання в розкладі проекту, ми можемо спуститися на рівень нижче і визначити детальніші завдання. У цьому випадку ми можемо розглядати кожне колективне завдання як “міні-проект”. Варто коротко визначити завдання, визначені у WBS, щоб згодом кожна людина, яка бере участь у проекті, точно знала, які функції на неї покладені. На наступній ілюстрації показана структура WBS, а для обраної, виділеної задачі праворуч показано діалогове вікно з деталями цієї задачі:
Після того, як ми переконалися, що розроблений нами WBS проекту є повним, слід визначити тривалість окремих завдань (їх трудомісткість) і чітко визначити відповідальність за їх виконання. Будь-хто, хто займається управлінням проектами, знає, як призначати відповідальних за завдання і як визначити, коли завдання має розпочатися і скільки часу воно має зайняти. Однак я хотів би звернути особливу увагу на побудову взаємовідносин і логіку зв’язків між різними завданнями, визначеними в календарному плані проекту. Якщо ми мудро пов’яжемо завдання в проекті на етапі створення плану, наша робота в майбутньому буде простою. Якщо пізніше виконання якогось із завдань буде відкладено, всі пов’язані з ним завдання автоматично просунуться вперед. Крім того, якщо ми вже створили зв’язки на етапі планування, коли одне із завдань пересувається вперед або назад у часі, інші пов’язані з ним завдання в проекті будуть рухатися відповідно. На ілюстраціях нижче ми бачимо структуру завдань проекту та графік Ганта з позначеними зв’язками:
Якщо ви впевнені, що у вас вже розроблений хороший графік проекту, збережіть його в системі як базовий план проекту (Baseline), на який ви будете посилатися під час реалізації проекту. На ілюстрації нижче показано поточний проект і його поточний зв’язок із затвердженим календарним планом. Тонкі чорні пунктири під кожним завданням показують затверджений план, а товстіші смуги над ними – поточний ступінь виконання кожного завдання з розкладу проекту:
Добре розроблений план-графік проекту суттєво вплине на кінцевий успіх його реалізації. Люди, які беруть участь у проекті, будуть точно знати, що вони повинні робити і коли. Впроваджуючи настанови, ми можемо чітко відстежувати відхилення та вживати коригувальних заходів.