Статут проекту (project charter)

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

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

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

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

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

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

Крок 1: Визначте і найміть спонсора / підтримку проекту

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

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

Крок 2: Призначити відданого своїй справі керівника проекту

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

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

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

Крок 3: Задокументувати потреби бізнесу проекту.

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

Іноді комерційні директори добровільно хочуть бути спонсорами, тому що вони хочуть бути залучені в проект, що володіє великим значенням в організації. В такому випадку як може вижити при таких перешкодах, як скорочення або вступ на посаду нового директора з інформаційних технологій (CIO), який захоче розглянути кожен ІТ-проект до того, як заново поставити пріоритети? Якщо потреби бізнесу були добре задокументовані, то навіть керівник проекту зможе пояснити їх значення для організації.

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

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

Компоненти хорошого статуту

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

  • Потреби бізнесу для проекту - як уже описувалося вище, це є ключовим аспектом статуту. Без чітко задокументованих потреб бізнесу проект буде плисти, як без компаса, в невідомих водах. Потреби бізнесу повинні відображати тип вигоди, виробленої проектом для організації, такий як, наприклад, зниження витрат, збільшення прибутку або збільшення споживчої задоволеності.
  • Економічне обгрунтування проекту - воно повинно переводити потреби в умовні одиниці (ієни, євро, фунти, долари, рублі і т.п.). Ваша організація повинна мати стандартний формат представлення економічного обґрунтування проекту для того, щоб оцінювати кілька проектів при виборі.
  • Масштаб проекту на високому рівні - даний пункт повинен бути складений з інформації, зібраної в основному від спонсорів проекту. Оскільки спонсори матеріально підтримують проект, то важливо розуміти їх бачення проекту до того, як зустрінетесь з «шпильками» інших учасників. У той же час потреби бізнесу можуть бути широкі, а масштаб проекту може бути обмежений певними областями.
  • Критичні фактори успіху - визначте і інвентаризують будь-які аспекти бізнесу, проекту, команди, розкладу, комплектуючих і т.д. що в разі
    невиконання буде шкодити успіху проекту. Добре поняті і задокументовані фактори успіху допоможуть у вирішенні конфліктів під час просування проекту в випадках, коли необхідно буде зробити складні рішення щодо альтернатив масштабу, розкладу, витрат або якості.
  • Обмеження і припущення - документуйте їх усіх на ранньому етапі і повертайтеся до них протягом проекту. Обмеження та припущення мають бути на таких рівнях проекту, як обмеження по бюджету, терміни виконання або вимоги до якості.
  • Повноваження керівника проекту - статут повинен описувати відповідальність керівника проекту, уточнювати його роль у взаємодії з учасниками проекту та організацією. Без такої документації повноважень проект буде залежати від індивідуальних навичок керівника. Якщо і існує така посада, яка чітко забезпечує успішне завершення проекту, так це керівник проекту.
  • Підписи - їх збір на статуті, швидше за все, виглядає як формальність, і обхід цього, здавалося б, не матиме великого значення (аналогічно складанню самого статуту), але це далеко не так. Підпис в статуті є той поріг, який свідчить, що людина прочитала, зрозумів і згоден з усією викладеної в статуті інформацією. Без наявності підпису статут буде лише одним з планувальних документів, який може бути, а може і не бути розглянутий і ясний учасникам. Як же учасники, які не пов'язані з текстом проекту, матимуть чітке розуміння важливості проекту в організації, якщо не буде підписів спонсора та вищого керівництва?

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

Схожі статті