Вы здесь

Проектное управление в сфере информационных технологий. 1. Основы проектного управления (Алексей Челяпин, 2016)

1. Основы проектного управления

Предисловие к главе

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

Проектное управление рассматривается автором как система, как совокупность взаимосвязанных элементов.

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

1.1. Что такое проект или пара слов о теории

В настоящее время понятие «проект» достаточно чётко определено в разработанных как за рубежом, так и в нашей стране стандартах по проектному управлению.

К наиболее известным и популярным в России стандартам можно отнести PmBok (свод знаний по управлению проектами, разработанный американским Институтом управления проектами (Project Management Institute, PMI) [4] и признанный стандартом проектного управления Американским Национальным Институтом Стандартов (ANSI)), и серия отечественных стандартов по проектному менеджменту:

ГОСТ Р-54869-2011 «Проектный менеджмент. Требования к управлению проектом» [7];

ГОСТ Р-54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» [8];

ГОСТ Р-54871 -2011 «Проектный менеджмент. Требования к управлению программой» [9];

ГОСТ Ρ ИСО 21500-2014 «Руководство по проектному менеджменту» [10].

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

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

Ещё одним стандартом, заслуживающим упоминания, является Карманное руководство по менеджменту проектами PRINCE2™ (редакция 2009 года) [6], выпущенное Центральным управлением вычислительной техники и телекоммуникаций Великобритании. Особенность данного стандарта в том, что он, в отличие от стандарта ΡΜΙ и отечественных ГОСТов, предлагает пошаговую методологию управления проектом, описывая конкретный набор шагов и соответствующих им документов по управлению проектом.

Другим интересным и популярным в России стандартом являются Национальные требования к компетенции специалистов, разработанные Российской Ассоциацией Управления Проектами СОВНЕТ [5]. Суть стандарта в том, что он определяет набор личностных и профессиональных качеств, которыми должен обладать успешный менеджер проектов.

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

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

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


Рисунок 1.1. Фазы жизненного цикла проекта


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

Принято выделять четыре фазы жизненного цикла проекта:

1. ИНИЦИАЦИЯ. Целью фазы является формальное открытие проекта. В результате инициации должно быть принято решения о старте проекта, назначен руководитель и куратор проекта, определены основные заинтересованные стороны проекта, даны обоснования необходимости выполнения проекта, определены основные результаты и общие требования к ним. Хорошей практикой является разработка Устава проекта – документа, содержащего всю вышеперечисленную информацию в упорядоченном виде. Про разработку Устава проекта будет сказано подробно в главе «Создание системы управления проектом».

2. ПЛАНИРОВАНИЕ. Если говорить кратко, то на данной фазе должны быть определены (или уточнены), запланированы и согласованы все составляющие проекта, которыми планируется управлять на фазе исполнения проекта: содержание, сроки, затраты, риски, персонал, заинтересованные стороны, поставки, качество, коммуникации, изменения, интеграция и др.

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

3. ИСПОЛНЕНИЕ. В рамках данной фазы происходит создание результатов (продукта) проекта за счёт применения ресурсов проекта, осуществляется контроль за ходом выполнения проекта, применяются ранее спланированные механизмы контроля и инструменты управления проектом.

4. ЗАВЕРШЕНИЕ. Целью данной фазы является формальное закрытие проекта. Чтобы проект можно было считать оконченным необходимо выполнить ряд формальных процедур:

провести приёмку результатов проекта Заказчиком (подписать акты);

закрыть договора по проекту (получить оплату от Заказчика, закрыть акты субподрядчиков и оплатить счета);

проинформировать команду проекта и заинтересованные стороны об окончании проекта и произвести расчёт премий по результатам проекта;

сформировать итоговый отчёт по проекту и создать архив проекта.

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

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

1.2. ИТ-проекты и их особенности

Информационные технологии (ИТ) – это процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов (Федеральный закон Российской Федерации «Об информации, информационных технологиях и о защите информации» № 149-ФЗ)[14]. Как отрасль человеческой деятельности информационные технологии занимаются созданием, внедрением, эксплуатацией и развитием информационных систем.

Информационная система (ИС) – система обработки информации и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382-1:1993[11]).

Можно выделить следующие направления в информационных технологиях:

разработка и развитие программного обеспечения;

внедрение информационных систем;

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

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

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

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

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

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

Организационный объём проекта. Организационный объём проекта применительно к ИТ-проектам по внедрению информационных систем определяет количество обособленных организационных единиц, в которых будет осуществлено внедрение/тиражирование информационной системы. Под обособленной организационной единицей в данном случае понимается и отдельная, как юридическое лицо организация, и отдельное подразделение в рамках конкретной организации – юридического лица. Показатель практически линейно влияет на стоимость работ. Размер и структура организационного объёма влияет как на выбор методов управления организационным объёмом, способов координации работ, так и на другие аспекты проекта.

Функциональный объём проекта. Данный показатель характеризует набор функциональных возможностей информационной системы, входящих в состав внедряемого решения. Также можно сказать, что функциональный объём – совокупность бизнес-процессов, функций и операций, информатизация/автоматизация которых предполагается за счёт внедрения информационной системы. Функциональный объём проекта внедрения информационной системы – наиболее важный для оценки сложности проекта показатель, т. к. он составляет основную часть содержания работ проекта, описывает объект автоматизации – бизнес-процессы организации. Его изменение влечёт пропорциональное изменение других показателей проекта, таких как методологический объём, интеграционный объём, стоимость проекта и т. д.

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

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

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

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

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

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

1.3. Что такое проектное управление

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

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

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

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

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

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

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

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

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

Проекты, которые организация выполняет в отношении своей деятельности, называются ВНУТРЕННИМИ, а проекты, выполняемые по заказу другой организации – ВНЕШНИЕ.

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

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

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

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

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

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

Принято считать, что проектное управление появилось в России в 90-х годах 20-го века с открытием отечественного рынка для иностранных компаний. Вместе с приходом иностранных компаний в Россию пришли и стали популяризоваться и заграничные практики управления.

Однако нельзя утверждать, что до 90-х гг. в Советском Союзе, а позднее в Российской Федерации, не было проектной деятельности и проектного управления.

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

Все крупные стройки Советского Союза, покорение космоса, развитие обороны страны – всё это можно рассматривать как мегапроекты. Можно дискутировать по поводу «проектности» отдельных методов и инструментов (с учётом особенностей эпохи: отсутствием рыночных механизмов, формированием научных центров на ресурсах ГУЛАГа и т. д.), с помощью которых достигался результат, но то, что такая деятельность содержала основные признаки проекта (уникальность результата, временную и ресурсную ограниченность) – факт.

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

Концепция книги предполагает рассмотрение проектного управления на разных организационных уровнях и разных уровнях проектного управления.

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

1.4. Формы организации проектного управления

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

Форма организации проектного управления влияет на эффективность проектного управления. Выбор формы следует осуществлять с учётом параметров проектной деятельности организации и/или с учётом особенностей конкретного проекта.

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

небольшое число уровней руководства;

небольшие подразделения или автономные группы с высококвалифицированным персоналом;

целенаправленная работа на результат;

предусмотрение изменений или быстрая реакция на них;

высокая производительность и низкие затраты – высокая эффективность.

Рассмотрим подробнее основные формы организации проектного управления:

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

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

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

Функциональная форма организации проектного управления приведена на рисунке 1.2.


Рисунок 1.2. Функциональная форма организации проектного управления


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

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

МАТРИЧНАЯ. Матричная форма характеризуется более обособленными структурными элементами проекта. Она связывает в себе вертикальное подчинение руководству компании и горизонтальные связи между участниками работ проекта.

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

Как правило, матричная форма применяется при временном характере проектной деятельности. После окончания проекта команда проекта, включая руководителя проекта, распускаются.

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

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

Эффективность такой формы определяется выбранной системой планирования действий, исходя из их приоритетности. Матричная форма имеет множество разновидностей, самые распространённые из них это: слабая, сбалансированная и сильная.

Такое деление происходит на основании степени загруженности сотрудников по каждому из проектов в течение рабочего дня. В процентах это выглядит следующим образом: 0-25 процентов, 15–60 процентов, 50–95 процентов загруженности соответственно.

