Управління великими і складними проектами
У міру зростання об'єму і складності проекту стає все більш важче управляти його функціональними специфікаціями, підтримувати календарний графік, забезпечувати зовнішню комунікацію, звітність про хід проекту і тому подібне. Для вирішення цих труднощів часто має сенс розділити обов'язки ролевого кластера "Управління програмою" на дві групи:
1) рішення, що відносяться до архітектури;
2) рішення, присвячені управлінню проектом.
Адміністративні служби проекту
У певному значенні, великий проект стикається з багатьма потребами, наявними в малих проектах: фінансовий контроль, постачання, управління текучістю кадрів, організація консалтингу і навчання, створення робочого середовища і так далі. У ще більших проектах завдання моніторингу ходу проекту, вартості і календарного графіка стають дуже затратними. Щоб дати можливість менеджерам проекту сфокусуватися на найбільш насущниших питаннях, рутинна робота по управлінню проектом переноситься в адміністративні служби (служби підтримки проекту). Вони також допомагають лідерам команд контролювати календарний графік роботи і здійснювати іншу діяльність, пов'язану з управлінням проектом.
Звітність перед замовником
Як правило, замовники хочуть мати єдине джерело звітності про хід роботи над проектом. У деяких організаціях цей обов'язок покладається на менеджерів проекту. Такий підхід іноді виправдовує себе у великих і складних проектах, але він може привести до дисбалансу звітності серед ролевих кластерів, що приведе до зниження ефективності роботи.
|
|
|
125
MSF бере до уваги потребу замовника в єдиному авторитетному джерелі інформації, але при цьому зберігає баланс відповідальності усередині проектної команди.
У команді, побудованій відповідно до принципів MSF, кожен ролевий кластер здійснює внутрішню звітність про свою діяльність. Додатково до цього, співробітники кожної з ролей, зазвичай, підзвітні деякій організаційній структурі поза рамками проектної команди. Оскільки MSF допускає наявність членів проектної групи, що працюють на різні компанії і організації, ієрархії підлеглості можуть вноситись в будь-які організації, групи або департаменти, до яких належать задіяні в проекті люди.
Слід пам'ятати, що:
• У даному питанні не існує абсолютних рішень. Крім самої проектної групи істотну роль грають структури залучених в проект організацій і особливості відносин, що існують між ними (договірних).
• Необхідно виявити схеми підзвітності в проекті. Прояснити, хто саме і за які аспекти проекту підзвітний, як в проектній групі, так і поза нею.
|
|
|
Нагадаємо, що модель проектної групи MSF передбачає наступну відповідальність перед замовником:
• Ролевий кластер "Управління продуктом" підтримує зв'язок із замовником і представляє його інтереси в проектній групі. Ця роль служить цілям задоволення замовника.
• Завдання ролевого кластера "Управління програмою" – успішне постачання рішення в рамках проектних обмежень.
• Ролеві кластери "Управління продуктом" і "Управління програмою" спільно працюють над задоволенням потреб замовника в рамках проектних обмежень. Вони мають загальну відповідальність за успіх проекту, але добиваються при цьому різних цілей.
• Як тільки виникає проблема, яку "Управління продуктом" і "Управління програмою" не здатні вирішити спільно, здійснюється ескалація за єдиною проектною ієрархією підзвітності.
Дата добавления: 2018-05-09; просмотров: 246; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!