Управление кризисными проектами.

Введение.

На написание данной статьи меня подтолкнуло неоднократное участие в проектах, которые находились в кризисном состоянии. Всегда, стараясь систематизировать хаос, приходил к одной и той же схеме, которую постараюсь здесь описать.

Как правило, на начальной стадии авторы идеи (спонсоры, заказчики) ставят цель будущего проекта, например, построить центр обработки данных или создать самолет. В дальнейшем, на основании сформулированной цели выполняются следующие этапы:

·        разработка технико-экономического обоснования проекта в целом;

·        разработка технического задания;

·        разработка эскизного проекта, содержащего анализ нескольких путей решения и выбор оптимального;

·        разработка рабочей документации, для осуществления проекта;

·        реализация проекта;

·        проведение испытаний или пробная эксплуатация;

·        внесение доработок и окончательная сдача проекта.

Перечисленная схема является общепринятой для проектов любых направлений, для технических объектов она подробно документирована в государственных стандартах[1].

Каждый из перечисленных этапов обязательно подразумевает наличие бюджета и  плана.

Естественно подключение специалиста в области управления проектами  на более ранних этапах повышает эффективность работы и вероятность положительного результата. Квалифицированный руководитель проекта (РП) не может довести проект до кризисного состояния, если он управлял проектом, начиная с этапа инициации или хотя бы с этапа планирования.

Однако в силу жизненных обстоятельств РП подключается к работе в середине проекта в момент, когда «стройка» идет уже полным ходом, но не все договора между подрядчиками и заказчиком заключены, а проектная документация в черновом варианте и не в полном объеме! Естественно, не идет речи об Уставе Проекта, Описании содержания проекта, Плане управления проектом, включая Организационную структуру проекта (OBS), Иерархическую структуру проекта (WBS), и прочих полезных документах, рекомендованных PMBOK[2] и другой литературой.

Крупная фирма-системный интегратор предлагает мне возглавить проект по инфраструктуре центра обработки данных, генеральный подрядчик уже ведет стройку, наша бригада уже прокладывает СКС, но проектной документации еще нет! Позже выясняется, что строительной документации тоже толком нет! Рабочие льют бетон, что называется по месту. В данной ситуации пришлось раскручивать довольно сложный клубок взаимосвязанных проблем.

Критериями того, что проект в кризисе, предлагаю считать следующее:

·        Отсутствие базового плана или Серьезное отставание от базового плана, на практике встречал от 1 месяца до полутора лет!

·        Бюджет не контролируется, использование методов Освоенного Объема невозможно, ввиду отсутствия или недостоверности данных

·        Не используется общая и обязательная для всех методология управления проектами, и нет автоматизации управления (ключевые фигуры даже не используют e-mail)

·        Команда проекта не обладает единой терминологией, а значит, не может общаться на одном языке между собой, со спонсорами проекта, членами управляющего комитета.

Список можно продолжать и дальше.

Причины возникновения кризиса.

Отсутствие дисциплины. В данном случае под дисциплиной понимается не только исполнение указаний, распоряжений и других зафиксированных «правил игры» таких как стандарты предприятий (СТП), договора, приказы, руководства и т.п., но и исполнение собственных обещаний. Отсутствие дисциплины порой граничит с саботажем.

Проигнорирован или формально выполнен этап планирования. Т.е. планы и остальные документы по управлению проектом могут существовать, но не иметь ничего общего с реальной жизнью.

Отсутствуют документы, регламентирующие обязанности. Имеется ввиду, что в рамках предприятия, отсутствуют должностные инструкции и положения о подразделениях. Также у руководства отсутствует понимание кто и чем должен заниматься.

Отсутствует план коммуникаций. Часто работники не знают, где хранится информация и  к кому и по какому вопросу можно обращаться. Испытывается информационный голод.

Неквалифицированный управленческий персонал. Руководители подразделений имеют серьезный технический опыт и являются специалистами в технической области, но не обладают знаниями в области общего менеджмента и в области управления проектами. Были моменты, когда приходилось объяснять основы управления проектами руководителю проекта от генерального подрядчика.

Жесткий командный принцип руководств, при котором полностью отсутствует обратная связь. Руководители не хотят прислушиваться к рекомендациям и просьбам снизу.

Полностью или частично отсутствует контроль исполнения поручений. Например, на совещании руководитель эмоционально раздает всем задания, приказы, отчитывает за общее отставание. Совещание закончилось. 90% заданий не то что не выполнено в срок, они вообще не выполнены. Руководитель про многие вещи забывает. На следующем совещание картина повторяется.

