1.11: Планування ресурсів

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

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

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

Оцінка ресурсів

Метою оцінки ресурсу діяльності є призначення ресурсів кожному виду діяльності в переліку видів діяльності. Існує п'ять інструментів і методик оцінки ресурсів діяльності.

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

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

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

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

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

Оцінка тривалості діяльності

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

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

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

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

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

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

Аналіз резервів означає додавання додаткового часу до графіка (званого резервом на випадок надзвичайних ситуацій або буфером) для обліку додаткового ризику.

(Рішення слідують.)

вправи

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

1. Саллі повинна з'ясувати, що робити для музики на весіллі Стіва і Сьюзен. Вона розглядає можливість використання ді-джея, рок-групи або струнного квартету.
2. В останньому випуску журналу Wedding Planner є стаття про роботу з кейтерингами. Вона включає в себе таблицю, яка показує, скільки офіціантів працює з різними розмірами списку гостей.
3. Існує національний весільний консультант, який спеціалізується на весіллям в Карибському басейні. Саллі зв'язується з нею, щоб запитати про варіанти меню.
4. Саллі завантажує та заповнює спеціалізовану електронну таблицю, яку менеджер проекту розробив, щоб допомогти з плануванням весілля.
5. Існує так багато роботи, яку потрібно зробити, щоб створити зал прийому, що Саллі повинна розбити його на п'ять різних видів діяльності, щоб призначити робочі місця.
6. Саллі просить Стіва і Сьюзен відвідати кілька різних громадського харчування та спробувати різні потенційні пункти для меню.
7. Саллі закликає свого друга, який знає специфіку різних місць у своїй області, за порадою, над якою можна було б працювати найкраще.
8. На весіллі є дві різні кейтерингові компанії. Саллі просить шеф-кухаря у кожного з них дати їй оцінку того, скільки часу знадобиться кожному з них, щоб виконати роботу.
9. Існує електронна таблиця Саллі завжди використовує, щоб з'ясувати, скільки часу займає гостьовий RSVP. Вона вводить кількість гостей і їх поштові індекси, і вона розраховує оцінки для неї.
10. Саллі зробила чотири весілля, які дуже схожі на Стіва і Сьюзен, і у всіх чотирьох з них знадобилося рівно стільки ж часу для організації громадського харчування, щоб створити зал прийому.

Рішення

1. альтернативний аналіз
2. Опубліковані оціночні дані
3. Експертне рішення
4. Програмне забезпечення для управління проектами
5. Оцінка знизу вгору
6. альтернативний аналіз
7. Експертне рішення
8. Експертне рішення
9. Параметрична оцінка
10. Аналогічна оцінка

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

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

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

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

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

Графік проекту та критичний шлях

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

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

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

Стів: Тітка Джейн вегетаріанка. Це не буде проблемою, правда?

Сьюзен: Ну, давайте подивимося. Яке меню ми дали громадського харчування?

Стів: Ми ще не дали його їм, тому що ми не матимемо остаточного меню, поки всі RSVP і не повідомлять нам, який entrée вони хочуть.

Сьюзен: Але вони не можуть RSVP, тому що ми не розіслали запрошення! Що тримає це?

Стів: Ми все ще чекаємо, щоб повернути їх з принтера. Ми не можемо відправити їх, якщо у нас їх ще немає!

Сьюзен: О ні! Мені ще доведеться розповісти принтеру, що друкувати на запрошеннях і який папір використовувати.

Стів: Але ви чекали на це, поки ми не закінчили список гостей.

Сьюзен: Який безлад!

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

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

Малюнок 11.1: Приклад проблем, які можуть бути викликані в межах критичного шляху.

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

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

Крок 1. Почніть з схеми мережі.

Малюнок 11.2 Крок 1. Створення схеми мережі

Крок 2. Знайдіть всі шляхи на схемі. Шляхом є будь-який рядок дій, що йде від початку проекту до кінця. [1]

• Пуск > Діяльність «A» > Діяльність «B» > Завершити
• Пуск > Діяльність «A» > Діяльність «C» > Завершити
• Пуск > Діяльність «D» > Діяльність «E» > Завершити

Крок 3. Знайдіть тривалість кожного шляху, склавши тривалість кожної з дій на шляху.

