Внедрение проектного управления

Размещено на http://www.allbest.ru/

Внедрение проектного управления

Паркинсон и Мерфи живы и хорошо себя чувствуют - в вашем проекте.

Г. Керцнер

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

Общие подходы к внедрению проектного управления

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

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

Из практики

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

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

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

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

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

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

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

Из практики

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

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

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

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

Формирование идеологии

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

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

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

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

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

Из практики

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

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

§ "жесткий противник", саботирующий применение всех проектных приемов и инструментов, резко негативно относящийся к нововведениям;

§ "мягкий противник", поведение которого выражается выжидательной позицией - подожду, что будет, может мое мнение изменится, но использовать это сейчас точно не стану;

§ "равнодушный", следующий принципу: буду работать по-старому, но если административно меня заставят, то что-то придется использовать;

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

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

Обучение управлению проектами

На практике сформировалось несколько основных правил обучения управлению проектами.

1. Обязательная предварительная активная диагностика.

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

2. Использование максимально адаптированных материалов.

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

3. Применение единого сквозного учебного или рабочего проекта.

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

4. Использование комбинации активных приемов при обучении.

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

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

5. Четкая проработка условий проведения.

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

§ Особое внимание необходимо уделить формату проведения программы. На практике оказались интересными следующие форматы:

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

§ Обучение в более мягком формате в течение нескольких недель. Здесь темп подачи материала снижается, но появляется возможность дать небольшие домашние задания, и это может легче восприниматься участниками более старшего поколения.

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

6. Продуманный и подготовленный раздаточный материал.

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

7. Обязательное тестирование и обратная связь после проведения программы.

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

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

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

Сертификация

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

Институт проектного управления (PMI) сертифицирует по одинаковым для всех стран требованиям. Существует два уровня: Certified Associate in Project Management (САРМ) - дипломированный помощник по управлению проектами и Project Management Professional (PMP) - профессионал управления проектами. Основным источником информации для сертификации является "РМ Body of Knowledge" (РМВоК, издания 2004 г.). PMI требует от кандидата предоставить описание его опыта управления проектами за последние шесть лет, которое должно показать не менее 4500 часов практического опыта с перечислением конкретных управленческих процедур, которые выполнял кандидат в качестве участника проектов, структурированных в рамках пяти основных процессов (инициация, планирование, исполнение, контроль, завершение). Кроме того, кандидат должен пройти обучение на специализированных и аттестованных PMI программах по управлению проектами и получить 35 баллов (PDU - Project Development Unit) для уровня PMP и 23 балла для уровня САРМ.

Экзамен PMI напоминает сдачу онлайнового экзамена по английскому языку. Экзамен базируется на одинаковых вопросах, случайным образом отбираемых из общей базы вопросов. Отвечая на вопросы, кандидат должен выбрать правильный ответ из четырех предложенных вариантов. Для прохождения сертификации нужно ответить правильно не менее чем на 75% из 200 вопросов на РМР и из 150 вопросов на САРМ. На каждый вопрос у кандидата есть примерно 1 мин, всего выделяется 4 ч (РМР) и 2 ч (САРМ). Кандидат может выбрать язык вопросов самостоятельно. Большинство вопросов предполагает детальное знание РМВоК. Однако есть вопросы, предполагающие наличие у кандидата практического опыта и знание межкультурных различий в менеджменте.

Международная ассоциация управления проектами (IPMA) проводит сертификацию по нескольким уровням (А, В, С, D). Чем выше уровень сертификата, тем большие требования предъявляются к знаниям и опыту кандидата. Самым высшим является уровень А. Данный уровень предполагает опыт управления проектно-ориентированной организацией. Уровни В и С предполагают наличие опыта управления отдельными проектами (различаются требованиями к сложности и масштабам проектов). Уровень D - специалист, имеющий квалификацию для выполнения отдельных функций управления проектом, способный работать в команде управления проектом. IPM А формулирует общие условия сертификации, на базе которых разрабатываются требования к компетентности специалистов с учетом национальной специфики. В нашей стране сертификация проводится на основе "Российских национальных требований к компетентности специалистов". Кандидат должен пройти предварительную квалификацию, подтвердив свой опыт в области управления проектами, а затем сдать квалификационный экзамен. По стандартам IPMA кандидат должен предоставить список проектов, в которых он принимал участие, и более подробно (до 20 страниц) описать проект, в котором он выполнял функции руководителя. Данное задание не составит сложности, если у вас под рукой есть рабочая документация (календарные планы, концепция, технические задания и т. п.) одного из завершенных проектов. Однако чисто технической редакцией здесь не обойдешься - требования к данному отчету предполагают осознанное переосмысление менеджером практики управления данным проектом и полученного опыта.

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

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

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

