Практика застосування ГОСТ Р 54869-2011 (Управління проектами) у державній компанії

  1. Кириліна Марина Миколаївна : Практика застосування ГОСТ Р 54869-2011 (Управління проектами) у державній...
  2. Ризики застосування ГОСТ Р 54869-2011
  3. Червоно-синій олівець і ГОСТ Р 54869-2011
  4. Західний досвід в Росії

Кириліна Марина Миколаївна : Практика застосування ГОСТ Р 54869-2011 (Управління проектами) у державній компанії

Практика управління проектами в Росії довгий час не була стандартизована на державному рівні. 22 грудня 2011 року було затверджено ГОСТ Р 54896-2011 «Проектний менеджмент. Вимоги до управління проектом », який став офіційним джерелом методології управління проектами (УП). Для кращого розуміння питання звернемося до його історії.
Випуском стандартів можуть займатися комерційні та міжнародні організації (наприклад, International Organization for Standardization, ISO), професійне співтовариство, а також держава. В останньому випадку стандарти - це спосіб державного упорядкування діяльності компаній. Фактично система стандартизації в Росії діє понад 80 років. Основною категорією стандартів в СРСР були державні стандарти, в даний час на території СНД застосовуються міждержавні стандарти. Документи, затверджені до 1996 р, були нормативно-правовими актами і тому були обов'язковими для застосування в областях, які визначалися в їх преамбулах. Нормативність документів, прийнятих після 1996 р сама по собі перестала означати їх обов'язковість. До їх числа відносяться і стандарти ГОСТ Р по управлінню проектами, програмами і портфелями проектів.
Дуже важливо, щоб всі учасники проектної діяльності використовували єдину базову термінологію, працювали в єдиному понятійному просторі, оскільки реалізація проектів - особливий вид діяльності, часто має високий рівень невизначеності, обумовлений участю в ньому значної кількості зацікавлених сторін. Без стандартизації вимог до процесів управління, документам і результатами проекту неможливо домогтися ефективної взаємодії учасників проектної діяльності.

ГОСТи з проектного менеджменту

На сьогоднішній день в сімейство стандартів «Проектний менеджмент», затверджених Наказом Федерального агентства з технічного регулювання і метрології від 22 грудня 2011 р №1582-ст, входять:

  1. ГОСТ Р 54869-2011 «Проектний менеджмент. Вимоги до управління проектом »;
  2. ГОСТ Р 54870-2011 «Проектний менеджмент. Вимоги до управління портфелем проектів »;
  3. ГОСТ Р 54871-2011 «Проектний менеджмент. Вимоги до управління програмою ».

Ці стандарти визначають як єдине розуміння загальної послідовності процесів управління проектами, програмами, портфелями проектів, так і вимоги до окремих процесів. Стандарти повинні сприяти подальшому розвитку дисципліни управління проектами, в них узагальнюються кращі практики УП.
Розробники ГОСТів врахували загальносвітові тенденції стандартизації, до яких відносяться взаємозв'язок процесів управління (як на рівні окремих проектів, так і на рівні програм та портфелів) і поділ базових вимог до процесів управління проектами і можливим (рекомендованим) процесам, методам і інструментам. тандартам дає чіткі і ємні визначення основних термінів, необхідних для опису процесу управління проектом.
Дана стаття не ставить за мету порівняти ГОСТ Р 54869-2011 з «Керівництвом PMBOK ® »PMI або стандартом ISO 21500 , Останнім часом з'явилося досить багато подібних матеріалів, а присвячена опису практики використання стандарту в конкретної російської держкорпорації і досвіду автора.
Унікальність даної компанії обумовлена ​​тим, що вона відноситься до держсектору і разом з тим її діяльність має комерційну складову. Можна стверджувати, що перед компанією стоїть амбітна мета - заробляти гроші для держави, внаслідок чого вона є об'єктом пильної уваги з боку всіх компетентних контролюючих органів.

Ризики застосування ГОСТ Р 54869-2011

