Основные ошибки проектного управления - Ремонт и установка крупной бытовой техники

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

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

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

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

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

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

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

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

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

Ошибка № 2: Нехватка опытных руководителей проектов.

Проявление: При отсутствии грамотного руководителя проекты могут быстро выйти из-под контроля.

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

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

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

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

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

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

Ошибка № 4: Слишком большое число процедур, ограничивающих ваши возможности.

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

Фуми Кондо, управляющий директор консультационной компании Intellilink Solutions, однажды была свидетелем интересного разговора между разработчиком программ и руководителем проекта. Разработчик заявлял, что функционал приложения можно расширить, не прилагая никаких дополнительных усилий. Руководитель проекта убеждал разработчика не добавлять никаких новых функций, потому что пользователи об этом не просили. «Тогда я посоветовала им следующее: ступайте к пользователям и посмотрите, действительно ли им нужны эти функции, — вспоминала Кондо. — Не вижу ничего плохого в том, чтобы предоставить клиентам больше того, что они ожидают, если при этом вы не выходите за рамки бюджета и установленных сроков».

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

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

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

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

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

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

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

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

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

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

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

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

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

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

Ошибка № 10: Игнорирование законов Мерфи.

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

Одна из фирм, вошедших в состав компании GlassHouse Technologies, решила перенести свой мэйнфрейм в новый центр данных. Всю субботу ИТ-группа занималась разборкой мэйнфрейма, чтобы на следующий день переместить его в новый ЦОД. А когда в воскресенье сотрудники ИТ-службы занялись перевозкой, на пути у них выросли участники гей-парада, перекрывшие все возможные выезды. Обойти их не было никакой возможности. Пришлось возвращаться в старый ЦОД и начинать все сначала. Недостатки планирования привели к тому, что персоналу ИТ-службы пришлось выполнить гораздо больший объем работ, чем предполагалось изначально.

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

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

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

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

Ошибка № 12: Незавершенность графика проектов.

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

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

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

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

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

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

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

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

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

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

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

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

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

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

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

Часто компании тратят кучу денег и времени на идеи, которые в итоге никак не могут реализовать. Так почему интересные проекты часто оказываются провальными? В
материале мы
собрали 12 типичных ошибок по управлению проектами и объяснили, как с ними можно справиться.

Ошибка №1: Вы выбрали не того project-менеджера

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

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

Ошибка №2: В вашей команде отсутствует мотивация

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

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

Ошибка №3: Ваш проект никто не контролирует

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

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

Ошибка №4: Вы берете на себя сразу несколько проектов

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

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

Ошибка №5: В вашей команде не налажена коммуникация

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

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

Ошибка №6: У вас нет четкой конечной цели проекта или вы меняете ее в ходе работы

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

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

Ошибка №7: Вы неверно рассчитали время для реализации проекта

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

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

Ошибка №8: Вы не идете на уступки

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

Решение: Посмотрите на проект со стороны. Подумайте, не нужно ли в нем что-то изменить. Это не значит, что нужно постоянно что-то менять – просто будьте
открытыми к
предложениям со стороны, если они пойдут на пользу проекту.

Ошибка №9: Вы не систематично отслеживаете изменения в проекте

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

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

Ошибка №10: Вы руководите каждым шагом своих сотрудников

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

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

Ошибка №11: Вы нечетко распределили обязанности в команде

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

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

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

Решение: Project-менеджер должен точно знать, что для заказчика будет являться успешно реализованным проектом. Этот фактор придаст уверенности, что
когда проект
закончен, все его исполнители могут спокойно расходиться.

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

14 наиболее распространенных ошибок в области управления проектами

Не удивителен тот факт, что только 29 процентов IT-проектов завершаются успешно, в соответствии со Standish Group. Консультанты в области управления проектами и поставщики программных обеспечений говорят, что они видят постоянные ошибки IT-отделов, которые повторяют их снова и снова: IT-группы не следуют стандартному процессу управления проектами. Они не обладают подходящим штатом сотрудников, работающих над проектом, не оценивают риски, которые могут поставить под угрозу их проекты, не пытаются найти способы их предотвращения. Список ошибок разматывается подобно клубку пряжи. Большинство ошибок, в управлении проектами IT-отделов сводятся либо отсутствием надлежащего планирования, либо отсутствием взаимопонимания (между проектной группой или между проектной командой и спонсоров проекта). Эти ошибки могут быть фатальными. Но их также можно избежать. Справиться со всеми проблемами и избежать их помогут консультанты и специалисты области управления проектами. А также они могут предложить пути предотвращения ошибок. Ниже приведен список 14 наиболее распространенных ошибок, которые должны помочь вам определить, правильно ли протекает процесс работы. Ваш проект добьется успеха, Вы повысите уровень удовлетворенности клиентов, IT-акции организации увеличатся в цене, компания станет конкурентоспособной.

