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



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



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



Преимущества и требования



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



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



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



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



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



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



Продолжая тему современного проектного управления, следует сказать об актуальности задачи управления рисками. В организациях, работающих в сфере высоких технологий, эта тема является очень важной. Любой проект уникален по определению, а проект информационно-технологический уникален вдвойне, поскольку используемые технологии меняются очень быстро. Часто приходится быть пионером по внедрению той или иной системы, поскольку ни у кого еще нет подобного опыта. И очень важно, чтобы это понимал не только исполнитель проекта, но и его заказчик. Понимали и предусматривали реагирование на возможные риски. Пожалуй, такое «взаимное понимание» является самым главным в процессе управления рисками проекта, поскольку сам процесс и правила управления рисками достаточно просты и описаны в стандарте управления проектами PMI. Эти процессы состоят в разработке общей политики риск-менеджмента (как мы принципиально будем реагировать на риски?), идентификации рисков, их оценке, планировании реагирования, систематическом мониторинге и собственно реагировании. В нашей практике принято соизмерять затраты на управление рисками с затратами на проект в целом. Так, для малых проектов можно просто сделать «надбавку» на сроки и стоимость проекта в целях компенсации всех рисков, и ни о чем не беспокоиться в дальнейшем. К сожалению, столь простой подход редко возможен. Чаще требуется на протяжении всего проекта вести серьезный комплекс работ по мониторингу и оценке рисков.



Управление практически любым современным проектом – это во многом управление взаимодействием. Взаимодействием заказчика и исполнителя, члена проектной команды и руководителя проекта, руководителя проекта и руководителя функционального подразделения (в организациях с матричной структурой), сотрудников заказчика между собой и т.д. Вот типовая ситуация в проекте программной разработки: исполнитель начал работы, подготовил ТЗ, заказчик его утвердил, программисты начали работы, к моменту сдачи работ выясняется, что сделано совсем не то, что ожидал заказчик. В чем причина? Да прежде всего в том, что команда исполнителя на продолжительное время «удалилась» в процесс реализации, а заказчик находится в неведении, что происходит, как идут дела, как учитываются его, заказчика, важные пожелания и мысли. В конце концов, ни одна система не может быть описана в ТЗ так, как ожидает заказчик, и сделана так, как написано в ТЗ. Поэтому важность взаимодействия заинтересованных лиц на всем протяжении проекта нельзя недооценивать. Как правило, хорошим интервалом для статус-отчетности в проекте служит календарная неделя. Руководитель проекта должен еженедельно информировать всех участников о состоянии дел, проблемах, рисках, основных событиях, выполненных и невыполненных (да-да, не надо этого бояться!) работах. Информирование всех сторон всегда ведет к положительным трендам в решении возникающих проблем проекта (а проекта без проблем не бывает!). Такое информирование, как правило, осуществляется путем рассылки текстовых отчетов, шаблон которого есть в организации-исполнителе и утвержден главным руководящим документом проекта – Уставом.


Раз уж речь зашла об Уставе проекта, следует сказать несколько слов о его роли. В нашей практике Устав – основной рабочий документ проекта, отвечающий на вопросы: а) каково содержание проекта и б) как управлять конкретным проектом. В разделе «как управлять» досконально описывается оргструктура и персональный состав проекта, зоны ответственности членов команды проекта (с обеих сторон), способы разрешения проблем и управления рисками, организация взаимодействия, матрица ответственности, отчетность в проекте, оформление и регламенты реализации запросов на изменения в проекте. Объем этого документа обычно составляет около 50 страниц текста (детальность Устава проекта существенно зависит от масштаба проекта).



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



Выбор



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



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



Выбор ИСУП, как и любой информационной системы, зависит от бизнес-требований. Далеко не всегда нужна самая «крутая» (и, как правило, самая дорогая) система. Далеко не всегда система, лучшая с точки зрения планирования расписания, одновременно обеспечит взаимодействие проектной команды на основе web-технологий. Далеко не всякая хорошая система имеет техническую поддержку в вашем регионе. Таким образом, выбор, как всегда, - дитя компромиссов.



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



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



Мы в своей практике пользуемся комплексом Microsoft Enterprise Project Management 2003, базирующемся на коробочном продукте Microsoft Project Server, что позволяет упростить начальное конфигурирование системы и очень быстро приступать к использованию: коробочная конфигурация содержит необходимые базовые настройки. Но установить программное обеспечение мало – нужно заставить работать систему. Наш опыт внедрения ИСУП показывает, что основные усилия в проекте внедрения направляются на то, чтобы вовлечь в работу с системой всех менеджеров и исполнителей, внедрить единый регламент планирования проектов и отчетности по трудозатратам и срокам исполнения работ. Особенность ИСУП в том, что она - не основной рабочий инструмент сотрудников, а всего лишь средство, позволяющее сделать работу с проектной информацией более эффективной и удобной.



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



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



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



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

Комментарии: (0)   Рейтинг: