4.3: Робота з проблемами

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

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

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

Встановлення стандартів та процедур для прийняття рішень

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

Конкуруючі інтереси

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

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

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

Малюнок 4.5 Матриця відповідальності

> Матриця відповідальності визначає ролі та залученість клієнтів.

Назва	Заява про сферу	Структура розбивки робіт	Бюджет	Якість	Процедури управління змінами	Змінити затвердження
Комітет з фрахтування проектів	Х
Клієнт Представник	Х	Х	Х	Х	Х	Х
Керівник проекту	Х	Х	Х		Х	Х
Технологічна команда		Х		Х
Фінансова команда			Х		Х
Графік координаційної групи		Х		Х	Х

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

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

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

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

Достроково вирішуйте складні питання

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

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

Нові оцінки збільшують прогнози витрат

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

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

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

Забезпечити механізми для повторного розгляду основних рішень та питань

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

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

Іноді люди просили переглянути рішення, тому що їм не сподобалося рішення, яке було прийнято.

Повторний розгляд рішень

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

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

Рішення постачальника не переглянуто

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

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

Створення культури та механізму перегляду проектних рішень має важливе значення для задоволення очікувань клієнтів.

Аварійна кнопка

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

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

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

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

Вправи

1. Таблиця, в якій відображається, хто повинен бути включений в прийняття різних типів рішень, - це рішення ______.
2. Клієнт повинен бути залучений до прийняття рішень ______ в процесі вирішення проблеми.
3. Інформація, яка розробляється на етапі планування, може зажадати перегляду рішень, які були прийняті на етапі _________.
4. Опишіть матрицю відповідальності та спосіб її використання.
5. Чому важливо інформувати клієнта на початку процесу вирішення проблеми?
6. Чому попередні рішення повинні бути переглянуті?

Поріг залучення клієнта

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