Управління обсягом проекту: що ми робимо?

Налаштуйте себе на успіх проекту, чітко визначивши цілі - обсяг - на початку.

Зображення Девіда Марка з Pixabay

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

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

Управління сферою є вирішальним для успіху проекту

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

Запобігання повзучості Scope

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

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

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

Хороша новина полягає в тому, що якщо ми чітко визначимо сферу та керуємо повзанням сфери, ми на шляху до успіху!

Я навчив понад 4000 менеджерів проектів і вів десятки проектів. Дозвольте мені показати вам, як визначити обсяг та керувати повзучістю обсягу, перш ніж ваш проект буде завалений!

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

stevendepolo Стівен Деполо (CC BY) через Flickr

Коли наступний вівторок?

Щоразу, коли я викладаю клас з визначення сфери застосування та чіткості спілкування, я прошу підняти руку на це питання. Скажімо, я викладаю у четвер. Я прошу: "Підніміть руку, якщо вважаєте, що наступний вівторок через 5 днів". Близько половини людей у ​​кімнаті піднімають руки. Тоді я прошу: "Підніміть руку, якщо вважаєте, що наступний вівторок через 12 днів". Інша половина людей у ​​кімнаті піднімає руки.

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

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

Погодження обсягу Вашого проекту

Співпраця із замовником, командою та усіма зацікавленими сторонами щодо узгодження результатів проекту та його функцій та цілей непроста. Наприклад, корпоративний веб-сайт:

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

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

Потрапляння на одну сторінку

Кожна людина, на яку впливає проект, має свою власну точку зору, а також свою мову. Як виконавчий "корпоративний імідж" перетворюється на "ефективну цільову сторінку" маркетингу та повідомлення "404 сторінки не знайдено" ІТ-відділу. Архітектура - це здатність бачити одне в кількох переглядах, безлічі перспектив та кількох мовах. Як менеджери проектів, ми також повинні бути архітекторами, здатними бачити проект з усіх точок зору та вирішувати всі проблеми.

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

Погоджуючись на сферу дії

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

Уточнення припущень

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

Етапи управління сферою

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

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

PMI пропонує вигадливу назву для створення високого визначення сфери дії спочатку, а детального WBS пізніше. Вони називають це поступовою розробкою.

Питання, що визначають решту проекту

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

Включення та виключення

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

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

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

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

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

Створення структури розподілу робіт (WBS)

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

Наприклад, скажімо, що ми будуємо літак. Наш початковий опис виглядає так:

• один фюзеляж
• одна кабіна
• одна каюта
• два крила
• один хвіст у зборі
• управління польотом
• електроніка для навігації та інших цілей

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

• тіло крила
• паливні баки
• паливопроводи
• закрилки

Зрештою, це докладно викладено до повного списку деталей. Для комерційного літака це може бути більше 1 мільйона деталей!

Створення решти плану проекту

Отримавши WBS, можна створити решту детального плану проекту. Ми можемо створити точні оцінки часу та витрат. Ми можемо виконати плани управління і іншими шістьма напрямами управління проектами: якість, ризик, людські ресурси, комунікації, закупівлі та інтеграція.

Наприклад, WBS - це список того, що ми робимо. З цього ми запитуємо, як ми будемо робити кожен компонент. Це генерує Список діяльності, який є ключовим компонентом оцінки часу. Крім того, коли ми знаємо, що робимо, ми можемо запитати: "Що може піти не так?" і це є відправною точкою для планування ризиків. І запитувати "що робить це добре?" є початком якісного планування.

Управління сферою впродовж проекту

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

Виконання цього вимагає роботи, яка називається виконанням. Але це також вимагає відстеження цієї роботи та коригування курсу, якщо це необхідно. Вони називаються відстеженням та контролем. Це все одно, що їхати шосе. Якщо все, що ви робите, це їхати на машині, ви пропустите свій вихід і затримаєтесь. Або ти підеш занадто повільно і запізнишся, або пришвидшишся і отримаєш квиток. Щоб добре їздити, ми повинні спостерігати, де ми знаходимось, наскільки швидко ми рухаємось, чи не закінчується бензин та що роблять інші водії на дорозі. Те саме на проекті. І ми досягаємо цього за допомогою аналізу заробленої вартості, управління повзучістю обсягу та управління всіма дев’ятьма напрямками проекту.

Аналіз заробленої вартості

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

Управління Scope Creep

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

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

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

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

Управління всіма дев’ятьма областями

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

Виконання того, що ви обіцяли

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

Або ми думаємо, що готові до реалізації. Але чи ми справді впевнені? І що думає замовник. Давайте розглянемо кроки, які ми виконуємо, щоб переконатися, що ми доставляємо потрібну річ замовнику, і закінчимо добре.

Перевірка та перевірка

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

Але чи погодиться замовник? На це питання відповідає процес перевірки. Ми не можемо зробити перевірку самі. Зазвичай це робить замовник, оскільки вони виписують і підписують при доставці результатів проекту. Але є дві інші можливості:

• Якщо ми доставляємо щось велике, складне або щось, що повинно відповідати вимогам, ми, мабуть, захочемо домовитись про перевірку задовго до дати доставки. Це дає команді проекту час на коригування або виправлення будь-чого, що не відповідає вимогам замовника.
• Якщо виникає суперечка щодо того, чи забезпечує наш проект результати, за якими зареєструвався замовник, вони можуть подати запит на незалежну перевірку та перевірку (IV&V), де зовнішній підрядник заходить, щоб визначити прогалини між тим, що ми постачаємо, і тим, що замовник хоче, і рекомендувати рішення.

Доставка

Як правило, однак, IV&V не потрібні. Ми надаємо результати проекту, які можуть включати встановлення, налаштування та навчання, залежно від того, чи були вони включені в заяву про обсяг проекту. Клієнт штовхає шини, так би мовити, або задоволений, або вимагає декількох невеликих змін, які ми вносимо. І тоді проект закінчений - майже.

Захоплення клієнтів

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

Що зупиняє ваші проекти?