1.4: Рамки для управління проектами

Багато різних професій вносять свій внесок в теорію і практику управління проектами. Інженери та архітектори керують великими проектами ще з доісторичних часів. Приблизно з 1960-х років були докладені зусилля для професіоналізації практики управління проектами як власної спеціалізації. Навколо цього є багато активних дискусій: Чи повинен проектний менеджмент бути професією так само, як інженерія, бухгалтерський облік та медицина? Вони мають професійні асоціації, які засвідчують, кому законно дозволено використовувати посаду, і хто може законно практикувати професію. Вони також забезпечують рівень гарантії якості та дисципліни членів, які поводяться неналежним чином. Ще одна дискусія: Скільки галузевих знань потрібно досвідченому менеджеру проекту? Наскільки легко може проектний менеджер з однієї галузі, скажімо, IT, перейти в іншу галузь, наприклад, гостинність?

Існують дві великі організації, які мають всесвітній вплив на практику управління проектами: Інститут управління проектами (PMI) зі світовою штаб-квартирою в США та Міжнародна асоціація управління проектами (IPMA) зі світовою штаб-квартирою в Швейцарії. Цей підручник використовує підхід, ближчий до підходу ФМІ. Більш детальна інформація включена в цей розділ разом з розділом про офіс управління проектами.

Огляд інституту управління проектами

П'ять волонтерів заснували Інститут управління проектами (PMI) в 1969 році. Їх початковою метою було створення організації, де члени могли обмінюватися досвідом в управлінні проектами та обговорювати питання. Сьогодні ФМІ є некомерційною професійною асоціацією з управління проектами та найбільш широко визнаною організацією з точки зору просування кращих практик управління проектами. PMI був сформований для обслуговування інтересів галузі управління проектами. Передумова ФМІ полягає в тому, що інструменти та методи управління проектами поширені навіть серед широкого застосування проектів від програмного забезпечення до будівельної галузі. PMI вперше почав пропонувати сертифікаційний іспит Project Management Professional (PMP) в 1984 році. Хоча це зайняло деякий час, щоб люди помітили, зараз понад 590 000 осіб у всьому світі мають позначення PMP.

Щоб допомогти зберегти терміни та концепції управління проектами чіткими та узгодженими, PMI представив книгу «Посібник з управління проектами» (PMBOK Guide) у 1987 році. Він був оновлений в 1996, 2000, 2004, 2009, а зовсім недавно в 2013 році як п'яте видання. В даний час в обігу налічується понад мільйон примірників Посібника ПМБОК. Високо оцінений Інститут інженерів з електротехніки та електроніки (IEEE) прийняв його як свій стандарт управління проектами. У 1999 році PMI був акредитований як Американський національний інститут стандартів (ANSI) розробник стандартів, а також має відмінність бути першою організацією, яка має свою сертифікаційну програму досягнення Міжнародної організації зі стандартизації (ISO) 9001 визнання. У 2008 році організація повідомила про понад 260 000 членів у понад 171 країнах. Штаб-квартира PMI знаходиться в Пенсільванії, США, а також має офіси у Вашингтоні, округ Колумбія, Канаді, Мексиці та Китаї, а також регіональні сервісні центри в Сінгапурі, Брюсселі (Бельгія) та Нью-Делі (Індія). Нещодавно відкрився офіс в Мумбаї (Індія).

Через важливість проектів дисципліна управління проектами перетворилася на робочий орган знань, відомий як PMBOK - Звід знань управління проектами. PMI відповідає за розробку та просування PMBOK. PMI також адмініструє професійну програму сертифікації для керівників проектів, PMP. Тож якщо ви хочете отримати ґрунт на управлінні проектами, PMBOK - це місце для початку, і якщо ви хочете зробити управління проектами своєю професією, тоді вам слід подумати про те, щоб стати PMP.

Так що ж таке ПМБОК?

PMBOK - це фундаментальні знання, необхідні для управління проектом, розділені на 10 областей знань:

1. Управління інтеграцією: Проекти мають всі види діяльності, і є необхідність тримати «все» річ рухатися колективно - інтегруючи всю динаміку, яка відбувається. Управління інтеграцією полягає в розробці статуту проекту, заяви про сферу діяльності та план направлення, управління, моніторинг та контроль змін проекту.
2. Управління сферою: Проекти повинні мати певний параметр або область дії, і це повинно бути розбито і управляти за допомогою структури розбивки робіт або WBS. Управління сферою - це планування, визначення, створення, перевірка та контроль WBS.
3. Управління часом/графіком: Проекти мають певний початок і певну дату закінчення. Тому виникає потреба в управлінні бюджетним часом згідно з графіком проекту. Управління часом/графіком - це визначення, послідовність, оцінка ресурсів та тривалості, розробка графіка та контроль розкладу.
4. Управління витратами: Проекти споживають ресурси, а отже, виникає потреба в управлінні інвестиціями з реалізацією створення вартості (тобто отримані вигоди перевищують витрачену суму). Управління витратами стосується планування ресурсів, оцінки витрат, бюджетування та контролю.
5. Управління якістю: Проекти передбачають конкретні результати або робочі продукти. Ці результати повинні відповідати цілям проекту та стандартам ефективності. Управління якістю - це планування якості, забезпечення якості та контроль якості.
6. Управління людськими ресурсами: Проекти складаються з команд, і вам потрібно керувати командою (ами) проекту протягом життєвого циклу проекту. Пошук потрібних людей, управління їх результатами та дотримання графіка - це велика частина управління проектом. Управління людськими ресурсами полягає в плануванні людських ресурсів, наймі, а також розробці та управлінні проектною командою.
7. Управління комунікацією: Проекти незмінно торкаються багатьох людей, а не лише кінцевих користувачів (клієнтів), які отримують вигоду безпосередньо від результатів проекту. Сюди можуть входити учасники проекту, менеджери, які здійснюють нагляд за проектом, і зовнішні зацікавлені сторони, які зацікавлені в успіху проекту. Управління комунікацією стосується планування комунікацій, розподілу інформації, звітності про ефективність та управління зацікавленими сторонами.
8. Управління ризиками: Проекти - це процес, заснований на виявленні, часто виявляє нові потреби клієнтів та виявляє критичні проблеми, які раніше не розкриті. Проекти також стикаються з несподіваними подіями, такими як звільнення членів команди проекту, раптово змінюються бюджетні ресурси, організація стає нестабільною та впроваджуються нові технології. Існує реальна необхідність правильно ідентифікувати різні ризики і управляти цими ризиками. Управління ризиками стосується планування та ідентифікації ризиків, аналізу ризиків (якісного та кількісного), планування реагування на ризик (дії) та моніторингу та контролю ризиків.
9. Управління закупівлями: Проекти закуповують послуги зовнішніх постачальників та підрядників, включаючи закупівлю обладнання. Існує необхідність керувати тим, як постачальники вибираються та управляються протягом життєвого циклу проекту. Управління закупівлями стосується планів придбання та контрактів, відповіді та вибору продавців, адміністрування контрактів та закриття контрактів.
10. Управління зацікавленими сторонами: Кожен проект впливає на людей та організації, і на нього впливають люди та організації. Визначення цих зацікавлених сторін на ранньому етапі, а також у міру їх виникнення та зміни протягом усього проекту є ключовим фактором успіху. Управління зацікавленими сторонами полягає у визначенні зацікавлених сторін, їх рівня зацікавленості та їх потенціалу для впливу на проект; а також управління та контролі відносин та комунікацій між зацікавленими сторонами та проектом.