(С использованием материалов А.В. Полковникова, сайт "Открытые системы", www.osp.ru)

Разработка политики, процедур, инструкций

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

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

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

Разработка документооборота и использование информационной системы

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

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

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

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

Г. Керцнер

Существует целый ряд относительно простых и сложных программных продуктов для управления проектами: "Microsoft Project", "Spider", "Open Plan", "Primavera" и ряд других. Данные решения упрощают процессы планирования, управления, контроля, модификации и внесения изменений, особенно при реализации крупных сложных проектов. Однако они не определяют целей и концепции проекта, не устанавливают приоритетов, не выставляют бюджетных или временных требований, и не определяют контрольных точек, действий или взаимосвязей. Все это должно быть сделано руководителем проекта и его командой. Чего руководитель проекта может ожидать от таких программных продуктов?

§ Как правило, легкости разработки и внесения изменений в календарно-сетевые графики, а также расчета резервов и критического пути.

§ Возможности визуализации информации на экране.

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

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

§ Легкости разработки различных сценариев проекта.

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

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

§ общее мнение о продукте, его имидж, популярность;

§ вид пользовательского интерфейса;

§ существующие ограничения по использованию;

§ ценовая политика;

§ техническая поддержка;

§ обучение;

§ информация о фирме производителе;

§ назначение, специализация;

§ мощность (в управлении проектом) и ряд других.

Проведем краткий анализ упомянутых выше наиболее популярных продуктов.

"Microsoft Project 2003", продукт Microsoft Corporation, принадлежит семейству Office. В 2007 году произошел переход на новую версию. Имеет все достоинства привычного интерфейса Microsoft, те же знакомые принципы работы. Существует локализованная русская версия. По использованию в мире и в России - продукт номер один среди систем офисного класса, имеет более 15 млн пользователей. В большей степени продукт предназначен для управления небольшими проектами. Универсален в применении к проектам различной природы. Обладает очень широкой поддержкой, существуют доступные книги и курсы обучения. Практически в каждом крупном городе России можно найти поставщика. По существующей статистике, компания, приступающая к управлению проектами, постепенно и осторожно выбирает для первых проб именно этот продукт. Проработав некоторое время, приходит понимание более осознанного выбора. Продукт особенно часто применяется в ИТ-проектах.

"Spider Project" является российской разработкой и поддерживается компанией Spider Technologies Group. По своим возможностям является полным конкурентом "MS Project", хотя и есть ряд отличий. Занимает второе место в России по популярности после конкурента. Ценовая ниша такая же. Поставка осуществляется напрямую компанией, которая дальше и сопровождает внедрение и обучение. Учитывает ряд российских особенностей, например использование нормативно-справочной информации - о производительностях ресурсов, стоимостях. Часто применяется в строительных проектах.

"Open Plan Desktop 3.1" разрабатывается компанией Deltek. Существует локализованная русская версия. В России поддерживается компанией А-Рго-ject Technologies. Продукт значительно мощнее двух предыдущих, что также отражается и на его цене. Продукт интегрируется с ERP ERP (Enterprise Resource Planning) - система планирования и управления ресурсами предприятия, необходимыми для осуществления продаж, закупок и учета при выполнении заказов клиентов в сферах производства, дистрибуции и оказания услуг.. Среди основных отраслей применения - строительство, крупное сборочное производство.

"Project Planner Prof myPrimavera" предназначена для управления большими проектами и программами. В России распространяется компанией "ПМСОФТ". Также существует локализованная русская версия. Использование этого и предыдущего продукта предполагает большие затраты на внедрение и специальную службу дальнейшей поддержки. Отрасли применений аналогичны - строительство, крупное сборочное производство.

Внедрение программного продукта

1. Неточно спланированная программа требует в 3 раза больше времени, чем предполагалось; тщательно спланированная - только в 2 раза.

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

Законы мира ЭВМ по Голубу

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

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

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

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

§ обсуждение идеи и получение поддержки руководства компании;

§ проведение первичной диагностики "Как есть";

§ моделирование и утверждение состояния "Как должно быть";

§ разработка и одобрение проекта внедрения;

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

§ запуск рабочих проектов на месте;

§ осуществление обратной связи, необходимая коррекция;

§ разработка начальных процедур, документации;

§ отработка документации;