Матричная форма организации проектного управления приведена на рисунке 1.3.


Рисунок 1.3. Матричная форма организации проектного управления


ПРОЕКТНАЯ. Проектную форму организации проектного управления следует использовать при большом масштабе проекта, определённом количестве участников, сложности работы и при регулярной проектной деятельности.

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

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

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

Проектная форма организации проектного управления приведена на рисунке 1.4.


Рисунок 1.4. Проектная форма организации проектного управления


Сравнение форм организации проектного управления приведено в таблице 1.1.


Таблица 1.1. Сравнение форм организации проектного управления


1.5. Проектное управление как система

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

Что даёт системный подход к проектному управлению конкретной организации?

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

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

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

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

Координация и повышение оперативности взаимодействия участников проектной деятельности за счёт:

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

– чёткого определения функций, полномочий, зон ответственности, формализации процедур взаимодействия основных участников проектной деятельности;

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

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

Снижение трудозатрат специалистов, временных и финансовых издержек на управление проектами (специализированное программное обеспечение поддержки процессов проектного управления автоматизирует единые правила выполнения процессов управления и формирование проектных документов на основе типовых форм).

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

Система проектного управления – это набор элементов проектного управления, сконфигурированных под потребности конкретной организации и направленный на эффективное выполнение проектов организации, на достижение целей деятельности организации. Таким образом, цели конкретных проектов должны быть связаны с целями деятельности организации. Как это происходит?

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

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

И внутренние, и внешние проекты имеют свои показатели (целевые и контрольные) и при выполнении показателя проекта выполняется процент (доля) показателя деятельности организации. Таким образом, совокупность показателей одного или нескольких проектов позволяют достичь 100 % выполнения показателя деятельности организации.

Более подробно о взаимосвязи проектов по информатизации с целями деятельности организации будет сказано в главе «От стратегии к отдельному проекту».

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

В соответствии с приведённой моделью основными элементами системы проектного управления организации являются:

Объекты проектного управления;

Субъекты проектного управления;

Процессы проектного управления;

Нормативное обеспечение проектной деятельности;

Технологическое обеспечение проектной деятельности;

Персонал, участвующий в проектной деятельности.


Рисунок 1.5. Модель системы проектного управления

1.5.1. Объекты проектного управления

Для применения проектного управления необходимо чётко понимать, в отношении чего оно будет осуществляться. Современные стандарты проектного управления в качестве объектов проектного управления определяют:

Проекты. В соответствии с ГОСТ Ρ 54869-2011 «Проектный менеджмент. Требования к управлению проектом» проект – комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.

Программы. В соответствии с ГОСТ Ρ 54871 -2011 «Проектный менеджмент. Требования к управлению программой» программа – совокупность взаимосвязанных проектов и другой деятельности, направленных на достижение общей цели и реализуемых в условиях общих ограничений. По сути, программа – это сложный проект, в котором отдельные направления, мероприятия, задачи можно реализовать по отдельности: в виде проектов или отдельных мероприятий. Цель программы – увеличить контроль и управляемость взаимосвязанных мероприятий и проектов. Принципы управления программой, в общем, соответствуют принципам управления проектом.

Портфели проектов. В соответствии с ГОСТ Ρ 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» портфель проектов – набор компонентов, которые группируются вместе с целью эффективного управления и для достижения стратегических целей организации. Цели и принципы формирования портфелей коммерческих и некоммерческих организаций могут существенно отличаться. Цель деятельности коммерческих организаций – получение дохода, следовательно – сохранение стабильности получения дохода в обозримой перспективе – основная задача стратегического планирования. Эту задачу можно решить путём диверсификации бизнеса за счёт включения в портфель различных по видам деятельности и содержанию проектов. Крупная коммерческая компания, например, для удобства управления может формировать портфели по направлениям своей деятельности и закреплять управление портфелями за руководителями соответствующих видов деятельности. Для некоммерческих организаций цели и принципы формирования портфелей, ввиду различных целей деятельности некоммерческих организаций, зависят исключительно от специфики деятельности конкретной организации.

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