• Пуск > Діяльність «A» > Діяльність «B» > Завершити = 4 + 7 = 11
• Пуск > Діяльність «A» > Діяльність «C» > Завершити = 4 + 2 = 6
• Пуск > Діяльність «D» > активність «E» > фініш = 3 + 5 = 8

Крок 4. Перший шлях має тривалість 11, що довше, ніж інші шляхи, тому це критичний шлях.

Розклад також можна відобразити за допомогою діаграми Ганта (рис. 11.3).

Малюнок 11.3: Приклад діаграми Ганта.

Управління ресурсами

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

HR-планування

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

Керування командою

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

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

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

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

• Якість і кількість виходів
• Робоча поведінка (наприклад, пунктуальність)
• Атрибути, пов'язані з роботою (наприклад, співпраця та ініціатива)

Провівши перевірку ефективності роботи співробітників, керівники проектів повинні:

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

Методи управління ресурсами

Одним з методів управління ресурсами є вирівнювання ресурсів. Він спрямований на згладжування запасів наявних ресурсів, зменшення як надлишкових запасів, так і дефіциту.

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

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

Вирівнювання ресурсів

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

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

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

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

Робота з фізичними особами

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

Емоційний інтелект

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

Емоційний інтелект включає в себе наступне:

• Самосвідомість
• саморегуляція
• Емпатія
• Управління відносинами

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

Типи особистості

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

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

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

Майерс-Бріггс визначає 16 типів особистості на основі чотирьох уподобань, отриманих з анкети. Уподобання знаходяться між парами протилежних характеристик і включають в себе наступне:

• Екстраверсія (E) -інтроверсія (I)
• Чутіння (S) -Інтуїція (N)
• Мислення (Т) -Почуття (F)
• Суддівство (J) -Сприйняття (P)

Шістнадцять типів Майерс-Бріггс можуть бути отримані з чотирьох дихотомій. Кожен з 16 типів описує перевагу: для фокусування на внутрішньому чи зовнішньому світі (E-I), для наближення та інтерналізації інформації (S-I), для прийняття рішень (T-F) та для планування (J-P). Наприклад, ISTJ - це тип Майерс-Бріггс, який вважає за краще зосереджуватися на внутрішньому світі та основній інформації, віддає перевагу логіці і любить швидко вирішувати.

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

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

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

• Домінування/Привід - стосується контролю, влади та напористості
• Індукція/Вплив — стосується соціальних ситуацій та спілкування
• Подання/стійкість - стосується терпіння, наполегливості та вдумливості
• Відповідність/сумлінність — стосується структури та організації

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

Стилі лідерства

Стиль лідерства - це функція як особистих характеристик лідера, так і середовища, в якому має відбуватися лідерство, і теми, яку намагалися зрозуміти кілька дослідників. Роберт Танненбаум і Уоррен Шмідт описали лідерів як самодержавні або демократичні (1958). Гарольд Лівітт описав лідерів як шляхошукачів (провидців), розв'язувачів проблем (аналітичних) або реалізаторів (орієнтованих на команду) (1986). Джеймс Макгрегор Бернс замислював лідерів як транзакційні (орієнтовані на дії та рішення), або трансформаційні (орієнтовані на довгострокові потреби групи та організації) (1978).

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

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

Жоден конкретний підхід до керівництва не підходить спеціально для управління проектом. У зв'язку з унікальними обставинами, притаманними кожному проекту, лідерський підхід та навички управління, необхідні для успіху, змінюються залежно від профілю складності проекту. Однак Інститут управління проектами опублікував дослідження Ши та Чена, які вивчали риси лідерства управління проектами та дійшли висновку, що хороші комунікативні навички та здатність будувати гармонійні стосунки та мотивувати інших є важливими (2006). Крім цього широкого набору лідерських навичок, успішний підхід до лідерства залежатиме від профілю проекту. Наприклад, менеджер транзакційних проектів із сильним підходом до керівництва командування та контролю може бути дуже успішним у невеликому проекті розробки програмного забезпечення або будівельному проекті, де завдання чіткі, ролі добре зрозумілі, а середовище проекту є згуртованим. Цей же керівник проекту менш імовірно буде успішним у більшому, складному проекті з різноманітною командою проекту та складними робочими процесами.

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

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

Приклад: Проект багатонаціонального видання підручників

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

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

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

Лідерські навички

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

Успішний керівник проекту повинен володіти хорошими комунікативними навичками. Всі завдання проекту пов'язані з навичками, необхідними менеджеру проекту:

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

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

Прослуховування

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

Приклад: Мова тіла клієнта

Клієнт щойно повернувся з поїздки до Австралії, де переглянув хід проекту з радою директорів своєї компанії. Менеджер проекту вислухав і зробив нотатки щодо п'яти занепокоєнь, висловлених радою директорів клієнту.

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

Потім менеджер проекту поставив більше питань, що досліджують і розмірковував над сказане. «Звучить так, ніби це було дуже жорстке засідання ради». «Чи відбувається щось поза подіями проекту?» З цих спостережень та питань керівник проекту виявив, що засідання ради директорів не пройшло добре. Компанія зазнала збитків на інших проектах, а скорочення бюджету означало менше ресурсів для проекту та очікування, що проект закінчиться раніше, ніж планувалося. Менеджер проекту також виявив, що майбутнє клієнта з компанією буде залежати від успіху проекту. Менеджер проекту запитав: «Як ви думаєте, нам потрібно буде робити щось по-іншому?» Вони почали розробляти план вирішення проблем ради директорів.

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

У наведеному вище прикладі керівник проекту використовував такі прийоми:

• Уважно слухати слова клієнта і спостерігати за мовою тіла клієнта
• Кивання і вираження інтересу до клієнта без формування спростувань
• Надання зворотного зв'язку та прохання ясності при повторенні резюме інформації назад клієнту
• Висловлення розуміння і співпереживання клієнту

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

Переговори

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

Переговори передбачають чотири принципи:

1. Відокремте людей від проблеми. Формування дискусій з точки зору бажаних результатів дозволяє переговорам зосередитися на пошуку нових результатів.
2. Орієнтуйтеся на спільні інтереси. Уникаючи акценту на розбіжностях, обидві сторони більш відкриті для пошуку прийнятних рішень.
3. Створюйте варіанти, які просувають спільні інтереси. Після того, як спільні інтереси будуть зрозумілі, рішення, які не відповідають інтересам жодної зі сторін, можуть бути відкинуті, а рішення, які можуть служити інтересам обох сторін, можуть бути більш глибоко вивчені.
4. Розробити результати на основі стандартних критеріїв. Стандартним критерієм є успішність проекту. Це означає, що сторони розробляють спільне визначення успіху проекту.

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

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

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

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

Вирішення конфліктів

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

Девід Уіттон та Кім Камерон розробили модель реагування на конфлікт, яка відображала важливість питання, збалансованого з важливістю відносин (2005). Модель представила п'ять відповідей на конфлікт:

• Уникаючи
• форсування
• Співпраця
• Компрометуючий
• Розміщення

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

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

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

Приклад: вирішення конфлікту офісних приміщень

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

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

Приклад. Конфлікт через порядок зміни

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

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

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

Делегування

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

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

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

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

Приклад навчального проекту в Перу

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

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

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

Регулювання стилів лідерства

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

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

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

Робота з групами та командами

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

Довіра

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

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

Контракти та довірчі відносини

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

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

Види довіри

Свенн Ліндскольд описує чотири види довіри (1978):

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

Створення довіри

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

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

Приклад: Висока вартість лежання в проекті Чарльстона

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

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

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

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

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

Засідання пункту дії

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

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

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

Наради керівництва

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

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

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

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

Нижче наведено кілька прикладів цілей на концептуальному етапі:

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

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

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

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

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

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

Лідерські зустрічі

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

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

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

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

Типи команд

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

Команди ефективні в декількох проектних ситуаціях:

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

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

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

Окрім того, щоб знати, коли команда підходить, керівник проекту також повинен розуміти, який тип команди буде функціонувати найкраще.

Функціональні команди

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

Крос-функціональні команди

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

Приклад: Крос-функціональна командна робота

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

Команди вирішення проблем

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

Якісна оцінка ефективності проекту

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

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

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

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

Приклад: Опитування Humm виявляє занепокоєння