Ошибка № 1
Недостаток правильных ресурсов, отсутствие навыков работы.
Последствия: Над проектом работает неподходящий штат работников, который играет немаловажную роль.
Отсутствие компетентных людей, работающих над проектом, может привести к его провалу. «Основным ключом успеха проекта, является правильно подобранный персонал с определенными навыками» говорит Joel Koppelman, исполнительный директор по управлению проектами программного обеспечения Primavera.
Решение: IT-руководителям проектов необходима полная видимость навыков работы всех их ресурсов, включая консультантов, подрядчиков и работодателей, говорит Koppelman. В этом могут помочь специалисты по управлению проектами, нужно лишь правильно распределить работу людей, назначить компетентного менеджера.

Ошибка № 2
Отсутствие опытных руководителей.
Последствия: В отсутствие опытного руководителя у руля, проект в быстром темпе выходит из под контроля.
Решение: Нанять руководителей с сертификатами, подтверждающими знания в области управления проектами. Matthew Strazza, вице-президент сервиса услуг (Северная Америка) компании CA, говорит, что хорошие руководители обязаны обладать навыками управления. Они должны знать, как управлять рисками, работать с людьми, заботиться о безопасности и бюджете, оповещать клиентов обо всех происходящих изменениях. Хороший менеджер проекта также должен обладать техническими знаниями.

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

Ошибка № 4
Дополнения, вносимые в процесс.
Последствия: Негибкость процесса, отсутствие взаимопонимания.
Решение: Будьте гибкими и общайтесь с авторами проекта и заинтересованными сторонами. Если вносимые дополнения не выходят за рамки бюджета и сроков выполнения проектов, их можно добавлять.

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

Ошибка № 6
Отсутствие точной и актуальной информации о состоянии проекта.
Последствия: Нельзя управлять тем, чего не знаешь — сказал Peter Drucker.
Решение: Программное обеспечение.

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

Ошибка № 8
Неправильно установленные сроки.
Последствия: Неправильно установленные сроки, приведут к конфликтным ситуациям.
Более того, IT-компаниям не хватает ясности и точности. Проект нужно закончить в сроки и в надлежащем бюджете, согласно ожиданиям клиентов.
Решение: Необходимо продумывать проект, все его детали и только после приступать к работе высказываются Intellilink Solutions’ Kondo.

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

Ошибка № 10
Не рассматривается Закон Мерфи.
Последствие: Происходит неразбериха, которой удивляются IT-компании. Проект выходит за пределы трека.
Решение: Нужно произвести оценку рисков как часть проектного планирования. Затем выявить пути их возможного уменьшения, говорит генеральный директор Primavera Koppelman. Необходимо потратить время на обдумывания и перед вами появится огромный список решения проблем возникновения рисков, говорит Koppelman. «Эта работа не займет много времени, и будет полезной в обнаружение слабых мест проекта».

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

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

Ошибка № 13
IT не отталкивается от возможности увеличения сроков завершения проекта.
Последствия: Потеря репутации компании.
Решение: IT-менеджеры должны объяснять руководителям, что сделают все возможное для завершения проекта в срок, с выделенным бюджетом. Но нужно учитывать, что могут произойти непредвиденные ситуации, которые могут повлиять на срок завершения.

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

Источник — http://www.networkworld.com/news/2008/072308-the-14-most-common-project.html?page=1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующая >

Older news items:

Илья Едигарьев, руководитель Департамента внедрения компании «Адванта Консалтинг»

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

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

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

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

А почему нет?

Для начала сформулируйте, какие именно проблемы вы хотите решить. Что исправить? Действительно ли вопрос в управлении вашими проектами и задачами? Убедитесь – с нашей помощью или самостоятельно – что приобретаемый продукт на самом деле вам подходит, что он способен решить ваш круг проблем. Не стоит покупать систему только потому, что у вашего конкурента или партнера она уже есть (и у него, условно, все хорошо).
Никакая информационная система в ближайшем будущем не заменит компетентного руководителя – она будет только предоставлять данные для принятия решений, а принимать решения предстоит вам, и никому другому. Увы, нужно признать, что иная картина пока остается в области научной фантастики.
Если вы все это осознаете, важно принять еще один факт: момент приобретения системы – только начало большого пути. Даже если вы сотрудничаете с нами (или другими консультантами – ну, это навряд ли), не стоит забывать, что это только ваша компания и ваши процессы. А если уж совсем честно – то это ваше внедрение. Консультант ведь потому так и называется, что только помогает и советует. Успех зависит только от вас.

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

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

Как же быть?

