Skip to main content
LibreTexts - Ukrayinska

1.3: Ініціація проекту, обсяг та структура

  1. Last updated
  2. Save as PDF
  • Page ID
    104550

    • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Планування без дій марно. Дія без планування є фатальною. —Анонімний

    Цілі

    Прочитавши цю главу, ви зможете

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

    Великі ідеї в цьому уроці

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

    3.1 Ініціація та життєвий цикл проекту

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

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

    Малюнок 3-1: Традиційний погляд на управління проектами

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

    Малюнок 3-2: Щоб успішно ініціювати проект, потрібно передбачити весь життєвий цикл результату проекту (Джерело: John Nelson)

    Приймаючи цей цілісний, життєвий цикл зору спонукає вас задавати кращі питання про те, що «успіх» насправді означає для вашого проекту. Наприклад, оскільки сталий розвиток стає постійно існуючим інженерним завданням, керівникам проектів часто потрібно враховувати довгострокові екологічні наслідки при оцінюванні успіху проекту. Це тягне за собою використання таких інструментів, як оцінки життєвого циклу (ДМС) для оцінки «потенційного впливу на навколишнє середовище продукту, матеріалу, процесу або діяльності» і для «оцінки діапазону впливу на навколишнє середовище протягом усього життєвого циклу системи продуктів, від придбання матеріалів до виробництва, використання, і остаточне розпорядження» (Агентство з охорони навколишнього середовища США n.d.).

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

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

    Один з найкращих способів дізнатися про проект - поговорити з усіма учасниками:

    • Взаємодійте з замовником, щоб дізнатися все, що ви можете про те, що вони хочуть від проекту в довгостроковій перспективі. Іншими словами, з'ясувати, як замовник визначає цінність проекту. Будьте готові задати багато питань. У деяких ситуаціях може бути корисно спостерігати, як клієнт використовує продукт, щоб отримати краще уявлення про незадоволені потреби. Майте на увазі, що клієнти не завжди точно знають, чого вони хочуть, і їм, можливо, не прийшло в голову, що вони можуть сформувати своє мислення навколо життєвого циклу проекту. Їм може знадобитися допомога поінформованого, досвідченого, чутливого керівника проекту, щоб сформулювати свої цілі.
    • Подумайте широко про те, хто такий клієнт, і включіть потреби кінцевого споживача - кінцевого клієнта - у своє мислення. Наприклад, якщо ви будуєте нову клініку, не обмежуйтеся керівниками HMO, які платять за будівлю. Знайдіть час, щоб поговорити з людьми, які дійсно будуть користуватися будівлею - лікарями, медсестрами, техніками, адміністративним персоналом, обслуговуючими працівниками та пацієнтами.
    • Поговоріть із зацікавленими сторонами - людьми, на яких вплине або які можуть вплинути на проект, і запитайте про їхні проблеми та потреби. Переконайтеся, що ви розумієте їх основні припущення.
    • Як і при виявленні клієнтів, загалом думайте про те, хто зацікавлені сторони. Замовник і кінцеві користувачі є явно зацікавленими сторонами, як і менеджер, який спонсорує проект, і члени команди проекту. Але не забувайте про постачальників, власників ресурсів, державних службовців та контролюючих органів, а також членів інших відділів у вашій організації. (Йорданія 2012)

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

    Малюнок 3-3: Навіть у традиційному погляді на управління проектами фази проекту часто перекриваються

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

    3.2 Робота посвяти

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

    • Статут проекту: «Єдине, консолідоване джерело інформації» (Richter 2014) для ініціації та планування проекту. Він описує ваші поточні знання про проект і включає в себе таку інформацію, як імена всіх зацікавлених сторін, заяву про потреби вашої організації, історію, що веде до проекту, мета проекту, результати, а також ролі та обов'язки. Статут проекту також іноді називають заявою про огляд проекту. Буде корисно розглядати статут проекту як контракт між командою проекту та спонсорами проекту.
    • оператор scope: документ, який визначає сферу реалізації проекту. Визначення сфери, яка дійсно є серцем фази ініціації, детально розглядається в наступному розділі.
    • бізнес-кейс: «Аргумент, зазвичай документований, який покликаний переконати особу, яка приймає рішення, схвалити якусь дію. Як правило, бізнес-кейс повинен сформулювати чіткий шлях до привабливої рентабельності інвестицій (ROI). Найпростішим, бізнес-кейс може бути розмовною пропозицією... Для більш складних питань бізнес-кейс повинен бути представлений в ретельно побудованому документі. Документ бізнес-кейсу повинен досліджувати переваги та ризики, пов'язані як з вчиненням заходів, так і, навпаки, не вчинення заходів. Висновок повинен бути переконливим аргументом для реалізації» (TechTarget n.d.). Бізнес-кейс стосується цих фундаментальних питань: 1) Чому цей проект? 2) Чому цей проект над іншим проектом? і 3) Чому цей проект зараз?

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

    • структура розбивки робіт (WBS): Опис завдань, пов'язаних з результатами проекту, часто у вигляді деревоподібної діаграми. Структура розбивки робіт «відображає зв'язок кожного завдання з іншими завданнями, до цілого і кінцевого продукту (мета або завдання). Він показує розподіл відповідальності та визначає необхідні ресурси та час, доступний на кожному етапі для моніторингу та управління проектами» (Business Dictionary n.d.). Завантажити файл Excel з шаблоном для структури розбивки робіт можна тут: Структура розбивки робіт.
    • Структура організаційної розбивки (OBS): Опис команди проекту. У ньому пояснюється, «хто кому звітує, деталі ієрархії та структура звітності... Організаційні структури розбиття зазвичай повідомляються візуально за допомогою графіків або діаграм. Проект або генеральний менеджер перераховані, і під ПМ може бути створено кілька підрозділів, таких як розробка продукту, дизайн, управління матеріалами та виробництво» (Бредлі н.д.). Див. також матрицю призначення відповідальності (ОЗУ) нижче.
    • робочий пакет: «Група пов'язаних завдань в рамках проекту. Оскільки вони схожі на самі проекти, їх часто розглядають як підпроекти в рамках більшого проекту. Робочі пакети - це найменша одиниця роботи, на яку можна розбити проект під час створення структури розбивки робіт (WBS)» (Wrike n.d.).
    • Матриця призначення відповідальності (ОЗУ): Тип організаційної структури розбивки у вигляді сітки, яка зазвичай перераховує завдання проекту в першому стовпці та зацікавлені сторони у верхньому рядку, із завданнями, призначеними різним зацікавленим сторонам. Ви можете використовувати його, щоб визначити, чи є у вас достатньо ресурсів для проекту, і для запису, хто за що відповідає. ОЗУ бувають декількох форм, але однією з найкорисніших є відповідальна, підзвітна, консультує та інформує (RACI) діаграма, яка позначає відносини кожної зацікавленої сторони до кожного завдання, використовуючи такі категорії: відповідальний (фактично виконує роботу), підзвітний (має остаточні повноваження над діяльність), консультації (доступні для надання інформації про діяльність), або інформовані (інформується після завершення діяльності, часто тому, що його або її власна робота залежить від цього) (Doglione 2018). Завантажити шаблон матриці RACI можна тут: «Матриця призначення відповідальності». Короткий вступ до діаграм RACI див. цю веб-сторінку: «Графіки RACI». (Діаграму RACI іноді також називають лінійною діаграмою відповідальності.)

    Уникайте посередності усереднення ідеї

    Коли ви приступаєте до систематичного навчання, яке є відмінною рисою фази ініціації, ви зіткнетеся з багатьма ідеями про найкращий спосіб досягти успіху. Деякі можуть бути по-справжньому інноваційними, а інші - невеликі варіації на тій же старій речі. Якщо інновації є вашою метою, то подбайте про те, щоб не стати жертвою усереднення ідеї - взявши трохи від однієї ідеї, і трохи від іншої, і трохи від іншої - не повністю зобов'язуючись жодної. За словами Ендрю Хілла, в блозі на цю тему, одним із способів уникнути усереднення ідеї «є створення сильної культури зворотного зв'язку. Надання членам команди налаштувань, де вони можуть вказати на недоліки в поточних проектах, допоможе перекласти їх розум у режим критичного мислення. Зворотній зв'язок також надає вам інструмент для вимірювання, виявлення або прогнозування невдачі проекту. Таким чином, ідеї, над якими ви вирішили діяти, ніколи не закладаються в камінь, вони постійно переоцінюються та переосмислюються» (Hill 2016). Ви можете прочитати повну публікацію в блозі тут: «Як уникнути усереднення ідеї».

    3.3 Визначення успіху

    Досвідчені менеджери проектів знають, що починати потрібно швидко, визначаючи, що означає «успіх» для вашого проекту та визначення того, як його виміряти. Для цього потрібно поговорити з приватними особами та організаціями, які визначать, чи є проект успішним. Це може включати внутрішніх або зовнішніх клієнтів, окремих осіб або груп з органом затвердження або групи потенційних клієнтів. Багато проектів грають, коли відповідальні інженери кажуть: «Ми виконали свою мету. Ми дотримувалися плану, як написано», але замовник каже: «Ви не надали того, що я хотів».

    Незліченні продукти були випущені, а згодом припинені, оскільки технічні характеристики не відповідали потребам клієнтів. Одним із прикладів є випуск Facebook Home 2013 року, призначеного для користувача інтерфейсу для телефону Android, який перетворив Facebook на домашній екран користувача, видаливши функції, такі як доки та папки додатків, які люблять користувачі Android. Як компанія могла зробити таку величезну помилку? Згідно з Business Insider, команда розробників Facebook Home, що складається в основному з користувачів iPhone, «була незнайома з функціями, до яких звичайний користувач Android може звикнути, і, можливо, не захоче втратити, коли вони встановили Facebook Home» (Карлсон 2013). Ця неможливість дізнатися про потреби клієнтів мала катастрофічні результати. Ціна HTC First, телефон, на якому Facebook Home був попередньо встановлений, знизилася з 99 до 99 центів протягом декількох тижнів (Tate 2013). Зрештою, журнал Time назвав HTC First одним із «найламніших моментів у техніці» за 2013 рік (McCracken 2013).

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

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

    Успішні менеджери проектів, як правило, дуже специфічні, коли вони визначають успіх проекту. Навпаки, нові менеджери проектів роблять помилку, будучи занадто загальними. Тим не менш, бути конкретним не обов'язково означає бути довгим. Зосередившись на потребах кінцевого користувача, а не на створенні вичерпного каталогу фізичних вимог, ви надасте стисле, корисне визначення «успіху» для вашого проекту. Використовуючи такий підхід, Лі Еві, менеджер проекту відновлення Пентагону після атаки 9/11, зміг консолідувати тисячі сторінок специфікацій у «16 вимог на основі продуктивності. Наприклад, його вимога щодо енергоефективності полягала в тому, щоб будівля не використовувала більше певної кількості БТУ [британських теплових одиниць] для обігріву та охолодження будівлі на рік. Тоді це було до проектувально-будівельних команд, щоб задовольнити вимоги в рамках бюджету» (Rife 2005).

    Успіх у Lean та Agile

    Традиційні менеджери проектів, як правило, визначають успіх з точки зору завершення проекту вчасно та в рамках бюджету. Але Lean передбачає більш широке визначення успіху - таке, яке надає пріоритет усунення відходів та максимізації вартості, а також у процесі побудови лояльності клієнтів, що поширюватиметься на ще непередбачені проекти. Невпинне зосередження уваги на усуненні відходів у потоці вартості має наслідковий ефект ведення проектів за графіком та в межах бюджету. Це також має тенденцію покращувати якість кінцевого продукту, додаючи цінність, яка насправді принесе користь клієнту. Щоб дізнатися більше, ознайомтеся з цим детальним поясненням історії та корисності Lean в управлінні проектами: «Витоки Lean Project Management».

    У Agile development команда узгоджує своє визначення проміжного успіху у вигляді мети спринту на кожній зустрічі планування. Успіх для всього проекту не вимірюється з точки зору того, щоб бути вчасно і за бюджетом. Натомість, в дусі маніфесту Agile, успіх означає надання «робочого програмного забезпечення часто» - програмного забезпечення, яке клієнт може фактично використовувати (Beedle et al. n.d.). Зрештою, успіх в Agile означає надання стільки робочого програмного забезпечення, скільки дозволить графік і бюджет. Тренер Agile Анджела Джонсон пояснює своє бачення успіху Agile в цьому цікавому блозі: «Визначення показників успіху для методології гнучкого проекту».

    3.4 Створення статуту проекту

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

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

    • Назва спонсора проекту
    • Взаємозв'язок між цілями проекту та вищими організаційними цілями
    • Переваги проекту для організації
    • Очікувані терміни виконання робіт
    • Короткий опис результатів (цілей) проекту
    • Бюджет, асигнування та ресурси, доступні команді проекту
    • Повноваження керівника проекту
    • Підпис спонсора (Видавнича корпорація Гарвардської школи бізнесу 2006, 2-3)

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

    Неоднозначність цілей може призвести до непорозумінь, розчарувань, дорогих переробок. Розглянемо цей приклад мети широкого пензля: «Розробити веб-сайт, який здатний надавати швидку, точну, економічно вигідну інформацію про продукт та їх виконання для наших клієнтів». Саме так спонсор може описати мету проекту в статуті. Але що саме це означає? Що таке «швидкий»? Як слід визначати точність? Чи прийнятна одна помилка в 1000 транзакцій, або одна помилка в 10 000 відповідає очікуванням спонсора? Якою мірою сайт повинен бути економічно ефективним? На кожне з цих питань слід відповісти за консультацією зі спонсором та ключовими зацікавленими сторонами. (Видавнича корпорація Гарвардської школи бізнесу 2006, 4-5)

    Але хоча ви хочете бути конкретними щодо цілей проекту, подбайте про те, щоб не зупинятися на точних деталями щодо того, як ви досягнете цих цілей:

    Продуманий статут вказує на цілі, але не вказує кошти. Засоби повинні бути залишені менеджеру проекту, керівнику групи та членам. Робити інакше - тобто розповідати команді, що вона повинна робити і як це зробити, підірве будь-яку вигоду, отриману від набору компетентної команди. (Видавнича корпорація Гарвардської школи бізнесу 2006, 5)

    Сфера застосування в Agile

    Роберт Меррілл, старший бізнес-аналітик Університету Вісконсин-Медісон та тренер Agile, радить приймати трикомпонентний підхід до сфери застосування Agile проектів, визначаючи наступне:

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

    Зауважте, що ці категорії не заморожені; їх можна змінювати під час кожного циклу планування ітерації. Область застосування в Agile проекті є змінною, але ретельно і помітно керованою.

    3.5 Управління обсягом проекту

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

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

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

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

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

    Малюнок 3-4: Контекст значною мірою визначається організаційними, соціальними та політичними структурами, в яких відбувається проект

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

    Успіх ≠ Немає змін до обсягу проекту

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

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

    Створення заяви про чітку область

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

    Написання заяви про область, документ, який визначає обсяг проекту, є основною частиною етапу ініціації. Однак, за словами Бреда Бігелоу у статті для Інституту управління проектами, це «зазвичай виражається якісно, що залишають місце для тлумачення та нерозуміння. Отже, часто це найбільше джерело конфліктів у проекті» (2012, 1).

    Щоб уникнути таких проблем, досвідчені керівники проектів докладають багато зусиль для того, щоб дізнатися, що слід, а не слід включати в проект, а потім максимально чітко сформулювати ці межі у вигляді заяви про сферу. За словами Бігелоу, ця робота має важливе значення для забезпечення успіху проекту: «Жоден проект ніколи не може бути повністю вільним від нечіткості - вільний від суб'єктивності та недосконалих визначень - до тих пір, поки люди беруть участь. З іншого боку, також дуже малоймовірно, що будь-який проект коли-небудь переживе ініціацію, якщо його обсяг буде повністю розпливчастим, невизначений і підлягає непередбачуваним очікуванням» (2).

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

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

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

    Думки різняться щодо того, що саме повинно включати в себе заяву про сферу дії, але принаймні воно повинно містити наступне:

    • Коротке обґрунтування мети проекту, включаючи резюме бізнес-потреб, на які буде розглянуто проект.
    • Пояснення цілей проекту.
    • Критерії прийняття, які визначають умови, які повинні задовольняти товар або послуга, перш ніж клієнт прийме результати.
    • Результати, які є «кількісними товарами чи послугами, які будуть надані після завершення проекту. Результати можуть бути матеріальними або нематеріальними частинами процесу розробки, і вони часто визначаються функціями або характеристиками проекту» (Investopedia n.d.).
    • Пояснення чогось виключеного з проекту — іншими словами, пояснення того, що виходить за рамки проекту. Цей список повинен бути «настільки деталізованим, наскільки це необхідно для визначення меж проекту для всіх зацікавлених сторін» (Feldsher 2016).
    • Обмеження, такі як бюджет і графік.
    • Припущення, включаючи все, що ви зараз вважаєте правдою щодо проекту. Також корисно включити ідеї «про те, як ви будете вирішувати невизначену інформацію, коли ви замислюєте, плануєте та виконуєте свій проект» (Portny n.d.).
    • Пояснення будь-якої нової або незвичайної технології, яку ви плануєте використовувати протягом усього проекту. Це не типова частина заяви про сферу застосування, але «цілком ймовірно, що зацікавлені сторони оцінять прозорість і почуватимуться більш комфортно з просуванням проекту» (Feldsher 2016).

    Деякі практичні ідеї для роботи з Scope

    Успішний менеджер проекту вміє керувати клієнтами, які просто можуть не знати, чого вони хочуть, поки не побачать його. Для справді інноваційних продуктів клієнти можуть навіть не мати можливості визначити, чого вони хочуть. Прислів'я, що приписується Генрі Форду, підсумовує це акуратно: «Якби я запитав людей, чого вони хочуть, вони б сказали швидше коней». Sony Walkman був створений не для того, щоб задовольнити будь-який виявлений споживчий попит на портативну музику, а у відповідь на запит співзасновника Sony Масару Ібука про зручний спосіб прослуховування опери. Дизайнер Sony приступив до роботи за спеціальним запитом, і результатом став один з найуспішніших продуктів Sony всіх часів (Franzen 2014).

    Спритний погляд на область повзучості

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

    У цьому середовищі постійних ітерацій і ревізій розробники Agile мають інший погляд на область повзучості. Повідомлення в блозі для OptiSol описує деякі способи визначити, що є і не є сферою повзучості в Agile. Внесення змін «до того, як команда почала думати про деталі» не буде вважатися повзучістю в Agile, а також не замінить одну функцію іншою, доки нова функція не додасть нову роботу для команди. Однак заміна нової функції на функцію, яка вже завершена, безумовно, є формою повзучості, оскільки вона створює нову роботу. Те ж саме стосується заміни невеликої функції чимось більш складним (OptiSol n.d.). Ви можете прочитати повний пост в блозі тут: «Що таке Scope Creep в Agile Development? »

    Коли розробники Facebook представили Facebook Home, вони думали, що вони направляють своїх клієнтів на новий спосіб використання своїх мобільних телефонів, так само, як Sony направляла своїх клієнтів на новий спосіб прослуховування музики. Але оскільки розробники Facebook так мало знали про потреби своїх клієнтів, що використовують Android, вони в кінцевому підсумку створили марний продукт. Мораль історії: перш ніж намагатися направляти своїх клієнтів, переконайтеся, що ви розумієте їх потреби.

    Ось кілька інших порад, про які слід пам'ятати, думаючи про сферу застосування:

    • Інженери, як правило, занадто зосереджуються на тому, що вони знають, мало звертаючи уваги на те, що вони не знають. Приділіть трохи часу, щоб подумати про те, що ви знаєте, що не знаєте. Тоді спробуйте уявити, як ви будете мати справу з можливими ризиками, які можуть спричинити за собою невідомі.
    • Інженери, як правило, дуже деталізовані люди. Це може бути проблемою під час ініціації проекту, якщо це змусить вас намітити кожну деталь проекту без урахування загальної картини. Звичайно, деталі важливі, але вам також потрібно взяти погляд на високому рівні на початку. Не всі деталі мають однакове значення, і важливі деталі можуть змінюватися з часом.
    • Інженери, як правило, зосереджуються на тому, щоб робити, а не думати. Вони люблять стрибати прямо в і почати виконувати проект. Але пам'ятайте, що ініціація проекту - це ваш час спочатку роздумувати. Визначення сфери, зокрема, - це процес мислення, в якому ви намагаєтеся осмислити те, чого не знаєте.
    • Не всі вимоги до проекту рівні. Вони можуть варіюватися від «абсолютно must have», до «хотів би мати». Обговорюючи вимоги з замовником, переконайтеся, що ви розумієте, де кожна вимога відповідає цій шкалі.
    • Задайте замовнику якомога більше різних питань щодо проекту. «Досліджуючи вимоги та очікування замовника з якомога більшої кількості ракурсів, проектна команда може значно скоротити кількість невизначених елементів обсягу проекту та зменшити потенційну мінливість цих елементів. Це не гарантує, що конфліктів за обсягом проекту не виникне, але може допомогти ізолювати потенційні джерела цих конфліктів» (Bigelow 2012, 4).
    • Кращі менеджери проектів розуміють важливість вивчення всього, що вони можуть про визначення своїх клієнтів «цінність» та «успіх», а потім пропонують способи досягнення тих цілей, які виходять за рамки того, що їх клієнти можуть уявити. Такі керівники проектів орієнтуються на вимоги до продуктивності та варіанти їх досягнення, і уникають занадто швидкого блокування в один підхід.
    • Оскільки проект прогресує після початку та до планування та виконання, не забудьте регулярно переглядати визначення обсягу проекту, щоб переконатися, що це все ще доречно. Оскільки проект рухається вперед і зацікавлені сторони дізнаються про нього більше, зміни масштабів, як правило, неминучі. «Дійсно, нездатність проекту врахувати зміну обсягу може мати набагато більш серйозні наслідки для організації в цілому, ніж якби зміни були прийняті - навіть якщо ця зміна збільшила бюджет проекту та продовжила його графік. Здатність проекту адаптуватися до таких змін може мати вирішальне значення в його кінцевій цінності для організації. Зрештою, цілі проекту підпорядковані цілям організації, а не навпаки. Тому дуже важливо, щоб проектна команда розуміла на самому старті проекту: що важливіше? Уникати змін або керувати ними?» (Бігелоу 2012, 6).
    • Одним з ризиків є визначення продукту, який має всі найкращі характеристики кожного конкурента на ринку - наприклад, проектування промислового двигуна з найменшим можливим розміром, найвищою ефективністю, найнижчою вартістю, найвищим крутним моментом та кожним аксесуаром, доступним при запуску. Просто спроба перевершити конкуренцію в специфікаціях заважає команді шукати проривне рішення.
    • Команди, які успішно визначають обсяг проекту, зазвичай починають проводити час, спостерігаючи за тим, як клієнти використовують відповідні продукти або послуги.

    3.6 З окопів: Майкл Муха про сталий розвиток та адаптивні виклики

    Майкл Муха є головним інженером та директором столичного каналізаційного району Медісон, є чинним головою Комітету ASCE з питань сталого розвитку, а також входить до ради директорів Sustain Dane в Медісоні, штат Вісконсін. Він пояснює, що обсяг проекту визначається типом проблеми, яку ви намагаєтеся вирішити. Це технічно - з чітким рішенням, яке інженери традиційно навчаються надавати? Або це адаптивне - без певного консенсусу щодо того, як діяти, при цьому кожне рішення гарантовано кине виклик цінностям та переконанням зацікавлених сторін? Або це поєднання обох?

    Сталі інженерні рішення часто пов'язані з адаптивними проблемами. Як приклад він описує недавній проект:

    Нам потрібно було модернізувати насосну станцію стічних вод між рампи човна Marshall Park Медісона та зайнятою велосипедною доріжкою. Будівництво самої станції було технічною проблемою. Якби ми працювали в загальному вакуумі, ми могли б побудували його певного розміру та потужності і зробили з цим. Але щоб побудувати цю насосну станцію в такому жвавому районі, до якого люди відчували сильні почуття, нам довелося застосувати адаптивний підхід. Це означало зосередження уваги на наданні соціальних переваг, таких як громадські туалети, два водні інвазивні види гідрантів для миття човнів та станція для ремонту велосипедів. Але ми також працювали над тим, щоб проінформувати громадськість про більшу важливість очищення стічних вод. Наприклад, один простий спосіб привернути чиюсь увагу - пояснити, що, коли ви промиваєте туалет, вода їде до Мексиканської затоки за 40 днів. Як тільки ви це зрозумієте, ви можете бути схильні бачити насосну станцію як частину більшої історії - спосіб допомогти захистити глобальне середовище.

    Іншими словами, проблема перейшла від технічного до адаптивного виклику. Будівництво насосної станції йде дуже прямо вперед. Ви можете викласти всі кроки в посібнику. Це технічна частина. Але керівництва по вирішенню адаптивної проблеми немає. Вона передбачає зміну переконань і цінностей людей. У випадку з насосною станцією ми хотіли змінити уявлення людей про те, як вони думають про стічні води, щоб вони бачили роботу на станції як частину чогось більшого. (Муха 2017)

    Різниця між адаптивними та технічними проблемами вперше була прописана Рональдом Хейфецем у своїй книзі 1998 року «Лідерство без відповідей». Для практичного, практичного введення в цю тему Муха рекомендує Практика адаптивного лідерства (Heifetz, Linsky and Grashow 2009).

    3.7 Контекст проекту

    Реалії екстерналій

    Один термін, тісно пов'язаний з контекстом, - це зовнішність. Він посилається на «наслідок економічної діяльності, яку відчувають непов'язані треті сторони» (Investopedia n.d.). Зовнішність може включати в себе «втрату або вигоду в добробуті однієї сторони в результаті діяльності іншої сторони, без компенсації збитку партії» (Business Dictionary n.d.). Наприклад, раптове зростання цін на нафту може стати руйнівним зовнішнім впливом у проекті, який залежить від стабільного та економічного постачання палива. Деякі зовнішні наслідки є позитивними - наприклад, рішення Ірландії зробити державну освіту в коледжі по суті безкоштовною для всіх громадян зробило вже високоосвічену робочу силу ще більш привабливою для фармацевтичних та програмних компаній, що збільшило їхні інвестиції в країну (Friedman 2005).

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

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

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

    Стаття Джеймса Кантера в New York Times описує будівництво двох європейських атомних електростанцій, які повинні були бути «клонами» один одного, причому обидва побудовані за жорсткими стандартами, що визначають кожен аспект проектів аж до «килимових покриттів і шпалер». Подібність проектів повинна була призвести до чіткого плавання для обох, але безліч непередбачених технічних проблем призвело до великих затримок і перевищення витрат. Це прекрасний приклад того, як контексти - один реактор був у Фінляндії, інший у Франції - може різко вплинути на результати нібито ідентичних проектів. Проблеми на фінському майданчику включали занадто пористий фундамент, який, отже, може роз'їдати, недосвідчені субпідрядники, буріння отворів у неправильних місцях, та проблеми з комунікацією, що виникають внаслідок робочої сили, що складається з людей, що говорять на восьми різних мовах. На нібито ідентичному французькому майданчику інший набір проблем включав тріщини в бетонній основі, неправильно розташовані сталеві арматури та некваліфіковані зварювальники. За даними UniStar Nuclear Energy, компанії, що стоїть за фінським і французьким проектами, парк подібних реакторів знаходиться в роботі по всьому світу. Хто знає, які ризики виникнуть на цих проектах. Адже Франція і Фінляндія як мінімум стабільні, геологічно кажучи. Але, як зазначає Кантер, «Ризики землетрусу в таких місцях, як Китай і США, або навіть загроза штормових сплесків означає, що будівництво цих реакторів буде ще складніше в іншому місці» (2009).

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

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

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

    У мінливих контекстах гнучкість є ключовою. У своїх дослідженнях успішних менеджерів проектів Олександр Лауфер виявив, що кращі менеджери проектів

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

    Лауфер стверджує, що сучасним менеджерам проектів необхідно використовувати сучасний, більш гнучкий підхід, ніж їх попередники:

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

    На уроці 5 ми поговоримо про цінність побудови різноманітних команд, які об'єднують людей з додатковими навичками — в ідеалі людей різного віку та рівня досвіду. Але як нові менеджери проектів, яким не вистачає цього важливого «багатого досвіду», підвищити загальне розуміння численних контекстів своїх проектів? Почніть з дослідження минулих проектів з подібними характеристиками, консультації з менторами та, як правило, перевірки якомога більшої кількості формальних та неформальних джерел щодо уроків, отриманих з попередніх проектів. Це також допомагає залишатися добре інформованими - про вашу організацію, ваших клієнтів, вашу галузь та світ загалом. Наприклад, якби ви працювали над проектом будівництва в галузі охорони здоров'я в останнє десятиліття, ви б зазнали виражених змін у контексті, від системи, орієнтованої на лікаря, до системи, орієнтованої на пацієнта, яка прагне надати пацієнтам можливість визначити цінність на своїх умовах (Porter and Lee 2013). Якби ви були новачками в управлінні проектами в цій галузі, вам було б розумно дізнатися все, що ви могли б про цю зміну. У живому порядку такі сейсмічні зміни є нормою, не винятком, практично у всіх галузях промисловості.

    ~Практичні поради

    • Залучайте усіх зацікавлених сторін: Ваша мета полягає в тому, щоб люди значуще брали участь у вашому проекті. Ви не хочете, щоб зацікавлені сторони з'являлися на урочистих виступах на зустрічах проекту. Замість цього ви хочете, щоб вони серйозно орієнтувалися на перспективи успіху проекту.
    • Чіткість результату: Попросіть свого клієнта визначити успіх прямо на початку. Потім, працюючи з замовником та іншими зацікавленими сторонами, визначте, як буде вимірюватися успіх.
    • Використовуйте загальний словниковий запас: На початку будь-якого проекту перейдіть до своїх кінцевих клієнтів і вивчіть їх словниковий запас. Переконайтеся, що ви розумієте важливі для них терміни і що для них означають такі терміни. Коли це можливо, використовуйте словниковий запас вашого клієнта, а не ваш. Крім того, прагніть говорити простою англійською, коли тільки зможете, і уникайте техно говорити.
    • Створіть глосарій термінів: На проектах з великою кількістю складного жаргону подумайте про створення глосарію термінів. Потім опублікуйте його таким чином, щоб зробити його доступним для всіх зацікавлених сторін, оновлюючи його за потребою. Ось приклад одного такого глосарію: «COSO Framework. »
    • Визначте те, чого ви не знаєте: Коли ви починаєте проект, завжди є речі, яких ви не знаєте. Головне - знати, що ви їх не знаєте. Чим більше ви прагнете визнати це, тим краще ви будете передбачати ці невідомі і робити для них положення.
    • Нехай ключові члени команди підписують основні проектні документи: Дослідження показують, що акт підписання документа робить людей набагато більш прихильними до виконання обіцянок, описаних у документі. Подумайте про те, щоб просити всю проектну команду підписати статут проекту та об'ємні документи. Цей простий вчинок може послужити потужним спонуканням до успішного завершення проекту.
    • Проактивний паралелізм: На ранніх стадіях уникайте пастки побудови однієї речі за іншою лінійним способом. Замість цього почніть швидко, роблячи стільки речей, скільки зможете одночасно, так швидко, як можете. Це дасть вам уявлення про те, чи є обсяг, бюджет, ресурси та графік є відносно тісним узгодженням у макромасштабі. Якщо ви виявите їх немає, повідомте про це керівництву відразу.
    • Постійна актуальність: У життєвому порядку, в якому розгортаються всі сучасні проекти, постійною актуальністю є новий закон природи. У традиційній формі геометричного порядку управління проектами можна припустити, що у вас буде достатньо часу та ресурсів, щоб робити речі лінійно, крок за кроком. Але в сучасному світі це рідко буває. Звикайте до елементу терміновості у всіх проектах. Постарайтеся не допустити, щоб це паралізувало вас і вашу команду. Замість цього, нехай почуття терміновості підштовхне вас до більш гнучких, оповіщення та гнучких методів управління проектами.
    • Розміщуйте проектні документи помітно: Розміщення важливих документів спереду та центру допомагає команді залишатися зосередженим, особливо якщо у вас всі підписують їх першими. Це також заохочує команду оновлювати їх, коли це необхідно.
    • План помилок: Ви і ваша команда майже напевно будете робити помилки, особливо на ранніх стадіях проекту. Тож плануйте це. Продовжуйте думати заздалегідь, що може піти не так, і як ви могли б виправити курс. Зробіть звичку зберігати резервні плани в задній кишені.
    • Визначте критерії підпису або прийняття: Один хороший спосіб визначити успіх - почати з складання критеріїв підпису або критеріїв прийняття, як їх іноді називають. Це узгоджені результати для кожного ключового етапу проекту, що дозволяє вважати етап завершеним. Зазвичай ці критерії пов'язують з платежами. Цінність цих критеріїв, що визначаються на початку, полягає в тому, що вони, як правило, дуже об'єктивні і їх можна постійно повертати назад, забезпечуючи тим самим, щоб усі заходи були узгоджені з кінцевими результатами. Основні розбіжності щодо того, чи був проект успішним, зазвичай зводяться до невизначення критеріїв прийняття. Досягнення згоди щодо цього є важливим, оскільки воно рухає всім іншим (ресурси, час, бюджети тощо).
    • Будьте готові до змін: Не обманюйте себе, думаючи, що лише тому, що ви створили всі документи, пов'язані з ініціацією проекту, у вас все прибито. Часто неможливо передбачити види поточних змін, що виникають у живому порядку.

    ~Резюме

    • Ініціація проекту полягає в закладці фундаменту для всього проекту. Хоча ініціація знаменує офіційний початок проекту, вона передбачає погляд у майбутнє, передбачаючи весь життєвий цикл проекту, який включає етап створення, етап експлуатації/використання/зміни та етап виходу на пенсію/повторне використання. Навіть у більш традиційному способі розгляду управління проектами фази управління проектами зазвичай перекриваються і часто тягнуть за собою озирнутися назад на документи, складені на етапі ініціації.
    • Ці документи, створені під час ініціації, зазвичай забезпечують високий рівень перегляду проекту. Вони включають статут проекту, заяву про сферу застосування та бізнес-кейс. Створюючи ці документи, ви повинні заздалегідь продумати створення наступних пунктів на етапі планування: структура розбивки робіт (WBS), структура організаційного розбивки (OBS), робочий пакет та матриця призначення відповідальності (ОЗУ).
    • Досвідчені менеджери проектів знають, що починати потрібно швидко, визначаючи, що означає «успіх» для вашого проекту та визначення того, як його виміряти. Успіх означає різні речі в різних галузях. Наприклад, у капітальних проектах загальна вартість володіння (загальна сума прямих та непрямих витрат, пов'язаних із будівництвом та використанням будівлі) має вирішальне значення для визначення того, чи є будівля успішною чи ні. Будьте максимально конкретними при визначенні успіху для вашого проекту, не вдаючись до зайвих деталей. Традиційні менеджери проектів, як правило, визначають успіх з точки зору завершення проекту вчасно та в рамках бюджету. Але Lean передбачає більш широке визначення успіху - таке, яке надає пріоритет усунення відходів та максимізації вартості, а також у процесі побудови лояльності клієнтів, що поширюватиметься на ще непередбачені проекти. У Agile успіх означає надання робочого програмного забезпечення після кожного спринту і, врешті-решт, надання стільки робочого програмного забезпечення, скільки дозволить графік і бюджет.
    • Чітко визначений статут проекту визначає цілі проекту, які, в свою чергу, диктують загальну організацію, графік, персонал і, в кінцевому рахунку, роботу, яка буде виконана.
    • З трьох обмежень на управління проектами - обсяг, бюджет та графік - найбільш важко визначити. За винятком найпростіших проектів, будь-яке визначення сфери діяльності майже напевно буде розвиватися, коли ви дізнаєтеся більше про проект та потреби замовника. Термін «еволюція сфери» стосується змін, про які погоджуються всі зацікавлені сторони, і які супроводжуються відповідними змінами бюджету та графіку. Зрештою, визначення обсягу базується на тому, що хоче замовник, але іноді вам потрібно буде направляти замовника до визначення обсягу проекту, оскільки замовник може не знати, що можливо. Витратьте час, щоб ретельно сформулювати сферу застосування у вигляді заяви про сферу застосування. Після створення оператора scope, зверніться до нього регулярно, щоб уникнути несанкціонованих змін, відомих як scope creep.
    • Обсяг проекту визначається типом проблеми, яку ви намагаєтеся вирішити. Технічні проблеми мають чіткі рішення - добрих інженерів традиційно навчають надавати. З адаптивними проблемами все менш зрозуміло, без певного консенсусу щодо того, як діяти, і будь-яке рішення гарантовано кине виклик цінностям та переконанням зацікавлених сторін. Деякі проблеми є сумішшю обох.
    • Всі проекти відбуваються в різних контекстах - в організаційному контексті (як вашому, так і в клієнті), ринковому контексті, технічному контексті та соціальному контексті. Все це може змінитися протягом життя проекту, і в постійній білій воді сучасного ділового світу, вони, ймовірно, будуть. Проект обов'язково буде розвиватися в міру зміни контексту проекту. Ваша робота менеджера проекту полягає в тому, щоб шукати зовнішні ефекти, які можуть вплинути на контекст проекту.

    ~Глосарій

    • бізнес-кейс —« аргумент, зазвичай документований, який покликаний переконати особу, яка приймає рішення, схвалити якісь дії. Сам документ іноді називають діловим кейсом. Як правило, бізнес-кейс повинен сформулювати чіткий шлях до привабливої рентабельності інвестицій (ROI). Найпростішим, бізнес-кейс може бути розмовною пропозицією... Для більш складних питань бізнес-кейс повинен бути представлений в ретельно побудованому документі. Документ бізнес-кейсу повинен досліджувати переваги та ризики, пов'язані як з вчиненням заходів, так і, навпаки, не вчинення заходів. Висновок повинен бути переконливим аргументом для реалізації» (TechTarget n.d.).
    • контекст —За словами Мерріама-Вебстера, «ситуація, в якій щось відбувається: група умов, які існують, де і коли щось відбувається».
    • усереднення ідеї —Беручи трохи від однієї ідеї, і трохи від іншої, і трохи від іншої - не повністю зобов'язуючись жодної.
    • лінійна діаграма відповідальності - див. Діаграму RACI.
    • Структура організаційної розбивки (OBS) — опис команди проекту. У ньому пояснюється, «хто кому звітує, деталі ієрархії та структура звітності... Організаційні структури розбиття зазвичай повідомляються візуально за допомогою графіків або діаграм. Проект або генеральний менеджер перераховані і під ПМ можуть бути створені кілька підрозділів, таких як розробка продукту, дизайн, управління матеріалами та виробництво» (Bradley n.d.). Див. також матрицю призначення відповідальності (ОЗУ) нижче.
    • упередженість планування —тенденція оптимістично занижувати кількість часу, необхідного для виконання завдання.
    • Статут проекту — «єдине, консолідоване джерело інформації» (Richter 2014) для ініціації та планування проекту. Він описує ваші поточні знання про проект і включає в себе таку інформацію, як імена всіх зацікавлених сторін, заяву про потреби вашої організації, історію, що веде до проекту, мета проекту, результати, а також ролі та обов'язки. Статут проекту також іноді називають заявою про огляд проекту. Іноді корисно думати про статут проекту як контракт між командою проекту та спонсорами проекту.
    • ініціація проекту —рання фаза, на якій ви закладаєте основу для всього проекту.
    • Заява про огляд проекту — Див. Статут проекту.
    • обсяг проекту —Вся робота, «яка повинна бути виконана, щоб забезпечити продукт або послугу, яку надає ваш проект» (Martinez n.d.).
    • матриця призначення відповідальності (ОЗУ) —Тип організаційної структури розбивки у вигляді сітки, яка зазвичай перераховує завдання проекту в першому стовпці та зацікавлені сторони у верхньому рядку із завданнями, призначеними різним зацікавленим сторонам. Ви можете використовувати його, щоб визначити, чи є у вас достатньо ресурсів для проекту, і для запису, хто за що відповідає. Дивіться також діаграму RACI.
    • Діаграма RACI —Матриця призначення відповідальності (ОЗУ). Також відомий як лінійна діаграма відповідальності. Назва «RACI» є абревіатурою «відповідальний, підзвітний, консультуватися та інформувати».
    • зацікавлені сторони - люди, на яких вплине або які можуть вплинути на проект.
    • scope creep— Неконтрольовані зміни в проекті, які відбуваються без відповідних санкціонованих змін у бюджеті та графіку.
    • scope statement —Документ, який визначає область (або вимоги) проекту.
    • структура розбивки робіт (WBS) —опис завдань, пов'язаних з результатами проекту, часто у вигляді деревоподібної діаграми. Структура розбивки робіт «відображає зв'язок кожного завдання з іншими завданнями, до цілого і кінцевого продукту (мета або завдання). Він показує розподіл відповідальності та визначає необхідні ресурси та час, доступний на кожному етапі для моніторингу та управління проектами» (Business Dictionary n.d.).
    • робочий пакет — «група пов'язаних завдань в рамках проекту. Оскільки вони схожі на самі проекти, їх часто розглядають як підпроекти в рамках більшого проекту. Робочі пакети - це найменша одиниця роботи, на яку можна розбити проект під час створення структури розбивки робіт (WBS)» (Wrike n.d.).

    ~Посилання

    Бідл, Майк, Арі ван Беннекум, Алістер Кокберн, Уорд Каннінгем, Мартін Фаулер, Джим Хайсміт, Ендрю Хант та ін. н.д. «Принципи спритного маніфесту». AgileМаніфест. Доступ до 16 червня 2018 року. http://agilemanifesto.org/principles.html.

    Бігелоу, Бред. 2012 рік. «Область дії — освоєння нечіткого обмеження». Інститут управління проектами. Доступ до 16 червня 2018 р. www.pmi.org/~/Медіа/Члени/R... ntbigelow.ashx.

    Бредлі, Джеремі. н.д. «Що таке організаційна структура розбивки (OBS)?» Хрон. Доступ до 16 червня 2018 року. http://smallbusiness.chron.com/organ...obs-72523.html.

    Бізнес-словник. н.д. «Зовнішні» Бізнес-словник. Доступ до 16 червня 2018 року. http://www.businessdictionary.com/de...rnalities.html.

    — н.д. «Структура розбивки робіт (WBS)». Бізнес-словник. Доступ до 16 червня 2018 року. http://www.businessdictionary.com/de...cture-WBS.html.

    Карлсон, Ніколас. 2013 рік. «Новий мобільний продукт Facebook - це величезний флоп, тому що він був побудований користувачами iPhone». Бізнес-інсайдер, 13 травня. http://www.businessinsider.com/faceb... -друга-2013-5.

    Дольоне, Кара. 2018 рік. «Розуміння матриці призначення відповідальності (матриця RACI)». ПМ. 25 січня. http://project-management.com/unders...x-raci-matrix/.

    Фельдшер, Рони. 2016 рік. «Що включити в заяву про обсяг проекту». Кларизен. 9 липня. https://www.clarizen.com/what-to-inc...ope-statement/.

    Францен, Карл. 2014 рік. «Історія Walkman: 35 років знакових музичних плеєрів». Грань, 1 липня. http://www.theverge.com/2014/7/1/586... -Walkman-at-35.

    Фрідман, Томас Л. 2005. Світ плоский: коротка історія двадцять першого століття. Нью-Йорк: Фаррар, Штраус і Жиру. https://books.google.com/books?id=-m...l%20educated%2.

    Видавнича корпорація Гарвардської школи бізнесу. 2006 р. Управління великими та малими проектами: фундаментальні навички для виконання бюджету та вчасно. Бостон: Видавнича корпорація Гарвардської школи бізнесу.

    Хейфец, Рональд А., Марті Лінскі та Олександр Грашоу. 2009 рік. Практика адаптивного лідерства: інструменти та тактика зміни вашої організації та світу. Бостон: Гарвардський бізнес-прес.

    Хілл, Андрій. 2016 рік. Як уникнути усереднення ідей: Нехай тільки кращі ідеї через. 4 січня. http://andrewxhill.com/blog/2016/01/...dea-averaging/.

    Інвестопедія. н.д. «результати». Інвестпедія. Доступ до 15 червня 2018 року. https://www.investopedia.com/terms/d/deliverables.asp.

    —. н.д. «зовнішність». Інвестпедія. Доступ до 15 червня 2018 року. https://www.investopedia.com/terms/e/externality.asp.

    Джордан, Енді. 2012 рік. «9 секретів успішної ініціації проекту». Управління проектами. Березень. http://www.projectmanagement.com/pdf...initiation.pdf.

    Кантер, Джеймс. 2009 рік. «У Фінляндії ядерне Відродження потрапляє в біду». Нью-Йорк Таймс, 28 травня. http://www.nytimes.com/2009/05/29/bu...nuke.html? _r=0.

    Martinez, Michael. n.d. сфера управління проектами. Доступ до 16 червня 2018 року. https://www.project-management-skill...ent-scope.html.

    Маккрекен, Гаррі. 2013 рік. «Цей німий рік: 47 найяскравіших моментів у технічному 2013 році». Час, 31 грудня. http://techland.time.com/2013/12/31/... в-тех-2013/.

    Мейснер, М., і Л.Блесінг. 2006 р. «Визначення методології адаптивної розробки продукту». Матеріали Міжнародної дизайнерської конференції DESIGN 2006. Дубровник, Хорватія: Дизайнерське товариство. 69-78.

    Муха, Майкл, інтерв'ю Енн Шаффер. 2017 рік. Технічні та адаптивні проблеми (11 грудня).

    OptiSol. n.d. «Що таке Scope Creep в гнучкій розробці?» Оптісол Бізнес. Доступ до 17 червня 2018 року. https://www.optisolbusiness.com/insi...le-development.

    Портер, Майкл Е., і Томас Лі, доктор медичних наук Лі. 2013 рік. «Стратегія, яка виправить охорону здоров'я». Гарвардський бізнес-огляд, жовтень. https://hbr.org/2013/10/the-strategy...ix-health-care.

    Portny, Stanley E.n.d. «Що включати в заяву про сферу проекту». Манекени. Доступ до 15 червня 2018 року. http://www.dummies.com/careers/proje...ope-statement/.

    Ріхтер, Лінда. 2014 рік. «Що таке статут проекту?» Яскравий хаб-менеджмент проектів. 24 жовтня. http://www.brighthubpm.com/project-p...oject-charter/.

    Райф, Метт. 2005 рік. «Перебудова Пентагону - це сучасне дослідження методу проектування та побудови». Остінський діловий журнал, 13 листопада. http://www.bizjournals.com/austin/st...14/focus3.html.

    Тейт, Райан. 2013 рік. «Facebook Головна буде «Величезним флопом», поки це не буде». Провідний, 14 травня. http://www.wired.com/2013/05/facebook-home-criticism/.

    TechTarget. н.д. «бізнес-кейс». Що таке. Доступ до 16 червня 2018 року. http://whatis.techtarget.com/definition/business-case.

    Агентство з охорони навколишнього середовища США. n.d. дизайн для оцінки життєвого циклу навколишнього середовища. Доступ до 16 червня 2018 року. https://www.epa.gov/saferchoice/desi...le-assessments.

    Wrike. n.d. «Посібник з управління проектами/Що таке пакет робіт в управлінні проектами?» Wrike. Доступ до 16 червня 2018 року. https://www.wrike.com/project-manage...ct-management/.