Реферат: Тема Внедрение проектного управления Паркинсон и Мерфи живы и хорошо себя чувствуют в вашем проекте

Управление проектами

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


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

Г. Керцнер


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


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

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

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

^ Из практики

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

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

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

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

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

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

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

^ Из практики

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

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

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

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


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

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

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

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


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

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

^ Из практики

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Институт проектного управления (PMI) сертифицирует по одинаковым для всех стран требованиям. Существует два уровня: Certified Associate in Pro­ject 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)


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

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

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

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


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

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

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


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

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

Г. Керцнер


Существует целый ряд относительно простых и сложных программных про­дуктов для управления проектами: «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. Продукт значительно мощнее двух предыдущих, что также от­ражается и на его цене. Продукт интегрируется с ERP2. Среди основных отрас­лей применения — строительство, крупное сборочное производство.

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


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

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

предполагалось; тщательно спланированная — только в 2 раза.

2. Работающая над программой группа питает отвращение к еженедельной

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

В условиях растущей конкуренции применять проектные подходы надо, и лучше делать это в рамках