Для начала сверьтесь со списком целей и проблем, который мы с вами подготовили в первом пункте. Все требования должны быть нацелены на решение этих проблем. Что не нацелено – отметайте.
Без крайней необходимости не закладывайте ничего на перспективу: сейчас функция не нужна, но вдруг что-то поменяется? Давайте отметем это «вдруг» и будем помнить, что жизненный цикл любой автоматизированной системы управления в компании редко превышает 5 лет. Как бы это ни было грустно для производителей.
Аккумулируйте лучшие практики, но берите из них только необходимый минимум. Помните, что тот же самый PMBoK – это свод знаний, а не буквальное руководство к действию. Блеснуть знаниями у вас, наверняка, еще будет повод.
Постарайтесь спроектировать такую систему, которую вы сможете запустить в реальные короткие сроки. Снова вспомним предыдущий пункт: внедрять – вам.

3. Объять необъятное: заказчик хочет всего и сразу. В знаниях об управлении проектами несколько областей: управление сроками, стоимостью, качеством и так далее. Точно также любая внедряемая система имеет модули или функциональные блоки, близкие по смыслу. С чего начать? Заказчик знакомится с возможностями системы, ему нравится все, ограничить рамки крайне трудно.

Как расставить приоритеты?

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

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

А как должно быть?

Снова обратимся к выводам в нашем первом пункте. Дорогие заказчики! Это ваша компания и ваше внедрение. Несмотря на юридически закрепленные обязательства и самые добрые намерения консультантов – мы уйдем, а вы останетесь.
Мало написать устав и приказ о начале проекта внедрения и назначить в нем роли – нужно всерьез озаботиться тем, чтобы назначенные на эти роли сотрудники (заказчик, РП, аналитики, администраторы, эксперты) смогли участвовать в проекте и считали эту деятельность хотя бы не менее важной, чем привычная операционная.
Подумайте о мотивации. Любой сотрудник должен понимать, за что он отвечает в проекте, и что – негативное лично для него – произойдет в том случае, если результат не будет достигнут.

5. Неизвестно, чего ждет от проекта реальный заказчик, как он будет оценивать результаты. На проекте нас встречает РП клиента, часто он же инициатор и эксперт в проектном управлении. На просьбу встретиться с директором по развитию или генеральным РП отвечает нам: «Все вопросы – ко мне. Я здесь отвечаю за проекты, и Петр Семенович во всем меня поддержит. Не будем его беспокоить, человек занятой». Проходят месяцы внедрения, на этапе финальной приемки неожиданно появляется Петр Семенович и говорит: «Э, ребята, что-то не то».

Как же так вышло?

Вполне возможно, что неопрошенный вами топ – действительно не эксперт, и именно в этом проблема. Но вы должны узнать об этом на старте проекта, а не при его завершении. Совсем необязательно безропотно следовать его указаниям: вы всегда можете скорректировать ожидания и договориться о критериях приемки, которые устроят всех. Главное – явно это озвучить и закрепить на старте.
Очень важно услышать требования, проговоренные самим заказчиком. Даже если у вас подписана тысяча документов, а двух трактовок требований может не быть. Свойство многих руководителей – не принимать никаких результатов без критики. А критиковать свои собственные решения будет уже сложнее.
Еще одна важная роль высокопоставленного заказчика – поддержка проекта авторитетом. Только он может встать на стартовом совещании и решительно сказать: проекту быть. Пресечь возражения. Регулярно интересоваться результатами проекта. Требовать от сотрудников выполнения обновленных регламентов и процессов даже тогда, когда они не очень значительно влияют на его работу и его решения. Для всего этого заказчик также нужен вам лично. Чем более высокую должность при этом он будет занимать, тем лучше.

Продолжение – во второй части публикации

Источник

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

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

Ниже попытаемся исправить данную несправедливость.

Зачем нужна градация ошибок?

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

Но документирование – не первопричина. Важнее – накопление опыта.

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

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

В рамках крупного предприятия/компании процесс управления рисками и ошибками называется риск-менеджментом – смотрите статью «Система управления рисками в компании».

По аналогии может помочь система градации ошибок менеджмента (системы управления предприятием или проектом).

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

Концепция «вина-ответственность» всегда остается актуальной.

Классификация рисков в IT-проектах

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

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

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

Сэм Канер в книге «Тестирование программного обеспечения» приводит следующую общую классификацию ошибок внутри программных продуктов:

Ошибки интерфейса (UX/UI).
Логика обработки ошибок (для облегчения их обнаружения).
Ошибки вычислений.
Ошибки обработки/интерпретации данных (очень близки по смыслу к вычислениям).
Проблемы начального и конечного состояния.
Превышение нагрузки.
Ситуация спешки.
Ошибки аппаратного обеспечения и несовместимость.
Контроль идентификаторов (процессов).
Ошибки, связанные с граничными условиями.

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

Как можно классифицировать ошибки проектного менеджмента?

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

Наиболее универсальный подход в классификации любых ошибок – опирание на функции и задачи.