§ проведение специализированного обучения;

§ пилотное использование ИСУП;

§ обратная связь, коррекция;

§ углубление внедрения и т. д.

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

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

Обоснование внедрения и объект для внедрения

При определении необходимости внедрения КСУП возникает самый первый и главный вопрос: нужно ли это делать? Будет ли это помогать текущим процессам? Подходит ли бизнес и сама компания для управления проектами? Оптимальны ли предлагаемая стратегия внедрения и само решение? Задайте вопрос своим подчиненным, хотят ли они получить некоторые рамки и ограничения при управлении проектами, комфортно ли им будет работать при наличии инструкций и шаблонов, общего языка? При правильной постановке вопроса большинство ответов будут положительными.

В условиях растущей конкуренции применять проектные подходы надо, и лучше делать это в рамках определенной формализации - тем более что в России существует генетическая предрасположенность к работе под чьим-то руководством (батюшки-царя, начальника, президента) и в рамках процедур и инструкций. Однако это не только русская специфика - целый ряд зарубежных компаний использует такие внутренние регламенты и системы управления проектами (Oracle, IBM, Pricewaterhouse Coopers, Andersen Consulting, SAP AG, Siemens).

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

Разработка стандарта по управлению проектами

Никогда не рассчитывайте, что так называемый "профессионал" действует исключительно в ваших интересах.

Дэвид Махони

Общие соображения по созданию стандарта

Управление проектами в общем смысле (без привязки к отрасли) регулируется так называемыми внешними рамочными документами общего характера. Чаще к таким внешним стандартам в российских компаниях относятся: "РМ Body of Knowledge" (PMBoK, версия 2004 года), признаваемый многими международным стандартом де-факто; стандарты качества системы ISO, придавшие ряду наиболее важных положений РМВоК статус стандарта де-юре, и International Competence Baseline (ICB), декларируемые европейской IPMA и известные в России больше как "Основы профессиональных знаний, национальные требования к компетенции специалистов по управлению проектами".

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

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

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

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

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

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

Состав регламента или стандарта (примерный)

По своему содержанию регламент или стандарт может включать следующие основные части:

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

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

3. Описание политики компании при:

§ отборе проектов и растравлении их по приоритетности; Ф ресурсном обеспечении проектов;

§ мотивации;

§ построении коммуникаций между участниками проектной деятельности;

§ управлении рисками в проектах компании; Ф управлении качеством;

§ работе с поставщиками.

4. Детальные процедуры и инструкции, привязанные, например, к жизненному циклу проектов компании.

5. Шаблоны и формы всех типовых документов, используемых при управлении проектом.

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

Стратегия внедрения системы управления проектами

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

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

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

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

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

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

§ Цели проекта и ожидаемые результаты не определены заранее или определены не в полном объеме. Жесткие временные ограничения, нетерпеливость или непоследовательность руководства могут не позволить реализовать цели проекта в полном объеме.

§ Планирование ввода в эксплуатацию всех компонентов КСУ П одновременно. Это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом.

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

§ Таким образом, некоторые общие рекомендации по внедрению КСУП будут следующими:

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

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

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

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

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

Краткий план внедрения

Базовая стратегия внедрения включает следующие основные элементы:

§ определение основных потребностей бизнеса и особенностей организации;

§ диагностика существующих подходов и бизнес-процессов;

§ определение текущего состояния проектного управления;

§ разработка и согласование модели "Как есть";

§ разработка и утверждение модели "Как должно быть";

§ формулирование и согласование плана проекта внедрения;

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

§ финансирование изменений;

§ создание начальных элементов внутренней инфраструктуры управления проектами:

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

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

в) создание аналитического центра по представлению проектной информации (возможно совмещение со службой);

г) выделение проектного офиса (не всегда);

§ подготовка кадров в виде базового обучения;

§ разработка механизма функционирования структур;

§ разработка типовых контрактов с командой и руководителями проектов;

§ разработка внутрифирменного стандарта или регламента по управлению проектами;

§ внедрение матричной структуры управления на ряде пилотных неосновных проектов;

§ апробация стандартов и инфраструктуры на пилотных проектах;

§ переход к постепенному использованию системы управления проектами на других проектах;

§ фиксирование дальнейшей разработки стандартов и инфраструктуры.

Проблемы внедрения проектного управления в компанию

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

Дионисий Галикарнасский, из письма к Помпею

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

Отсутствие должной поддержки руководства

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

Отсутствие системы делегирования полномочий

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

Из практики

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

...