A. Функціональні групи

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

Приклад показаний на рис.

2.

Лідери груп (team leads) є ключовими фігурами, інтегруючими свої колективи в загальну проектну діяльність.

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

Рисунок 25. Приклад функціональної групи "Задоволення споживача"

B. Групи напрямів

Групи напрямів – це багатопрофільні під-команди, організовувані для створення певної складової рішення. Вони компонуються з ролей моделі проектної групи

Рисунок 26. Приклад груп напрямів

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

Масштабування функцій управління проектом

Рис. 4 показує, як організовується управлінська діяльність в проектах трьох різних масштабів.

122

Рисунок 27. Управління проектами різних розмірів

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

Удругому проекті всім (або майже всім) ролевим кластерам відповідають підкоманди, у кожної з яких є свій лідер. Ці лідери здійснюють управління проектом на рівні своїх під-команд. Ролевий кластер "Управління програмою" здійснює загальне управління проектом. Тут на малюнку не показані групи напрямів, хоча вони також є під-командами, в кожній з яких є власний лідер – "Управління програмою".

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

•Великий розмір або витрати.

•Географічна віддаленість працівників.

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

•Фіксований або вкрай обмежений бюджет або календарний графік.

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

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

123

Обов'язки по управлінню проектами

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

Рисунок 28. Розподіл відповідальності по управлінню проектом серед лідерів груп

На рис. 5 показано обов'язки по управлінню проектом, які виконують лідери ролевих кластерів і лідер кластеру "Управлінням програмою". Фахівці з управління проектами, що притягуються в складних випадках (як, наприклад, третій проект, показаний на рис. 4), фокусуються виключно на відповідних завданнях кластера "Управління програмою". Одна і та ж зона відповідальності може розглядатися як на рівні всього проекту, так і на рівні підкоманд.

Лідери груп

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

Існує 3 аспекти (на рис. 5), відповідальність за яких не покладається на лідерів команд:

1.Управління вартістю проекту зазвичай здійснюється централізовано кластером "Управління програмою". Розподіл цієї функції серед лідерів команд був би не раціональним і могло б привести до хаосу в роботі.

2.Функції постачання зазвичай здійснюються ролевими кластерами "Управління програмою" і/або "Управління випуском" без участі інших лідерів команд. "Управління програмою" керує закупівлями і висновком контрактів на надання необхідних для проекту послуг.

124

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

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

Кластер "Управління програмою"

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

"Управління програмою" інтегрує плани під-команд в звідний план проекту, синхронізує календарні графіки і контролює міжкомандні взаємозв'язки.

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

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

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

1)рішення, що відносяться до архітектури;

2)рішення, присвячені управлінню проектом.

Адміністративні служби проекту

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

Звітність перед замовником

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

125