PMBOK, Управління проектами/Управління проектами - Технологія
Перейти до вмісту

PMBOK, Управління проектами/Управління проектами

Інститут управління проектами (PMI) — це організація, яка намагається встановити стандартний порядок і критерії управління проектами.

Оголошення

З цією метою PMI підтримує Книгу знань з управління проектами (PMBOK), яка містить цілий набір інструментів і передових практик, які повинен знати та застосовувати кожен керівник проекту.

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

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

Перш ніж перейти до теми, необхідно встановити визначення та характеристики проекту відповідно до PMBOK:

  • Проект намагається вирішити проблему (покрити потребу).
  • це тимчасово
  • Він унікальний у часі і не повторюється за тих самих обставин.
  • несе в собі невизначеність
  • Це споживає ресурси: час, гроші, матеріали та праця.

Проекти мають свій життєвий цикл, який поділяється на наступні фази:

  • Початок: Визначається потреба та ставиться питання, чи можливо реалізувати проект.
  • Планування:
    • Більш детально розроблено рішення.
    • Визначення завдань, календар.
    • Оцінка витрат часу та грошей.
    • Знову ж таки, питання в тому, чи життєздатний проект.
  • Виконання: Моніторинг та коригування планування.
  • Завершення: перевіряється, чи проект задовольняє потреби, які необхідно розглянути

Усі ці фази передбачають такі загальні процеси:

  • Визначте проблему чи можливість
  • Визначте та визначте ідеальне рішення
  • Визначте необхідні завдання та ресурси.
  • Підготуйте розклад і отримайте ресурси
  • Оцініть вартість проекту та підготуйте бюджет
  • Аналізуйте ризики та встановлюйте стосунки із зацікавленими сторонами (будь-ким, хто прямо чи опосередковано зацікавлений у проекті): періодичне управління ризиками
  • Підтримуйте контроль і комунікацію на належному рівні під час виконання: періодичні зустрічі для виявлення відхилень і повідомлення про них
  • Керуйте успішним закриттям
    • Punch list: список завдань для виконання проекту.
    • Члени команди, як правило, розходяться, коли проект наближається до завершення.

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

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

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

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

Ця друга ситуація може спричинити у співробітників «менталітет силосу», тобто людей, чиї цілі пов’язані з їх функціональною сферою, а не з проектом, до якого вони були призначені; вони можуть не дбати про успіх проекту, віддаючи перевагу виконанню своїх стабільних зобов'язань від свого підрозділу. Ця проблема може блокувати командну співпрацю (горизонтальне мислення).

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

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

Нарешті, PMBOK встановлює, що для того, щоб вважати проект успішним, мають бути виконані такі очікування:

  • І рівень. Досягнення цілей проекту
  • II рівень. Ефективність проекту.
    • Рівень перерви в роботі клієнта.
    • Ефективне використання ресурсів
    • Зростання кількості членів команди
    • управлінський конфлікт
  • III рівень. Утиліта для кінцевого користувача/клієнта.
    • Чи вирішено початкову проблему?
    • Виплати зросли чи була реальна економія?
    • Чи використовує користувач зараз продукт?
  • IV рівень. Організаційне вдосконалення: вивчення досвіду

керівник проекту

Керівник проекту або керівник проекту має такі обов’язки:

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

З іншого боку, керівник проекту постійно стикається з проблемами, серед яких ми можемо знайти наступне:

  • Відповідальність vs. Відсутність повноважень
    • Високий рівень відповідальності.
    • Я працюю з людьми, над якими не маю прямої влади.
  • нереалістичні цілі
    • Це одна з найпоширеніших проблем.
    • Це підсилює ідею правильного аналізу та планування обсягу проекту.
  • функціональна спрямованість
    • Люди, як правило, зосереджуються на своїй функціональній області знань.
    • Його функціональна сфера важливіша за проект, враховуючи його тимчасовість.
  • Фундаментальний конфлікт через невизначеність
    • Швидко приймайте рішення з невеликою кількістю інформації.
    • Інтервальні оцінки (наприклад, витрати)
    • Намагайтеся, щоб начальство та члени команди розуміли труднощі з оцінкою.

Щоб успішно справлятися з обов’язками та викликами, пов’язаними з управлінням проектами, керівник проекту повинен постійно вдосконалювати такі навички:

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

Визначення проекту

Визначення проекту складається з наступних етапів:

  • Етап I. Зрозумійте проблему чи можливість.
  • II етап. Визначте найбільш оптимальне рішення
  • ІІІ етап. Розробіть рішення та складіть план
  • Етап IV. Запуск проекту

Етап I. Зрозумійте проблему чи можливість.

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

По-перше, необхідно розрізняти потребу та рішення.

Необхідність:

  • Описує мету клієнту
  • Конкретизуйте цілі та завдання
  • Залиште відкритим питання про те, як це зробити.
  • Відповідь на те, чому це робиться, має вказувати на бізнес-виправдання.

Натомість рішення:

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

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

  • Опис проблеми або можливості
  • Вплив або наслідки проблеми
  • Визначте, кого або чого стосується проблема
  • Наслідки ігнорування проблеми
  • бажана ситуація
  • Переваги, пов'язані з досягненням бажаної ситуації
  • Узгодження зі стратегією організації
  • Конфлікт сумісності з іншими сферами організації
  • невизначеності
  • основні припущення
  • Обмеження рішення
  • екологічні міркування
  • Історична довідкова інформація

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

II етап. Визначте найбільш оптимальне рішення

Щоб визначити рішення, які задовольняють визначену потребу, можна виконати таку процедуру:

  • Груповий мозковий штурм із майбутніми членами групи залучення або зацікавленими сторонами.
  • Перевірте, наскільки вони відповідають положенням документації вимог проекту.
  • Виберіть від 2 до 5 варіантів рішення.

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

Фінансовий аналіз (витрати х вигоди):

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

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

Слід вивчити як мінімум такі показники:

  • Чиста теперішня вартість (NPV). Визначте, скільки грошей принесе проект, беручи до уваги часову вартість грошей.
  • Внутрішня норма прибутку (IRR) . Визначити рентабельність інвестицій.
  • Крапка повернення . Визначає, коли інвестиції будуть окуплені (NPV = 0).
  • грошова діра . Визначте максимальні необхідні інвестиції.

Нефінансовий аналіз (модель оцінки зважених факторів – матриця рішень)

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

Перевага:

  • Дозволяє використовувати різні дані, в тому числі фінансові.
  • Дозволяє залучати керівництво та аналізувати чутливість.

Недоліки:

  • Дуже суб'єктивний процес.
  • Це свідчить про привабливість проекту, але не є комерційним обґрунтуванням.

Окрім фінансового або матричного аналізу, остаточне рішення про те, яке рішення вибрати, може ґрунтуватися на використанні інших інструментів:

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

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