Зона відповідальності в проекті: як визначити і контролювати

1. Чому важлива зона відповідальності в проекті
2. Як формувати склад робочої групи проекту
3. Склад і кількість учасників проектної групи визначаються індивідуально для кожного проекту
4. 8 обов'язкових ролей в ефективній проектній команді з точки зору класичного підходу
5. Як визначити зону відповідальності в проекті за допомогою спеціальної матриці
6. 6 порад, які дозволять скласти ефективну матрицю зон відповідальності в проекті
7. Як керівник повинен здійснювати контроль зон відповідальності учасників проекту
8. 5 корисних книг по ефективному управлінню проектами

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

Ви дізнаєтеся:

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

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

Чому важлива зона відповідальності в проекті

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

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

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

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

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

ТОП-5 найбільш затребуваних статей для комерсанта:

Чітке розмежування цих сфер дозволяє:

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

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

Як формувати склад робочої групи проекту

Фахівці рекомендують при виконанні завдань з реалізації проектів всередині компанії, наприклад, для впровадження комунікаційних систем використовувати наступну структуру:

• куратор з числа управлінців;
• робоча група;
• керівник, який є учасником робочої групи;
• команда виконавців.

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

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

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

думка експерта

Склад і кількість учасників проектної групи визначаються індивідуально для кожного проекту

Франк Мюллер,

генеральний директор міжнародної групи компаній AsstrA, Цюріх

У 2006 році ми впровадили проектне управління. Це рішення було прийнято з метою реалізації завдань за такими напрямами, як:

• збільшення відсотка доходу від продажу послуг при комплексному сервісі клієнтів в загальному обсязі збуту компанії;
• підвищення якісного рівня послуг.

У перші місяці 2007 року я сформував департамент контрактної логістики і став його керівником. Ця структура була створена для управління проектами у всіх підрозділах групи компаній. Система менеджменту якості AsstrA отримала сертифікат, що підтверджує відповідність стандартам ISO 9001: 2000, а отже, впровадження механізму управління проектами вироблялося через процедури, пов'язані з розробкою, затвердженням і реалізацією всіх нових бізнес-процесів.

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

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

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

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

Методичні рекомендації, що містяться в сучасних наукових джерелах, по-різному описують ролі і зони відповідальності учасників проекту. У наведеній тут таблиці представлена ​​найбільш популярна за версією досліджень PWC (глобальна мережа компаній Pricewaterhouse Coopers International Limited) модель управління - PMBOK.

Назва ролі

Зона відповідальності

повноваження

керівник

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

Визначаються ієрархією компанії

клієнт

Затвердження вимог до результатів проекту.
Приймання продуктів проекту

Зміна важливості окремих моментів в системі вимог до результатів проекту

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

Затвердження завдань, строків виконання та вартості робіт.
фінансування проекту

Дозвіл питань, які не входять до зони компетенцій керівника проекту

команда проекту

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

Надання інформації про проблемні питання, що виникають в процесі реалізації завдань

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

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

8 обов'язкових ролей в ефективній проектній команді з точки зору класичного підходу

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

1. Голова (chairman)

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

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

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

1. Оформлювач (shaper)

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

1. Генератор ідей (plant)

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

1. Критик (monitor-evaluator)

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

1. Робоча бджілка (company worker)

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

1. Опора команди (team worker)

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

1. Здобувач (resource investigator)

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

1. Завершальний (completer)

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

Як визначити зону відповідальності в проекті за допомогою спеціальної матриці

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

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

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

1. Responsible (виконавець) - ця роль предполагает відповідальність за конкретний етап РОбочий процесса. Тобто Виконавцю довіряється один або кілька ділянок роботи, які відповідають его компетенцій.
2. Accountable (відповідальний) - Цю роль, пов'язану з управлінням повний ОБСЯГИ процесів, найчастіше Виконує власник. У его зону відповідальності входитиме контроль ключовими показніків и питання стратегічного керівніцтва. В окремий проекті подібна роль є Єдиною.
3. Consulted (експерт) - грає роль експерта в конкретних сферах. Для успішної реалізації проектів необхідно, щоб в команді було не більше 2 таких фахівців, так як велика їх кількість в одному проекті може створювати складності в комунікаціях і здатне виявитися причиною професійних суперечок.
4. Informed (інформує) - володіє повним обсягом інформації по процесах, які можуть мати місце в проекті. Виконуючий цю роль також має вплив на результат.

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

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

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

Четвертий етап - введення KPI. Треба застосовувати якісні, кількісні та фінансові показники ефективності. Коли матриця зон відповідальності сформована і зрозуміла всім учасникам, можна переходити до безпосередньої роботи над завданнями проекту. Правильно складений шаблон зон відповідальності буде виступати в якості інструкції, в якій завжди можна підглянути, хто саме відповідає за ту чи іншу частину робочого процесу. Шаблон зон відповідальності не повинен викликати негатив і нерозуміння з боку членів команди.

6 порад, які дозволять скласти ефективну матрицю зон відповідальності в проекті

Рада 1. Виключіть нераціональний розподіл зон відповідальності.

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

індикатори:

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

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

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

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

Порада 3. При формуванні матриці необхідно врахувати специфічні потреби проекту.

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

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

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

Треба врахувати вимоги обраної політики в таких областях, як якість і формування вартості.

Рада 5. Почніть зі складання спрощеної матриці по системі завдання / відповідальний, а потім доповніть її деталізацією зон відповідальності, показниками KPI і контрольними точками.

Рада 6. При формуванні матриці застосовуйте принципи колегіальності та аналізу реальних процесів всередині проекту.

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

Як керівник повинен здійснювати контроль зон відповідальності учасників проекту

1. Визначте для кожного учасника проекту основні зони відповідальності.

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

1. Зона відповідальності менеджера.

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

1. Диференційований контроль виконавців.

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

1. Розвивайте взаємоповага серед учасників і проводите роботу над помилками.

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

1. Адміністративні зони відповідальності не слід передавати кваліфікованим фахівцям.

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

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

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

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

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

1. Покажіть, що контроль - спосіб переконатися, що все в порядку, і похвалити за досягнення.

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

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

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

5 корисних книг по ефективному управлінню проектами

1. Том Демарк "Deadline. Роман про правильному управлінні проектами »

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

1. Сазерленд Джефф «Scrum. Революційний метод управління проектами »

У цьому виданні ви знайдете докладну інформацію про метод ефективного використання управлінських функцій Scrum. Ця книга допоможе усунути традиційні недоліки в керівництві проектами:

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

1. «Керівництво до зводу знань з управління проектами (Керівництво PMBOK)»

За допомогою цього посібника ви навчитеся керувати проектами відповідно до американським стандартом PMBOK. Робота може здатися досить складною для вивчення, але отриманий результат буде відповідати витраченим зусиллям.

1. А. Д. Перерва, В. Іванова, С. Сергєєв «Шлях IT-менеджера. Управління проектною середовищем і IT-проектами »

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

1. Том Демарк "вальсуючи з ведмедями: управління ризиками в проектах з розробки програмного забезпечення»

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