Трудности в работе над проектом. Способы их преодоления

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

Перечислю топ-7 ключевых, с моей точки зрения, проблем внутренних проектов из своей более чем 10-летней практики управления внутренними проектами:

• Отсутствие штатного сотрудника, компетентного в управлении проектами;
• Совмещение роли заказчика и руководителя проекта в одном лице;
• Непонимание заказчиком проекта своей роли в проекте или неадекватное выполнение этой роли;
• Отсутствие у сотрудников компании мотивации на участие во внутренних проектах;
• Выделение запланированного времени на внутренний проект не по плану;
• Отсутствие у сотрудников практики отчетности за выполнение задач по проекту;
• Отсутствие правил приемо-сдаточных испытаний при сдаче результатов проекта.

Рассмотрим проблемы на примерах, после чего разберем способы их решения.

Допустим, компания решилась на проект внедрения CRM-системы. При этом принято решение о том, что доработку программного продукта, в случае необходимости, будет делать сторонняя ИТ-компания.

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

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

Теперь представьте, что руководителем проекта внедрения CRM назначили начальника отдела продаж и его же определили как заказчика проекта. В силу отсутствия опыта в управлении проектами начальник отдела продаж явно допустит ошибки при планировании проекта, чем заложит «бомбу» под проект. А совмещение двух ролей приведет к тому, что он начнет исправлять допущенные при планировании проекта ошибки через компромисс с самим собой относительно требований к CRM-системе. ИТ-компания не успевает дописать функциональность продукта, связанную с получением отчета по состоянию сделок? Откажемся от нее… А потом на этапе запуска системы, в случае неудачи, все свалим на ИТ-компанию или нерадивых сотрудников, которые не умеют пользоваться программой. Мое убеждение заключается в том, что между руководителем проекта и заказчиком должен быть здоровый конфликт интересов, который заключается в том, что руководителю проекта нужно сдать проект в срок и в бюджет, а заказчику проекта - получить ожидаемый результат и начать его использовать для решения его проблем. Поэтому я выступаю за то, чтобы во внутренних проектах не совмещать роль руководитель проекта и заказчика в одном человеке.

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

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

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

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

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

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

Итак, проблемы внутренних проектов разобрали, перейдем к рекомендациям:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение – утверждение (исполнителем) с указанием даты, утверждение (заказчиком) с указанием даты;

Исполнение – кто проводит анализ изменения, дата анализа, документ, подтверждающий исполнение (на конкретную дату), связанная форма «Запрос на изменение».

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

Из-за каких проблем возникают проекты?

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

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

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

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

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

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

Ошибки реализации проектов и сопутствующие проблемы

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

Обратите внимание: ни недостаток выделяемых финансовых ресурсов, ни уровень технологического развития не обозначены источниками ключевых затруднений. Акцент именно на несовершенстве управления. В принципе, вся проблематика, которую можно выявить в крупных проектах, хоть и в меньших масштабах, может быть перенесена на простые задачи. Интересны также исследования, которые были проведены PM Network в 1998 г., повторены в 2005 г. и в более позднее время. Они свидетельствуют, что 46-48% проектов имеют проблемы и чуть менее 28% не доводятся до результата вообще по тем же причинам.

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

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

Состав причин неудач проектов по данным исследований Metagroup («Why Operation Projects Fail?»), 2002 год

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

1. Упущения, связанные с объектом управления. Менеджер берется за проектную задачу, не до конца понимая, в чем состоит его объект (цели, результаты, границы, планы и т.д.).
2. Просчеты, относящиеся к субъекту управления (ошибки в учете интересов участников, в организационной структуре и т.п.).
3. Ошибки, связанные с процессами проекта (оценка рисков, недоработки в коммуникациях и т.д.).

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

1

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

квалификация управленческого персонала.

система вознаграждения

программное обеспечение

проблемы

управление проектами

1. Ветлужских Е. Система вознаграждения: Как разработать цели и KPI. – М. : Альпина Паблишер, 2013. - 217 с

2. Гаврилов Н.Н., Козлов А.С., Матвеев А.А., Богатов А.А. «Естественный отбор» руководителя проектом. - URL: http://www.pmsoft.ru/knowledgebase/articles/detail.php?ID=1500

3. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М. : Альпина Бизнес Букс, 2007. – 418 с.

4. Пятенко С.В. Методы анализа наиболее типичных проблем управления проектом / Элитариум: Центр дистанционного образования. - URL: www.elitarium.ru

5. A guide to the project management body of knowledge. PMBOK guide. 5th edition. – Project Management Institute, 2013. – 616 с.

Введение

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

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

Рис. 1. Проблемы и их решения в управлении проектами.

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

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

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

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

Даже применение ПО от лидеров сегмента — MS Project, Primavera, не страхует от возможных проблем, ведь это всего лишь инструменты, эффективно работающие в руках профессионала, а не искусственный интеллект, решающий все ваши проблемы .

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

Следующим способом решения выше обозначенных проблем является активное использование системы вознаграждения. Чаще всего в российских компаниях используется стандартная система вознаграждения: в небольших по длительности проектах (например, до шести месяцев) сотрудники поощряются за выполнение проекта в срок, а при более долгосрочных проектах - за завершение каждого этапа и всего проекта в срок. Причем за выполнение первого этапа проекта размер вознаграждения обычно меньше, чем за завершение всего проекта. Например, если проект состоит из трех этапов, а общее вознаграждение составляет 100%, то за завершение первого этапа выплачивается 20% от общей суммы вознаграждения, 30% - за второй и этап и за завершение всего проекта - остальные 50%.

При этом используются два варианта взаимосвязи с вознаграждением:

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

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

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

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

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

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

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

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

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

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

Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 2.

Рис. 2. Качественные соотношения динамики требований проекта и квалификации руководителя проекта.

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

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

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

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

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

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

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

Рецензенты:

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

Трещевский Ю.И., д.э.н., профессор, заведующий кафедрой экономики и управления организациями Воронежского государственного университета, г. Воронеж.

Библиографическая ссылка

Усова Ю.П., Чинарева О.И. ПРОБЛЕМЫ В УПРАВЛЕНИИ ПРОЕКТАМИ И СПОСОБЫ ИХ РЕШЕНИЯ // Современные проблемы науки и образования. – 2013. – № 6.;
URL: http://science-education.ru/ru/article/view?id=11844 (дата обращения: 20.03.2020). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»