10 правил повышения производительности проектов

ИТ проект продвигается вперед весьма сложными путями. Не без сожаления приходится признать, что несмотря на все формальные методологии, широкое внедрение практик управления проектами, все более и более мощные инструменты управления проектами, большинство проектов не вписываются хотя бы в один компонент незыблемой триады: затраты, сроки, качество. Наиболее острые, проблемы возникающие при выполнении проектов, одновременно указывают на пути повышения производительности. Этот опыт можно представить в виде десяти правил повышения производительности проектов. Правило № 1. График работ - это не поле для политики

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

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

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

Многие проекты останавливаются по той же причине, по которой останавливается военное отделение, попавшее под снайперский огонь: все прижимаются к земле и боятся пошевелиться. Никто не решается поднять голову, чтобы определить направление огня. С другой стороны, если при этом продолжать лежать лицом к земле, ситуация только ухудшится. Необходимо или двигаться вперед, или же отступать одним из возможных путей. Отсутствие ответных действий ставит отделение под гораздо больший удар.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

В большинстве своем ИТ-проекты редко применяют даже несколько изложенных выше принципов. Чаще всего команда продвигается вперед пытаясь решить проблему сложными путями, которые как правило представляют собой переизобретение решений которые уже были найдены в одном из предыдущих проектов, далее, смотри по тексту начала статьи. Если проблема остается нерешенной, работа замирает и все ожидают что проблема как то разрешится, занимаясь при этом решением других менее важных проблем. Графики выполнения начинают плавать, бюджеты перерасходуются, качество падает. Даже если половина из того о чем здесь говорилось будет введена в ИТ-проект, его производительность возрастет. Но, как показывает опыт настоящая проблема состоит в том что бы заставить ПМ и членов проекта принять данные рекомендации.