Основные проблемы проектного менеджера и как с ними бороться
Время на прочтение
3 мин
Количество просмотров 19K
Постарался расставить проблемы, с которыми сталкиваемся, по степени их влияния на исход проекта. К некоторым болезням проектного менеджмента удалось найти лекарства, но некоторые по-прежнему дают большие риски, которые съедают бюджеты и ресурсы.
Хочу попросить не отсылать к известным методологиям PMI, PRINCE2 и т.д. Так как в них указаны диапазоны бюджетов, в которых применимость их будет давать эффект больший чем затраты на саму методологию — это от 50 000 $ USA. Интересуют решения для проектов бюджетами от 5 000 до 30 000 $ USA.
1. Неправильная оценка проекта. Почти все заказчики хотят fix-cost. И это правильно с их точки зрения, только имея понимание об этом, они принимают решение запускать или не запускать проект.
Как лечится: выделение консалтинга в отдельный проект. По результатам имеем концепт проекта, ТЗ, ИСР, бюджет, календарь.
2. Противодействие или отсутствие действий со стороны персонала заказчика на этапе внедрения. На проект деньги еще выделяют, а зарплатный фонд никто не увеличивает на работы во время переходного процесса, например когда на предприятии работают две системы учета, или на обучение.
Как лечится: обучение заказчика, создание у него центра компетенции.
3. Ошибки при проработке требований заказчика. Все требования вроде как и фиксируются, систематизируются, но требования исходят от разных отделов и людей. Люди меняются и к моменту, когда есть результат, на месте внедрения оказываются уже другие люди с другими взглядами. Никто не отслеживает кто и как меняется, и нет процедуры чтобы вызвать инициативные изменения требований со стороны Заказчика.
Как лечится: управление требованиями, утвержденная процедура изменения требований.
4. Учет изменений на проекте и документация особенностей. Реализация идет с согласованными отклонениями от постановки, и это нормально, но когда проект уже запущен и летит, никто не занимается документацией этих отклонений и «фич». В итоге, если приходит новый человек на проект или его в дальнейшем надо сопровождать, то чтобы ввести его в курс дела, ничего нет кроме как первоначального устаревшего ТЗ и спецификаций. Проект изменился, он уже другой. Денег на исправление нет никогда. Такой проект становится кошмаром для support.
Как лечится: фиксировать все изменения в концепте проекта, хотя это ресурсозатратно.
5. Недостаточная обеспеченность проекта ресурсами. Сюда можно включить все разнообразие:
a. Людей не выделяют в нужном количестве и нужной квалификации
b. Людей забирают в середине проекта на тушение пожаров
c. Людей забирают в середине проекта на support их прошлых проектов
d. Неадекватная замена исполнителей
e. Текучка на проекте – уходят те, кто «в теме», а набирают тех, кого найдут
Лекарства пока нет. Видимо такова специфика отрасли – «овертаймить» и проваливать сроки.
6. Замыкание многих процессов на самых компетентных и перегрузка их работой. Нет делегирования. Всегда на проекте те кто знает и делает и те кто делает только если скажут. Ответственные и компетентные люди не всегда используют делегирование или этому не способствует обстановка в команде.
Лекарства пока нет. Видимо такова специфика отрасли IT. Хорошие инженеры и программисты по своей природе интраверты. Все говорят о Agile team building как лекарстве, но пока не получилось. Так как этот процесс утянет и так ограниченные ресурсы и деньги, понадобится компетентный и недешевый HR. Если у кого есть идеи, посоветуйте.
7. Много средств требует поддержка инфраструктуры и управление ей. Сколько не пиши правила где девелопим, как деплоим где тестируем, как выливаем релизы — в PMI это называется «Концепция проекта», — все же постоянно нужно проверять, разъяснять наказывать, и в итоге ПМ берет на себя все больше и больше участков работы.
Как лечится. Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.
8. Сложность постановки процесса разработки под конкретный проект. Тут как не унифицируй, но каждый проект уникален в плане какие сервера, где стоят какой к ним доступ. Как пример — есть заказчики, которые выделяют к себе только узкий VPN через которые должны все ходить.
Как лечится. Выделение ресурса на процесс планирование и прямое отражение этой статьи в затратах.
9. Отсутствие итерационности в проекте. Заказчику нужно показывать и давать оценивать промежуточные результаты, чтобы понимать, что мы не сбились с пути. А у заказчика не всегда есть время на оценку. А надо лететь дальше, так как заказчику нужны сроки, а не оправдания и не дай бог его потыкать носом в не отвеченные запросы.
Как лечится. Введение в проект роли «аккаунт менеджер» который постоянно на связи с заказчиком и выдергивает из него все необходимое.
10. Плохое использование прошедшего опыта разработок и отсутствие условий его накопления и использования в будущем. Когда проект «горит» никто не думает о формирований библиотек или модулей для использовании в будущем. В итоге постоянное изобретение велосипедов вместо производства.
Лекарства пока нет. Если есть опыт посоветуйте, как замотивировать ПМ и разработчиков на выполнение этого процесса?
- Авторы
- Резюме
- Файлы
- Ключевые слова
- Литература
Усова Ю.П.
1
Чинарева О.И.
1
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, не страхует от возможных проблем, ведь это всего лишь инструменты, эффективно работающие в руках профессионала, а не искусственный интеллект, решающий все ваши проблемы [2].
Понимание алгоритмов, лежащих в основе ПО, или хотя бы поверхностное знание методик, применяемых в управлении проектами, поможет вам избежать множества проблем.
Следующим способом решения выше обозначенных проблем является активное использование системы вознаграждения. Чаще всего в российских компаниях используется стандартная система вознаграждения: в небольших по длительности проектах (например, до шести месяцев) сотрудники поощряются за выполнение проекта в срок, а при более долгосрочных проектах – за завершение каждого этапа и всего проекта в срок. Причем за выполнение первого этапа проекта размер вознаграждения обычно меньше, чем за завершение всего проекта. Например, если проект состоит из трех этапов, а общее вознаграждение составляет 100%, то за завершение первого этапа выплачивается 20% от общей суммы вознаграждения, 30% – за второй и этап и за завершение всего проекта – остальные 50%.
При этом используются два варианта взаимосвязи с вознаграждением:
- вариант жесткий (одноуровневый): если этап (проект) выполнен в срок, менеджер получает вознаграждение, если нет – наказывается и остается без премии. Такой вариант используется в проектах, имеющих жесткие сроки выполнения (например: Олимпиаду нельзя перенести, все строительные объекты должны быть сданы вовремя).
- вариант более мягкий: разрабатывается таблица с пороговым значением, при котором уже возможна выплата вознаграждения.
Участники проектов вознаграждаются при достижении поставленных целей всей командой проекта, а также за выполнение в срок своих операций.
Преимущество такой системы вознаграждения: сбалансированность, комплексность, прозрачность и понятность. Однако, несмотря на все плюсы данной системы вознаграждения, следует выделить проблемы, которые возникают при использовании данной системы вознаграждения.
Чтобы получить вознаграждение, каждый менеджер проектов при оценке длительности работ закладывает достаточный (не всегда необходимый) временной резерв на непредвиденные обстоятельства, а также запас по бюджету. Причем, если даже проект можно завершить раньше срока, менеджеры этого не делают, т.к. не получают за это дополнительного поощрения и опасаются того, что в следующий раз руководство, скорее всего, сократит планируемую длительность проекта. И если даже сотрудник (участник проекта) выполнил свою операцию раньше срока, это никак не поощряется руководителем, разве что он может нагрузить его дополнительной работой. Поэтому сотруднику нет никакого смысла завершать свою операцию раньше срока. То же самое с бюджетом, нет никакого резона его экономить.
Если проект можно выполнить раньше срока, то экономится ресурс – оплачиваемые человеко-часы (кроме того, свободных специалистов можно будет уже занять другим проектом). Но это никому не выгодно: есть риски, что руководство на следующем подобном проекте урежет бюджет. Поэтому сотрудники делают вид работы или спокойно работают над улучшением полученных результатов. В результате менеджеры учат подчиненных соблюдать установленные сроки и не поощряют сотрудников, закончивших работу досрочно. Кроме того, некоторые «умные» сотрудники иногда специально задерживают сроки сдачи работы, чтобы получить оплату за сверхурочные.
Свое негативное влияние оказывает и так называемый студенческий синдром: большинство людей склонны откладывать выполнение задания до последнего. Исследования показали, что менее трети задания обычно выполняется в первые две трети срока, отведенного на него, и две трети – за последнюю треть срока. Кроме того, сотрудников постоянно отвлекают на выполнение новых заданий, а многозадачность, как известно, ведет к увеличению длительности выполнения проекта. Чтобы быть хорошим в глазах руководителя, сотрудник просто обязан брать и выполнять новые задания, в результате – он перегружен, что часто приводит к стрессу и в конечном итоге еще к большему увеличению длительности проекта. Поэтому проекты редко выполняются досрочно. Если бы некоторые этапы проекта завершались сотрудниками досрочно, то возникающий запас времени мог бы использоваться на непредвиденные обстоятельства, которые всегда могут возникнуть на завершающих этапах проекта [1].
А так получается, что существует постоянный конфликт между целями компании: удовлетворением требований клиента и руководства, достижением большего результата за минимальные сроки и деньги и личными целями каждого члена команды — личной успешностью (а для этого нужно закладывать запас времени, не сдавать работу досрочно, укладываться в бюджет, но ни в коем случае не экономить, брать новые задания, чтобы быть хорошим в глазах руководителя и т.д.). Формируется определенный стереотип поведения, выгодный сотруднику. Получается, что вроде все работают хорошо с точки зрения индивидуального результата, но нужных результатов для бизнеса нет [3].
В настоящее время квалификация управленческого персонала на промышленных предприятиях не отвечает международным требованиям к компетентности специалистов по управлению проектами. В связи с этим возникает необходимость обучения сотрудников предприятий проектному менеджменту. С учетом вступления России во Всемирную торговую организацию, перехода предприятий России на международную систему финансовой отчетности повышается необходимость создания на каждом предприятии отдела управления проектами, отвечающего за вопросы анализа и мониторинга инвестиционных проектов развития.
Уникальность проекта диктует необходимость владения междисциплинарными знаниями и навыками, в отличие от руководителя функциональной организации, который может являться профессионалом только в одной области.
Для иллюстрации такой ситуации введем качественные показатели «требования проекта» и «квалификация руководителя проекта». Под понятием «требования проекта» будем понимать совокупный уровень знаний и навыков, необходимых для успешной реализации проекта. Под понятием «квалификация руководителя проекта» будем понимать совокупный уровень знаний и навыков, которыми обладает руководитель проекта на определенный момент времени. Требования проекта и квалификация руководителя проекта – это динамичные характеристики [2].
Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 2.
Рис. 2. Качественные соотношения динамики требований проекта и квалификации руководителя проекта.
Введем предположение, что по мере выполнения проекта его требования сначала возрастают за счет постоянного уточнения и детализации требований к продукту, услуге, цели проекта. Затем, достигнув максимального уровня, состав и уровень требований стабилизируются и некоторое время могут оставаться неизменными, определяясь требованиями к качеству проекта. Далее, при завершении проекта, его требования естественным образом снижаются (в принципе, до нулевого уровня к завершению проекта). Вместе с тем с развитием технологий требования каждого следующего проекта больше, чем у предыдущих подобных ему проектов в той же прикладной области. Введенное предположение верно не для всех проектов — требования к проекту могут уменьшаться или оставаться постоянной величиной [2; 3].
Квалификация же руководителя проекта в большей степени определяется личностными характеристиками. В каждый конкретный момент своей жизни руководитель проектов должен принимать решение: либо повышать свою квалификацию, либо остаться на прежнем уровне. В принципе, может существовать и третий вариант — деградация, но такие ситуации мы рассматривать не будем. Однако важно принимать во внимание, что при современных темпах развития технологий, оставаясь на прежнем уровне развития, человек в каком-то смысле деградирует в своем профессиональном развитии.
При «входе» в проект квалификация руководителя проекта должна быть не ниже требований проекта на момент вхождения. В ходе реализации проекта квалификация руководителя проекта должна все время соответствовать требованиям проекта. Если по каким-либо причинам на некотором интервале времени требования проекта превышают квалификацию руководителя проекта, то можно утверждать, что данный проект с данным руководителем будет либо выполняться не эффективно и потребуется заменить руководителя проектом, либо вообще проект потерпит фиаско. Для дальнейшего продолжения карьеры в качестве руководителя проектов, по завершении очередного проекта, квалификация его руководителя должна соответствовать требованиям следующего проекта [5].
Исходя из всего сказанного, можно сказать, что понятия «требования проекта» и «квалификация руководителя проекта» естественным образом взаимосвязаны. Для того чтобы быть руководителем проекта, необходимо иметь соответствующую квалификацию и постоянно ее повышать. С другой стороны, для управления конкретным проектом необходим профессионал соответствующей квалификации.
Возникновение тех или иных проблем в процессе выполнения проекта — нормальное явление. Существует немало разнообразных методов их структуризации и разрешения. Выбор наиболее эффективного метода зависит от множества разных обстоятельств. Главное — работать над разрешением проблем систематически и организованно. Накопленный опыт позволяет выявить обычные ошибки при решении проблем:
- неосведомленность о проблеме;
- неверный «диагноз»;
- решение не «продано» топ-менеджменту;
- принятие решений без запланированных действий;
- действия при отсутствии рамок решения;
- неспособность действовать тогда, когда нужно;
- действия, не соответствующие принятым решениям [4].
Таким образом, в данной статье мы рассмотрели решение некоторых проблем, возникающих в ходе управления проектом. Появление их нельзя считать чем-то необычным или неестественным – без них не обходится ни один проект, однако умение вовремя определить проблему, выявить причины ее возникновения и устранить их и является основным достоинством проектного менеджера.
Рецензенты:
Демченко А.Ф., д.э.н., профессор кафедры экономики, финансов и менеджмента Воронежского филиала Российской академии народного хозяйства и государственной службы при Президенте Российской Федерации, г. Воронеж.
Трещевский Ю.И., д.э.н., профессор, заведующий кафедрой экономики и управления организациями Воронежского государственного университета, г. Воронеж.
Библиографическая ссылка
Усова Ю.П., Чинарева О.И. ПРОБЛЕМЫ В УПРАВЛЕНИИ ПРОЕКТАМИ И СПОСОБЫ ИХ РЕШЕНИЯ // Современные проблемы науки и образования. – 2013. – № 6.
;
URL: https://science-education.ru/ru/article/view?id=11844 (дата обращения: 20.05.2023).
Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»
(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)
В прошлом считалось, что опыт управления проектами практически нельзя обобщить, поскольку каждый проект уникален, как следствие такой области, как «решение проблем» уделялось мало внимания. Но постепенно становится очевидным, что управление проблемами является ключевым ингредиентом успеха проекта: с проблемами надо разбираться, иначе прогресс замедлится, и проект пострадает.
Накопленный опыт позволяет составить определенный алгоритм решение проблем, складывающийся из последовательных шагов.
Алгоритм «Решение проблем»
Распознавание проблемы
Прежде всего необходимо ответить на следующие вопросы: связан ли симптом с существующей проблемой; можно ли объединить симптом с чем-то, происходящим в настоящий момент; каковы характерные черты проблемы; какую приоритетность следует ей приписать; что нужно сделать с проблемой сначала.
Анализ проблемы
Для этого используется сочетание прямых наблюдений, интервью, обзоров документов и заседаний. При сборе информации не всегда целесообразно привлекать внимание к проблеме — целесообразно говорить о симптомах и возможных действиях. Рекомендуется начать с сотрудника, который предложил усовершенствование, собрать как можно больше информации, определить категорию проблемы, дать ее трактовку — от консервативной до радикальной, сосредоточиться на действиях.
Определение альтернатив
- ничего не делать;
- реструктурировать проект без новых ресурсов;
- добавить ресурсы для решения проблемы, не обращая внимания на стоимость;
- перераспределить ресурсы внутри команды проекта;
- устранить ресурсы из проекта;
- расширить масштаб и/или цель проекта;
- сузить масштаб и/или цель проекта;
- решить проблему за пределами проекта;
- изменить технологию работы в проекте.
Принять решение проблем
Действия в данном контексте обычно подразумевают или политику, или изменения плана и меры в отношении ресурсов. Выбрав решение и определив действия, следует проинформировать топ-менеджмент о проблеме и рекомендованном подходе.
Объявление о решении и действиях
Одновременно с принятием решения проблемы!
Совершение действия
Совершать действия следует одновременно: если делать это последовательно, некоторое время будет существовать «гибрид» старого и нового.
Проверка и контроль исполнения
Результаты действий и решений должны проявиться вскоре после их претворения в жизнь. Для этого следует ответить на вопросы: вылечена «болезнь» или только ее симптомы; не создают ли побочные результаты решений новые проблемы; существуют ли дополнительные области, где можно применить эти действия, и решения с небольшими дополнительными усилиями.
Для практического применения можно предложить три различных по уровню детализации способа структуризации и анализа возникающих проблем:
- формулирование проблемы и возможные последствия;
- выделение определенных проблемных областей и мониторинг потенциальных сложностей;
- структуризация проблем и возможных способов их решения.
Каждый из этих методов имеет как преимущества, так и недостатки. На практике возможна любая их комбинация. Главное — осознать: проблемы можно структурировать и анализировать с использованием определенных алгоритмов. Далее приводятся примеры рассмотрения проблем различными способами.
Всегда существует несколько вариантов решения проблемы, но использование неправильного подхода может лишь усугубить ситуацию. Даже чрезмерным привлечением внимания к проблеме можно нанести вред — иногда это вызывает панику. Еще один вариант — набрать новых членов команды, однако их придется вводить в курс дела, что отвлечет сотрудников от продуктивной работы и замедлит координацию и принятие решений.
Первый метод
Возникающие в процессе реализации проекта проблемы можно условно разделить на несколько групп и порекомендовать некоторые методы их наиболее эффективного решения.
Проблема 1. Моральный дух команды: если моральный дух слаб, разумно укреплять его «снизу вверх», повышать уверенность сотрудников в себе, обеспечивать дополнительную поддержку. Если моральный дух силен, не обольщайте себя тем, что все идет хорошо, — у команды может быть просто завышена самооценка.
Проблема 2. Состав команды: рекомендуется решать кадровые проблемы самостоятельно и мирно. Если такие меры не помогают, имеет смысл обсудить проблему с топ-менеджментом.
Проблема 3. Неэффективность управления крупным проектом: можно разбить команду на подкоманды, планируя их взаимодействие.
Проблема 4. Создание дружеской атмосферы: если в проекте участвуют сотрудники, имеющие сложные отношения друг с другом, не стоит заставлять их работать вместе. Нужно организовать выполнение задач таким образом, чтобы ограничить их контакт.
Проблема 5. Управление технологией: неразумно воспринимать технологию как должное — любая технология требует управления и активной оценки ее использования.
Проблема 6. Изъятие из проекта критически важных ресурсов: следует с самого начала учитывать, что такая угроза существует; четко представлять себе потребности, настаивать на получении определенных ресурсов, учитывая при этом состояние бизнеса фирмы в целом.
Проблема 7. Низкие показатели деятельности и отставание от графика: прежде всего необходимо выявить причины ее возникновения (задачи не были включены в план; проект вовремя не получает ресурсов; команда не выполняет работу в срок и т. д.). Часть проблем можно предотвратить за счет четкого планирования, однако, если проблема все же возникает, стоит поговорить с командой и выяснить, что можно сделать, чтобы разрешить ее с имеющимися ресурсами.
Проблема 8. Координация работы с поставщиками и подрядчиками: еще до начала проекта следует выяснить личный интерес поставщика или подрядчика и использовать его. При выборе поставщиков или подрядчиков необходимо четко формулировать задачи проекта. Для облегчения координации работы с ними выявить зависимости между проектами; определить способы контроля качества и изменения графика и приоритетов; установить процесс координации между проектами на уровне менеджера проекта и ниже.
Второй метод
Рассмотрим три проблемы, которые могут возникнуть в группах, их причины и возможные пути решения.
Проблема 1. Низкие результаты работы. Клиент считает, что группа не заинтересована в решении проблемы и ее члены не способны работать вместе.
Возможные причины:
- члены группы не могут достичь согласия по поводу задачи группы;
- задача группы в отношении результата и ресурсов была поставлена нечетко;
- менеджеры не справляются с работой;
- руководитель проектной группы не имеет соответствующих полномочий или лидерских качеств;
- члены группы не обладают достаточными техническими и функциональными качествами.
Возможные способы коррекции ситуации:
- более четко сформулировать задачу группы;
- прояснить разделение функций и подотчетность в группе;
- организовать тренинг руководителю группы по лидерству;
- провести тренинг для членов группы по техническим и функциональным навыкам.
Проблема 2. Личностные конфликты в группе. В команде проекта существуют очень сильные противоречия. Основываясь на опыте, предположим следующие причины межличностных конфликтов в группах:
- члены группы уверены в том, что именно они, а не менеджер, несут полную ответственность за результаты работы группы;
- руководитель группы не распределил задания и ответственность между членами группы.
Возможные пути решения проблем:
- дать понять членам группы, что руководитель отвечает за результат ее работы;
- объяснить каждому сотруднику круг его обязанностей и ответственности и провести общее собрание для разрешения возникших конфликтов.
Проблема 3. Члены группы не могут работать как одна команда. Одна из наиболее распространенных проблем, как в функциональных, так и в проектных группах. Возможные причины:
- руководители не могут прийти к согласию по поводу конкретной задачи группы и подотчетности;
- задача группы была поставлена нечетко с точки зрения результата и ресурсов.
Решение: проконсультировать топ-менеджмент по поводу распределения между ними полномочий и ответственности.
Во всех трех случаях мы рассматривали ситуации с иерархической структурой группы. Предположим, мы имеем дело с группой партнеров. В зависимости от предполагаемых причин проблем, можно предложить одно из следующих решений:
- выработать коллективное видение задания группы в отношении ресурсов и результатов;
- выработать персональное видение задачи каждого в отношении ресурсов и результатов;
- обсудить совместно значимость разделения обязанностей и распределить сферы ответственности между членами группы;
- провести обучение членов группы по лидерству, навыкам межличностного общения и техническим. Особый акцент сделать на коллективных обсуждениях, разрешении конфликтов.
Разумеется, это далеко не полный список проблем, причин их возникновения и возможных действий. Но сама методология анализа ситуации достаточно универсальна.
База данных по проблемам. По опыту, полезно иметь базу данных по проблемам, для составления которой не требуется много усилий. Вот ее основные элементы: опознавательный код проблемы; статус (выявлена, решена, анализируется, завершена и пр.); уровень приоритетности; на что воздействует; дата возникновения; описание; сотрудник, отвечающий за проблему; дата ожидаемого решения; код решения (заменен на другой, решено, отложено на неопределенный срок, завершено); решение по проблеме; действия; комментарии.
Резюме
Возникновение тех или иных проблем в процессе выполнения проекта — нормальное явление. Существует немало разнообразных методов их структуризации и разрешения. Выбор наиболее эффективного метода зависит от множества разных обстоятельств. Главное — работать над разрешением проблем систематически и организованно. Накопленный опыт позволяет выявить обычные ошибки при решении проблем:
- неосведомленность о проблеме;
- неверный «диагноз»;
- решение не «продано» топ-менеджменту;
- принятие решений без запланированных действий;
- действия при отсутствии рамок решения;
- неспособность действовать тогда, когда нужно;
- действия, не соответствующие принятым решениям.
Пятенко Сергей Васильевич,
генеральный директор «Экономико-правовой школы ФБК»,
д.э.н., магистр делового администрирования
Просмотры: 17 413
Если проект – это корабль, то управление проектом – это его парус. Управление проектом – это то, что обеспечивает руководство конкретным проектом, чтобы направить его к успеху. Однако при выполнении проекта можно столкнуться с беспрецедентными проблемами управления проектами.
Creately совместно с командой Proofhub и ее директором по маркетингу Вартикой Кашьяп провели Twitter-чат, намереваясь пролить свет на 10 самых больших проблем в управлении проектами и на то, как их избежать.
Ниже приводится список проблем и ответы участников на них.
Вызовы
- Демонтаж изолированных структур и создание среды, способствующей эффективному и результативному сотрудничеству и общению в рамках проекта
- Вклад правильного планирования в успех проекта
- Решение проблем управления проектом, возникающих, когда проектная команда не обладает необходимыми навыками для решения поставленной задачи
- Важность плана действий на случай непредвиденных обстоятельств в управлении проектом
- Создание среды подотчетности, в которой команда берет на себя ответственность за свои действия и должным образом выполняет возложенные на нее роли
- Улучшение взаимодействия с заинтересованными сторонами и обеспечение того, чтобы все были на одной волне
- Установление четких целей и критериев успеха для обеспечения успеха проекта
- Важность приобретения правильного программного обеспечения для управления проектами
- Улучшение взаимодействия проектной команды и укрепление доверия
- Распределение ресурсов на проект
Как устранить замкнутость и создать среду, способствующую эффективному и результативному сотрудничеству и общению в рамках проекта?
Команда проекта не может функционировать изолированно. Успешное выполнение проекта зависит от того, насколько эффективно каждый член команды сотрудничает друг с другом при выполнении задач. В связи с этим команда Proofhub подчеркнула важность ведения всех коммуникаций, связанных с проектом, через один общий портал, доступный всем членам команды.
“Подключите всех к одному коммуникационному порталу и позвольте всем ядерным командам участвовать без творческих ограничений. Каждый учит каждого!”
Proofhub
Дополняя заявление Proofhub, CMO Вартика Кашьяп также заявила, что использование коммуникационных инструментов и создание межфункциональных команд может обеспечить эффективное и результативное сотрудничество в рамках проекта.
“Создавайте межфункциональные команды. Используйте средства коммуникации. Обеспечить более открытую и прозрачную культуру”
Вартика Кашьяп
А как насчет удаленной работы? Пандемия способствовала быстрому росту удаленных схем работы из-за закрытия магазинов и ограничений на поездки. Creately направил Кашьяпу вопрос о дополнительных шагах, которые компания должна предпринять, чтобы избавиться от силосов в среде удаленной работы.
В ответ Кашьяп подчеркнул важность прозрачной культуры труда.
“Сделайте прозрачность новой культурой. Относитесь к общению как к улице с двусторонним движением. Боритесь с ямами продуктивности/вовлеченности с помощью виртуальных культурных инициатив”
Вартика Кашьяп
Исследование утверждает, что около 39% проектов терпят неудачу из-за недостатков в планировании проекта. Как планирование способствует успеху проекта?
Бывший президент США Дуайт Д. Эйзенхауэр однажды заявил: “Планы – ничто, планирование – все” План жизненно важен при выполнении проекта.
Компания Proofhub подчеркнула важность наличия надлежащего плана проекта.
“Планирование проекта сродни компасу и рулю на парусном судне. Вы все равно доберетесь до места назначения без них, просто это займет на 100 лет больше времени”
Proofhub
Участница Нандини Сехедев отметила многочисленные преимущества наличия плана проекта.
“Планирование проекта жизненно важно для предотвращения или минимизации рисков и количества неудач. Планирование проекта помогает направлять спонсоров, команды, заинтересованные стороны; а менеджер проекта ориентируется на сложных этапах проекта”
Нандини Сехдев
Как справиться с проблемами в управлении проектом, возникающими, когда у проектной команды нет необходимых навыков для решения поставленной задачи?
В процессе работы над проектом вы можете столкнуться с беспрецедентными трудностями или проблемами. В таких обстоятельствах вы сможете решить их без заметного влияния на ход проекта, если вооружитесь необходимыми навыками для борьбы с ними. Представьте себе ситуацию, когда вы не знаете, как решить проблему? Что же делать дальше?
Proofhub подчеркнул, что совместная работа команды над визуализацией рассматриваемой проблемы приведет к другой перспективе и вероятным решениям.
“Соберите команду, заставьте их говорить, выслушайте их и помогите им представить, что не так. Большинство команд способны решать проблемы, но медленно их подхватывают. Если вы станете их путеводной звездой, они найдут конец туннеля”
Proofhub
Визуальные рабочие пространства, такие как Creately, могут быть эффективными в отслеживании ваших шагов и переоценке процессов. Например, вы можете использовать причинно-следственную диаграмму, чтобы ( выяснить основные причины проблемы, и использовать карты ума ( для мозгового штурма решений.
Как устранить пробелы в навыках? Открыто общаться и создавать среду, в которой члены команды могут участвовать в увлекательном обучении.
“Открытое общение необходимо, если вы надеетесь успешно сократить разрыв в квалификации. Вы также можете создавать увлекательные учебные мероприятия, и недостаточно просто проводить обучающие программы, необходимо оценивать, насколько эффективны ваши стратегии”
Proofhub
Насколько важен план на случай непредвиденных обстоятельств в управлении проектом?
Ровное плавание в любой момент может превратиться в шторм, и если вы не обладаете достаточным мастерством, чтобы противостоять ему, вся миссия может зайти в тупик. План на случай непредвиденных обстоятельств может подготовить вас к успешному преодолению непредвиденных обстоятельств.
“Часто говорят, что ваш план А никогда не должен нуждаться в плане Б. Но на самом деле вам нужны планы С, D, E и F, просто на всякий случай. Непредвиденные обстоятельства – это беспокойство о проблемах сегодня, которые потенциально могут свести вас с ума завтра”
Proofhub
Как вы можете создать атмосферу подотчетности, в которой команда берет на себя ответственность за свои действия и должным образом выполняет возложенные на нее роли?
Первым шагом в обеспечении подотчетности в управлении проектами является четкое определение целей проекта и соответствующее распределение обязанностей между членами команды. Однако важно отметить, что существует разница между подотчетностью и ответственностью.
Например, ответственным членом команды может быть человек, которому поручено выполнение конкретного задания. Ответственность можно разделить. Подотчетный член команды является лицом, принимающим окончательное решение по заданию.
Кашьяп считает, что наделение людей необходимыми навыками и ресурсами для выполнения своей работы позволит им быть ответственными.
“Ваша цель должна заключаться в том, чтобы предоставить сотрудникам навыки и ресурсы, необходимые для выполнения их работы, а затем создать среду, в которой им будет легко взять на себя ответственность за свои решения и действия”
Вартика Кашьяп
С другой стороны, компания Proofhub подчеркнула, что четкое понимание ожиданий от проекта и последствий ответственности каждого человека создаст атмосферу подотчетности.
“Ответственность лучше всего понимается, когда ожидания ясны, а последствия более ясны. Покажите им весь игровой набор – мишень, дротик, как бить и что происходит, когда они промахиваются”
Proofhub
Creately задал вопрос: “Что происходит, когда члены команды не справляются со своими обязанностями?” В ответ на это компания Proofhub заявила, что первым шагом является беседа с человеком и, соответственно, предоставление обратной связи о том, как необходимо изменить ход действий.
“Ваш первый шаг – поговорить с заинтересованными лицами. Затем обеспечьте обратную связь, чтобы люди знали, что нужно изменить. То, что вы узнаете в ходе обсуждения, создает контекст для следующих действий, которые вы предпринимаете”
Proofhub
Невовлеченный клиент может стать причиной множества проблем. Как улучшить взаимодействие с заинтересованными сторонами и добиться того, чтобы все были на одной волне?
Еще одним ключевым фактором, определяющим успех проекта, является взаимодействие с заинтересованными сторонами. Взаимодействие с заинтересованными сторонами – это поиск поддержки и обратной связи с заинтересованными сторонами проекта для обеспечения достижения его целей.
Правильное управление заинтересованными сторонами включает в себя надлежащий анализ заинтересованных сторон с использованием реестра заинтересованных сторон для определения их требований. Вовлеченность заинтересованных сторон, как правило, выше в начале проекта и снижается по ходу его реализации. Чтобы избежать этого, важно поддерживать постоянную связь с заинтересованными сторонами с помощью инструментов совместной работы, средств удаленного общения и так далее.
Предоставляйте своим клиентам ежеминутные обновления, информацию из первых рук, своевременные отчеты и общайтесь с ними по установленному графику”. Привлеките их к участию, и вам никогда не придется перелистывать страницу. Именно это больше всего нравится нашим клиентам в работе с ProofHub!”
Proofhub
Плохо определенные цели и задачи могут погубить проект. Как установить четкие цели и критерии успеха для обеспечения успеха проекта?
Вы всегда должны ставить SMART-цели. Следующий шаг – разработать четкий план действий для достижения этих целей в течение срока реализации проекта. Наличие такого плана действий обеспечит четкое понимание того, кто за что отвечает, с указанием сроков выполнения каждой задачи.
“Четкая цель – это то, с чем могут согласиться и клиент, и менеджер, и сотрудник. Главное – не дать никому опередить себя в постановке целей”
Proofhub
Сехдев повторил, что постановка целей ведет к определению задач для достижения этой цели. Это будет вашим путеводным светом на протяжении всего проекта.
“Постановка цели склоняет к разработке предложения, а затем к определению задач, которые помогут достичь цели. Когда вы знаете свои цели, вы можете определить задачи, то есть – как, почему и что вам нужно сделать для планирования проекта.”
Нандини Сехдев
Между тем, Кашьяп подчеркнул, что правильное сочетание планирования, контроля и мониторинга может определить, как проект может быть завершен в установленные сроки и в рамках бюджета.
“Правильное сочетание планирования, контроля и мониторинга может иметь значение для того, как менеджеры проекта завершат проект в срок, в рамках бюджета и с высококачественными результатами”
Вартика Кашьяп
Насколько важно приобрести правильное программное обеспечение для управления проектами?
Правильное программное обеспечение для управления проектами может повысить производительность и эффективность работы межфункциональных команд. Это делает общение более быстрым, легким и помогает в процессе принятия решений.
В связи с этим Proofhub подчеркнул, что это одно из самых важных решений, когда речь идет о проведении проекта.
“Безусловно, это одно из самых важных решений. Большинство команд слишком поздно осознают, как много они могут улучшить, имея в своем распоряжении правильный инструмент управления проектами. 85 000+ наших пользователей согласятся с этим!”
Proofhub
На какие основные факторы следует обратить внимание при покупке инструмента управления проектами? Анализ требований проекта и целей, поставленных командой, поможет вам определить наиболее подходящее программное обеспечение для управления проектами.
“Знайте свои проблемы, чтобы лучше сформулировать свои потребности, понять, как инструменты могут помочь, и определить критерии для оценки инструментов”
Proofhub
Как улучшить взаимодействие проектной команды и укрепить доверие?
Общение является ключевым фактором для улучшения сотрудничества в рамках проекта и укрепления доверия. Важно создать среду, в которой члены команды могут обмениваться знаниями и совместно работать над решением проблем.
Свободно делитесь знаниями”. Учитесь друг у друга. Гибко перераспределяйте рабочую нагрузку, чтобы устранить неожиданные узкие места, помогать друг другу выполнять задания и укладываться в сроки, а также совместно использовать ресурсы”
Вартика Кашьяп
Компания Proofhub также подчеркнула, что улучшение коммуникации приведет к улучшению сотрудничества, поскольку каждый сможет поделиться своими идеями.
“Сотрудничество – это все, что связано с общением, и подбадривайте людей из вашей команды, чтобы они могли выразить себя. Руководители должны поощрять новые идеи и позволять каждому свободно выражать свои мысли. В результате сотрудничество улучшится”
Proofhub
Такие инструменты, как Creately, помогут вам лучше сотрудничать в режиме реального времени, даже если вы работаете удаленно. Такие инструменты обеспечивают бесперебойное межфункциональное взаимодействие.
Есть ли какие-то приемы “ледокола”, которые можно использовать для укрепления доверия?
“Прозрачность, доверие к своей команде, запрос на общение и обратную связь и ответ на общение и обратную связь”
Proofhub
Какие факторы следует учитывать при распределении ресурсов на проект?
Эффективное распределение ресурсов направлено на распределение ограниченных ресурсов наиболее подходящим и экономичным способом. Эта ответственность часто возлагается на менеджера проекта, чтобы обеспечить правильное распределение и учет каждого ресурса.
Подчеркивая нехватку ресурсов, Кашьяп отметил, что управление проектами – это достижение большего за меньшие деньги.
“Распределение ресурсов в управлении проектами – это достижение большего за меньшие деньги. Проанализируйте объем проекта Определите ресурсы Имейте резервный план на случай изменения клиента Разделите проект на более мелкие задачи”
Вартика Кашьяп
Proofhub, с другой стороны, подчеркнул важность наличия инструмента управления проектами для повышения эффективности управления проектами.
“Sналичие специалистов Требования к квалификации проекта Цели проекта Существующие текущие задачи Нагрузка на проект Хотя все это необходимо, умный инструмент управления проектом поможет вам сделать эти моменты менее беспокойными.”
Proofhub
При управлении проектом вы обязательно столкнетесь с непредвиденными проблемами и препятствиями. Важно, чтобы вы обладали необходимыми навыками и инструментами для преодоления таких трудностей и успешного завершения проекта.
Введение
В настоящее время проектное управление становится неотъемлемой частью управленческого процесса. Управление проектами можно считать методологической базой, способствующей планированию и координации деятельности [1]. Проектное управление направлено на эффективную реализацию проекта при установленных ограничениях. В настоящее время стремительно увеличивается число компаний, осознавших преимущества использования проектов в своей деятельности, как для реализации отдельных проектов, так и для стратегического выстраивания деятельности бизнеса.
В России к проектно-ориентированным сферам деятельности относят: информационные технологии и телекоммуникации, архитектуру и строительство, космическую и оборонную промышленность, консалтинг и другие сферы, в которых бизнес построен на проектных продажах [2].
Управление ИТ-проектами основывается на стандартных проектных методологиях, однако они имеют свои особенности, характерные конкретно для области информации и связи. Поэтому необходимо учитывать такие специфики как особенности жизненного цикла технологических проектов, формирования проектных команд, применения современных гибких методологий управления ИТ-проектами.
Понятие инновационного проекта рассмотрено в трудах К. В. Хомкин, В. А. Первушина, Д. И. Кокури на, А. С. Дроботова, Д. А. Профатилова. Под инновационным проектом понимается форма управления инновационной деятельностью предприятия.
Анализ динамики отрасли информационных технологий относительно других был выполнен с использованием общероссийского классификатора видов экономической деятельности (далее — ОКВЭД). Отрасль информационных технологий относится к классу ОКВЭД 62 «Разработка компьютерного программного обеспечения, консультационные услуги в данной области и другие сопутствующие услуги», так как наиболее полно раскрывает деятельность цифровой отрасли [3].
В рассматриваемый класс ОКВЭД по данным Министерства экономического развития Российской Федерации входят следующие виды деятельности [4]:
62.01. Разработка, модернизация, тестирование, поддержка программного обеспечения. Издание пакета ПО, его перевод и адаптация, а также создание компьютерных систем;
- 02. Обучение пользователей, установка компьютерных систем и подготовка его к эксплуатации, консультативная работа;
62.03. Управление и сопровождение компьютерных систем как напрямую, так и дистанционно;
- 09. Прочие информационные технологии, не включенные ни в одну группу деятельности.
На данный момент в качестве основного стратегического документа отрасли в России выступает Стратегия развития отрасли информационных технологий в Российской Федерации на 2014 — 2020 годы и на перспективу до 2025 года, разработанная Минкомсвязью РФ [5]. Однако в марте 2020 года стало известно о разработке НИУ ВШЭ стратегии развития ИТ-отрасли до 2036 года по заказу Минкомсвязи, сейчас документ еще не принят и подвергается критике.
В феврале 2021 года эксперты рейтингового агентства «РИА Рейтинг» провели оценку капитализации крупнейших эмитентов Российской Федерации и составили топ-100 компаний на ее основе. В рейтинге оказались лишь 4 организации, занимающиеся информационными технологиями: Яндекс (8 место), Озон (19 место), Mail.ru Group (27) и HeadHunter (54). При этом только Яндекс и НН относятся к отрасли ОКВЭД 62. Оценка капитализации проводилась исходя из стоимости акций на Московской бирже, а перерасчет на валюту был осуществлен по курсу Центрального банка РФ, установленного в конце 2020 года [6].
Несмотря на хорошие показатели компаний в сфере информационных технологий, сама отрасль только начала развиваться, о чем также свидетельствует структура валовой добавленной стоимости по отраслям экономики из официального сайта Росстата за последние семь лет [7]. До 2017 года уровень соотношения не превышал даже 1%, для сравнения деятельность по операциям с недвижимым имуществом занимает более 10%, а строительство более 5,5% ежегодно.
Результаты исследований
В области информационных технологий формой развития является проектная деятельность. Согласно проектной методологии, проект — это ограниченная по времени активность, направленная на создание уникального продукта, сервиса или иного результата. У проекта определены сроки, бюджет, объем работы и показатели эффективности.
В сфере информационных технологий можно выделить основные виды ИТ-проектов:
- разработка программного обеспечения;
- модернизация программного обеспечения;
- внедрение информационных систем;
- развитие и модернизация вычислительных мощностей и инфраструктуры передачи данных.
Стандартный процесс управления ИТ-проектом, связанным с разработкой нового компьютерного программного обеспечения, представлен на рисунке 1.
Рисунок 1 — Процентное соотношение отрасли ОКВЭД 62 в структуре ВВП
При управлении ИТ-проектом, связанным с разработкой нового программного обеспечения, необходимо учитывать специфику проектной деятельности в сфере информационных технологий:
- Основным отличием ИТ-проектов от проектов, реализуемых в других сферах деятельности, является то, что результат проекта, как правило, неосязаем в информационном пространстве. В связи с этим требования к продукту, который необходимо получить в результате успешной реализации проекта, должны быть определены максимально детально.
- Необходимо также в расписании проекта учесть время для тестирования продукта и исправления ошибок — данный цикл может повторяться несколько раз, так как неизвестно заранее, с какими техническими проблемами могут столкнуться разработчики.
- При управлении проектом необходимо также помимо основных факторов, к которым относятся сроки, бюджет, ресурсы, учитывать технологические вопросы, касающиеся операционных систем, технических средств, баз данных и т.д.
- Также внедрение любой новой технологии в организации может быть рискованно, так как эта технология может вывести из строя всю систему, поэтому при наличии подобного риска необходимо заранее обеспечить резервную копию информационной среды предприятия.
Что касается проектных методологий, в сфере информационных технологий последовательная проектная методология («Водопад») подходит для небольших или коротких повторяющихся проектов, где требования фиксированы и не изменятся ни при каких обстоятельствах, а результат заранее четко определен. Также может использоваться в сфере разработок компьютерного программного обеспечения. Однако для реализации сложных ИТ-проектов подходят гибкие методологии, позволяющие вернуться к предыдущим этапам или пересмотреть продукт после окончания его разработки [11].
Управление ИТ-проектами также может использовать адаптивный жизненный цикл, например, методологию Agile. Этот тип объединяет временные рамки в более короткие всплески активности, называемые спринтами. Популярность Agile как относительно новой методологии возросла благодаря подходу, основанному на изменениях, которые дают командам проектов в сфере информационных технологий динамическую способность быстро адаптироваться к необходимым изменениям или корректировкам курса [8].
Согласно исследованию, Ambysoft Project Success Rates Survey, проведенному в 2013 году, Agile имеет более высокий процент успеха (64%), чем Waterfall (49%), когда дело касается ИТ-проектов. Также преимущество гибких методологий при ведении ИТ-проектов подтверждается исследованием 2017 года, проведенным PricewaterhouseCoopers (PWC), которое выявило, что гибкие проекты на 28% успешнее традиционных [9].
Процесс разработки программного обеспечения состоит из нескольких этапов (рис.2). В теории при использовании традиционного метода, когда каждый этап начинается после завершения предыдущего, рабочее приложение должно создаваться быстрее, чем при использовании гибкого. Однако сложность могут вызвать большое количество технических ошибок, которые невозможно предугадать: если на начальном этапе появится даже небольшая ошибка в разработке кода или несоответствии подготовленного дизайна для кодинга, то проект провалится. В это же время взаимосвязанные этапы управления в гибких методологиях позволяют разработчикам и заказчикам раньше получать доступ и тестировать отдельные части приложения, и в зависимости от результатов которого принимать решения о том, как должно развиваться остальное приложение. Данный подход дает преимущества обеим сторонам.
Рисунок 2 — Проект разработки программного обеспечения по методологиям Agile и Waterfall
Что касается тестирования и обеспечения качества — это непрерывные процессы при разработке программного продукта, так как своевременное выявление ошибок путем тестирования каждой части по мере ее создания очень важно для реализации проекта в срок с выделенным бюджетом. При использовании каскадной модели этап тестирования выносится в качестве отдельного этапа, который осуществляется после того, как всё приложение готово целиком.
В проектном управлении в сфере информационных технологий часто используется методология SCRUM. Она подходит для проектов, которые могут повлечь за собой множество изменений в бэклоге продукта или когда требования проекта могут часто меняться. Методология основана на предположении, что заинтересованные стороны не знают деталей того, каким они хотят видеть продукт, не имея рабочего прототипа, что подходит для управления ИТ-проектами.
Учитывая высокую конкуренцию в технологическом секторе, необходимо также регулярно анализировать и выявлять основные тенденции развития отрасли, влияющие на управление ИТ-проектами. Сейчас существенное влияние на отрасль информационных технологий оказал переход компаний на удаленную работу. Развитие дистанционного режима внесло изменения в сферу управления проектами и в бизнес в целом. ИТ-компаниям была предоставлена дополнительная ниша для развития — разработка программных решений для организации взаимодействия и совместной работы удаленно [10].
Ориентация на удовлетворение потребностей клиентов — еще одна тенденция управления ИТ-проектами, повышающая шансы компании на успех. Менеджеры ИТ-проектов должны отдавать приоритет продуктам, которые оказывают наиболее существенное влияние на удовлетворенность клиентов.
Также острее становится проблема нелинейного приращения компетенций, удержания и развития кадров в ИТ-сфере. Среди способов привлечения квалифицированных специалистов по управлению проектами можно выделить прозрачную систему карьерного развития и роста, интересные задачи, предоставление возможности самостоятельно принимать решения и нести ответственность, признание результатов труда, постоянную обратную связь с топ-менеджментом компании.
Рост объёмов информации и мобильных платформ ведет к более крупным и сложным ИТ-проектам. Помимо сложности управления непрерывно увеличивающихся объемов информации важно также обеспечивать безопасность её хранения. Таким образом, внимание к кибербезопасности — еще одна тенденция, влияющая на управление ИТ-проектами.
Одной из главных сложностей в управлении ИТ-проектами предприятий является управление внутренними коммуникациями в проекте. Необходимо настроить своевременную передачу управленческой информации и обеспечивать её надлежащее качество. В крупных ИТ-компаниях можно встретить различные барьеры в коммуникациях.
Во-первых, это территориальный и языковой барьеры. Находящиеся в разных территориальных точках (города, регионы, страны) офисы требуют координации обмена информацией удаленно, например, через различные компьютерные программы. Одним из наиболее действенных методов решения подобной проблемы являются регулярные еженедельные онлайн-встречи всех ключевых участников проекта с представлением друг другу обновленной информации по компонентам проекта. Ситуация осложняется языковым барьером, когда родной язык участников проекта отличается. В таком случае, как правило, используется язык, принятый в компании рабочим — в большинстве случаев для международных компаний это английский язык. Тем не менее, управление проектом и координация большого количества информации на иностранном языке может вызывать трудности из-за некачественного перевода и отличий в трактовке дефиниций, для исправления ситуации топ-менеджменту важно создать развитый и приведенный к единому образцу понятийный аппарат.
Во-вторых, важно четко выделить зоны ответственности ключевых участников на начальном этапе, чтобы занимающиеся проектом специалисты понимали, к кому и по какому вопросу они могут обратиться или кому они должны передать определенную информацию. Надлежит выделить взаимосвязи между компонентами проекта и проинформировать его участников, а также заинтересованные стороны. Необходимо также заранее обеспечивать участников и заинтересованные стороны информацией о ходе проекта и его планах развития, о возможных изменениях. При ведении крупного ИТ-проекта у участников может угаснуть интерес к проекту из-за того, что они долгое время не видят результаты продвижения работы над проектом. Для решения данной проблемы необходимо всегда давать обратную связь, регулярно информировать об основных результатах работы и обновлять информацию. Важно сформировать образ проекта как открытой, прозрачной и доступной инициативы.
Для обеспечения передачи качественной управленческой информации могут использоваться различные каналы коммуникации:
- Электронная почта;
- Личные встречи (совещания в группах, выездные семинары, сессии вопросов и ответов);
- Программное обеспечение для организации онлайн-встреч (Zoom, Microsoft teams и другие);
- Интернет, чаты для более быстрого и неформального обмена информацией (в некоторых случаях более удобный канал коммуникации, чем электронная почта);
- ПО для хранения проектной информации, единые базы данных, доступ к которой имеют все участники проекта (например, Confluence — система для внутреннего использования организациями с целью создания единой базы знаний);
- ПО для гибкого управления проектами, удобное для организации взаимодействия участников проекта (например, система Лга, Trello).
Таким образом, необходимо подбирать такие каналы коммуникации, которые облегчат процесс координации и передачи качественной управленческой информации при управлении крупным ИТ-проектом. При выборе определённых каналов стоит учитывать корпоративную культуру компании, а также уже сложившийся опыт использования тех или иных каналов коммуникации.
Заключение
Переход технологий из категории Nice-to-have в Must have меняет и отношение к ним. ИТ-проекты сегодня создают преимущества за счёт качества технологических решений и новых возможностей, которые они обеспечивают компаниям: повышение эффективности существующих бизнес-процессов, создание добавочной стоимости и приобретение конкурентных преимуществ. Компании разных отраслей нуждаются в инструментах, которые не просто обеспечивают работу, а позволяют быть стабильными, эффективными и устойчивыми в кризисных ситуациях. Поэтому можно утверждать, что пересмотр компаниями стратегий развития в пользу достижения большей сопротивляемости внешним факторам, а также отложенный спрос на цифровые решения, приведут к росту инвестиций в технологии и развитию ИТ-отрасли в целом за счет новых проектов.
Читайте также