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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

Продолжение

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

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

Цель проекта . Очень часто случается ситуация, когда руководство компании, начиная реализацию проекта, либо не до конца осознают, для чего начинается проект и какие преследует цели, либо у них полностью отсутствует это понимание. Человеческая натура в совокупности с данной ей должностью предполагает, что прекрасно знает назначение деятельности, которую они ведут, однако в 90% случаев руководители не понимают цели проектов. Очень часто на вопрос «Зачем нужна реализация проекта?» менеджеры отвечают не точно, например, «построить новый цех», однако никто не говорит, зачем необходим этот цех.

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

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

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

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

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

Отметим самые главные причины, которые влияют на появление данного явления:

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

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

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

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

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

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

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

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

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

Процессный подход позволяет:

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

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

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

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

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

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

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

Можно выделить наиболее часто встречаемые ошибки инвестиционного проекта в рамках данного признака:

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

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

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

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

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

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