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

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

Алгоритм «Решение проблем»

Распознавание проблемы

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

Анализ проблемы

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

Определение альтернатив

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

Принять решение проблем

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

Объявление о решении и действиях

Одновременно с принятием решения проблемы!

Совершение действия

Совершать действия следует одновременно: если делать это последовательно, некоторое время будет существовать «гибрид» старого и нового.

Проверка и контроль исполнения

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

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

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

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

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

Первый метод

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

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

Проблема 3. Неэффективность управления крупным проектом: можно разбить команду на подкоманды, планируя их взаимодействие.

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

Проблема 5. Управление технологией: неразумно воспринимать технологию как должное - любая технология требует управления и активной оценки ее использования.

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

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

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

Второй метод

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

Проблема 1. Низкие результаты работы. Клиент считает, что группа не заинтересована в решении проблемы и ее члены не способны работать вместе.

Возможные причины:

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

Возможные способы коррекции ситуации:

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

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

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

Возможные пути решения проблем:

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

Проблема 3. Члены группы не могут работать как одна команда. Одна из наиболее распространенных проблем, как в функциональных, так и в проектных группах. Возможные причины:

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

Решение: проконсультировать топ-менеджмент по поводу распределения между ними полномочий и ответственности.

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

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

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

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

Резюме

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

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

Пятенко Сергей Васильевич,
генеральный директор «Экономико-правовой школы ФБК»,
д.э.н., магистр делового администрирования

Просмотры: 7 505

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. К чему приводит непонимание роли заказчика проекта - со стороны сотрудника, который на эту роль назначен?

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

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

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

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

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

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

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

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

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

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

Максим Якубович

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами - более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания - 10 лет. Около 2200 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.

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

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

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

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

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

Однако результаты этого нередко бывают противоположными и порождают типичные ошибки:

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

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

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

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

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

Выводы

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

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

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

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

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

На основании проведенной проверки составляется аудиторский отчет. Он выполняется в соответствии с конкретным проектом, реализуемым в конкретной организационной среде. Главная цель отчета - улучшить управление будущими проектами. Аудиторский отчет должен содержать следующую информацию: 1) краткое описание и классификацию проекта; 2) анализ собранной информации; 3) рекомендации по проведению корректирующих действий; 4) уроки - выводы на основе анализа причин недостатков управления проектом.

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

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

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

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

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

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

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

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

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

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

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

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