Ответы на эти вопросы зависят от специфики организации и не так очевидны, как может показаться на первый взгляд. Для примера рассмотрим структуру объектов управления органа государственной власти субъекта Российской Федерации (например, N-ской области). В состав объектов управления входят:

Государственные программы N-ской области;

Подпрограммы Государственных программ N-ской области;

Мероприятия, входящие в подпрограммы Государственных программ N-ской области;

Проекты, входящие в мероприятия, входящие в подпрограммы Государственных программ N-ской области;

Инвестиционные проекты, включённые в программу социально-экономического развития N-ской области;

Инвестиционные проекты, реализуемые в рамках инвестиционной стратегии N-ской области;

и т. д.

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

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

1.5.2. Субъекты проектного управления

Описание субъектов проектного управления должно дать ответ на вопрос: «Кто осуществляет функции проектного управления?». Для описания субъектов проектного управления обычно применяют ролевую или организационно-ролевую модели, отражающие состав участников проектного управления (в широком смысле – в рамках системы проектного управления организации, или в узком смысле – в рамках конкретного проекта) и их взаимосвязи.

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

Можно выделить два типа участников проектного управления: коллективные (Проектный комитет, Проектный офис, Координационный комитет, рабочие группы по направлениям и проч.) и одиночные (Куратор проекта, Заказчик, Руководитель проекта, Руководитель портфеля проектов, Администратор проекта и проч.).

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

1. Заказчик проекта – физическое или юридическое лицо, которое является владельцем результата проекта;

2. Руководитель проекта – лицо, осуществляющее управление проектом и ответственное за результаты проекта;

3. Куратор проекта – лицо, ответственное за обеспечение проекта ресурсами и осуществляющее административную, финансовую и иную поддержку проекта;

4. Команда проекта – совокупность лиц, групп и организаций, объединённых во временную организационную структуру для выполнения работ проекта.

Ролевая модель проектного управления, отражающая основных участников проекта в соответствии с ГОСТ, приведена на рисунке 1.6.

Приведённые выше описания участников проекта и их ролей в проекте представляют собой минимальный достаточный набор для реализации проекта (в соответствии с ГОСТ Р-54869-2011).

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

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


Рисунок 1.6. Ролевая модель проектного управления


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

Участники проекта в структуре управления проектом располагаются на разных уровнях управления проектом. Состав уровней управления проектом приведён на рисунке 1.7.


Рисунок 1.7. Уровни управления проектом


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

Уровень определения идеи и целей проекта. Этот уровень можно охарактеризовать как стратегический уровень управления проектом. Здесь рождается идея проекта – как самостоятельного предприятия, или как составной части программы или портфеля проектов, реализуемых организацией, происходит обоснование проекта и формулировка его целей, утверждение лимитов денежных средств на проект и сроков его реализации. Детализация планов – минимальная, периодичность контроля – максимальная, по вехам и целевым показателям. Как правило, на этом уровне находится руководство организации – Заказчика проекта.

Уровень формализации проекта и тактического управления проектом. Предназначение данного уровня – формализация проекта в виде конкретного договора или контракта и управление его выполнением на том уровне детализации, который определён договором или контрактом. Контроль хода работ на уровне целевых и контрольных показателей проекта, в соответствии с укрупнённым планом проекта, на уровне вех и контрольных точек. На этом уровне обычно действует куратор проекта от Заказчика.

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

Уровень исполнения проекта. На этом уровне осуществляется непосредственное выполнение работ по проекту. Детализация работ проекта – максимальная, периодичность контроля и отчётности – минимальные. Обычно на этом уровне управления проекта располагаются исполнители-субподрядчики или рабочие группы по направлениям работ проекта.

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

1.5.3. Процессы проектного управления

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

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

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

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

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

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

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

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

Общий принцип определения процессов проектного управления – их соотнесение с ролями команды управления проектом. Не выполняемые командой проекта процессы – за рамками проектного управления.