Боязнь ответственности, как правило, является следствием отсутствия документов, регламентирующих обязанности сотрудников и функции подразделений. В этом случае, никто из руководителей среднего, а порой и высшего звена, не готов взять на себя ответственность. Любой документ, независимо от его важности, исписан подписями, все требуют визы своих коллег или служб. Встречал акты приемки работ с более чем десятком виз. Ответственного за ту или иную задачу найти невозможно.

Отсутствует командный дух. Большое количество внутренних конфликтов. Конфликты на эмоционально уровне, конфликты интересов.

Естественно, существуют и другие причины, характерные для конкретного проекта или предприятия.

Подходы к разрешению проблем.

Для наглядности на рисунке ниже изображен общий подход к разрешению кризисных ситуаций.

Шаг 1. Осознание.

Итак, вы попали в ситуацию, когда вам нужно управлять проектом, который уже находится на стадии исполнения. Жизнь показывает, что первые недели работы над проектом вы не подозреваете, что все так плохо. Обычно вас берут на работу со словами, что есть небольшие проблемы и легкое отставание. Первые недели, пока будете изучать состояние дел, вы, возможно, тоже не поймете всей критичности ситуации. Окончательное понимание придет примерно через месяц. Вы спросите, почему так долго – потому что нет реальной «исторической» информации по проекту, предыдущие шаги не документированы. Информация от команды проекта противоречива.

Больше всего проблем на данном этапе я испытал на одном «полугосударственном» предприятии авиационной промышленности, где была большая проблема с объективной информацией по проектам. В силу массы причин информация собиралась с большим трудом. Кто-то не хотел делиться информацией, где-то она отсутствовала.

Шаг 2. Подготовка.

Попытайтесь найти людей на всех уровнях управления и исполнения, на которых можно опираться в работе, найдите единомышленников. Также нужно определить  «врагов» - это тоже необходимо. Не думайте, что это легкая задача, может оказаться так, что на первый взгляд человек, готовый вам помочь, несет в себе скрытую угрозу.

На первых этапах основная польза от «друзей» - это объективная информация по проекту, по политической ситуации на предприятии. Параллельно со сбором информации обсуждайте с коллегами ваши соображения и идеи по исправлению ситуации. Обзаводитесь «друзьями». Будьте более открытыми, интересуйтесь ситуацией, техническими проблемами – это повысит лояльность по отношению к вам.

Одна из психологических проблем - это то, что люди не любят признавать своих ошибок или своей некомпетентности в каких-либо вопросах, тем более перед человеком, с которым едва знакомы и чья компетентность под сомнением. Тут вам нужно будет проявить незаурядные способности политика и психолога в одном лице. Ни в коем случае не стоит заявлять с первых недель работы, что «вы тут все дураки» и провалили проект. Наоборот, надо указывать на их компетентность в технической сфере. На данном этапе вашей работы я рекомендую вам лишний раз пролистать литературу по психологии, например М.Е.Литвака[3]. Вы будете работать во враждебной атмосфере и понятие «стрессоустойчивость» не пустые слова.

Еще одна проблема, которая вас поджидает на первых порах – это получение прав на управление проектом. Данная мысль звучит и странно и смешно – ведь вы Руководитель Проекта! Реалии жизни таковы, что высшему руководству неинтересно, кому и какие права делегированы, они думают, что наняли профессионала и все проблемы по проекту разрешатся сами собой, без их участия. За делегирование прав придется еще побороться. Был случай, когда я в течении двух недель пытался объяснить руководству, что я не могу давать указания сотруднику другой организации (Итальянский партнер). Естественно, имея хорошие отношения с сотрудниками данной организации, я мог добиться от них выполнения небольших поручений, но полномасштабных работ проводить на таком уровне невозможно. Пришлось использовать политическую многоходовую операцию, чтобы перевести отношения в формальное русло.

Шаг 3. Действие.

По мере того, как вы разобрались в ситуации и поняли, на кого можно опереться, начинайте действовать, возможно, не имея формальных прав. Действовать нужно осторожно, ни в коем случае не старайтесь устроить революцию. Хотя так хочется форсировать работы по исправлению ситуации, и вы как профессионал понимаете, что время – основной фактор.

Полномасштабные действия по исправлению ситуации возможны только после того, как вы добились понимания у руководителя(лей) высшего звена.

Первое, на что следует обратить внимание – это исполнительская дисциплина. Обратите внимание высшего руководителя, что это ключевой фактор на данном этапе. А главное, что повышать исполнительскую дисциплину нужно с себя. Нужно мягко намекнуть руководству, что контроль данных им (руководством) поручений входит в их должностные обязанности. Контролируйте высшее руководство, чтобы оно выполняло свои функции.

Опираясь на ваших «друзей», постарайтесь сформировать для себя организационную структуру проекта (OBS). Сделать это будет не так просто, т.к. члены команды проекта не смогут четко сформулировать зону своей ответственности, а также логические связи между участниками проекта. Процесс будет долгим и итерационным. Параллельно члены команды сами зададутся вопросом, а чем они тут занимаются и за что отвечают. Старайтесь создавать OBS в максимально красивой, с точки зрения дизайна, форме и как можно нагляднее и проще. Данный психологический трюк позволит вам заслужить больше доверия в команде проекта. Я обычно делаю OBS в MS Excel на двух листах. На одном в таблице свожу информацию по персоналу (ФИО, организация, должность, роль в проекте, телефоны, e-mail и пр.), на другом в графическом виде изображаю организационную структуру.

Старайтесь не использовать сложной терминологии. Постоянно держите в голове, что привычные для вас термины, например «Проект» или «Руководитель проекта», для ваших коллег имеет совсем другое значение! Со временем ситуация поменяется, но не сразу.

Двигаемся дальше. Создаем Иерархическую Структуру Работ (WBS). Тут тоже не стоит забывать про красоту, и чтобы произвести впечатление, я обычно использую MS Project, строю красивые диаграммы Ганта. Здесь вы уже можете во многом положиться на квалифицированных, в техническом плане, руководителей. Для начала стоит совместно более детально описать цель проекта, договориться о едином понимании, как должен выглядеть конечный продукт проекта. Не нужно бояться погрузиться в технические детали, ваш интерес к технической стороне проекта увеличит лояльность к вам со стороны руководителей подразделений и других членов проектной команды. Детальное планирование стоит делать только краткосрочное, 2-3 недели, не больше. Если вы дошли в вашей работе до данного момента, разрешите поздравить вас, вы прошли самую сложную часть пути! Маховик проекта, со скрипом, но начал вращаться правильным образом.

Если не предусмотрено планом, нужно обратиться к высшему руководству с просьбой о необходимости организовать курс обучения для руководителей подразделений основам управления проектами.

Если проект находится на начальной стадии, а в организации нет специалистов по управлению проектами, подведите к мысли высшее руководство взять их со стороны, нанять профессионалов или воспользоваться услугами по аутсорсингу.

Шаг 4. Анализ.

Старайтесь регулярно анализировать, что изменилось как в политическом и моральном плане, так и в целом по проекту и на предприятии. Возможна ситуация, что ваши труды прошли даром и нужно начинать заново.

К этому моменту вы уже сможете делать реалистичные прогнозы по срокам, а возможно, и по бюджету проекта. Но поверьте, что высшее руководство не захочет вас слушать, боюсь, что даже масса доводов с вашей стороны не снимут с них «розовые очки». Так что делайте аналитику по проекту исключительно для себя и руководителей среднего звена. Будьте осторожны с этими данными, т.к. это может подломить моральный дух проектной команды.

Конкретный пример из практики: меня взяли как специалиста для организации системы проектного управления (КСУП). Но после 2-х месяцев работы в этом направлении я пришел к выводу, что наиболее важно на данный момент - это «тушение пожаров» по уже запущенным проектам, а не запуск нового проекта, т.е организация КСУП,- еще 2 недели ушло на то, чтобы убедить руководство в этом.

Ключевые факторы успеха:

Факторы успеха я только коротко обозначу, т.к. по каждому из факторов можно написать отдельную статью:

·        Поддержка руководства

·        Нацеленность на будущее, четкое понимание целей

·        Гибкость подходов, гибкая организация

·        Дисциплина

·        Коммуникации, общение в реальном времени

·        Честность, доступность информации

·        Мотивация сотрудников

·        Командный дух

Заключение

В заключении хотелось бы процитировать Л.Толстого: "Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему". К проектам, которые протекают успешно и к проектам, которые находятся в кризисе, данная цитата подходит на 100%. Таким образом, не может существовать стандартного подхода к вытягиванию проекта из кризиса. Сказать можно одно - личностные качества РП играют не последнюю роль. РП должен уметь систематизировать хаос, быть политиком и коммуникатором, желательно знать предметную область.

Список литературы.



[1]

·        ГОСТ Р ИСО 9001-2001,

·        ГОСТ 2.103-68

·        ГОСТ 34.601-90, 34.602-89

·        ГОСТ Р ИСО/МЭК 12207-99

[2] PMI PMBOK® 2004 Guide Third Edition

[3] М.Е.Литвак “Если хочешь быть счастливым” 2005г.