Стандарт ГОСТ Р 54869-2011   дуже затребуваний в держструктурах Стандарт ГОСТ Р 54869-2011 дуже затребуваний в держструктурах. Він дозволяє відійти від розуміння проекту як комплекту документації, а проектної діяльності - як технології її розробки і може використовуватися в якості основного підходу до організації роботи проектно-орієнтованої компанії. Часто проектне управління в Росії нагадує знаменитий діалог Аліси і Чеширського кота з «Аліси в країні чудес» Льюїса Керролла:

«- Скажіть, будь ласка, куди мені звідси йти? - запитала Аліса.
- А куди ти хочеш потрапити? - відповів Кіт.
- Мені все одно ... - сказала Аліса.
- Тоді все одно, куди і йти, - зауважив Кіт.
- ... тільки б потрапити куди-небудь, - пояснила Аліса.
- Куди-небудь ти обов'язково потрапиш, - сказав Кіт. - Потрібно тільки достатньо довго йти. »
На початку проекту команда з ентузіазомом приступає до його виконання, при цьому ігноруючи будь-які перешкоди на своєму шляху. Як перешкоди може сприйматися, наприклад, необхідність оформлення документації належним чином. Однак проекти здійснюються в конфліктному середовищі, і тому виникнення розбіжностей - їх неминуча складова. Незафіксовані документально домовленості призводять до серйозних конфліктів, які неможливо вирішити, тому що у усних угод в подібних ситуаціях немає правового статусу. Це відбувається через те, що з самого початку порушується головний постулат проектного управління - послідовність в організації УП. Перш ніж здійснювати будь-які дії, необхідно, щоб замовник сформулював мету, потім потрібно деталізувати її, створити команду, розподілити ролі, розробити план, узгодити бюджет і продумати ризики.
Зупинимося на ризики докладніше. Часто до порушення термінів і перевищення бюджету призводить саме неуважне ставлення до проектних ризиків. У ГОСТ Р 54896-2011 ризик визначається як «ймовірне для проекту подія, настання якого може як негативно, так і позитивно відбитися на результатах проекту». Дане визначення не є загальновизнаним ні в міжнародній, ні в російській практиці. У автора даної статті подібне формулювання викликає деяке здивування: незрозуміло, чому подія вже визначено як ймовірне і вказані тільки результати проекту. Існуюча трактування ризику малозастосовна на практиці, тому що часто управління проектами здійснюється «інтуїтивно». У частині роботи з ризиками ГОСТ явно вимагає удосконалень і доповнень.
Для підприємств держсектора типова ситуація, коли для управління проектом залучаються високопрофесійні співробітники, кожен з яких є унікальним у своєму роді фахівцем, але у команди в цілому немає спільного бачення, стратегічного підходу до вирішення поставлених завдань.
Підприємство, про який піде мова в даній статті, надає широкий спектр телекомунікаційних послуг. Воно має статус Федерального державного унітарного підприємства (ФДУП), контролюється і регулюється державою.

Червоно-синій олівець і ГОСТ Р 54869-2011

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

