Що таке ескалація в управлінні проектами і навіщо вона потрібна, управління
Забавно, але досить часто стикаюся з питанням «що таке ескалація» і «що значить ескаліровать» незважаючи на те, що це одне з найбільш базових понять як в управлінні проектами, так і в менеджменті в цілому. Тому цей пост (обережно, спойлер!) Буде сповнений досить банальних речей про ескалацію, якщо ви все про це знаєте - не відчиняйте. Я попередила.
Отже, що таке ескалація? Вікіпедія дає універсальне визначення - це поступове збільшення, посилення, розширення чого-небудь (наприклад, корупції у владі, або ескалація війни); нарощування (озброєнь і т. п.), поширення (конфлікту і т. п.), загострення (положення і т. п.).
Красиво, але пов'язати з керуванням проектами складно, але ж все дуже просто.
Ескалація - це «підйом вгору» конфлікту або проблеми, які ви не можете дозволити самостійно в рамках своєї ролі або своїх повноважень.
У нормі процес виглядає так: учасники проектної команди взаємодіють один з одним і в разі, якщо вони не можуть домовитися між собою, або вирішити якусь зовнішню проблему самостійно - вони ескаліруют питання на керівника проекту. Якщо він може вирішити питання - він його дозволяє, якщо немає - ескалірует вище.
Ескалація - це також один з основних інструментів, що використовуються в ході управління ризиками.
Мої правила ескалації:
- Спробувати домовитися без ескалації.
- Якщо не вдалося - чесно попередити, що раз ми не домовилися - я змушена ескаліровать питання на такого-то менеджера, тому що інтереси проекту і все таке. Після цього дивним чином в половині випадків домовитися вдається.
- Продумати виразну аргументацію з позиції впливу піднімається питання на проект і на його результати / терміни / бюджет і інші обмеження.
- Включити в лист (поставити в копію) або покликати на зустріч з керівником другу сторону конфлікту, щоб вирішувати питання спільно. У разі якщо питання критично важливий для проекту - не забути включити в процес спонсора проекту, заздалегідь погодивши з ним свою позицію.
- Отримати результат, пам'ятаючи при цьому, що негативне рішення - це теж результат. І якщо, наприклад, мені в ході ескалації не вдалося отримати потрібний ресурс, це привід відобразити це в плані управління ризиками і відзначити в протоколі, що в підсумку вплив на проект таке-то.
- Продовжувати працювати в звичайному режимі, не роблячи висновків типу «всі вони неправі», «менеджер, який не дав ресурс - негідник», «так робіть тоді самі свій проект, кому з нас це взагалі треба» і ін. Ескалація - робочий процес, в якому немає місця особистому сприйняттю. Хоча деякі поправки в план управління стейкхолдерами після цього модно внести, так як тепер ви краще уявляєте їх мотивацію, вплив та ін.
Часто керівники проектів бояться самого слова «ескалація», чомусь вважаючи, що в разі, якщо вони винесуть проблему вище, вони продемонструють свою некомпетентність, невміння управляти командою і ін. А даремно, поки ви не генеральний директор - 100% впливу і влади у вас все одно не буде (та й у випадку з генеральним директором теж), а значить - ситуації, в яких знадобиться ескалації, неминучі. І краще зробити це раніше, поки проект не завдано зовсім вже великої шкоди.