Следует отделять процессы проектного управления, выполняемые в рамках этапов жизненного цикла проекта, от процессов, не выполняемых в рамках этапов жизненного цикла проекта. Первые процессы можно определить как ОСНОВНЫЕ, вторые – как ПОДДЕРЖИВАЮЩИЕ проектное управление. Общий состав процессов проектного управления приведён на рисунке 1.8.

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

Выбор формата описания процессов зависит от предпочтения заказчика и от удобства использования того или иного формата в конкретном случае. Описание процессов рекомендуется выполнять как минимум в текстовом и табличном видах, по возможности дополнив описанием в виде диаграммы или модели процесса, описанной в одном из распространённых форматов описания процессов (например, ЕРС- Event Driven Process Chain – нотация описания цепочки процесса, управляемого событиями).

Пример описания процесса в табличном виде приведён в таблице 1.2. Примеры описания процесса в виде схемы процесса в формате ЕРС и дорожечной диаграммы приведены на рисунках 1.9. и 1.10.

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


Рисунок 1.8. Состав процессов проектного управления


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

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


Рисунок 1.9. Пример описания процесса в виде диаграммы ЕРС


Таблица 1.2. Пример табличного описания процесса


Рисунок 1.10. Пример описания процесса в виде дорожечной диаграммы

1.5.4. Нормативное обеспечение проектной деятельности

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

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

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

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

Представленный на рисунке 1.11. состав документов отражает общие направления разработки нормативной базы проектного управления организации.

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


Рисунок 1.11. Основные документы системы проектного управления организации

1.5.5. Технологическое обеспечение проектной деятельности

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

Применение специализированного программного обеспечения позволяет повысить эффективность выполнения процессов проектного управления за счёт:

Сокращения трудозатрат при выполнении процессов проектного управления;

Улучшения коммуникаций участников проектной деятельности за счёт использования общих информационных ресурсов;

Повышения скорости выполнения процессов проектного управления и процесса мотивации участников проектов;

Минимизации количества ошибок проектной информации;

Автоматизированной обработки и централизованного хранения информации о проектах.

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

1. Базовые системы поддержки проектного управления. Представляют собой специализированное программное обеспечение, предназначенное для выполнения узкого набора базовых процессов проектного управления, например календарного планирования, учёта проектных трудозатрат, фиксации проектных решений и т. д. Базовые системы обычно имеют локальный режим работы, устанавливаются на персональном компьютере пользователя, обычно руководителя проекта или администратора. К таким системам можно отнести Microsoft Project локальная версия (Microsoft, США), Open Project (Serena Software, США) и другие.

2. Расширенные системы поддержки проектного управления. К ним можно отнести программное обеспечение, предназначенное для поддержки широкого набора «классических» процессов проектного управления. Такие информационные системы содержат взаимосвязанные данные разных процессов проектного управления, могут иметь возможность разного представления данных для разных уровней управления организации, возможность многопользовательской работы, но обычно имеют ограниченные возможности интеграции со смежными информационными системами. К системам данного класса можно отнести такие системы как РМ Foresight (ГК «Проектная ПРАКТИКА», Россия), ADVANTA (Адванта Труп, Россия), Microsoft Enterprise Project Management (Microsoft, США) и др.

3. Продвинутые системы поддержки проектного управления. Представляют собой эволюционное развитие систем, относящихся к классу «Расширенные». Отличаются от них в первую очередь тем, что позволяют интегрировать проектную деятельность с другими видами деятельности и процессами организации за счёт создания единого информационного пространства, использования продвинутых механизмов интеграции данных. Точнее будет сказать, что это уже не специализированные системы поддержки процессов проектного управления, а комплексные информационные системы, создающие единое информационное пространство организации, и включающие в себя, в том числе, и функционал для поддержки процессов проектного управления. Примерами таких систем могут служить Oracle e-Busines Suite (ORACLE, США), SAP ERP (SAP, Германия).

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

1.5.6. Персонал: компетенции и мотивация

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

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

1.5.6.1. Компетенции

Компетенции – набор знаний, умений и опыта, личностных качеств, требуемых от участника проектной деятельности[26].Способность применять знания, умения, успешно действовать на основе практического опыта при решении задач в рамках проектной деятельности определяют компетентность специалиста в области проектной деятельности.

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

Руководство организации;

