Часть 1. Стоит оно того?
На определенном этапе большинство руководителей проектов получают предложение войти в кризисный проект. Вас попросят спасти провальный проект или восстановить проект, столкнувшийся с серьезными проблемами. Ваша роль может заключаться в диагностике здоровья проекта, но вы можете и возглавить попытку спасения. Эта статья состоит из трех частей и в ней обсуждаются некоторые вопросы, подлежащие рассмотрению перед стартом, порядок проведения диагностики и мероприятия по восстановлению.
Перед началом необходимо выяснить, какие у вас полномочия. Они могут варьироваться от ревизии и отчета до "разобраться с проблемой, пленных не брать".
Множество попыток спасения оканчивается неудачей из-за того, что в начале нет четкого понимания ожиданий. И даже хуже того - ожидания смешаны. Чтобы проиллюстрировать данный пункт, давайте рассмотрим более конкретный пример. Помощь при стихийных бедствиях может быть совершенно неэффективна, когда несколько организаций и служб пытаются делать одни и те же вещи, либо не четко определены зоны ответственности. Образцом для организации помощи при стихийных бедствиях является центральная европейская служба, объединяющая различные агентства, в обязанности которой входит определение плана действий и назначения ответственных агентств, наилучшим образом оснащенных для выполнения поставленных задач.
Если вас попросили войти в проект, вам должно быть понятно, чего от вас ждут. Эти ожидания должны быть документированы и согласованы со спонсором или другим ответственным лицом. Этот документ должен быть доступен всем заинтересованным лицам, чтобы все понимали вашу роль и что вы собираетесь делать.
Содержание мандата (документа описывающего полномочия)
Мандат должен описывать следующие моменты:
Ваши полномочия по доступу к информации. Например, должны ли вы иметь доступ к конфиденциальной и всей финансовой информации?
Конфиденциальность информаторов. Обязаны ли вы передавать всю собранную информацию руководству или она может предоставляться на условиях анонимности?
Уровень кооперации, который ожидается от участников. Например, обязаны ли участники оперативно принимать приглашение на встречу для обсуждения состояния проекта с вами? Вполне возможно, что в интересах определенных людей быть слишком занятыми для разговоров с вами месяц-другой.
Какая поддержка будет оказана. Кто поможет вам собрать информацию и выполнять административную работу?
Ожидаемый результат. От вас требуется отчет по состоянию проекта, рекомендации, решения и т.д.
Какой у вас контроль над результатами работы. Я видел, как множество ревизионных отчетов переписывались для покрытия виновных. Я всегда настаиваю на том, чтобы мой отчет оставался таким, каким я его написал. Обычно это означает, что отчет идет к спонсору, и уже он решает, насколько широко этот отчет распространяется. Если подготавливается еще и отредактированная версия, я настаиваю, чтобы из такой версии была удалена закрытая информация (финансовые показатели, условия контрактов). Я не участвую в подмене фактов, отраженных в отчете для защиты определенных людей. Если организация настаивает на переписывании отчета, я требую удаления своего имени из документа.
Ограничения. Например, можно ли менять персонал? Можно ли изменить содержание? Может ли проект быть прекращен?
Сроки. Какие будут контрольные точки проведения ревизии и разработки плана мероприятий?
Промежуточные задачи. Редко получается получить представление о проекте за несколько часов и даже за несколько дней. Для завершения отчета может потребоваться несколько недель. Что происходит в это время в проекте? Продолжается ли работа, должны ли люди быть перекинуты на другие работы, пока отчет не будет подготовлен?
Следующие шаги
Один мой коллега, которого часто просят провести диагностику проекта, сказал, что обычно после того, как он указывает на проблему, его обычно просят исправить ее. У меня был такой же опыт, несмотря на то, что изначально мы договаривались только на подготовку отчета. Ответьте себе и заказчику на вопрос, готовы ли вы или нет возглавить спасательную операцию. Четко обозначьте свою позицию спонсору в самом начале, особенно если вы не заинтересованы. Самый худший вариант, по которому могут пойти события - это предложение вам огромной компенсации за "передумать", в случае, если заказчик будет впечатлен вашей работой.
Влияние на карьеру
Проведение такой ревизии может иметь цену - как эмоциональную, так и для карьеры. Несколько лет назад ко мне обратился клиент, с которым у меня был бизнес ранее, меня попросили провести ревизию одного проекта. Вскрывшиеся факты были были очень критичными по многим аспектам деятельности компании, включая руководителя проекта и поддержки, которую он получал от топ-менеджмента. Результаты ревизии никто не оспаривал, но они, тем не менее, были болезненными для множества людей, которые надеялись на то, что факты заметут под ковер. К их сожалению, я не прислушался. Результат - они ко мне больше не звонили.
Сожалею ли я об этом? Не особо. Я начинал ревизию с пониманием того, что результат может быть нелицеприятным и что есть риск быть гонцом с плохими новостями с очевидными последствиями. По крайней мере я могу сказать, что этот отчет - это мое честное мнение о данной организации. В частности, я не хочу писать отчет, перемещающий вину с неспособности участников управлять проектом на мою неспособность анализировать ситуацию. Подлоги имеют тенденцию возвращаться к вам бумерангом по прошествии времени.
Часто организации ищут козла отпущения. Минимум, на который они рассчитывают, это найти человека, которого можно обвинить в текущих проблемах и зачастую это стрелочник, а не истинный виновник.
Эмоциональный ущерб
Я упомянул эмоциональный ущерб. Если ваши близкие друзья связаны с проектом, и окажется, что они виноваты в какой-либо оплошности? Готовы ли вы рискнуть вашей дружбой ради правды? В самом начале моей карьеры я работал в одной организации, и там проходила ревизия работы подразделения. В отчете на десятки страниц была одна строка, которая стала точкой в карьере одного руководителя. Проводивший ревизию человек был близким другом руководителя подразделения. Он, наверное, боролся с собой оставить или нет эту строку в отчете на протяжении нескольких дней. Фраза была примерно такой: "Реализованные мероприятия не соответствовали утвержденному годовому плану из-за недостаточного управленческого надзора за деятельностью отдела".
Руководитель подразделения был перемещен на должность с примерно таким же названием, но по значимости даже близко не стоящей к предыдущей. Это было во времена, когда увольнения по сокращению штатов было последней мерой, а не частью нормального бизнес-цикла. С точки зрения корпорации это, возможно, было правильным решением, но эти двое никогда больше не разговаривали.
Стиль управления
Спасательная операция не обязательно сопровождается демократическим стилем принятия решений. Когда корабль тонет, никто не собирает комитет по распределению спасательных шлюпок и определению способов латания пробоин. Человек, который призывнее всех кричит "За мной!" скорее всего и будет лидером. Кто-нибудь, кто берет командование на себя и возглавляет передний край борьбы, является идеальным кандидатом в большинстве ситуаций.
Но есть и исключения. Если проблемы возникли из-за разрушенных отношений и нарушенной коммуникации, подход, основанный на совместном принятии решений может оказаться наиболее эффективным. Перед стартом вы должны понимать, хотя бы на самом высоком уровне, в чем корень проблемы.
Необходимые навыки
Для проведения диагностики требуются более выраженные по сравнению с обычными руководителями проектов навыки. Вы должны спросить себя, а достаточно ли у вас способностей для того, чтобы согласиться на эту работу. Как кто-то сказал мне однажды: "Достаточно сложно даже просто собрать команду проекта, но намного хуже комплектовать команду для проведения ревизии. Если они потерялись, у них все еще есть шанс найти дорогу домой, но если ты укажешь им дорогу в неправильном направлении, то они точно потеряны навсегда".
Навыки управления проектами
Вряд ли есть необходимость указывать, что человек, который проводит ревизию скорее всего должен быть очень опытным руководителем проектов. Он должен обладать как теоретическими знаниями, так и практическими навыками, чтобы понимать, куда и на что смотреть в проекте. Он должен иметь четкое представление об инфраструктуре проекта. Инфраструктура проекта - это все поддерживающие организацию инструменты, процессы и шаблоны.
Навыки проведения интервью
Если что-то пошло не так, то скорее всего, кто-то захочет это скрыть. Еще более вероятно, что некоторые вопросы люди захотят пропустить мимо ушей и уж тем более не захотят на них отвечать. Ревизор должен быть искусен в извлечении информации и уметь проводить перекрестные проверки. Вот некоторые примеры вопросов, которые вы, возможно, захотите добавить в свой репертуар.
Это мнение или факт?
Как это можно подтвердить?
Какая документация необходима для понимания проекта?
Кто хорошо работал в проекте? Вы ничего не сказали про Х?
Когда вы впервые подумали, что проект срывается?
Какие значительные трудности были между проектом и бизнесом?
Насколько заинтересован был Х в проекте в самом его начале?
Сильно ли менялся результат/содержание/сроки?
Что надо было бы делать по другому?
Что нужно сделать для воскрешения проекта?
Уверен ли спонсор/управляющий комитет/руководитель проекта в большинстве людей?
Что изменилось в окружении с начала проекта?
Нужно ли прекратить проект?
Навыки ведения бизнеса
Множество проектов ломаются из-за несоответствия целей между проектной командой и бизнесом. Если это ИТ проект, и ревизор смотрит на него со стороны ИТ, ревизия может не получить поддержку со стороны бизнеса. Ревизор должен быть отстранен от обоих лагерей, и зачастую именно поэтому этим человеком чаще всего является консультант.
Навыки письменной речи
Критичным является навык четкого и сжатого изложения информации в письменном виде. Отчеты такого рода - основные кандидаты на творческое переосмысление и неверную интерпретацию. Автор обязан однозначно указать на факты и не оставлять никакой возможности для неверной интерпретации.
Смелость
Смотреть на проект в кризисе - занятие не для слабохарактерных. Спросите себя перед тем, как согласиться: "Если я решу, что проект должен быть остановлен, хватит ли мне смелости донести эту точку зрения до спонсора или того, кто будет принимать решение?"
Вы скорее всего столкнетесь со всеми видами противостояния людей, у которых есть интересы в проекте либо просто по причине личной привязанности и высоких вложений своих сил в проект. Возможно, вам потребуется твердо выстаивать против нажима различных сил. Если вы не верите, что сможете это сделать, лучше откажитесь возглавить попытку восстановления, а возможно и от проведения ревизии.
Заключение
Может показаться, что слишком много внимания уделено подготовке к спасательной операции, но я надеюсь, что вы увидите, что такого рода предприятия не стоит воспринимать беззаботно. Для определения того, можно ли спасти проект, требуются определенный набор навыков. В следующей части статьи будет описание того, что же на самом деле надо сделать.
Часть 2. Подготовка
Обзор
Это вторая статья по управлению кризисными проектами. В ней описано, как проводить диагностику проекта для определения, что же конкретно произошло в проблемном проекте. Также приведен чек-лист, на что нужно смотреть в ходе обычной диагностики или пересмотра проекта.
Структура
Меньше всего при проведении диагностики вы захотите ходить вокруг да около и тыкаться куда попало. Это завершится примерно с тем же успехом, как покупка первого попавшегося подержанного автомобиля. Если вы просто попинаете шины и посмотрите уровень масла, заглянете под капот, то вряд ли при покупке у вас будет полная уверенность в том, что автомобиль стоит своих денег. А если вы проведете профессиональную проверку - подвеску, тормоза, двигатель, коробку передач, чехлы, покраску и т.д. - вы скорее всего определите неисправности, которые надо будет устранить.
Для того, чтобы провести оценку статуса проекта, вам нужна определенная структура работы. PMBOK дает неплохую основу для подхода. Есть еще и другие аспекты, требующие рассмотрения, но приведенный здесь чек-лист обеспечит вам основными вопросами и укажет на области обследования для того, чтобы понять, что же нужно исправить.
Вопросы, приведенные ниже, логически сгруппированы по областям обследования. У всех организаций будет своя специфика, и вопросы, посвященные ей, добавятся в этот список.
Содержание
Содержание было хорошо определено на старте проекта?
Есть ли процесс по изменению содержания?
Есть ли отклонения, не прошедшие через этот процесс?
Может ли команда определить суммарное влияние на сроки и стоимость по всем таким отклонениям?
Отслеживается ли факт против плана/оценок для отклонений?
Был ли план проекта изменен, чтобы снабдить проект необходимыми ресурсами для реализации изменений?
Стоимость
Есть ли система отслеживания затрат?
Отслеживаются ли затраты?
Есть ли затраты, которые отслеживаются неправильно?
Вовремя ли отслеживаются затраты?
Сверяются ли затраты с корпоративным планом счетов?
Есть ли прогнозы по стоимости проекта на момент его завершения?
Все отклонения по стоимости одобрены в письменном виде?
Сроки
Есть ли достаточно подробное расписание проекта?
Оно актуальное?
Оно соответствует текущему содержанию проекта?
Используются ли контрольные точки для отслеживания хода реализации?
Достаточное ли количество контрольных точек по ходу проекта для отслеживания проекта или в расписании есть недели, когда контроль отсутствует?
Отслеживаются ли трудозатраты через систему табелирования и учета рабочего времени?
Существует ли устойчивый и реалистичный план для оставшейся работы?
Качество
Есть ли план управления качеством?
Предметы поставки принимаются согласно плану по качеству?
Какие действия происходят после аудита качества и отслеживается ли их выполнение?
План проекта предусматривает время на переработку и устранение дефектов по результатам аудита качества?
План приемки и тестирования реалистичен (есть стратегия тестирования, план и тест-кейсы)?
Правильные ли люди выделены для проведения тестирования и приемки?
Тестирование и приемка включает в себя систему, ее характеристики и интерфейсы?
Ресурсы
Ресурсов достаточно?
Они правильные?
Они в состоянии работать над проектом достаточное время?
Есть ли чувство хорошего взаимодействия в проекте?
Команда управляется хорошо?
Ресурсы используются эффективно?
Хороший ли рабочий настрой в команде проекта?
Коммуникация
Есть ли план по коммуникациям?
Он реализуется?
Как определялись ключевые стейкхолдеры?
Все ли ключевые стейкхолдеры определены?
Чувствуют ли стейкхолдеры, что их держат в курсе?
Есть ли общие области в коммуникации, которые вызывают опасения?
Приведет ли проект к изменениям в организации и есть ли план по управлению ожиданиями?
План реализуется и ожидания отслеживаются?
Закупки
Используются ли внешние ресурсы?
Есть ли актуальные договоры, по которым работают внешние ресурсы, до завершения проекта?
Есть ли план по использованию этих ресурсов после окончания плановой длительности проекта, в случае необходимости?
Требует ли проект закупки оборудования, установок, программного обеспечения, и если да, то есть ли план по проведению переговоров по договору?
Уровни и полномочия по согласованию договоров и сроки подписания понятны и включены в план проекта?
Риски
Есть ли актуальный план по управлению рисками?
Стейкхолдеры были привлечены к разработке плана?
Стратегии уклонения существуют и отслеживаются?
Проводится ли регулярный аудит рисков?
Есть ли журнал проблем?
Решение проблем отслеживается до полного разрешения?
Процесс эскалации проблем существует? Он работает?
Мероприятия по сдерживанию
Есть ли план по сдерживанию последствий, если реализация не укладывается в сроки?
План сдерживания подписан всеми заинтересованными сторонами?
План испытан?
Последствия реализации сдерживающих мероприятий понятны руководству?
Какие сроки по реализации плана сдерживающих мероприятий?
В течение какого срока будет действовать план сдерживания? Что случится потом?
Эффекты
Какие эффекты были определены на старте проекта?
Они пересматривались недавно?
Они все еще актуальны?
Были ли идентифицированы новые эффекты и включены ли они в результат проекта?
Измеряются ли и будут ли измеряться эффекты?
Определены ли ответственные за реализацию и использование эффектов?
Бизнес-процессы
Повлияет ли проект на бизнес-процессы?
Рассчитывает ли на них бизнес?
Когда и как они будут изменены?
Мы знаем, что они заработают?
Какое влияние они окажут за пределами компании?
Эти изменения запланированы?
Обучение
Есть ли план обучения?
Заложено ли время на производство обучающих материалов?
Тренеры определены?
Персонал будет доступен для обучения?
Есть ли план проведения пилотного обучения?
Реализация
Есть ли план реализации проекта по месту (предполагая, что проект идет по плану)?
Поддержка будет оказываться во время и после запуска?
Кто даст разрешение на ‘go live’?
Есть ли критерии ‘go live’?
Если реализация подразумевает преобразование данных, известно ли состояние этих данных?
Требуют ли данные работы с ними и был ли этот процесс протестирован?
Подотчетность
Определены ли контрольные точки, в которых управляющая группа определит, соответствует проект корпоративным стандартам или нет? Конечно, ревизия является такой точкой, но обычно проект должен пройти один или несколько ревизионных контрольных точек, в которых должны быть выполнены определенные критерии.
У команды проекта есть все необходимые инструменты, навыки и процессы для успешной реализации проекта?
Кто отслеживает комплаенс (соответствие внутренним корпоративным нормам, регламентам, этике и т.п.)?
Если у компании есть методология, придерживается ли ее команда проекта?
Роли и ответственность
Четко ли обозначены зоны ответственности?
Достаточно ли точно они отражают то, что происходит по факту?
Бизнес обеспечивает необходимый уровень поддержки?
Достаточный ли уровень поддержки оказывает руководство?
Есть ли какие-то участки работы, которые не описаны в ролях и ответственности?
Документация
Хранится ли вся документация по проекту в централизованном хранилище?
Хорошо ли организовано хранилище и легко ли найти необходимый документ?
Наличествует ли корректная система контроля версий?
Основные документы обычно хорошо составлены?
Повестка и протоколы ключевых собраний ведутся и хранятся?
Ключевые решения подписаны уполномоченными лицами?
Есть ли словарь/глоссарий проекта?
Есть ли реестр принятых решений?
Требования
Требования хорошо документированы?
Есть ли система отслеживания требований и их изменений?
Предметы поставки соответствуют документации по требованиям или преображаются в ходе разработки?
Документируются ли причины и утверждающие лица при изменении требований?
Проведение очных встреч
1. Кто был на вашем последнем собрании? Когда вы в последний раз общались со стейкхолдерами из подготовленного на старте проекта короткого списка?
2. Как вы управляете собой? Сколько времени в неделю выделено на управление собой? Опишите свою систему управления задачами.
3. Какой план коммуникаций в проекте? С какими участниками есть регулярные очные
встречи? С какими далекими от вас участниками и заинтересованными сторонами вы регулярно списываетесь в чате или разговариваете по телефону? Повестка ваших встреч и обсуждений?
4. Когда в последний раз с ними общались? Сколько баллов по 10-балльной шкале вы поставите себе за содержательность и структурированность последней беседы? Что можно улучшить?
5. Посвящена ли каждая встреча только одной теме? Не размыта ли повестка? Достаточно ли все концентрируются на предмете, чтобы достичь понимания и найти устраивающее всех решение?
6. Какие интересы у участников? Какие у них KPI? Какие рычаги влияния на их поведение есть у вас или спонсора проекта?
7. Ведете ли вы личные дела сотрудников? Фиксируете ли вы их характеры, особенности поведения, сильные и слабые стороны? Ведете ли вы список задач, которые можно и нельзя им доверять? Можете ли вы ответить на вопрос, почему надо управлять этим сотрудником? О чем с ним говорить? Как с ним надо говорить? Где с ним говорить? Подстраиваете ли вы график встреч и бесед с ним, так, чтобы ему было удобно и он не торопился домой или по другим делам?
8. Какие темы для еженедельного разговора у вас есть? Какие проблемы (расхождения между желательным и действительным) есть? Что мешает решить проблемы?
9. Общение с кем вы уделяете больше времени и почему? Подсказка – чем более способный и талантливый человек, тем больше ему надо уделять внимания.
10. Следуете ли вы при общении схеме «Мои ожидания от вас-Вот какие результаты я ожидаю-Вот что будет считаться успехом-Вот что будет считаться неудачей-Вот какие будут последствия плохо сделанной работы-Обратная связь по выполненной работе».
11. Понимают и осознают ли сотрудники последствия плохо выполненной работы для проекта и для них лично? Предоставил ли спонсор проекта вам право на письменную оценку эффективности работы персонала, выделенного на проект? Вы внесли задачу по проведению этой оценки в список задач по проекту? Знают ли участники проекта о том, что эта оценка будет проведена? Оценка будет направлена линейному руководителю, директору по персоналу и спонсору проекта?
12. Регулярно ли вы обсуждаете общий план-график и расписание проекта с ключевыми участниками? Понимают ли они последствия сдвига сроков по выполнению задач на общие сроки проекта? На все ли ближайшие задачи по плану-графику выделены и подтверждены ресурсы?
13. Какие ресурсы нужны для выполнения задач? Используете ли вы при обсуждении стандартный список ресурсов:
a. Рабочее пространство
b. Снабжение
c. Материалы
d. Оборудование
e. Транспортировка
f. Информация
g. Производственный процесс
h. Техническое обслуживание
i. Персонал
j. Таланты/Компетенции, м.б. внешние
k. Тренинги
l. Коммуникации
m. Конкретный сотрудник
14. Кто может сказать, есть ли в наличии нужный ресурс? С помощью какого процесса можно получить этот ресурс? Ожидаемое время поставки ресурса. Что вы должны сделать, если столкнетесь с проблемами при получении ресурса? Все ли участники проекта знают про процесс запроса и получения ресурса? Знакомы ли они с ключевыми людьми, отвечающими за процесс предоставления ресурса?
15. Содержит ли запрос на получение ресурса следующие пункты?
a. Что я заказываю?
b. Для кого и зачем я это заказываю? В чем польза?
c. Какие затраты на выполнение заявки? Деньги, время. Чьи это затраты, когда они будут?
d. График выполнения заявки. Дедлайн, основные этапы обработки выполнения, ресурсы на обработку заявки.
e. Есть ли План Б, если ресурс не будет получен? Какие есть альтернативные источники поставки ресурса? Какие есть возможности по возможностям замены ресурса? Есть ли способ выполнить работу без этого ресурса? Можно ли увеличить сроки и стоимость выполнения работ, если ресурс не будет получен?
16. Есть ли повторяющиеся проблемы? Если они есть, то есть ли процедура, политика, стандарт или регламент, описывающий процесс решения проблемы? Какие необходимые ресурсы для решения проблемы есть у подчиненного? Границы импровизации при решении проблемы. Как принять наилучшее решение? Есть ли детальный пошаговый план решения проблемы? Прослеживается ли исполнение плана решения проблемы совместно с командой?
В заключение
Есть и другие области, которые необходимо будет рассматривать, и этот список, в большинстве случаев, покрывает, наверное, от 70 до 80%.
Часть 3. Спасти рядового Райана
В первой части обсуждалась личность человека, спасающего проект. Во второй был приведен список тем, которые необходимо отработать. В этой третьей и заключительной части, посвященной конкретно самой операции мы рассмотрим, что же на самом деле необходимо сделать.
Кто тут главный?
Первая вещь, с которой необходимо разобраться, это то, кто руководит проектом. Мы не ищем менеджера проекта, а скорее спонсора. Человека, который подписывает договора. Человека, который может остановить проект, если это потребуется.
Как-то я разговаривал с консультантом, который выполнял работу для большой политической партии и разрабатывал рекомендации по тому, как ее лучше организовать. Большое количество финансовых доноров были обеспокоены тем, что текущая организационная структура является причиной потери популярности. Он ответил донорам, что приняться за работу только в том случае, если это будет с согласия первого лица партии. И он говорил не про человек с должностью, наиболее близкой к этому описанию, а о том, кто реально держал бразды правления.
На эту роль подходило несколько кандидатов. Одним из них был премьер-министр. Глава партии был другим. Была еще пара очень влиятельных спонсоров, которых тоже стоило рассматривать. Как и в большинстве партий, в этой были и финансисты, которые обладали невероятным влиянием на то, как партия управлялась. Они знали, в каких шкафах лежали скелеты и разные деликатные подробности того, как они там очутились.
Он искал, кто же, по общему мнению, был тем, кто рулил и жал на газ. Он летал по всей стране на партийные собрания с функционерами и со всеми перечисленными выше лицами и пытался достичь соглашения. После двух лет поисков он так и не приблизился к пониманию и отказался от предложения. Он сказал: "Если мы не можем договориться, кто же ведет это представление, как вообще можно задумываться о его реорганизации?"
Вам нужно определить, кто в проекте дергает за веревочки, даже если некоторые из них и обветшали. Обычная тактика в таких случаях - показать на комиссию. Мой ответ в таких случаях - а кто отвечает за комиссию? Кто председатель? Кто утверждает решения? Кто может отменить решение большинства? Вы должны найти этого человека.
Содержание проекта
Следующий шаг - это определение содержания. Обычно состоит из двух частей:
Какое было содержание, когда проект начинался;
Какое представление о содержании проекта сейчас;
Очень часто здесь кроется корень всех проблем. На самом деле совершенно типично, когда по поводу того, что же входит в содержание, согласия нет и в помине. В ряде наших других статей эти проблемы подробно описаны, так что мы не будем останавливаться на том, как надо определять содержание. Если по поводу содержания есть различные точки зрения, выпишите их все и найдите различия.
Решение проблем с содержанием
Если есть неразрешенные проблемы с содержанием, сейчас самое время их решить. Это может проходить через переговоры с ключевыми стейкхолдерами либо можно просто спросить человека, отвечающего за проект. Пока вы не решите, что же вы хотите сделать в проекте, остальной анализ бесполезен.
Я всегда устанавливаю ожидания в этом месте, описывая документ как "рабочее содержание". Другими словами, это не окончательно согласованное содержание проекта, а скорее текущая оценка того, что будет получено в этом проекте. Содержание может значительно меняться по мере определения дополнительных факторов. Например, уровень усилий, необходимый для реализации содержания полностью, может быть неприемлем для организации. Содержание может быть урезано. Проект может быть разбит на подпроекты. Если вы хотите двигаться вперед, по поводу содержания необходимо делать предположения. Эти предположения надо проверять или изменять, и развивать предложение по дальнейшим шагам.
Ожидания и реальность
В то же самое время вы можете начать записывать что люди ожидают и какова реальность. Цель этого упражнения - это определение различий в восприятии различных людей, попадающих в сферу влияния проекта.
Вот пример:
Кто владелец: Клиентский отдел
Ожидание: Проект завершится к Августу
Реальность: Проект будет идти до конца года
"Д. Смит.; система будет обрабатывать возвраты; будут обрабатываться возвраты только для клиентов категории А"
"Команда проекта; бизнес-пользователи будут доступны минимум 3 дня в неделю; бизнес-пользователи доступны крайне редко"
Цель создания этого списка - свести вместе все невыполненные ожидания, которые и создали ощущение, что проект находится в кризисе. Возможно, проект и не в кризисе. При правильном управлении ожиданиями люди могут быть удовлетворены направлением движения и результатом.
Решение проблем
Есть искушение решать проблемы по мере их выявления. Это скользкая дорожка, ведущая к зыбучим пескам. Даже спасательные миссии могут провалиться, если их затянуть. Определите проблемы, но тратьте времени на их решение. Очевидные пути решения часто слишком примитивные и никогда не работают. Как только вы начнете реализовывать простые решения, вы погрязнете в технических деталях, которые окажутся под водой.
Во время одной спасательной операции с самого начала было понятно, что наибольшей проблемой было то, что не были приняты 15-20 основных решений. Значительное количество работ по проекту стояли в ожидании принятия этих решений. Большинство из них касалось достаточно сложных проблем и ситуаций, но все-таки некоторые из них стали жертвой неправильной расстановки приоритетов. Люди тратили все свое время на решение сложных и больших проблем, не уделяя малым никакого внимания. Было искушение выделить время на решение этих малых проблем проблем во время ревизии. К счастью, я устоял против этого искушения и быстро завершил анализ.
Моя рекомендация была остановить проект на неделю-другую и провести серию рабочих совещаний, на которых бы присутствовали главные лица, принимающие решения, и где были бы решены все найденные на данный момент вопросы. Рабочие совещания проводились по принципу суда присяжных - никто не имел права выйти с совещания, пока решение не было принято. Конечно, это привело к тому, что топ-менеджмент посвятил проекту все свое время на несколько дней. Это имело свое воздействие на скорость принятия решений.
Для принятия некоторых решений потребовалось менее часа, но одно заняло более двух дней. Никто не покидал совещания по распоряжению генерального директора, который сказал сидеть до последнего. Внедрение ERP зачастую требует такого от компании. Смысл моего рассказа в том, что не пытайтесь решить все проблемы с первого раза. Соберите факты как можно скорее, затем ищите решения. Помните, что люди ждут, пока вы не построите им курс. Чем дольше они ждут, тем больше вероятность, что они откажутся следовать вашим рекомендациям.
При поиске проблем используйте чек-листы и вопросы из первых двух частей статьи. Аспекты бизнеса и технические моменты будут различаться от проекта к проекту. Например, при ремонте здания, вопросы будут касаться строительных материалов, доступа в здание, архитектурных чертежей, одобрений юристов и т.п. При производстве программного обеспечения, вопросы бизнеса могут касаться юридических моментов, бизнес-процессов, маркетинга, а технические аспекты относиться к безопасности, хранению данных и апгрейду оборудования. Вам нужно создать свой чек-лист для каждого из проектов.
Игра "Кто сидеть будет?"
Неизбежна ситуация, при которой одни люди будут обвинять других за то, что проект дошел до точки. Такие обвинения редко приводят к разрешению кризиса. Цель этой техники - замутить воду и перенести внимание из будущего в прошлое. Избегайте обсуждений кто в чем виноват, но используйте эту информацию как фильтр для интерпретации получаемой информации.
Я интервьюировал двух людей при аудите реализации проекта. Их обоих я видел в первый раз в роли независимого аудитора. Было трудно поверить, что они описывают один и тот же проект. Они оба обвиняли друг-друга за то, что проект превысил бюджет и сорвал сроки. Каждый представил набор фактов (и немного выдумки) таким образом, что вы бы уволили второго за некомпетентность, если бы имели только свидетельство одной стороны. Истины находилась посредине, или немного в сторону от центра. И потребовалось несколько других интервью для определения, что же произошло на самом деле.
Всегда помните, что все, что вы слышите, искажено чувством самозащиты и веры людей в то, что их способ выполнять работу является самым верным. Каждый будет видеть ситуацию несколько односторонне. Слушайте, что вам говорят, но спрашивайте себя, почему они это говорят.
И последнее, что я хочу сказать на тему вины. Ищите исходную причину. Кто-то назначил некомпетентного менеджера проекта. Почему его назначили? В приведенном выше примере, менеджер проекта не имел достаточно опыта для управления крупным сложным проектом. И хотя он допустил множество ошибок, исходная причина была в том, что менеджер по реализации проекта организации не обладал достаточным количеством квалифицированных ресурсов для проекта. Все это явилось следствием того, что компания имела политику не нанимать менеджеров проекта по контракту и не позволяла тратить достаточное количество денег на найм квалифицированного постоянного штата. Поверх этого наложилась проблема с недостаточным бюджетом на обучение. Мои рекомендации не включали в себя увольнение менеджера проекта, они заключались в следующем: увеличить бюджет на обучение, платить менеджерам проектов рыночные ставки и нанять пару опытных менеджеров проектов, которые могли бы обучать текущих менеджеров проектов.
Для определения проблем необходимо понять, что пошло не так. Как только вы определили причины, по которым проект оказался в кризисной ситуации, вы можете добавить эти причины в список проблем.
После определения содержания
После того, как вы определили содержание, нужно обратить свое внимание на план и ресурсы. Какие ресурсы есть в наличии, и на какие ресурсы еще надо получить одобрение? На этой стадии полезно сделать несколько сценариев. Например, с двумя людьми, которые есть сейчас, работа будет завершена за три месяца, если добавить еще один ресурс, можно справиться за два.
Как только план готов, можно оценить его стоимость. Если было разработано несколько планов, надо обсчитать их все. Вернитесь к начальному бюджету и проанализируйте расхождения по статьям расходов. На этом шаге более вероятно, что вы сможете протолкнуть идею управленческих резервов. Например, предположим, что в проекте было изначально заложено 20 тыс. долларов на тестирование программного обеспечения, но оно оказалось намного сложнее, чем ожидали, и тестирование вызвало задержку. Вы можете заложить в бюджет 25 тыс. и добавить 10 тыс. управленческого резерва, т.к. у вас нет понимания сложности задачи. И до тех пор, пока вы не поймете задачу полностью, вы не сможете оценить затраты на нее. Обжегшись один раз, организации обычно более консервативной подходят к оценке предстоящих затрат.
Другой важный момент – это пересмотр ролей и ответственности при планировании. Мало сказать, что вы хотите тестировщика, если вы под ним подразумеваете человека с определенным набором навыков, а лицо, принимающее решения, считает, что для того, чтобы проводить тестирование, достаточно иметь пульс.
Эффекты
Предположим, что в какой-то момент проект подразумевал получение каких-то эффектов. Вы должны пройтись по эффектам и проверить, имеют ли они какой-то смысл. Также обратите внимание на эффекты, которые не были идентифицированы в начале проекта. Иногда, по мере развития проекта, становятся очевидными новые эффекты.
Черновик отчета
К этому моменту у вас должен быть:
Идентифицирован ключевой игрок. Человек, который принимает решения или по крайней мере, дает рекомендации исполнительному комитету либо совету директоров.
Понимание содержания проекта – начальное и текущее, согласованное участниками.
Список ожиданий и реальности и различия между этими двумя.
Определены основные проблемы и открытые вопросы, мешающие ходу проекта.
Определены роли и ответственность, необходимые для продолжения проекта.
Один или несколько рабочих планов для завершения проекта.
Новый расчет затрат и эффектов.
Теперь вы можете давать рекомендации. Никогда не сбрасывайте со счетов варианты «ничего не делать» и «отменить». Иногда вы обнаружите, что настоящей проблемой является различия между тем, что люди верят, должно произойти и тем, что на самом деле должно произойти. Если проблема в том, что все ожидают завершения проекта за 6 месяцев, в то время, как он будет идти еще 12, то решением может быть смириться с 12 месяцами. Проблема в том, что делать с ожиданиями по 6 месяцам. Проект может идти как идет, но нужно провести коммуникацию, которая объяснит почему проект займет в два раза больше, чем было запланировано.
И точно также, не стоит оставлять в живых проект только из-за того, что люди с ним эмоционально связаны. Играйте в адвоката дьявола, спрашивайте людей: «Почему нужно продолжать проект?»
Если не найдется хорошей, ориентированной на бизнес, причины, то выдвигайте рекомендацию с отменой. Даже в стадии рекомендации вариант «отменить проект» может быть приемлем и должен рассматриваться. Реальность многих организаций такова, что никто не хочет принимать сложное решение. Если среди вариантов, которые вы предложите, будут только варианты с продолжением проекта, люди, которые думают, что проект надо отменить, будут бояться что-нибудь говорить, т.к. они могут подумать, что это отразится на их карьере. Ваша задача – обсудить все возможные варианты.
После принятия решения
После того, как решение принято, вы столкнетесь с тем, что надо учесть массу человеческих факторов.
Нужно будет заменить ресурсы либо получить на проект новые ресурсы. Запомните, это не военный трибунал. Если нужно кого-то убрать с проекта, сначала поговорите с ним, и позвольте уйти с достоинством. Подумайте, как вы объявите об уходе.
«Билл покидает нас, потому что у него не хватает навыков для управления проектом. Да и вообще, Билл хреновый проектный менеджер и поэтому его и увольняют».
Или
«Проект оказался намного сложнее, чем мы ожидали и теперь, принимая во внимание новые сроки, от нас потребуются сверхчеловеческие усилия. Нам посчастливилось нанять на этот проект Супермена. Большое спасибо Биллу, который вел проект до этого момента под давлением этих невероятно сложных обстоятельств. Мы попросили его ввести Супермена в курс дела перед уходом».
Помните, что Билл скорее всего пытался сделать все, от него зависящее, но ожидания по его работе просто превышали его способности.
Другой фактор, требующий рассмотрения, это рабочий настрой команды. Когда в проект приходят аудиторы, то вполне вероятно, что мораль команды будет невысокой и даже могут образоваться фракции. Есть много способов решения проблем с рабочим настроем, но мой любимый способ – это дать понять, что командой слишком долго пренебрегали и теперь руководство признало важность происходящего. Обычно я объясняю лицам, принимающим решения, что они руководители и сейчас правильный момент, чтобы начать руководить. Это означает, что они должны найти время на то, чтобы поддержать настроения участников проекта.
Другим вариантом может быть ужин, организованный спонсором проекта для команды, посещение им проектных совещаний, разговоры с участниками об их вкладе в проект, вознаграждения (все, что угодно, от билетов в кино до бонусов), обратная связь о ходе реализации, чтение еженедельной отчетности и самых важных документов. Полезно также определить, что делает эту команду отличающейся от других. Однажды я организовал для команды проекта особые места на парковке ближе к зданию, т.к. они надолго задерживались по вечерам. Это ничего не стоило для организации, разве что цену краски для разметки парковочных мест «Зарезервировано для команды проекта». Зато боевой дух взлетел до небес.
Реализация
Если проект продолжается, соберите команду проекта и лиц, принимающих решения вместе минимум на один день. Убедитесь, что все понимают:
- Свои роли и ответственность, включая все изменения
- Содержание проекта
- Согласованный план, включая контрольные точки
- Способ контроля исполнения плана
- Вовлечение и поддержка со стороны топ-менеджмента
- Текущие трудности и планы по их преодолению
- План коммуникации по управлению ожиданиями
Скорее всего, потребуется еще больше планирования, но «план по составлению плана» будет частью движения вперед. Если следующую неделю придется потратить на планирование, объясните как пойдет процесс и кто будет вовлечен. Организуйте еще одно рабочее совещание, когда план будет готов.
Заключение
Вернуть контроль над проектом, потерявшим управление, нелегкая задача. Вам будет нужна структура, прежде чем вы приняться за работу, иначе вы будете погребены под грудой «самых важных фактов и мнений» при попытке разобраться в проблемах. Кризисное управление требует особых навыков. Оно требует умения не отвлекаться на то, что было и лучше всего поручать эту работу кому-нибудь со стороны, лучше всего, вообще не из этой организации. Кого-нибудь, кто способен бесстрастно разобраться в ситуации и дать рекомендации по выполнению целей проекта. Эта статья дает представление, как это сделать. Конечно, в реальности ничто никогда не пойдет как по писаному, но следуя описанному процессу, вы быстро поймете, в какой точке вы сейчас находитесь, и куда двигаться дальше, если вообще куда-то двигаться.
Дополненный перевод, оригинал Rescuing a project in crisis