За что отвечает менеджер проекта? Ранее мы рассматривали обязанности администратора проекта, которые во многом дублируют обязанности менеджера (ведь администратор – правая рука руководителя команды).

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

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

Группы ошибок проектного менеджмента в зависимости от их источника

Руководитель проекта:

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

Заказчик:

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

Команда в целом (включая в том числе руководителя):

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

Внешняя среда:

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

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

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

Во-вторых, все потенциальные ошибки управления должны быть идентифицированы (как в матрице рисков) и для каждой конкретной ошибки должна быть определена вероятность наступления + определён эффект последствий (цена ошибки). Так вы сможете заранее оценить потенциальные проблемы и спланировать пути их обхода.

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

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

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

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

Источник

Источник — http://www.networkworld.com/news/2008/072308-the-14-most-common-project.html?page=1

Источник

Илья Едигарьев, руководитель Департамента внедрения компании «Адванта Консалтинг»

А почему нет?

Для начала сформулируйте, какие именно проблемы вы хотите решить. Что исправить? Действительно ли вопрос в управлении вашими проектами и задачами? Убедитесь – с нашей помощью или самостоятельно – что приобретаемый продукт на самом деле вам подходит, что он способен решить ваш круг проблем. Не стоит покупать систему только потому, что у вашего конкурента или партнера она уже есть (и у него, условно, все хорошо).
Никакая информационная система в ближайшем будущем не заменит компетентного руководителя – она будет только предоставлять данные для принятия решений, а принимать решения предстоит вам, и никому другому. Увы, нужно признать, что иная картина пока остается в области научной фантастики.
Если вы все это осознаете, важно принять еще один факт: момент приобретения системы – только начало большого пути. Даже если вы сотрудничаете с нами (или другими консультантами – ну, это навряд ли), не стоит забывать, что это только ваша компания и ваши процессы. А если уж совсем честно – то это ваше внедрение. Консультант ведь потому так и называется, что только помогает и советует. Успех зависит только от вас.

Как же быть?

Для начала сверьтесь со списком целей и проблем, который мы с вами подготовили в первом пункте. Все требования должны быть нацелены на решение этих проблем. Что не нацелено – отметайте.
Без крайней необходимости не закладывайте ничего на перспективу: сейчас функция не нужна, но вдруг что-то поменяется? Давайте отметем это «вдруг» и будем помнить, что жизненный цикл любой автоматизированной системы управления в компании редко превышает 5 лет. Как бы это ни было грустно для производителей.
Аккумулируйте лучшие практики, но берите из них только необходимый минимум. Помните, что тот же самый PMBoK – это свод знаний, а не буквальное руководство к действию. Блеснуть знаниями у вас, наверняка, еще будет повод.
Постарайтесь спроектировать такую систему, которую вы сможете запустить в реальные короткие сроки. Снова вспомним предыдущий пункт: внедрять – вам.

Как расставить приоритеты?

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

А как должно быть?

Снова обратимся к выводам в нашем первом пункте. Дорогие заказчики! Это ваша компания и ваше внедрение. Несмотря на юридически закрепленные обязательства и самые добрые намерения консультантов – мы уйдем, а вы останетесь.
Мало написать устав и приказ о начале проекта внедрения и назначить в нем роли – нужно всерьез озаботиться тем, чтобы назначенные на эти роли сотрудники (заказчик, РП, аналитики, администраторы, эксперты) смогли участвовать в проекте и считали эту деятельность хотя бы не менее важной, чем привычная операционная.
Подумайте о мотивации. Любой сотрудник должен понимать, за что он отвечает в проекте, и что – негативное лично для него – произойдет в том случае, если результат не будет достигнут.

Как же так вышло?

Вполне возможно, что неопрошенный вами топ – действительно не эксперт, и именно в этом проблема. Но вы должны узнать об этом на старте проекта, а не при его завершении. Совсем необязательно безропотно следовать его указаниям: вы всегда можете скорректировать ожидания и договориться о критериях приемки, которые устроят всех. Главное – явно это озвучить и закрепить на старте.
Очень важно услышать требования, проговоренные самим заказчиком. Даже если у вас подписана тысяча документов, а двух трактовок требований может не быть. Свойство многих руководителей – не принимать никаких результатов без критики. А критиковать свои собственные решения будет уже сложнее.
Еще одна важная роль высокопоставленного заказчика – поддержка проекта авторитетом. Только он может встать на стартовом совещании и решительно сказать: проекту быть. Пресечь возражения. Регулярно интересоваться результатами проекта. Требовать от сотрудников выполнения обновленных регламентов и процессов даже тогда, когда они не очень значительно влияют на его работу и его решения. Для всего этого заказчик также нужен вам лично. Чем более высокую должность при этом он будет занимать, тем лучше.

Продолжение – во второй части публикации

Источник