Какая проблема может быть в бизнес проекте

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

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

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

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

Проблема с запуском какого либо проекта, бизнеса в чём же может быть причина / Отзыв для Olena Ruta

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

Определение альтернатив: 1) ничего не делать; 2) реструктурировать проект без новых ресурсов; 3) добавить ресурсы для решения проблемы, не обращая внимания на стоимость; 4) перераспределить ресурсы внутри команды проекта; 5) устранить ресурсы из проекта; 6) расширить масштаб и/или цель проекта; 7) сузить масштаб и/или цель проекта; 8) решить проблему за пределами проекта; 9) изменить технологию работы в проекте.

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

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

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

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

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

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

«Понять. Простить.» 1201 серия — Любовь как бизнес-проект

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

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

Первый метод

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

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

Проблема 2. Состав команды: рекомендуется решать кадровые проблемы самостоятельно и мирно. Если такие меры не помогают, имеет смысл обсудить проблему с топ-менеджментом.

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

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

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

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

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

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

Второй метод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: hr-portal.ru

№4. Проблема, которую решает ваш проект

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

а особенно если значительно лучше, чем конкуренты 🙂

На каждом рынке есть так называемые opportunity gaps — пробелы между существующими продуктами и реальными потребностями людей. Любой из этих пробелов может стать нишей для вашего проекта. Как же правильно выбрать лучший из них?

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

великое всегда начинается с малого

Именно таким образом появился Фейсбук. Марк Цукерберг хотел сделать сайт, удовлетворяющий естественное студенческое любопытство по поводу своих сокурсников — и особенно сокурсниц. Будучи студентом сам, он прекрасно понимал что делать, и на его новом сайте в течении месяца зарегистрировалось более половины студентов Гарварда. Интерес к новому сервису был так высок, что шаги по подключению других учебных заведений были просто неизбежны. И только потом создатели поняли, что сайт, позволяющий поддерживать связь со знакомыми и организовывать сообщества, нужен не только студентам, а практически всем обитателям интернета.

такой замечательный сайт был, простой.

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

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

какие прекрасные капельки на логотипе!

Тем же путём на свет появились вездесущие теперь клейкие листочки Post-It Notes. Арт Фрай, сотрудник компании 3M, придумал нанести на листочки бумаги слабый клей, чтобы сделать закладки для своей нотной тетради (он пел в хоре). Обычные закладки постоянно вываливались, а портить тетрадь скотчем ему не хотелось. Решив свою собственную проблему, он обнаружил, что эти же листочки очень удобно использовать для напоминаний и обмена сообщениями в офисе. Так была открыта действительно огромная ниша на рынке, которую 3М на много лет полностью забрала себе.

и даже не только в офисе

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

Заинтересовавшись этим явлением, Андрей обнаружил, что совместные закупки очень популярны в России, однако в основном происходят на форумах, для торговли совсем не приспособленных. Здесь он и увидел классический «гэп», возможность создать успешный проект — удобный сайт совместных покупок.

неудобно — это ещё мягко сказано

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

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

Источник: spark.ru

Какая проблема может быть в бизнес проекте

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

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

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

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, не страхует от возможных проблем, ведь это всего лишь инструменты, эффективно работающие в руках профессионала, а не искусственный интеллект, решающий все ваши проблемы [2].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рецензенты:

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

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

Источник: science-education.ru