В июне 2010 года я разместил в этом блоге сообщение О вреде проектного управления, а чуть позже расширил тему в кратком обзоре гартнеровской статьи Projects Today, “Change Operations” Tomorrow. По законам жанра рано или поздно должна была появиться и сегодняшняя заметка. И дело совсем не в том, что я изменил свое отношение к корпоративным проектам. Пренебрежительное отношение к диаграммам Ганта, регулярному подкручиванию процента выполнения работ, наукообразным рассуждениям о методе критического пути и инструментам, типа MS Project, предназначенным для отображения фиктивной отчетности по проектам у меня сохранилось. Точно так же сохранилось убеждение в полезности средств организации совместной деятельности, общего информационного пространства, трекеров и событийных лент. Но речь совсем не о том. Я хочу рассмотреть проектный офис как некоторый социальный институт внутри компании, форму организации совместной деятельности людей, обладающей признаком самовоспроизводимости.
Говоря словами Википедии:
Социальный институт — это механизм, обеспечивающий набор постоянно повторяющихся и воспроизводящихся социальных отношений и социальных практик людей. Э. Дюркгейм образно называл социальные институты «фабриками воспроизводства общественных отношений». Эти механизмы опираются как на кодифицированные своды законов, так и на нетематизированные правила (неформализованные «скрытые», обнаруживающиеся при их нарушении), социальные нормы, ценности и идеалы
Введение проектного управления это прежде всего институциализация определенных правил совместной деятельности, связанных с развитием и управлением изменениями в компании. Установление правил того, как мы тратим бюджет развития, распределяем между задачами наш экспертный ресурс, реализуем те или иные политики. Многие виды деятельности, такие как безопасность или архитектура вряд ли смогут существовать вне контекста такого института. Этим просто никто не станет заниматься. Многие стратегические установки так же останутся за бортом.
Говоря об институте следует понимать, что речь идет не только об определенных ограничениях. Но будет неверным считать, что задача института заключается в упрощении и повышении эффективности тех или иных действий. Институт – это всегда сочетание одного и другого. Он предоставляет некоторые дополнительные возможности тем, кто соблюдает его правила. Речь идет о своего рода контракте: правильное поведение поощряется, а неправильное наказывается. Институт не является ни плохим, ни хорошим. Это просто способ организации власти. А единственное, о чем заботиться власть – увеличение сферы собственного влияния. Институт поощряет одни стереотипы поведения и наказывает за другие. Речь не обязательно о каком-то реальном наказании. Это может быть прямая или завуалированная угроза наказания – интуитивное ощущение субъектом, что вслед за нежелательным поведением наступит что-то плохое: бедность, скитания под холодным осенним дождем, насмешки бывших друзей и злорадство вечных врагов.
У любого института есть несколько полезных и несколько вредных черт. К полезным следует отнести упрощение механизма принятия решений. На недавнем вебинаре о процессе проектирования ИТ-решений, мы говорили о теории ограниченной рациональности нобелевского лауреата Герберта Саймона – модели принятия решений, изложенной в книжке «Административное поведение» (Administrative Behavior, 1947) и развитой потом в «Модели человека» (Models of Man, 1957). Согласно этой теории, при выборе варианта действий, человек не производит полный анализ возможных альтернатив с целью оптимизации собственной выгоды. Для этого у нет ни полной информации, ни достаточного вычислительного ресурса. Вместо этого для принятия решений мы проводим серию случайных испытаний (присматриваемся к возможным вариантам действий) и затем формулируем для себя некоторый набор критериев выбора, определяем от каких вариантов мы откажемся наверняка, а какие опции постараемся получить. Но даже такой выбор требует определенных усилий. Наличие институциализированных правил, рекомендаций и предписаний позволяет нам осуществить рекомендуемый ими выбор, проще говоря согласиться с тем что «правильно» и какого-либо выбора вообще не осуществлять. Главной же проблемой института является его косность и невосприимчивость к инновациям. Задача любого института сохранения status quo в механизмах и практиках принятия решений в сочетании с увеличением зоны собственного влияния. Какие уж тут инновации. Так что, дело вовсе не в медлительности и нерасторопности программистов, которых следует лечить огнем и мечем agile-ом. На процедурах бюджетирования, приоритезации задач, проведении закупочных мероприятий вы потеряете намного больше времени и сил. Все дело в правилах и практики принятия решений. Об этом мы подробней поговорим на следующем вебинаре: Фундамент цифровых сервисов, а сейчас вернемся к механикам института проектного офиса.
Вообще говоря, в организации может быть множество внутренних институтов, которые формируются финансовым блоком, закупками, управлением персонала или ИТ отделом. Внедрение процессов управления ИТ услугами следует в первую очередь рассматривать именно как построение института – системы взаимоотношений в деле распределения благ информационных технологий. Задача такого института не только в оптимизации деятельности ИТ или удовлетворении непрерывно увеличивающихся потребностей пользователей. Главная задача в распространении убеждения, что следование правилам позволяет получить наибольший объем услуг наивысшего качества, а нарушение правил – к проблемам и неприятностям. Причем убеждение в данном случае не обязано совпадать с реальным положением дел. Об этом почему-то не пишут в книжках по ИТ-сервисам и не рассказывают на курсах по ITIL. Я готов восполнить этот пробел 🙂
Проектный офис находится в жесткой конкуренции с другими институтами. HR урезает ему штатное расписание и сокращает фонд оплаты труда. Финансисты постоянно стремятся втянуть проектные бюджеты в свои правила игры (это когда раз в год, мы в сентябре собираем заявки и до марта следующего года их урезаем в несколько итераций, а оставшиеся девять месяцев дрючим организацию за трехмесячное отставание в освоении бюджета). Закупки тоже вносят свою посильную лепту в увеличение сроков работ. Ну и естественно вспомогательные функции пытаются забраться на паровоз проектного управления. Не буду перечислять всех, остановлюсь только на ИТ-архитекторах. Эти нехорошие люди обязательно добьются того, чтоб каждый проект с ИТ составляющей проходил архитектурный надзор. Даже архитектурный комитет создадут для пропаганды своих ритуалов и верований. Астрологические картинки нарисуют, назвав их целевой архитектурой и будут на полном серьезе утверждать, что каждый проект этим картинкам ни разу не соответствует. Особо резвых отправят в трехлетний тендер покупать промышленное решение или заставят реализовывать ИТ-составляющую проекта в какой-нибудь допотопной системе из прошлого века. В общем с ними лучше не ссориться. В благодарность от них можно получить замысловатые картинки для презентации на проектном комитете и верхнеуровневый обзор решения для создания структуры работ проекта.
Но вернемся к проектному офису. Его принципиальное отличие от других институтов – кросс-функциональность. Он не принадлежит ни одной конкретной функции, что является бесспорным преимуществом и позволяет ему занять одно из центральных мест в организации(если тому не помешает расклад политических сил). В общем честь вам и хвала корпоративные проектные менеджеры. Мы готовы не глумиться над вашими дурацкими планами и даже раз в неделю инкрементить процент выполнения задач в ваших фиктивных отчетах. Только не давайте компаниям сорваться в пучину хаоса
RE “Его принципиальное отличие от других институтов – кросс-функциональность.” except a quality unit, an ethics unit, an organisational unit (in some countries), an independent control unit, an enterprise architecture function (sometimes) and a security unit (sometimes).