Ошибки руководителя проекта

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

Ошибка 1. РП — передаст

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

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

Ошибка 2. Ответственность

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

Руководитель проекта — это пионер (да, имеется ввиду тот, кто с красным галстуком): в советское время была фраза «Пионер, ты отвечаешь за все».

Ошибки

Решение. Решение лежит в нескольких правилах.

Ошибка 3. Эмоциональность

Руководитель проекта — это человек, который управляет эмоциональным состоянием команды.

Давайте представим: есть человек, о котором вы все время слышите страшные истории, — в вашем представлении он ужасен. И теперь вам для него нужно делать проект. С каким настроением вы будете его делать? Будете ли вы выкладываться? НЕТ!

Заказчики — это люди, бывает так, что РП сложно с заказчиком. И эту тяжесть коммуникации он передает команде:

Решение

Ошибка 4. Страх

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

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

Ошибка

РП тянет до последнего и не сообщает о проблемах, надеясь на их решение. Последствия такого поведения очень тяжелые. Заказчик думает, что все хорошо, но в день сдачи узнает о FUCK UP’е. Реакция заказчика понятна: он озвереет, кто-то даже может пострадать:)

Решение

Ошибка 5. Неправильная коммуникация

Тут можно говорить много. Сегодня остановимся на том, как правильно задавать вопросы.

Ошибка РП. Задать вопрос и ждать ответа. Далее при получении ответа идет коммуникация по уточняющим вопросам. Это долго!

Решение. Уменьшить время на коммуникацию правильной формулировкой вопросов.

В нашей компании я написал отдельную инструкцию о том, как правильно задавать вопросы. Во главе стоит тезис — «Задавая вопрос, ты должен знать на него ответ».

Когда я услышал эту фразу, не сразу понял.

Суть в следующем. Перед тем как задать вопрос, вы сами должны предположить, что может ответить заказчик. Таким образом, клиенту вы сбрасываете вопрос и варианты ответов. В ответ заказчик подтверждает определенный вариант ответа или формулирует свой.

Это значительно экономит время.

Важно! Этот способ требует тренировки, зато позволяет выстраивать эффективные коммуникации не только на работе, но и в личной жизни.

Нет плохих заказчиков — есть неправильная коммуникация

Бонус

Это уже про главное качество РП. Если этого качества нет или РП не стремится его развить, он будет совершать ошибки.

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

Как развить гибкость?

Заключение

Надеюсь, статья была полезной. Если да, поделитесь ею, чтобы больше людей получили полезную информацию.

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

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

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

Ошибка № 1. Нас это не касается!

Часто руководитель проекта отстраняется сам и не позволяет своим сотрудникам «нырнуть глубже» в суть процесса – т.е. изучить особенности функционирования фирмы, вникнуть в бизнес-процессы, потратить пару дней на анализ работы компании в режиме «изнутри». Это позволило бы всей команде лучше понять особенности работы и провести полноценный анализ. Благодаря этому, можно было бы точнее оценить, как трудоемкость, так и специфику предстоящей работы.

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

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

Ошибка № 2. Не учитывается время, необходимое на приемку работ

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

Само собой, появляются объективные претензии как у исполнителя, так и у клиента.

Наш главный совет тут один – проговаривайте подробным образом все особенности сдачи проекта. У каждой организации свои правила приемки подобных проектов.

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

Ошибка № 3. Не учитывается, что проект может безмерно расти в процессе его выполнения

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

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

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

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

Ошибка № 4. Регулярный срыв сроков сдачи проекта

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

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

Ни в коем случае нельзя пропадать и держать заказчика в неведении.

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

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

Это не наше

Зарисовка из жизни.

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

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

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

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

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

Совет 1

«Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»

В каждой избушке свои погремушки

Зарисовка из жизни.

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

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

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

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

Совет 2

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

За время пути собачка могла подрасти

Зарисовка из жизни

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

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

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

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

По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.

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

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

Как избежать данной ошибки или нивелировать ее последствия для исполнителя?

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

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

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

Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.

Например, очень часто исполнители упускают следующие работы:

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

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

Совет 3

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

Ожидания

Зарисовка из жизни

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

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

И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.

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

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

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

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

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

Совет 4

«Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».

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

Татьяна Белова

Просмотры: 8 253

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

Эпиграф

Умный учится на чужих ошибках, а дурак на своих…. (автор неизвестен)

1. «Это не наше»

Зарисовка из жизни.

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

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

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

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

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

Итак, совет 1. «Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»

1. «В каждой избушке свои погремушки»

Зарисовка из жизни.

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

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

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

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

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

1. «За время пути собачка могла подрасти»

Зарисовка из жизни

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

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

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

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

По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.

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

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

Как избежать данной ошибки или нивелировать ее последствия для исполнителя?

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

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

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

Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.

Например, очень часто исполнители упускают следующие работы:

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

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

Итак, совет 3. «Чтобы контролировать содержание проекта применяйте методы раннего прототипирования, уточнения требований, ведите реестр типовых работ на проектах внедрения для каждого конкретного заказчика».

1. «Ожидания»

Зарисовка из жизни

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

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

И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.

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

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

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

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

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

Итак, совет 4. «Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».

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

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

В данной статье рассмотрены самые распространенные ошибки в управлении проектами:

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

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

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

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

5.  Я –  начальник: Руководителю проекта не рекомендуется упиваться властью и мешать своей проектной группе вносить предложения, но такая ситуация встречается в организациях. Члены группы, вероятно, больше всего знают о грозящих трудностях или проблемах с проектом по причине своего ежедневного активного участия. Следуя принципу «я – начальник», руководитель проекта может привести проект к провалу.

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

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

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

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

10. Быть безотказным: Вы не всегда должны говорить «да», иногда необходимо говорить «нет». Руководитель проекта и члены группы должны знать, когда все – значит, все, и уметь говорить «нет»! Никто не обязан делать все, что его просят. Упорно работайте и сосредоточьтесь на том, что вы способны сделать.

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

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