На проекті в Південній Кароліні проект щотижня опитував керівництва проекту за допомогою Humm Survey. Фактор Хума вказав на зростаючу стурбованість з приводу того, що графік починає прослизати, коли звіти про графік вказували, що все було за планом. Коли керівник проекту почав намагатися зрозуміти, чому Humm Factor виявляє занепокоєння щодо графіка, він виявив побоювання щодо ефективності критичного постачальника проекту. Коли він запитав членів команди, вони відповіли: «Це було так, як вони відповідали по телефону або коливання при наданні інформації - щось не відчувало себе правильно».

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

Інша команда проекту використовувала Humm Factor для щомісячного опитування клієнта. Заповнені опитування дісталися людині, яка не була в проектній команді, щоб забезпечити анонімність відповідей. Відповіді обговорювалися на щомісячних зустрічах з огляду проектів, а керівник проекту підсумував результати та розглянув усі проблеми, висловлені у звіті. «Я не відчуваю, що мої занепокоєння почуті» була одна відповідь, яка почала збільшуватися під час проекту, і керівник проекту провів значну частину наступної зустрічі з огляду проекту, намагаючись зрозуміти, що це означало. Команда виявила, що у міру просування проекту до основних етапів команда проекту стала більш зосереджена на вирішенні щоденних проблем, більше часу проводила на зустрічах, а робочий день ставав довшим. Результатом стало менше контактів з клієнтами, повільніші відповіді на зворотні телефонні дзвінки та набагато менше перерв на каву, де члени команди могли випадково обговорити проект з клієнтом.

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

Створення проектної культури

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

1. Артефакти та поведінка
2. Отримані цінності
3. припущення

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

Характеристика проектної культури

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

Культура розвивається через спілкування:

• пріоритет
• Заданий статус
• Узгодження службових і експлуатаційних правил

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

Приклад: Експлуатаційні правила на багатомайданчиковому проекті

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

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

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

Приклад: Створення культури співпраці

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

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

Інновації в проектах

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

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

Приклад: стрес керований на дизайн-проект веб-сайту

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

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

Посилання

Бернс, Дж. М. Лідерство. Нью-Йорк: Харпер енд Роу.

Фідлер, Ф.Е. (1971). Перевірка та розширення моделі ефективності лідерства на випадок непередбачених ситуацій. Психологічний вісник, 76 (2), 128—48.

Лівітт, Х. (1986). Корпоративні Pathfinders. Нью-Йорк: Книги Доу-Джонса-Ірвіна та Пінгвіна.

Ліндскольд, С. (1978). Розвиток довіри, пропозиція GRIT та наслідки примирливих актів на конфлікт та корпорацію. Психологічний бюлетень 85 (4), 772—93.

Ши, Q., & Чень, Дж. (2006). Людська сторона управління проектами: лідерські навички. Ньютаун Сквер, Пенсильванія: Інститут управління проектами, Inc.

Танненбаум, Р., Шмідт, В. (1958). Як вибрати шаблон лідерства. Гарвардський бізнес-огляд 36, 95—101.

Уеттон, Д., і Камерон, К. (2005). Розвиток управлінських навичок. Верхня річка Сідло, Нью-Джерсі: Освіта Пірсона.

Текстові атрибуції

Цей розділ управління проектами є похідним від наступних текстів:

• Управління проектами Меррі Баррон та Ендрю Баррон. © CC BY (Атрибуція).
• Управління проектами/PMBOK/Посібник з управління персоналом та співробітництва з розвитку/Як ми керуємо людськими ресурсами програм та проектів? /Керування командою проекту за допомогою Вікіпідручників. © CC BY-SA (Із Зазначенням Авторства — Поширення На Тих Самих
• Управління ресурсами, Едгар Шейн та вирівнювання ресурсів за допомогою Вікіпедії © CC BY-SA (Із Зазначенням Авторства — Поширення На Тих Самих Умовах).
• Управління проектами для навчальних дизайнерів Амадо, М., та ін. © Creative Commons Attribution 3.0 Ліцензія.

Атрибуції ЗМІ

• Весільний критичний шлях від Barron & Barron Управління проектами для вчених та інженерів © CC BY (Attribution)
• Крок 1 Мережева діаграма від Barron & Barron Управління проектами для вчених та інженерів © CC BY (Attribution)
• Діаграма Ганта MindView від Matchware Inc (MindView) © CC BY-SA (Із Зазначенням Авторства)