14.06.17 - 03-23

Авторские колонки

6 вопросов, которые спасут проект

18 ноября 2015, 16:56 Роман Худорожков

Роман Худорожков, основатель компании Liberty Grant,

написал шесть универсальных вопросов,

которые нужно держать в голове в течение всего времени работы над проектом.

Вопросы помогут наладить бизнес-процессы

и как итог

– завершить проект с хорошими результатами и максимально быстро.

Недавно знакомый предприниматель поделился со мной своей бедой:

«Не знаю, что делать с менеджерами проектов.

Половину проектов мы делаем плохонько, а вторую половину – еще хуже.

Несмотря на два десятка KPI и регулярную отчетность,

они все равно не выявляют проблемы на ранних стадиях,

и поэтому мы тратим вдвое больше ресурсов.

Кроме того, слишком часто мы вынуждены идти на поводу у заказчиков

и снижать выручку проекта.

И ведь ПМ-ы – парни все хорошие и стараются,

но получается все равно кое-как».

Это, впрочем, неудивительно.

Большинство проектных KPI

(и особенно сложные, такие как остаточная трудоемкость или удельный проектный доход)

с математической точки зрения абсолютно бессмысленны.

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

Так что же делать?

Куда смотреть?

Как понять, что в проекте уже что-то идет не так?

И что именно?

------------------------

Я использую методику шести вопросов,

которые быстро вскрывают всю подноготную проекта.

Такой экспресс-анализ следует проводить не реже 1-2 раз в неделю,

поскольку ситуация обычно меняется очень стремительно,

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

Тогда у вас будет шанс все быстро исправить и вернуть проект в рабочее русло.

По теме: 4 вопроса, которые нужно задать себе перед запуском стартапа

Итак, начнем.

1. Результат проекта все еще выгоден заказчику?

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

Но ситуация может измениться и сама по себе. Допустим, ваш проект играет важную роль в выходе заказчика на новые рынки. Но вот заказчик сменил стратегию на повышение эффективности – и теперь вы противоречите направлению компании. Или ваш проект должен был увеличить прибыль на 10 миллионов, но тут заказчик получил господряд на 3 миллиарда. Или у вас был приятный и понятный проект по ускорению кластера Oracle Database, а заказчик включился в «импортозамещение».

Если бизнес-интересы заказчика изменились, а вы не в курсе, то ваш проект в беде. Некоторые люди считают, что именно по этой причине лучше не фиксировать заранее конкретные бизнес-цели, финансовые показатели и подробные метрики.

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

Лучше заранее все зафиксировать, чтобы вы могли контролировать ситуацию и исключить из повестки дня внезапные настроения. Но если изменения грядут, то тут уже не тушуйтесь – действуйте быстро и смело. Когда в дело вступают масштабные корпоративные инициативы, то логика обычно отключается. Поэтому теперь ваша главная задача – переформулировать проект так, чтобы он снова вписывался в вектор интересов компании. Выход на новые рынки – нужно сокращение затрат путем стандартизации региональных форматов. Маленькая прибыль – поможет разработка перспективного продукта для крупного заказчика. Кластер Oracle – пусть будет технология повышения производительности ключевой СУБД.

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

2. Точно ли результаты проекта всем понятны и согласованы?

Почти в любом проекте результаты имеют наибольшую неоднозначность и разнообразие трактовок и пониманий. Даже когда явно спрашиваешь:

– Вы точно все одинаково понимаете, что должно быть сделано в ходе проекта?

– Да, мы это много раз обсуждали.

– Ну, тогда рассказывайте.

– Мы должны создать технологию анализа данных.

– Подождите, вы же говорили, что будет сайт.

– Ну да, сайт на этой технологии.

– Какой сайт?! Мы сейчас вообще только ТЗ должны разработать.

И вроде бы никто из них не злодей, но очевидно: проекту – хана.

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

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

Правильное описание проекта выглядит примерно так:

«В рамках проекта будет создана компьютерная программа. ТЗ описано в документе «А» версии 12. Критерии приемки описаны в документе «Б» версии 14. Процедура приемки описана в документе «В» версии 08. Сдача-приемка производится 15 апреля 2016 года в 14:00 по адресу: г. Москва, Красная пл., 1.

Система передается под подпись представителю заказчика, Иванову И.И., в откомпилированном виде на установочном CD. Исходные коды системы и алгоритмов не передаются».

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

3. Мы никого не забыли?

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

Чтобы не допустить подобных проблем, следует непрерывно актуализировать перечень вовлеченных со стороны заказчика лиц.

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

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

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

4. Объем работ все еще реалистичен?

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

Именно так всегда и бывает. Тут же начинаются конфликты, взаимные обвинения и переваливание ответственности… Вот только статус проекта от этого только страдает. Поздно рассказывать заказчику, что вы не успеете к сроку – он уже и сам все прекрасно видит. Поздно объяснять, почему это случилось и кто виноват – делу это все равно не поможет. И даже если вы героическими усилиями вытащите проект и сдадите его в срок, все равно он будет восприниматься чуть хуже, чем «средненько». Ведь нервы-то вы заказчику попортили изрядно.

