Проектный офис (он же Project Management Office, или PMO) – модное слово. Внедрением PMO у себя занимаются многие ИТ-, строительные компании и консалтинговые компании. Я лично пережил несколько таких внедрений. Мне доводилось формировать PMO штатным сотрудником, и в качестве внешнего консультанта. В этой статье – рассказ о нескольких «извлеченных уроках» (набитых шишках). При этом сколько- нибудь серьезно углубляться в методологию строительства проектных офисов не стану (отдельная тема).
Зачем нужен проектный офис?
Проектный офис vs разрозненные менеджеры
Определение из PMBoK 5th edition (2013):
В моей интерпретации это определение могло бы звучать так: «проектный офис это структура, которая помогает с управлением проектами; она занимается всевозможной стандартизацией, а иногда может напрямую рулить проектами».
Приведем еще одно определение из PMBoK 5th edition (2013):
«The project manager is the person assigned by performing organization to lead team that is responsible for achieving the project objectives.»
Менеджер и его команда отвечают за проект в целом. Так зачем усложнять? Кому и для чего нужны дополнительные стандарты, «политики», правила, инструменты и уж тем более стороннее вмешательство в работу? Разберемся. Как видит мир менеджер проекта?
Опытный менеджер обладает знаниями (как проектом управлять) и навыками (как эти знания применить).
Рассмотрим для примере менеджера, работающего преимущественно по PMI (www.pmi.org), Свод знаний (PMBoK) предоставляет в его распоряжение десятки процессов (собранные и классифицированные, наподобие химических элементов в таблице Менделеева).
Принимаясь за очередной проект (слово химик, планирующий цепочку реакций), менеджер отбирает и выстраивает процессы и правила перехода между ними, после чего осуществляет проект.
Разумеется, различные комбинации одинаковых элементов могут дать разный результат.
Обычно, менеджер не выбирает себе проекты и не придумывает для них цели. Он работает на «высшее руководство». Продолжая «химическую» аналогию – менеджер уточняет у руководства какое вещество оно хочет получить и сообщает, какие реактивы, помощники и сколько времени потребуется на химическую реакцию. Вполне возможно, что его не волнуют затраченные руководством средства и вообще целесообразность всей работы (от этого он не перестает быть профессионалом в своем деле).
Природа и полномочия проектного офиса отличаются. Чтобы это проиллюстрировать – разберемся с как устроена «типовая компания».
Почти любую организацию, работающую через проекты (будь то ИТ-, строительная, консалтинговая или иная компания), можно представить как трехэтажный дом.
Под самой крышей – топ-менеджер (он обозревает окрестности вокруг организации, определяет бизнес-цели и транслирует их «внутрь»).
На втором этаже – менеджеры проектов. Они работают на интересы «босса –с-чердака», однако работу выполняют не своими руками.
На первом уровне – команда. Те, кто «делает дело» (а не командует и контролирует) – технические эксперты, аналитики и прочие.
Где-то вне здания находятся заказчики (и пользователи) – люди и организации, ради которых работает весь трехэтажный дом.
Все этажи достаточно автономны, при условии, что между ними хорошо работают «стыки» (взаимодействия). Босс может сосредоточиться на финансовых показателях и контрактах; менеджеры – на иерархических планах, контроле целей и приоритетов работ, коммуникациях; команда – на распределении между собой пакетов работ и выполнении их удобным способом. Не важно кто и что использует в своей работе (методологически, технически). Менеджер проектов может быть адептом MS Project, а команда – использовать канбан-доски. При налаженных коммуникациях и адекватных подходах (приоритеты менеджера верны, а команда не проваливает сроки и качество) – этажи будут функционировать слажено, не мешая друг другу.
Сколь сложной не была бы реальная организационная структура компаний, сколь многоступенчатой ни казалась бы иерархия – обладателя любой должности, задействованного в проекте, можно отнести к одному из этажей (бывают и исключения – об одном из них ниже). О подобных уровнях переключения ответственности писал, например, Игорь Ашманов в своих «правилах Ашманова», как об одном из фундаментальных принципов.
Итак, типичная организация на «втором этаже» населена менеджерами проектов.
Исходя из того, для чего нанят руководитель проектов (см. выше — определение PMBoK), можем предположить, что в его сознании должен быть выстроен баланс между задачами «от топа» и реальными желаниями и возможностями команды. Пока менеджер один (и если он достаточно профессионален) – он не нуждается в проектном офисе, каких-либо подсказках и правилах которые сам себе не мог бы определить.
Однако рассмотрим чуть более сложную ситуацию. Менеджеров много. Многочисленны и задачи от «топов».
Именно так и бывает в большинстве случаев. А значит, на проектах обязательно возникнут «узкие места». Одно из таких — «производственные мощности». Руководители проектов начнут делить одни и те же ресурсы (команду, оборудование).
Кроме того, каждый из руководителей – личность, со своими привычками, подходами и проверенными практиками. Где-то они смогут сосуществовать мирно, но время от времени конфликты между менеджерами будут происходить обязательно. Особенно, если ресурсы черпаются из одного общего «пула». Тут уж столкновения «парадигм» неизбежны.
В ИТ- и консалтинговой сфере главные ресурсы – люди, они же – главный дефицит почти в любой компании. Соответственно «битву за кадры» ведет со своими коллегами каждый обитатель «второго этажа».
Вспомним определение проектного офиса. Где в нашем «доме» существует эта «управленческая структура» и кого из обитателей затрагивает?
Строго говоря – это «коллективный разум второго этажа». Т.е. не голова конкретного менеджера, а сознание ведущих руководителей проектов.
«Просто менеджер» мог бы потребовать себе ресурсы на проект и без зазрения совести включился бы в борьбу за них с коллегой. Проектный офис определит правила вовлечения сотрудников (учитывая как интересы руководителей, так и самих сотрудников – во избежание их перегруза или чрезмерного переключения между проектами).
«Просто менеджер» возьмется за тот реалистичный проект, который ему поручат. Проектный офис постарается выяснить – по средствам ли это компании, и нет ли другого, более удачного проекта, который можно было бы запустить взамен.
Наконец, проектный офис всерьез задумывается о лучших практиках безотносительно привычек и пристрастий отдельных обитателей второго этажа.
Разрушительное веяние моды
Итак, PMO – может быть полезен. Он может быть очень разным (в зависимости от нужд бизнеса), однако как «коллективный разум» умеет делать то, что не под силу отдельному руководителю.
Тут и таится первая порция проблем. В индустриях, где прижилось проектное управление – роль и место PMO обычно понимают плохо. Это касается всех «этажей», от топ-менеджеров до команды.
«Что такое PMO мы не знаем, но с ним лучше, чем без него. Будем создавать!».
Вот достаточно типичный слоган, который можно вынести из общения со многими топами (в частности, в ИТ-индустрии). Подобные идеи я встречал и в частном секторе, и в гос. власти.
Представьте себе пациента, который приходит к врачу и уверенно заявляет что-то в духе «доктор, мне нужна операция Троянова- Тренделенбурга, срочно!» (не снисходя до объяснения симптомов и дифференциального диагноза). Нелепо выглядит хирург, с готовностью соглашающийся выполнить именно это вмешательство, без дополнительных вопросов. Однако именно так ведут штатные менеджеры проектов, члены команд и даже некоторые внешние консультанты.
Нужен проектный офис? Не вопрос, «щас сделаем!»
Конечно, не любая компания нуждается в проектном офисе. И уж точно невозможно себе представить как именно должен выглядеть PMO до сколько-нибудь серьезного анализа.
Далее я буду говорить о разумных и не разумных (исходя из моего опыта) действиях, которые можно допустить, берясь за формирование PMO (не важно, кто инициирует работу и занимаются ли ей штатные сотрудники или сторонние консультанты).
Аудит всегда
Прежде чем перейти к рассмотрению отдельных проблем – сформулируем единственное жесткое правило («Правило No0»): «Формирование PMO обязательно нужно начинать с аудита (обследования)».
Особенно важно помнить об этом штатным сотрудникам (у которых часто есть иллюзия, что они «итак знают, как компания работает» и держат наготове наболевшие идеи). Проектный офис – это коллективный разум, для того, чтобы посмотреть на бизнес и проектную деятельность его глазами – нужно приложить отдельные усилия.
Аудит – ранний и важный этап внедрения PMO. Он заставляет задуматься о том к чему и какими силами удастся прийти, посредством проектного офиса.
Обычно говорят об уровнях зрелости. На первом – «проектный хаос», но втором – определенная повторяемость проектов, на третьем – уровень управляемости повышается на столько, что стабильность реализации проектов перестает зависеть от персонала и так далее. Не будем углубляться в подробности. Важно, что достижение и удержание каждого уровень проектной зрелости требует от организации разного уровня сил и средств.
Несколько типичных проблем
Поговорим о том, какие типичные проблемы с внедрением PMO можно и нужно предвидеть на этапе аудита и как не наступить на отдельные грабли. Наша задача – trouble-list.
Проблема 1 – размеры и их значение
Некоторые компании слишком маленькие для PMO. По большому счету, вопрос «сколько у Вас сотрудников?» — должен звучать вторым или третьим в диалоге с «топом», желающим создать проектный офис.
Значение имеет численность каждого этажа. Много ли топов («чердак»), много ли средних менеджеров («второй этаж»), какова численность команды, включая сторонних подрядчиков и фрилансеров («первый этаж»). В случае с подрядчиками и фрилансерами – имеет значение количество людей, которыми приходится непосредственно управлять.
Важны как абсолютные цифры, так и пропорции.
Отсутствие одного из этажей – абсолютное противопоказание в PMO. Например: «У нас нет топов, у нас все единомышленники, сами себе менеджеры, команда и бизнесмены» — картина, характерная для небольших (и эффективных) стартапов.
Проектный офис (по своей природе) облегчает взаимодействие «чердака» организации и «первого этажа» за счет усилий второго этажа. Это мост между бизнес-интересами «сверху» и конкретными планами и насущными проблемами снизу. Городить эту «пристройку» там, где организация до нее не доросла (по штату и орг. структуре), где царят неформальные взаимоотношения и именно они обеспечивают конкурентоспособность – неуместно.
Если в фирме мало сотрудников — проектный офис будет только мешать. На мой взгляд, строить PMO можно в компаниях со штатом от 50-70 человек (в зависимости от характера деятельности). При меньшем штате стоит ограничится неформальными коммуникациями (стартап-стайл), или положится на опыт и профессионализм отдельных менеджеров и топов (в маленьких фирмах они вполне могут «вытащить» все на себе, острота и накал проблем, как правило, это позволяют).
Необычное (неадекватное) доминирование одного этажа над другим – тоже симптом. Так, я долго время работал с компанией, где соотношение менеджеров проектов и команды приближалось к 1:1. Причина была в том, что высший менеджмент предпочитал решать проблемы «нанимая управленцев» а не команду исполнителей. Когда эти меры не дали эффекта (бардак на проектах не уходил), один из топов инициировал создание PMO. После короткого анализа, я обратил внимание «босса» на то, что в фирме банально не хватает исполнителей (отсюда и провалы сроков, и нереалистичные планы, и проблемы с качеством и провал отношений с клиентами) и PMO сам по себе такой проблемы не решит. Разговоры по PMO были отложены до укомплектования «первого этажа».
Проблема 2 – вовлечение власти
Проектный офис – это объединение «крутых менеджеров», которые что-то меняют в компании (практики, правила, подходы).
Любая компания – это сложившаяся система. И для того, чтобы в систему изменения привнести – нужна энергия. Много энергии.
Процитирую Дмитрия Коткина, работающего в сфере переговоров и коучинга (близко к тексту): «Хотите увидеть как система сопротивляется изменениям – попробуйте переставить в офисе пару столов и увидите, как яростно будут сопротивляться этому сотрудники, какие взвешенные и серьезные аргументы будут Вам приводить…».
Организационные перестройки – это куда более сильные изменения, чем перестановка мебели. Проектный офис пытается научить работать некоторых менеджеров (а также тим-лидеров и даже «топов»), навязать им правила, регламенты.
Помимо собственной энергии членов PMO обязательным слагаемым является «власть». Создаваемый PMO должен быть сразу наделен полномочиями, достаточными чтобы авторитетно общаться с разными этажами компании. Об этих полномочиях должно быть известно всем.
Но этого мало. У проектного офиса обязательно должен быть единомышленник «на чердаке». Топ-менеджер, который является «заказчиком» работ, а также (с подачи самого PMO) – их идеологом. Как не дать «остыть» высшему руководителю, все время заставлять его держать руку на пульсе офиса – отдельная тема. Однако если в высших эшелонах у вашего PMO нет статусного
покровителя – он обречен. Вы не сможете передвинуть в офисе диван, не потонув в бесконечных согласованиях и спорах.
Фирма, где я когда-то работал штатным менеджером (консалтинг, ИТ) – затеяла строительство PMO. Идеологом был генеральный директор. Он обсудил идею с двумя «замами» и собрал общее совещание, на котором поручил «лучшим 5 менеджерам» (среди которых и ваш покорный слуга) организовать офис.
Идея была встречена с энтузиазмом и через месяц первая версия «положения о проектном офисе» и еще целая охапка очень толковых документов, главы которых я использую до сих пор – были представлены для общего обсуждения. Генеральный директор полистал, кивнул и предложил подчиненным «самим разбираться». И тут понеслось!
Во-первых, 2 из 5 «лучших менеджеров» к тому моменту ушли в оппозицию (им не нравилось, что не все их идеи включены в драфт документа).
Во-вторых, «замы топа» вдруг осознали, что PMO в чем-то ограничит их полномочия и, фактически, станет еще одни «коллективным замом».
В третьих, тим-лмиды (которых попросили ознакомиться с документами) не увидели в них ничего, кроме бюрократии.
Совещание переросло в серию, серия – в сериал. Тонны корпоративной переписки, поток «встречных предложений», крупных и мелких придирок и никакой возможности сколько-нибудь продвинуться вперед. У «лучших ПМ-ов» не хватало наглости и полномочий перейти от обсуждений к внедрению, а генеральный директор, увидев сколько разногласий порождает его идея, самоустранился с беспроигрышным аргументом «я занят». Пакет документов так никогда и не был принят, а ведь воли одного топа было бы достаточно, чтобы запустить работу PMO хотя бы в одном из подразделений, хотя бы в «тестовом режиме». Именно его энергии не хватило всей системе, чтобы перестроиться.
Позднее я видел, и другие примеры как PMO оказывался мертворожденным, или, хуже того, беспомощным инвалидом – безнадежно застрявшим где-то на задворках второго этажа компании и не выполняющий ни одной из возложенных на него функций.
Поддержка, желательно первого или второго лица в компании (филиале, департаменте) – критичный фактор успеха.
Проблема 3 – топ менеджмент – хаотичный интуит
Продолжая тему власти – нужно сказать о еще одной особенности топ- менеджмента (особенно характерной для российских предпринимателей).
Проектный офис обязательно порождает какие-то правила. Строго говоря — он для того и создается. Помимо менеджеров проектов, одни из главных потребителей этих правил – как раз «топы».
Какие проекты запускать, а какие нет? Можно ли перекинуть ресурсы с одного стратегического проекта на другой, не менее стратегический? Эффективны ли наши руководители «второго этажа» и как это оценить? Проектный офис, как правило, претендует на участие в решении таких вопросов.
Вот тут-то и возникает «интуитская» специфика «топов». В российской компании собственник- руководитель – это, зачастую, человек прошедший огонь, и воду, и горнило различных испытаний (от претензий пожарной и налоговой до происков конкурентов и даже бандитов, если «топ» с большим стажем). Прошел успешно и, не в последнюю очередь благодаря своей интуиции, знанию жизни — людей и ситуаций. Типичный топ предполагает (порой, не без оснований), что окружающие его – подобными знаниями не обладают; а значит – им попросту нельзя доверять.
« — Вот если бы я в свое время на взял управление авторитарно, то нас в еще в 2001-м бы сожрали из корпорации X, а если бы в 2009 мы не вписались в тот ключевой проект для гос.сектора – не присутствовали бы сейчас в 10 регионах России и 6 странах ближнего зарубежья…» — типичная фраза такого руководителя. И наверняка он прав. И сам знает, что прав. Тут-то и кроется еще одна проблема в строительстве PMO.
Человек, привыкший брать ситуацию под контроль по велению сердца – сделает это вновь. И тогда его интуитивный менеджмент повернется к вам другой стороной.
«Рядовой» менеджер проектов подобных вещей со стороны босса либо не
замечает, либо на них не зацикливается. Однако те кто по долгу службы плотно взаимодействует с руководителями компаний – как правило отмечают повальное неумение российских директоров и собственников по-честному по-честному делегировать значимые полномочия (в том числе и проектному офису).
Один пример. Мы (менеджеры проектов и директора) разработали алгоритм отбора и запуска проектов, договорились как и когда будем проекты останавливать (дабы не ввергать фирму в убытки); сломали не одно копье в спорах о назначении ресурсов на проект. В итоге – получилась стройная и всеми признанная версия. На все это ушло около 3 месяцев, еще 2 месяца мы внедряли такую схему в отдельно взятом подразделении (чтобы потом учесть и тиражировать опыт на компанию).
Спустя 5 месяцев произошел всплеск интуиции Директора. Он, своей властью забрал чассть ресурсов с проекта подразделения, а также вменил ему «сделать быстренько короткое бизнес- обследование, с результатами через 2 недели; это срочно!».
«- Как так? Почему?»
«-Это важно, верьте мне. Я отвечаю за бизнес, я вижу, что открылась возможность и возникла необходимость… А в остальном все наши договоренности в силе, продолжаем, PMO быть, по- любому.»
В эту игру нельзя играть наполовину. Если ваша команда играет в футбол по правилам, а противник в решающий момент может бегать с мячом в руках и уносить его на трибуны – футбол не получается.
Аналогия не самая удачная — менеджер и «топ» не противники. Однако принцип тот же. PMO должен обладать полномочиями и иметь репутацию полноценного партнера в глазах обитателей «чердака» организации. И, будучи партнером – настаивать на систематическом применении правил, в этом его сила и основная полезность.
«Необузднанная интуиция» топов разрушает магию PMO, мешает ему.
Проблема 4 – саботаж
Говоря о проблемах власти и полномочиях PMO ни в коем случае нельзя надеяться, что покровительство, скажем, директора, само по себе решит все проблемы, «заткнет рот недовольным» и превратит противников в сторонников.
В той же самой компании, где генеральный директор отстранился от своего проектно-офисного детища, я наблюдал широчайший диапазон различных форм саботажа.
Коллеги «теряли регламенты», использовали не те версии,
доводили до абсурда постановку задач, превращали совещания в балаган а любой документ – в «светофор» из-за обилия выделенных цветом правок.
Нет смысла описывать, кто и как будет ставить палки в колеса PMO и пытать каленым железом его представителей. Важно, что это произойдет обязательно, по «законам природы», если не показать коллегам что новая управленческая структура может быть им полезной. А для этого нужно знать «где у коллег болит» (помните – аудит это непременный шаг во внедрении каждого PMO?).
На «первом этаже», обычно, хроническая нехватка ресурсов и перегруз задач, очень часто люди страдают от «мультитаскинга» (когда одного специалиста в течение дня 3-4 раза переключают между разными проектами). Проектный офис может помочь. Если это в ваших планах – обязательно обсуждайте.
Головная боль второго этажа – невыполнимые проекты (нереальные сроки, нехватка команды), «произвол» менеджера или заказчика и т.п. Проектные офисы создают, в том числе, и для наведения порядка тут.
Топам обычно не хватает контроля (работы на проекте – как в черном ящике, пока сдача контракта не поспеет – точно не узнаешь как идут дела), и квалифицированных менеджеров, способных разговаривать и с ними на одном языке.
Основной принцип – ищите больную «мозоль» на каждом этаже и у каждой «группы коллег». Думайте, как можете помочь от лица PMO – проверяйте и обсуждайте свои идеи. Но не обманывайте. Не «втюхивайте» офис как волшебную пилюлю (в современном бизнесе люди, как правило и умные и злопамятные) :)
Проблема 5 – слабый второй этаж
Одно из качеств «строителя PMO» – компетентность. Если кто-то берется за работу — предполагается, что он с ней справиться.
Основные работы ложатся на плечи второго этажа, а значит к нему – особые требования. На мой взгляд, менеджеры должны знать:
- как управлять единичными проектами (вообще)
- как управляют проектами в данной отрасли
- как управляют группами проектов (программами, портфелями)
- как оптимально провести аудит в данной компании и интерпретировать его результаты
- как спланировать переход из состояния «имеем сейчас» к «хотим в будущем»
- как в ходе такого перехода удержать ситуацию в коллективе под контролем
(коммуникации — лидерство, и прочее) и какие ключевые показатели контролировать. Без этих знаний PMO будет построен криво и может принести больше вреда, чем пользы.
Не важно, откуда эти знания добываются – опытны ли руководители проектов, или знания привносит внешний консультант, или PMO строится «по книжке». Успеха можно достичь самыми разными способами.
Однако гарантировано одно – пренебрежение этими компетенциями ни к чему хорошему не приведет.
Я сотрудничал с одной из компаний в качестве отраслевого эксперта. Случайно выяснилось, что у них провалилось внедрение PMO (проводили собственными силами). Я вызвался помочь, пригласил коллег.
Короткий аудит выявил, что предложения, которые продвигал проектный офис, отторгались на всех этажах. Временами, высшему руководству даже приходилось «свешивать ноги на первый этаж» и непосредственно разруливать конфликты и задачи.
Инициативы PMO были, скажем мягко, не слишком продуманными. Вместо «лечения мозолей» — усугубляли ситуацию (так, рядовых менеджеров заставили писать кратно больше отчетов, ничего не дав взамен; а команды первого этажа – насильственно и в сжатые сроки переводились на работу с одинаковыми таск-треккерами и системами контроля версий, без учета производственной специфики).
Мы затеяли короткое обучение – серию внутренних семинаров для «второго этажа» (и замаскировали в нем аудит сотрудников). Быстро выяснилось, что по стечению обстоятельств – все менеджеры обладают минимальным «боевым» опытом проектного управления. Никто из них не имел опыта в бизнес-анализе (часто встречается у менеджеров, выросших из бизнес- аналитиков).
Увы, в такой ситуации внедрение «самых светлых и правильных» методологий – не обойдется без перегибов и неверных трактовок. На втором этаже, в составе PMO обязательно нужен «играющий тренер». Хотя бы один. В приведенном примере мы так и поступили. Один из моих коллег был «оставлен в рабство» — его ввели в штат примерно на год, как руководителя портфелей (и по совместительству – главу PMO). На своих плечах он приподнял просевший потолок «второго этажа» и в течение года передавал свои знания и навыки коллегам, после чего смог покинуть компанию.
Проблема 6 – слабый первый этаж
Никто лучше конечных исполнителей не знает, как им строить свою работу.
В грамотно построенном PMO первый этаж получает достаточно «творческой свободы» наравне с ответственность за качество работ. Порой, удается достичь высокого уровня комфорта (менеджер не сильно «лезут» к команде, та не подводит руководство.
Но верно и обратное. Никакой PMO не даст эффекта, если «делать дело» некому. Без сильной команды «снизу» никакого эффекта от PMO получить невозможно.
В одном из приведенных примеров я говорил о компании, где соотношение менеджеров и исполнителей стремилось к 1. Какой бы ни была специфика таких проектов – ситуацию нельзя назвать нормальной.
К сожалению, на современном российском рынке (в ИТ-, консалтинге, по другим направлениям) – нехватка людей (и низкая квалификация имеющихся) – актуальная проблема. Общая рекомендация – не приниматься за строительство PMO или фиксировать недостижимость серьезных результатов с его помощью до тех пор, пока первый этаж не окажется достаточно заполнен.
Проблема 7 – бесконечное внедрение PMO
Внедрение PMO (если оно идет «как надо») – штука, радующая глаз и разум «заказчика» (т.е. высшего руководителя).
«-В кой-то веки собрались люди, наводят порядок в нашем бардаке».
Если же Вам еще и удается радовать «топа» результатами (а я верю, что взявшись за дело с умом вы обязательно добьетесь положительного результата), то возникает риск оказаться заложником собственной полезности.
Если Вы сторонний консультант – Вас не отпустят (придираясь по пустякам будут требовать продолжения за те же деньги), если штатный специалист – будьте
готовы, что у босса проснется аппетит. Все, что до сих пор не устраивало его в компании (внутреннее обучение, акаунт-менеджмент, организация корпоративов и т.п.) будет предложено сделать силами PMO. И не важно, как сильно это коррелирует с его предназначением.
Данная проблема – хорошо знакомое специалистам ИТ и консалтинга «разрастание хотелок». Лечится старым как мир способом – фиксацей договоренностей и управлением ожиданиями.
Увы, столь очевидный шаг, например, при создании программного обеспечения или строительстве дома почему-то не приходит в голову когда твой собственный босс предлагает «давай наведем порядок в проектах». К тому же, чтобы зафиксировать «хотелки» — нужно хорошо понимать, что и как предстоит построить (см. проблему 5).
Мои знакомые, работающие с органами государственной власти, уже четвертый год перестраивают проектный офис. Меняются их руководители (министры регионального уровня), трансформируются «хотелки и ожидания», а десятки специалистов (из администрации и частных компаний) раз за разом переписывают постановления, распоряжения и внутренне регламенты, попутно выполняя множество полезной работы во благо «будущего проектного офиса» и под обещание занять в нем видное место.
Коллеги не видят желания и возможности жестко настоять разумных целях и рамках PMO и лишь продолжают свой нелегкий труд. В такой ситуации, похоже, им никто не в силах помочь.
Заключение
Вспомним все перечисленные в данной статье проблемы и сведем их в короткий trouble-list. Это не исчерпывающий перечень всех возможных проблем, но некий короткий список неприятностей из собственного опыта. Рекомендую обратить на него внимание, при формировании формированию PMО.
Иван Селиховкин