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

Вид материала

Документы

Содержание 9.5. Разработка политики, процедур, инструкци 9.6. Разработка документооборота и использование информационной системы 10.6.1. Краткая информация о программном обеспечении управления проектами 10.6.2. Внедрение программного продукта 9.7. Обоснование внедрения и объект для внедрения 10.8. Разработка стандарта по управлению проектами Общие соображения по созданию стандарта 10.8.1. Состав регламента или стандарта (примерный) 9.9. Стратегия внедрения системы управления проектами

Подобный материал:

• Программа развития колледжа «Развитие и совершенствование образовательного процесса», 493.46kb.
• Журавлева Сергея Юрьевича Группа 1 «Б» план доклад, 300.44kb.
• Видеть в детях злость и жестокость всегда очень тревожно и неприятно, 58.4kb.
• Барбара де Анджелис секреты о мужчинах, которые должна знать каждая женщина, 44.34kb.
• Типовой план проекта «Разработка стратегии и внедрение системы стратегического управления», 117.19kb.
• «управление проектами в сфере бизнеса», 21.93kb.
• Ю. М. Волынский-Басманов, 333.39kb.
• Расписание передач, 2030.14kb.
• Джин Шинода Болен, 8099.36kb.
• Всё зависит от вас!, 98.27kb.

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

Дэвид Махони

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

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

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

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

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

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

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

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

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

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

1. Введение, включающее: основные определения, терминологию, назначение и связь с другими документами, используемые сокращения, порядок утверждения, ввода в действие и т. п.
   
2. Основные понятия, где рассматриваются: типовой жизненный цикл проекта компании, классификация проектов, участники и заинтересованные лица, организационная структура, критерии отбора, процессы и инструменты.
   
3. Описание политики компании при:
   
   • отборе проектов и растравлении их по приоритетности; Ф ресурсном обеспечении проектов;
     
   • мотивации;
     
   • построении коммуникаций между участниками проектной деятель­ности;
     
   • управлении рисками в проектах компании; Ф управлении качеством;
     
   • работе с поставщиками.
     
     4. Детальные процедуры и инструкции, привязанные, например, к жизненному циклу проектов компании.
        
     5. Шаблоны и формы всех типовых документов, используемых при управлении проектом.
        
     6. Различные приложения, среди которых могут быть предложения по оценке работы исполнителей и их мотивации, должностные инструкции руководителя и куратора проекта, положение о команде, краткоеописание инструментария управления проектами и т. п.
        

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

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

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

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

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

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

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

• Цели проекта и ожидаемые результаты не определены заранее или определены не в полном объеме. Жесткие временные ограничения, нетерпеливость или непоследовательность руководства могут не позволить реализовать цели проекта в полном объеме.
  
• Планирование ввода в эксплуатацию всех компонентов КСУ П одновременно. Это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом.
  
• Планирование перевода сразу всей компании на использование системы, подобно попытке связать сразу всех сотрудников крупной организации в локальную вычислительную сеть вместо того, чтобы осуществлять подключение пользователей последовательно, отдел за отделом.
  
• Таким образом, некоторые общие рекомендации по внедрению КСУП будут следующими:
  
• Решите, что вы хотите от внедрения новой системы. Обсудите ожидаемые от внедрения системы результаты со всеми, кого это может касаться, на разных уровнях управления в организации.
  
• Спланируйте последовательное внедрение от простого к сложному. Рекомендуется начать с элементов планирования и контроля временных параметров, затем освоить ресурсное управление и только после этого переходить к стоимостному планированию и контролю. К интеграции системы управления проектами с другими системами лучше переходить после того, как процедуры использования основных ее функций освоены.
  
• Спланируйте внедрение системы по отделам. Начать лучше с небольшого отдела, обладающего достаточно квалифицированными сотрудни­ками. Необходимо помнить, что в каждой организации есть сотрудники, более заинтересованные в использовании новых систем автоматизации и более способные в их освоении. Начать лучше именно с них. Получив первую группу пользователей, освоивших систему, можно переходить к распространению ее на остальные отделы в организации. Когда система начнет реально работать в организации, противникам ее использования придется тоже перейти в ряды сторонников. Важно убедиться, что руководители отделов осведомлены о планах внедрения новой системы и действуют в соответствии с планом.
  

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


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