Но можно избежать этих проблем. Тут помогут простые правила:

• Тратьте силы, время и ресурсы только на получение результатов проекта;
• Делайте их ровно такими, как нужно для сдачи: не лучше и не хуже;
• Четко соблюдайте реальный последний срок;
• Если все пошло не так, меняйте «сроки – стоимость – результат»;
• Тщательно готовьте заказчика, не заваливайте его информацией.

А теперь подробнее.

Во-первых,

в ходе проекта вы должны создавать только результаты,

зафиксированные в контракте или ТЗ.

Не надо разрабатывать никаких дополнительных инструментов,

систем, устройств и документов.

Во-вторых, для каждого результата следует делать только то, что необходимо для его сдачи. Не надо делать красивее, удобнее, функциональнее, универсальнее и в любом другом смысле «лучше», чем это требует процедура приемки-сдачи результатов. Уже только этим вы сэкономите не меньше 30-40% времени.

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

Если нет никаких жестких ограничений, заданных извне,

значит, вы можете спокойно двигать этот срок,

предварительно подготовив заказчика.

Если выставка пройдет 16 октября,

то не имеет никакого значения,

с какой степенью геройства вы завершили проект к 17 октября

– выставка уже закончилась, проект больше никому не нужен.

Если показ для акционеров назначен на 5 января, значит, надо сделать именно к пятому января – и ни на день позже, потому что 6 января все уже уедут.

Все остальные сроки, заданные в формате «надо сделать к двадцать пятому, потому что мы так записали», можно при желании подвинуть.

В-четвертых, если сроки все-таки поплыли,

то вы должны грамотно разрулить

великий проектный треугольник

«сроки – стоимость – результат»,

например:

• Поставить результат немного хуже, но в тот же срок и с теми же затратами;
• Увеличить затраты, но все-таки сделать нужный результат в срок;
• Подвинуть сроки, не наращивая бюджет.

Можно сформировать свою уникальную комбинацию,

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

В-пятых, если изменений в конфигурации проекта не избежать,

то надо плавно, но целенаправленно подготовить к этому заказчика.

Здесь самый главный трюк заключается совсем не в том,

чтобы заблаговременно проинформировать заказчика о переносе сроков.

Наоборот: не спешите вываливать всю информацию,

а поставляйте ее небольшими частями.

Дайте людям время и возможность все переварить

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

чем планировалось изначально.

По теме: Как правильно управлять персоналом?

5. Команда действительно работает?

Потеряв все волосы на голове в ходе бесчисленных согласований, утверждений и обсуждений,

вы наконец-то обо всем со всеми договорились и даже подписали.

Но проект опять в опасности.

Потому что Смирнов ждет от Сидорова документ,

для которого нужны данные от Орлова,

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

Но Андрееву никто задачу в трекере не поставил, и он вообще не в курсе.

Чтобы не допустить проблем, руководствуйтесь такими правилами:

• Узнайте, всем ли поставлены задачи и все ли к ним приступили;
• Поинтересуйтесь, есть ли у каждого необходимые инструменты и технологии;
• Выясните, всем ли хватает знаний;
• Убедитесь, что сотрудник на самом деле работает над задачей,
• а не готовится начать предварительную фазу вводного обучения;
• Задайте правила взаимодействия в проекте,
• чтобы никто не зависал в ожидании непонятно чего,
• не боялся узнать, попросить или сделать,
• не терялся в глубоких поисках смысла жизни
• или мельчайших багов в выбранной технологии,
• а также всегда четко представлял,
• кому и когда нужно отчитаться о результате
• или сообщить о проблемах.

Задача всей команды – выполнить проект,

то есть, получить все необходимые результаты только этого конкретного проекта

(а не изучить новую технологию,

создать универсальную методику реализации проектов,

обучения сотрудников или оценки качества работы…).

Обходите баги, отложите глобальные теоретические разработки,

не нужные в данной задаче,

не ищите причин несовершенства мира, технологий и людей.

В любую минуту вы должны быть уверены,

что каждый член команды работает эффективно и оптимально.

Проще говоря, делает только то, что нужно,

и ровно так, как нужно для данного конкретного проекта.

Как говорится, just do it.

6. А вам-то это вообще зачем?

И напоследок – самое вкусное.

Большинство людей и компаний считают, что,

если бы у них было все необходимое и ничто не мешало,

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

Вот только это неправда.

Себя заставить и организовать порой гораздо сложнее.

Даже если все остальное в порядке.

Особенно когда все в порядке.

Огромное количество проектов провалились только потому,

что они оказались не нужны и не интересны самому исполнителю.

Поэтому вы должны четко понимать,

для чего вы как исполнитель вступаете в конкретный проект.

Причин может быть много, но все они должны быть для вас критически важны.

Иначе рано или поздно (и, скорее всего, рано) вы забьете на проект, и он пойдет под откос.

А вот какие могут быть причины для старта и продолжения проекта.

Фото на обложке: Shutterstock.

Свяжись с героем материала