Беручи документ до розгляду, чиновник використовує червону сторону олівця для резолюції «відмовити», а синю - для резолюції «в роботу», при цьому дотримуючись бюрократичних процедур, що призводить до постійних затримок. У такій ситуації планування стає неможливим, тому що на обдумування і формулювання цілей і завдань для узгодження на різних рівнях організації необхідний час, а цілі і терміни визначаються директивно. Таким чином, можна стверджувати, що зрілість такої компанії за шкалою розвитку проектної методології має значення нижче нуля. Фактично проекти здійснюються, і багато хто навіть успішно.
Відзначимо, що це відбувається частково завдяки керівної ролі держави, яке зобов'язало ФГУП дбайливо використовувати його майно і збільшувати капітали: якби не було цієї комерційної складової - не було б і проектів. Однак з методологічної точки зору ситуація виглядає катастрофічно: спостерігається плутанина в термінах, визначеннях і поняттях. У компанії одночасно здійснюється регулювання її діяльності за допомогою бюрократичних процедур і управління проектом в його комерційному розумінні.
Перше має на увазі відношення до проекту як до пачці паперових документів або креслень. Терміни при цьому встановлюються наказами, в яких вказуються відповідальні особи, що не володіють якими-небудь реальними повноваженнями. Це пов'язано з тим, що компанія має жорстку функціональну структуру, що не передбачає, що фахівець, який знаходиться на нижньому рівні службової ієрархії, може бути керівником проекту.
Важливу роль тут також зіграло те, що згідно з існуючими нормативами і законам, неможливо зробити запис в трудову книжку співробітника, що виконує обов'язки керівника проекту, тому що в класифікаторі професій такої професії немає. Якщо для інших компаній цей документ носить рекомендаційний характер, то структура, подібна описуваної, спирається на нього як на обов'язковий.
Інша сторона діяльності підприємства пов'язана із здійсненням проекту в його комерційному розумінні. В цьому випадку у проекту повинен бути керівник, який планує хід його виконання від початку і до кінця, підбирає і структурує команду, готує звіти для керівництва, відповідає за результат і досягнення цілей проекту. При цьому повинні бути сформульовані цілі проекту, встановлені його терміни, визначені куратори і замовники, описані їхні обов'язки і повноваження.
Неважко уявити, яким чином виконувалися проекти в описаних вище умовах до прийняття ГОСТу Р 54896-2011. У ситуації, коли керівник проекту не міг сам формувати команду, відповідати за терміни проекту і контролювати його ведення, проект в кращому випадку був приречений на уповільнене виконання з нескінченним очікуванням коригувань «зверху», а в гіршому - на закриття в фазі планування. Резолюції, винесені з використанням червоної боку інструменту регулювання, про який ми згадували раніше, - «відкласти», «доопрацювати», «відправити на розгляд» і т.п.- могли тягнутися нескінченною низкою.

Західний досвід в Росії

Можливість застосування західних методик УП, наприклад PMBOK, на підприємствах державного сектору сприймалася негативно. Керівництво вважає, що в Росії для управління проектами характерні свої особливості, і тому повинні застосовуватися свої регулюючі механізми.
Було очевидно, що необхідний документ, законодавчо затверджує проекти і проектну діяльність - стандарт або інший нормативний акт, в якому були б формалізовані вимоги до процесу отримання результатів, результату цього процесу і продуктів проекту, дано цілісне уявлення про управління проектами як окремої галузі менеджменту, визначено єдине розуміння загальної послідовності процесів управління проектами та вимог до окремих процесів. Крім того, такий документ повинен був сприяти розвитку дисципліни управління проектами, узагальнення передового досвіду і практики УП. При розробці стандартів були враховані як загальносвітові тенденції стандартизації, так і її російські особливості.
Розглянемо ситуацію, в яку потрапила проектна команда компанії при здійсненні проекту IT-служби. Керівництво поставило перед командою масштабну і дуже важливу для підприємства завдання комплексної автоматизації управління. Однак під час виконання проекту команда не мала інструментів для ведення проектної документації згідно загальносвітовій практиці. В її розпорядженні було тільки «Керівництво PMBOК», однак при здійсненні своєї діяльності ФГУП як держкорпорація повинна спиратися тільки на офіційні документи, тому команда не могла застосовувати його в своїй роботі. Наприклад, використання в документах формулювання «Статут проекту» було відкинуто з коментарем: «Статут у компанії повинен бути тільки один». Складні завдання, які стояли перед командою проекту, неможливо було почати вирішувати без серйозної роботи над документацією. Через бюрократичну затримок в певний момент управління проектом було призупинено. Поява офіційного стандарту стало для команди проекту «рятівним колом».
Головна відмінність між ГОСТом Р 54896-2011 і «Керівництвом PMBOК» полягає в тому, що перший не містить обов'язкового списку документів, які потрібно підготувати для того чи іншого проекту, тобто в ньому немає небажаних для російської практики формулювань, таких як, наприклад, «Статут проекту».
Згідно з рекомендаціями ГОСТу Р 54896-2011, в даній компанії використовуються наступні документи:

  • Наказ про початок проекту;
  • Наказ про створення менеджерської групи, яким затверджуються:
    • Повноваження керівника проекту;
    • Склад проектної команди;
    • Розмір мотиваційних виплат;
    • Основні фази проекту;
    • Графік виконання робіт;
    • Графік звітності;
  • Наказ про закриття проекту.

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

А куди ти хочеш потрапити?