Почнемо з елементів, які в перепетії зміни організації будуть відігравати визначальну роль - організаційна структура і адміністративна система управління проектом.
Широко відомо, що робота по проектам може здійснюватися в рамках різних типів організаційних структур. Ідеальним варіантом є мережева оргструктура, в якій існують тільки проектні команди і їх керівники. Але такий варіант організації роботи по проектам є ефективним, мабуть, лише для тих компаній, праця співробітників яких має творчий, слабо формалізований характер, а самостійність вражає уяву. Для Росії в даний час більш характерні ситуації, коли проектне управління здійснюється в рамках функціональних організаційних структур. У цьому випадку ми маємо справу з елементами матричної організації праці. Залежно від рівня організації проектної системи управління така матрична структура може бути сильною, збалансованої і слабкою. Однак нас більше цікавить технологія формування структури управління проектом, а не теоретичні викладки по теорії організаційних структур, якими сучасні підручники рясніють в достатньому обсязі.
Отже, яким чином запровадити систему управління проектами в компанії? Перш за все слід визначити, що є проектом у вашій компанії. Прикладом може служити розробка і виведення нового продукту на ринок, надання послуги консалтинговою фірмою. Далі необхідно визначитися, як часто виконуються дані проекти в компанії: разові роботи, періодичні, постійно повторювані. Це дозволить прийняти рішення про те, який тип буде мати команда проекту - тимчасовий або постійний, чи будуть змінюватися склади учасників команд чи ні, тобто чи буде команда проекту кроссфункціональной або стійкої за складом. Не можна забувати і про те, скільки людина входить в команду. Якщо в команді бере участь велика частина вашого персоналу, то, ймовірно, у вас буде всього лише одна і постійна команда, а директор виявиться її керівником. Якщо ж команда виходить нечисленної, то, швидше за все, вам доведеться подумати про керівника команди. Хто може виступити в ролі керівника проекту або проектного менеджера? Слід вибрати того, хто володіє найбільшою професійною компетенцією в області проекту, має яскраво виражені лідерські якості, може стати хорошим організатором. Тут вибір залишається за вами і вашою інтуїцією.
Наступним питанням, з яким вам доведеться зіткнутися, стане формування робочої команди. Тут все визначає відповідь на питання, чи буде команда постійної або формується на час. У тимчасових командах, як правило, на перше місце доцільно ставити професійні якості співробітників в сфері, до якої належить проект. У постійних проектних командах важливу роль відіграє психологічна сумісність співробітників. Але якщо ви готові пожертвувати психологічним кліматом колективу заради досягнення результату, то гарною підмогою виявиться тренінг командоутворення. Тренінг може бути корисним і в тому випадку, якщо ваші співробітники жодного разу не чули про проектний управлінні і не знають «з чим його їдять». Тут можна порадити тренінг з управління проектами, що розкриває не тільки суть проектного менеджменту, а й дає практичні навички управління проектом.
Наступним етапом в епопеї постановки системи управління проектами повинні стати формування стандартів планування роботи по проекту і контроль за ходом його виконання. Основними є «Планування графіка», «Планування бюджету», «Управління графіком і вартістю», «Управління проблемами», «Управління ризиком», «Управління якістю проекту». Розглянемо коротко сутність цих стандартів.
Стандарт «Планування графіка» має на увазі регламентацію дій учасників проектної команди з планування термінів виконання робіт. Цей стандарт може мати форму звичайної таблиці із зазначенням термінів або трансформуватися в діаграму Ганта. Остання може бути без праці сформована в програмі Microsoft Project.
Мал. 1. Діаграма Ганта з програми Microsoft Project
Стандарт «Планування бюджету» відповідно містить вказівки по формуванню бюджету проекту. Його неважко скласти, базуючись на досвіді фінансових служб по формуванню бюджету компанії.
Стандарт «Управління графіком і вартістю» визначає дії, що виконуються для контролю за термінами і бюджетом проекту. Тут, як правило, вказуються контрольні точки проекту - ті моменти, в яких повинна бути виконана певна частина процесів (важлива для проекту), і де наочно видно витрачання ресурсів проекту.
В ході виконання проекту часто виникають різні проблеми або ризики - перешкоди, які мають небажані наслідки для компанії. Їх своєчасне виявлення і реакція на них мають надзвичайно важливе значення. Важливим моментом також є оцінка ризику. Вона може бути проведена в якісної і кількісної формах. У першому випадку оцінка ризику простіше і може бути проведена досвідченим експертом, в другому випадку необхідно використання спеціальних статистичних методів розрахунку. Стандарт «Управління ризиком» включає в себе визначення можливих ризиків, їх класифікацію по частоті і силі впливу на проект, а також можливі реакції на дані ризики. Наприклад, в туристичному агентстві «XYZ» вирішено освоїти новий напрямок - подорожі по російській глибинці. Менеджери агентства визначили основні ризики проекту, як: невідповідність попиту з боку потенційних клієнтів у порівнянні з виявленими в ході попередніх досліджень; погіршення погодних умов, що унеможливить поїздку у віддалені села; нестача грошових ресурсів для розкрутки програми; неможливість знайти підходящі для розміщення туристів приміщення, що потребують додаткових вкладень. Оцінка ризиків досвідченими експертами показала, що найбільш вірогідним і небезпечним ризиком може стати невідповідність попиту.
Взагалі, всілякі реакції на ризик прийнято зводити до трьох видів - мінімізація ризику, щоб уникнути ризику і прийняття ризику. Мінімізація означає зменшення ефекту ризику за рахунок зниження ймовірності його появи. Уникнення ризику - усунення ризику за рахунок усунення його причин (на практиці неможливо повністю усунути ризик, оскільки усунення одного ризику веде до збільшення іншого). Прийняття ризику означає те, що ми усвідомлюємо його наявність і його наслідки і готові впоратися з негативними пострісковимі явищами. Так, в прикладі з туристичним агентством для вирішення проблеми був обраний шлях прийняття ризику. У тому випадку, якщо нам заздалегідь відомі негативні наслідки, які виникнуть в результаті тієї чи іншої реакції на ризик, необхідно визначити шляхи вирішення виниклих проблем. Особливо важливий цей момент, якщо дані проблеми носять циклічний характер. Наприклад, нам відомо, що при прийнятті ризику недотримання термінів перед нами завжди постає проблема пояснення замовнику причин відставання від графіка. Тому ми заздалегідь можемо визначити можливі пояснення і прописати їх в стандарті «Управління проблемами».
Стандарт «Управління якістю проекту» дуже важливий, оскільки якість проекту - це один з основних показників результативності проекту. Даний документ може базуватися на системі стандартів ISO 9000, якщо вона застосовується в організації. Тут потрібно докладний опис критеріїв, за якими оцінюється якість проекту, вимірювачі даних критеріїв і способи вимірювання показників. Критеріями якості можуть виступати: відсоток дотримання стандартів оформлення документів, кількість скарг на надання послуги і т.п.
Всі описані стандарти в компанії об'єднуються в єдину систему управління проектами. До них можна додати регламент призначення проектного менеджера, посадові інструкції членів команди, положення про проектній команді, положення про оплату праці проектної команди.
Перш за все слід визначитися, як ми маємо намір винагороджувати учасників проектних команд - за індивідуальні або командні результати, а може, ми хочемо поєднати обидві форми оплати? Далі необхідно буде вирішити, чи будуть у команди преміальні виплати і чи передбачається будь-яка додаткова компенсація (медична страховка, оплата тренувань в тренажерному залі і т.п.).
Почнемо з індивідуальної оплати праці. За що ми можемо платити членам нашої проектної команди? Пропонуємо використовувати кілька показників оцінки вкладу кожного виконавця в командний процес праці: складність праці, якість роботи, дотримання термінів. До цього списку можна додати виплати за компетенцію співробітників (проте вони не враховують характеру праці) і відсоток виконання планових показників (досягнення цілей).
Складність праці можна оцінювати за показниками, що характеризують характер роботи і напруженість праці. Характер праці визначається різноманітністю і регламентованих виконуваних робіт, масштабом керівництва, додатковою відповідальністю і характером процесів. Напруженість праці характеризує фізичні навантаження під час виконання робіт. Цей критерій доцільно використовувати, наприклад, в будівництві або виробництві. Управлінська праця характеризується в основному показником складності.
Припустимо, що команда займається розробкою нової моделі дитячого дивана. Частина членів команди займається пошуком інформації про існуючі моделях дивана, а також просуванням нових ідей команди в пресі. Інша частина зайнята безпосередньо розробкою конструкції під керівництвом проектного інженера, в обов'язки якого входить контроль за технічною частиною. Третя частина відповідальна за вартість нової моделі, а точніше, за її мінімізацію. Усією командою керує менеджер проекту, який відповідальний за результат проекту в цілому (терміни, якість, бюджет). Очевидно, що складність праці інженера буде вище, ніж у інших членів команди, але нижче, ніж у проектного менеджера, за рахунок того, що в його праці присутній елемент керівництва за певну частину проекту. Якщо говорити про напруженість праці, то в даному випадку вона приблизно однакова і в розрахунок при розподілі фонду заробітної плати не береться.
Якість праці членів команди можна вимірювати по-різному, ми вже говорили про це вище. Але очевидно, що той, чиї результати були більш якісними, отримає ще більшу заробітну плату.
Точно так само йде справа і з термінами виконання. Тут можна ввести коефіцієнт затримки у вигляді (1 - затримка * коеф затримки), де затримка - термін, на який затриманий проект, коеф затримки - частка, на яку зменшується розмір виплат за один період затримки. Даний коефіцієнт буде вносити поправки в облік загальних трудовитрат члена команди в проекті.
Система оплати за компетенціями досить повно описана в літературі, тому не будемо докладно зупинятися на ній. Обмовимося лише, що дане доповнення до системи оплати може бути ефективним в ситуації, коли для виконання проекту важливі саме знання і вміння співробітників.
Крім того, для команди можуть бути встановлені певні планові показники: за вартістю, за термінами, за якістю і т.д. Тоді оплата праці буде проводитися за виконання плану.
Відзначимо також, що систему оплати, засновану на описаних вище умовах, можна ускладнити шляхом присвоєння критеріям певних терезів. Ці ваги можуть бути визначені компетентними експертами.
Другий варіант системи оплати - плата за командні результати з наступним розподілом даного фонду заробітної плати між членами команди. При розподілі фонду можна враховувати згадані вище критерії як окремо, так і в комплексі. Наприклад, шляхом перемноження даних критеріїв може бути обчислений комплексний показник вкладу співробітника в роботу команди, який і буде базою при подальшому розподілі:
До комплексний = К складності * До якості * (1 - затримка * коеф затримки) * До компетенції.
де До комплексний - комплексний коефіцієнт;
До якої складності - коефіцієнт складності;
До якості - коефіцієнт якості;
Затримка - період затримки виконання проекту (годин, днів);
Коеф затримки - коефіцієнт, що визначає частку зниження заробітної плати за 1-й період запізнення в термінах;
До компетенції - коефіцієнт, що оцінює рівень компетентності співробітника.
Слід зазначити, що викладений варіант моделі нарахування заробітної плати може використовуватися як при преміальні виплати, так і при відсутності останніх. Варіацій на цю тему можна запропонувати масу. Але модель у кожної команди буде своя - «єдина і неповторна». Однак необхідно пам'ятати при цьому про тип організаційної структури компанії. Оскільки в разі функціональної структури з елементами матричної (коли лінійно-функціональна організація застосовує командну форму праці за проектом) учасники команди крім роботи за проектом можуть виконувати основну роботу в рамках своєї функціональної спеціалізації. Тоді їх заробітна плата буде включати в себе дві складові - за проектом і за основним місцем роботи. У цьому випадку на перший план виходить проблема формування фонду заробітної плати команди. Останній може складатися за фактом, а може плануватися заздалегідь - за плановими показниками проекту.
На закінчення торкнемося теми організаційної культури проектної компанії. Якщо проектна команда вписана в лінійно-функціональну схему організації, то слід ретельно підійти до формування в компанії уявлення про проектну формі роботи, про цілі проектної команди, важливості результатів її роботи. Інакше може статися така ж історія, як в компанії Apple в 1980-х роках, коли протистояння «елітної» команди решти організації призвело до того, що компанія перетворилася в дві воюючі групи. Це серйозно підірвало роботу Apple. Профіль організаційної культури проектної компанії, за нашим досвідом, виглядає наступним чином:
Мал. 2. Профіль організаційної культури компанії,
орієнтованої на проектну форму роботи
Таким чином, алгоритм побудови системи управління проектами виглядає так, як представлено на рис. 3: