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

Last updated
Save as PDF

Page ID: 14351

Anonymous
LibreTexts

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

Цілі навчання

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

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

Довіра

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

Фільтри

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

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

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

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

Види довіри

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

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

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

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

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

Висока вартість лежачи в проекті Чарльстона

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

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

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

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

Керування зустрічами команд

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типи команд

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Humm Factor - це інструмент, розроблений Руссом Дарналом (Caudron, 1995) для захоплення думок учасників проекту, які не відображені в інструментах звітності проекту. Humm Factor отримав свою назву від керівника проекту, який завжди стверджував, що може розповісти вам більше, слухаючи гул проекту, ніж читаючи всі звіти про проект. Інструмент розробив якісну інформацію для керівника проекту та керівництва.

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

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

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

Опитування Humm виявляє занепокоєння з приводу постачальника

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

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

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

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

Розробка історії проекту

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

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

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

Історія проекту «Наркотики для порятунку життя»

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

> Щоб виконати роботу, команда проекту знайшла творчі способи виконання роботи за межами майданчика та планування роботи, щоб мінімізувати проблеми безпеки при дотриманні агресивних термінів. Історія стала викликом. Люди ототожнювалися з викликом і хотіли бути частиною успіху.

Створення репутації для швидкості завершення проекту

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

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

Ключові виноси

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

Вправи

Тип довіри, який формується шляхом спостереження за тим, що правдивість людини підкріплюється спостережуваними фактами, називається ________ _________ (два слова).
Тип довіри, який формується, знаючи, що інша особа не ризикуватиме покараннями за неправдивість, називається високою вартістю ________.
Тип довіри, який формується, знаючи, що інша людина діє в своїх власних інтересах, називається ___-________ довірою.
Тип довіри, який формується шляхом оцінки мотивів людини і висновку, що вони не ворожі, називається атрибутом ________________.
Щоб створити довіру, менеджер повинен узгодити офіційні цілі з ______ цілями.
Humm Factor - це метод збору ________ інформації про проект, який вказує на «почуття кишечника», яке має команда проекту щодо проекту.
Коротка заява про проект, яка фіксує його мету та характер, які можна було б передати менш ніж за хвилину, називається _________ історією.
Як недовіра впливає на фільтрацію інформації, і як це впливає на проект?
Які чотири типи довіри?
Як менеджеру створити довіру?
Які три основні типи зустрічей і які їх характеристики?
Чим функціональні, крос-функціональні команди та команди вирішення проблем відрізняються один від одного?
Яке призначення «Хумм-фактора»?

Інтерналізуйте свій досвід навчання, підготувавшись до обговорення наступного.

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

Посилання

Кодрон, С., «Неоспіті герої індустрії», Промисловий тиждень, 4 грудня 1995 р., 12—16.

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