Сотрудники подразделений, ответственных за организацию, осуществление и сопровождение проектной деятельности (Проектные офисы, Центры компетенций и т. д.);

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

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

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

С этой целью для всех трёх групп участников проектной деятельности рекомендуется пройти обучение проектному управлению как минимум в рамках общего базового курса по проектному управлению.

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

ДЛЯ РУКОВОДСТВА ОРГАНИЗАЦИИ – курсы, направленные на приобретение навыков достижения стратегических целей организации за счёт применения инструментов и методов проектного управления, курсы по управлению программами, портфелями проектов, управлению по показателям и т. д.

ДЛЯ СОТРУДНИКОВ ПРОЕКТНЫХ ПОДРАЗДЕЛЕНИЙ:

курсы, развивающие навыки, связанные с выполнением конкретных процессов проектного управления: календарное планирование, управление рисками, управление коммуникациями и т. д.;

курсы, обучающие навыкам использования информационных систем и специализированных инструментов поддержки процессов проектного управления (MS Project, Sure Trak Project Manager, Open Plan, Spider Project, PM Foresight и т. д.);

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

ДЛЯ ПРОЧИХ УЧАСТНИКОВ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ – курсы по освоению навыков в зависимости от роли и функций участника в проектной деятельности, а также курсы, формирующие навыки ролевого поведения и взаимодействия участников проекта.

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

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

1. ЛИЧНОСТНЫЕ КОМПЕТЕНЦИИ. Данная группа компетенций отражает личностные качества, требуемые от участника проектной деятельности. К основным личностным компетенциям, по которым рекомендуется проводить оценку участников проектной деятельности, относятся:

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

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

Личная эффективность. Компетенция позволяет оценить, обладает ли специалист высокой работоспособностью, стрессоустойчивостью, ответственностью и т. д.;

Другие личностные компетенции.

2. КОМПЕТЕНЦИИ В ОБЛАСТИ ПРОЕКТНОГО УПРАВЛЕНИЯ предназначены для оценки, насколько компетентен участник проектной деятельности при выполнении своих функций в рамках областей знаний проектного управления – планирования, интеграции, управления рисками, закупками, заинтересованными сторонами и т. д.

3. СПЕЦИАЛЬНЫЕ КОМПЕТЕНЦИИ предназначены для оценки компетентности участника проектной деятельности при выполнении задач, связанных с управлением проектами в конкретной организации с учётом принятых в организации инструментов, технологий и методов проектного управления. К основным компетенциям, входящим в данную группу, можно отнести навыки делового администрирования, знание и умение владения персональным компьютером, знание и соблюдение норм и стандартов организации и т. д. Отдельно следует выделить компетенции в предметной области выполняемого проекта (например, знание информационных технологий, отдельных информационных систем, стандартов).

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

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

1. Формирование оптимальных проектных команд и/или кадрового состава организации;

2. Реализация прозрачной мотивационной политики и определение приоритетов по направлениям развития персонала;

3. Оценка эффективности отдельных процессов и выявление причин возможных проблем. [18]

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


Рисунок 1.12. Группы компетенций


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

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

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

1.5.6.2. Мотивация

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

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

Объём данной книги не позволяет подробно остановиться на теоретических аспектах мотивации персонала и это будет не совсем уместно, т. к. тема мотивации уже достаточно хорошо освещена в научной и популярной литературе. Ответы на основные вопросы по мотивации можно найти в трудах Φ. Герцберга, А. Маслоу, В. Герчикова и др.

Остановимся на прикладных аспектах мотивации персонала, занятого в проектной деятельности. Хорошей практикой является создание системы проектной мотивации и утверждение этой системы распорядительным документов организации. Какие требования должны предъявляться к системе проектной мотивации?

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

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

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

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

Мотивация должна быть своевременной.

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

Мотивация участников проектной деятельности должна быть направлена на:

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

Стимулирование командной работы.

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

Повышение уровня проектной дисциплины.

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

Как было сказано выше, мотивация имеет различные аспекты. Для удобства применения рекомендуется выделять материальные и нематериальные части мотивации.

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

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

Конец ознакомительного фрагмента.