Це велика основа для управління проектами, і якщо ви хочете бути ефективними в управлінні проектами, то вам потрібно бути ефективним в управлінні кожною з 10 областей знань, що входять до складу PMBOK (див. Рис.

Малюнок 4.1: Модель зірки PM, запропонована GeekDistedsed

Сертифікація в управлінні проектами доступна з PMI, PRINCE2, ITIL, критичного ланцюга та інших. Agile методології управління проектами (Scrum, екстремальне програмування, Lean Six Sigma, інші) також мають сертифікати.

Вступ до областей знань з управління проектами

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

Запуск проекту та інтеграція

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

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

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

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

Сфера проекту

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

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

Відповідно до PMI, заява про сферу застосування повинна включати наступне:

• опис сфери застосування
• Критерії прийняття продукції
• Результати проекту
• Виключення проекту
• Обмеження проекту
• Припущення проекту

Обсяжний документ є підставою для узгодження всіма сторонами. Чіткий документ про обсяг проекту також має вирішальне значення для управління змінами в проекті. Оскільки обсяг проекту відображає, яка робота буде виконана над проектом, будь-яка зміна очікувань, які не фіксуються та не задокументовані, створює можливість для плутанини. Однією з найпоширеніших тенденцій на проектах є поступове розширення обсягу проекту. Ця тенденція позначена як «сфера повзучості». Обсяг повзучості загрожує успіхом проекту, оскільки невелике збільшення обсягу вимагає додаткових ресурсів, яких не було в плані. Збільшення обсягу проекту є звичайним явищем, і в бюджет і графік проекту вносяться корективи з урахуванням цих змін. Обсяг повзучості відбувається, коли ці зміни не розпізнані або не керовані. Здатність керівника проекту виявляти потенційні зміни часто пов'язана з якістю обсягу документів.

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

Графік проекту та управління часом

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

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

Щоб розробити більш детальний графік, команда проекту спочатку розробляє структуру розбивки робіт (WBS) - опис завдань, розташованих у шарах деталей. Незважаючи на те, що обсяг проекту є основним документом для розробки СБС, WBS включає всі результати проекту та відображає будь-які документи або інформацію, яка уточнює результати проекту. Від СБС розробляється план проекту. У плані проекту перераховані заходи, необхідні для виконання роботи, визначеної в СБС. Чим детальніше WBS, тим більше заходів, які визначені для виконання роботи.

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

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

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

Витрати на проект

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

Точність бюджету проекту пов'язана з обсягом відомої командою проекту інформації. На ранніх стадіях проекту кількість інформації, необхідної для розробки детального бюджету, часто відсутня. Щоб вирішити проблему нестачі інформації, команда проекту розробляє різні рівні кошторису бюджету проекту. Концептуальна оцінка (або «бальна оцінка») розробляється з найменшим обсягом знань. Основним вкладом в концептуальну оцінку є експертні знання або минулий досвід. Менеджер проекту, який виконував подібний проект в минулому, може використовувати ці витрати для оцінки витрат поточного проекту.

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

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

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

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

Якість проекту

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

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

Посібник ФМІ до Зведення знань з управління проектами (PMBOK Guide) містить велику главу про управління якістю проектів. Матеріал, знайдений у цьому розділі, був би подібний до матеріалу, знайденого в хорошому тексті оперативного управління.

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

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

Ще одна можливість застосування інструментів вдосконалення процесів - це проекти, які мають повторювані процеси. Житловий підрядник, який будує кілька однакових будинків може отримати вигоду від оцінки робочих процесів в перших кількох будинках, щоб вивчити можливості, доступні для поліпшення робочих процесів. Інвестиції $1,000 в робочий процес, який економить $200 за будинок є хорошою інвестицією до тих пір, поки підрядник будує більше п'яти будинків.

Команда проекту: Людські ресурси та комунікації

Забезпечення проекту потрібними навичками, в потрібному місці і в потрібний час є важливою відповідальністю команди управління проектом. У проекті зазвичай є два типи членів команди: функціональні менеджери та менеджери процесів. Функціональні менеджери та команда зосереджені на технології проекту. На будівельному проекті функціональні менеджери включали б інженерного менеджера та будівельного наглядача. На навчальному проекті функціональний менеджер включав би професійних тренерів; на проекті інформаційних технологій менеджери з розробки програмного забезпечення будуть функціональними менеджерами. До складу команди управління проектами також входять менеджери проектних процесів. Команда контролю проекту буде включати менеджерів процесів, які мають досвід оцінки, відстеження витрат, планування та планування. Менеджер проекту потребує функціональної та технологічної експертизи для планування та виконання успішного проекту.

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

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

Наприклад, на великому комерційному будівельному проекті команда цивільного будівництва, яка проектує роботу на майданчику, де буде побудована будівля, зробить свій найбільший внесок на ранніх етапах проектування. Ведучий цивільного будівництва призведе до різних цивільних інженерних спеціальностей, як вони були необхідні. Оскільки будівельні роботи завершені, а будівельна інженерія йде в повному обсязі, велика частина інженерів-будівельників буде звільнена від проекту. Функціональні менеджери, інженерний менеджер та керівник цивільного будівництва надаватимуть експертизу протягом усього періоду проекту, вирішуючи технічні питання, які можуть виникнути, та вирішуючи запити на зміни.

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

Комунікації

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

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

Ризик проекту

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

Перший крок у розробці плану управління ризиками передбачає виявлення потенційних ризиків проекту. Деякі ризики легко визначити, наприклад, потенціал для шкідливого шторму в Карибському басейні, а деякі менш очевидні. Багато галузей або компаній мають контрольні списки ризиків, розроблені на основі минулого досвіду. Інститут будівельної галузі опублікував контрольний список ризиків із 100 пунктів, який містить приклади та напрямки проектних ризиків. Жоден контрольний список ризиків не включатиме всі потенційні ризики. Цінність чек-листа полягає в стимулюванні дискусії та роздумів про потенційні ризики на проекті.

Команда проекту аналізує виявлені ризики і оцінює ймовірність виникнення ризиків. Потім команда оцінює потенційний вплив на цілі проекту, якщо подія відбудеться. Результатом цього процесу є пріоритетний перелік оцінюваних ризиків проекту зі значенням, яке представляє ймовірність виникнення та потенційний вплив на проект.

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

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

Закупівля проекту

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

На великих, більш складних проектах персонал присвячений закупівлі та управлінню обладнанням, витратними матеріалами та матеріалами, необхідними для проекту. Через тимчасовий характер проектів обладнання, витратні матеріали та матеріали закуповуються як частина продукту проекту або для виконання проекту. Наприклад, цегла, закупована для будівельного проекту, буде закуповуватися для продукту проекту, а змішувач розчину - обладнання, закуплене для виконання проектних робіт. Після закінчення проекту обладнання, куплене або орендоване для виконання робіт по проекту, продається, повертається орендним організаціям або утилізується якимось іншим способом.

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

Управління зацікавленими сторонами проекту

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

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

Таблиця 4.1 Реєстр зацікавлених сторін

Область знань	Ініціювання	Планування	Виконання	Моніторинг та контроль	Закриття
Управління інтеграцією проектів	Розробка статуту проекту	Розробка плану управління проектами		Моніторинг і контроль роботи проекту Виконання інтегрованого контролю змін	Закрити проект або фазу
Управління сферою проекту		Планування управління сферою Зібрати вимоги Визначте область застосування Створити WBS		Перевірити область Сфера управління
Управління часом проекту		Управління розкладом плану Визначте діяльність Послідовність дій Оцініть ресурси діяльності Оцініть тривалість активності Розробити графік		Графік контролю
Управління витратами проекту		План управління витратами Оцінити витрати Визначте бюджет		Контроль витрат
Управління якістю проектів		План управління якістю	Виконання забезпечення якості	Контроль якості

Огляд розробки Scrum

«Скрам» - це ще одна формальна методологія управління проектами/розробки продукту та частина agile-менеджменту проектів. Scrum - термін від регбі (scrimmage), що означає спосіб перезапуску гри. Це як перезапуск зусиль проекту кожні X тижнів. Він заснований на ідеї, що ви насправді не знаєте, як планувати весь проект наперед, тому ви починаєте і будуєте емпіричні дані, а потім переплануєте і повторюєте звідти.

Scrum використовує послідовні спринти для розробки. Спринти - це як невеликі фази проекту (в ідеалі від двох до чотирьох тижнів). Ідея полягає в тому, щоб взяти один день, щоб спланувати те, що можна зробити зараз, потім розробити те, що планувалося, і продемонструвати це в кінці спринту. Scrum використовує коротку щоденну зустріч команди розробників, щоб перевірити, що було зроблено вчора, що планується на наступний день, і що, якщо щось заважає членам команди виконати те, що вони взяли на себе зобов'язання. Після закінчення спринту те, що було продемонстровано, потім можна перевірити, і починається наступний цикл спринту.

Методологія Scrum визначає кілька основних ролей. Ними є:

• Власники продукту: по суті власник бізнесу проекту, який знає галузь, ринок, клієнтів та бізнес-цілі проекту. Власник продукту повинен бути тісно залучений до процесу Scrum, особливо планування та демонстраційних частин спринту.

• Scrum Master: чимось схожий на менеджера проектів, але не зовсім. Обов'язки Scrum Master по суті полягають у усуненні бар'єрів, що перешкоджають прогресу команди розробників, навчити власника продукту, як максимізувати рентабельність інвестицій (ROI) з точки зору зусиль з розробки, сприяти творчості та розширенню можливостей команди, підвищити продуктивність команди, поліпшити інженерні практики та інструменти, проводити щоденні стендап-зустрічі, відстежувати прогрес та забезпечувати здоров'я команди.

• Команда розробників: самоорганізуюча (лідерство з легким дотиком), уповноважена група; вони беруть участь у плануванні та оцінці кожного спринту, роблять розробку та демонструють результати наприкінці спринту. Показано, що ідеальним розміром для команди розробників є 7 +/- 2. Команду розробників можна розбити на «teamlets», які «рояться» на історії користувачів, які створюються в сесії планування спринту.

Як правило, спосіб розробки продукту полягає в тому, що існує «передній пальник» (який має історії/завдання для поточного спринту), «задній пальник» (який має історії для наступного спринту) та «холодильник» (який має історії на потім, а також зміни процесу). Можна подивитися на продукт як розбитий так: продукт -> особливості -> історії -> завдання.

Часто оцінки зусиль робляться за допомогою «сюжетних точок» (крихітні = 1 СП, малі = 2 СП, середні = 4 СП, великі = 8 СП, великі = 16+ СП, невідомі =? SP) Історії можуть бути різних типів. Історії користувачів дуже поширені і є описом того, що користувач може зробити і що відбувається в результаті різних дій з заданої відправної точки. Інші типи історій з цих областей: аналіз, розробка, QA, документація, інсталяція, локалізація та навчання.

Планування зустрічей для кожного спринту вимагає участі власника продукту, Scrum Master та команди розробників. На планувальній зустрічі вони встановлюють цілі для майбутнього спринту та вибирають підмножину відставання продукту (запропонованих історій) для роботи. Команда розробників розкладає історії на завдання і оцінює їх. Команда розробників та власник продукту проводять остаточні переговори, щоб визначити відставання для наступного спринту.

Методологія Scrum використовує метрики для подальшого планування та відстеження прогресу; наприклад, «спалити» — кількість годин, що залишилися в спринті, проти часу в днях; «швидкість» — по суті, кількість зусиль, які команда витрачає. (Після приблизно трьох спринтів з тією ж командою можна відчути, що команда може зробити вперед.)

Деякі застереження щодо використання методології Scrum: 1) Вам потрібні віддані, зрілі розробники; 2) Вам все ще потрібно зробити основні визначення вимог, деякий аналіз, визначення архітектури та визначення ролей та термінів заздалегідь або рано; 3) Вам потрібно зобов'язання від компанії та власника продукту; і 4) Це найкраще для продуктів, які потребують частих нових випусків або оновлень, і менш ефективні для великих, абсолютно нових продуктів, які не дозволять часто оновлювати після їх випуску.

Офіс управління проектами

Багато великих і навіть середніх організацій створили відділ для нагляду та підтримки проектів у всій організації. Це спроба зменшити велику кількість невдалих проектів (див. розділ Огляд управління проектами). Ці офіси прийнято називати офісом управління проектами або PMO.

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

Типовими цілями PMO є:

• Допомога забезпечити відповідність проектів організаційним цілям
• Забезпечити шаблони та процедури для використання менеджерами проектів
• Забезпечити навчання та наставництво
• Забезпечити полегшення
• Будьте в курсі останніх тенденцій в управлінні проектами
• Служити сховищем для звітів про проекти та отриманих уроків

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

Текстові атрибуції

• Таблиця 4.1 Адрієнна Ватт. © CC BY (Зазначення авторства).

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

• Управління проектами Меррі Баррон та Ендрю Баррон. © CC BY (Атрибуція). [1]
• Управління проектами від простого до складного Рассел Дарналл, Джон Престон, Університет Східного Мічигану. © CC BY (Attribution).

Атрибуції ЗМІ

• Модель зірки PM від GeekDesplaced © CC BY-SA (Із Зазначенням Авторства На Тих Самих Умовах)