Управління портфелем проектів

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

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

Успішно працюючі організації, як і хороші керівники, не бажають, щоб їх співробітники брали на себе такий обсяг роботи, з яким вони не зможуть впоратися і тому видохнуться на півдорозі, зазнавши невдачі. Ефективно працюючі підприємства хочуть, щоб контроль над їх портфелями проектів взяли на себе підрозділу ІТ. Тільки не варто розслаблятися: за останніми теж необхідний нагляд. У ході нещодавно проведеного журналом Information Week опитування 968 фахівців з бізнес-технологій 75% з них відповіли, що навантаження на підрозділи ІТ є або високої, або просто непідйомною.

Більш досвідчені керівники компаній тримають управління портфелями проектів (Project Portfolio Management – PPM) під постійним контролем і або виділяють важливим проектам підвищений пріоритет, або при необхідності згортають окремі проекти, коли справи в них ідуть з рук геть погано. Як і управління ризиками, управління PPM далеко не останнє слово управлінської науки. Ця технологія вже протягом багатьох років використовується в будівництві і виробництві, і ІТ-менеджерам залишається просто грамотно скористатися наявними напрацюваннями. У своєму найпростішому і найбільш корисний вигляді пакет PPM включає в себе можливості установки параметрів, класифікації і пріоритизації всіх проектів.

Як показують результати нещодавно проведеного американським інститутом IT Process Institute (ITPI) дослідження, до найбільш ефективних відносяться ті ІТ-організації, які не бояться закривати провальні проекти, по суті роблячи це в два рази частіше, ніж їх менш успішні побратими.

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

Усунення бар'єрів


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

Вимірювання навантажувальної здатності ІТ-підрозділу


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

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

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


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

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

Так уже склалося, що, будучи сервісно-орієнтованим, ІТ-відділ часто, по суті, нічим не володіє, а, значить, пріоритизація проектів повністю входить в компетенцію бізнес-підрозділів. Він фактично підтримує потреби основного бізнесу. І якщо процес управління портфелем проектів не автоматизовано, то практика щотижневих зустрічей ІТ-керівництва з виконавчим і фінансовим директорами буде ефективна тільки у випадку невеликого числа проектів – скажімо, від 1 до 10. А що робити, якщо таких проектів 500?

Відстежуйте глобально, оцінюйте локально


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

При оцінці більшості проектів беруть до уваги вісім факторів. Перший з них – фінансовий, що визначає коефіцієнт окупності інвестицій (ROI): принесе прибуток реалізований проект або хоча б поверне вкладені в нього гроші? Часто в ході оцінки враховують також додатковий ризик, організаційний розвиток, зміни в обслуговуванні клієнтів, відповідність вимогам нормативних актів, дотримання вимог охорони праці та забезпечення безпеки життя, відповідність стратегії ради директорів і контроль над втратами. Кожен з перерахованих факторів можна ранжувати за важливістю за десятибальною шкалою від 1 до 10, потім, віддаючи перевагу окремим із них, зважити з тим чи іншим коефіцієнтом і, нарешті, отримати результуючу сукупну оцінку.

Розмірковуючи про те, які критерії оцінки можуть виявитися для вашої організації дієвими, не забудьте про інтереси і власне ІТ-підрозділу: прагнете ви до того, щоб завершити проекти, в яких ви берете участь, в найкоротші терміни? Цей показник оцінюють 27% опитаних нами організацій. Або, може бути, ви прикладаєте максимум зусиль до того, щоб ваші дії відповідно до сервісної моделлю лише найбільш точно відповідали потребам ваших бізнес-підрозділів? Що б там не було, врахуйте це у своїх критеріях оцінки проектів.

Не нехтуйте малими ІТ-проектами


Не всяка робота в організації являє собою багатомільйонний ІТ-проект, що вимагає формальної декомпозиції робіт, використання мережевих графіків Гантта, аналізу критичного шляху і т. д. Однак жоден з малих проектів не повинен розцінюватися як те, що можна виконувати абияк. Розмова в дусі: "Ну, так нам і треба-то всього кілька нових сканерів. Які тут можуть бути труднощі?!" – Може обернутися тижнем доставки, мережевого конфігурування, пошуком нестиковок, придбанням і конфігуруванням додаткових ліцензій для системи управління документообігом – і все це тільки для того, щоб прийняти сканери на баланс.

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

Створення офіційної групи управління для кожної затребуваної роботи, звичайно ж, є безглуздям. Тим не менш, не маючи можливості оцінювати всі проекти (і таким чином контролювати всі проектні потоки), нечисленний персонал ІТ буде постійно перебувати в стані авралу.

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

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


Корпоративне управління і управління проектами


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

У ході нашої дискусії з директорами та інженерами-практиками з ІТ ми знову і знову поверталися до однієї і тієї ж теми: що трапиться, якщо ваш процес управління портфелем проектів видасть на запит щодо доцільності виконання якогось проекту для бізнес-підрозділу відповідь "Не зараз" або "Не доцільно", а бізнес-підрозділ (що має свій власний бюджет і деяку ступінь автономності) все одно приступить до його виконання без схвалення представників ІТ-відділу, і згодом, в силу того що неправильно спланована технологія вийде з-під контролю або не буде піддаватися інтеграції з корпоративними системами, цей неконтрольований проект обрушить на ІТ-підрозділ вал термінової позапланової роботи?

Представник інституту ITPI відповідає на це питання питанням: "Як ви справляєтеся з ситуацією, коли ваша корпоративна стратегія говорить:" Ми не будемо виходити на ринок Латинської Америки ", і в той же час одне з лінійних підрозділів все одно бере і робить це? "Іншими словами, якщо ваш процес PPM досить ефективно інтегрований у вашу корпоративну структуру субординації і прийняття рішень, то ніяких узгоджень з ІТ-підрозділом не буде потрібно, оскільки грамотне керівництво – це контроль над усіма процесами в компанії ..

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*