Архивы

10 тенденций проектного управления в 2010 году

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

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

«Хотя 2008 и 2009 годы были непростыми, они дали профессионалам проектного управления редкую возможность продемонстрировать свои компетенции, а также пользу от применения систематического проектного подхода в сложных экономических условиях, — говорит исполнительный вице-президент ESI Дж. Лерой Вард, PMP, PgMP. — Вот почему рачительные руководители продолжают вкладывать деньги в профессиональное развитие своих проджект-менеджеров. Они заботятся об успехе проектной деятельности, повышении удовлетворения клиентов и увеличении доходов компаний».

Представляем вашему вниманию 10 тенденций проектного управления в 2010 году по версии ESI:

1. Будут популярны новые решения в области управления портфелями проектов.

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

2. Использование показателей требований для контроля выполнения проектов возрастет.

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

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

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

4. Проектные офисы дадут старт созданию центров развития бизнес-анализа.

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

5. Спрос на измерение гибких проектных показателей возрастет.

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

6. Управление поставками и аутсорсинг выйдут на передний план в проектном управлении.

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

7. Управление рисками станет важнейшей частью работы проектных менеджеров.

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

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

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

9. Оценка знаний по проектному управлению приобретет больший вес.

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

10. Обучение управлению проектами выйдет за пределы классов.

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

По материалам www.projectsatwork.com.

http://www.pmsoft.ru

Роль команды в процессе управления изменениями

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

Организационные изменения как объект управления имеют специфические черты:

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

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

  • Размораживание организации и вывод ее из текущего состояния.
  • Осуществление желательного типа преобразований.
  • Замораживание организации в новом желательном состоянии.

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

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

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

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

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

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

На рисунке 1 представлены факторы, которые влияют на эффективность работы команды.


Рисунок 1. Факторы, влияющие на эффективность работы команды.

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

Количество членов команды

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

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

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

Как правило, в литературе приводится следующая классификация команд по количественному составу:

  • маленькие команды (менее 4 человек);
  • средние команды (от 5 до 9 человек);
  • большие команды (свыше 10 человек).

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

Командные роли

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

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

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

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

Один из известных специалистов в области командообразования Р. Мередит Белбин выделяет девять командных ролей (см. табл.1). Исследования показали, что каждый член команды играет не одну, а часто две, даже три или четыре командные роли. Необходимо отметить, что их можно считать в равной степени важными для эффективности командной работы, при условии, что они используются в команде в надлежащие периоды времени и наилучшим образом. С учетом характерных черт командных ролей и особенностей стадий процесса управления изменениями можно предложить следующие рекомендации по структуре команд (0 – отсутствие данной командной роли на этапе процесса изменений, + — командная роль присутствует, ++ — преобладание данной роли над другими).

Тип роли Характерные черты Стадии процесса изменений
Размора-
живание
Преобра-
зования
Замора-
живание
Рабочая пчелка Недостаток гибкости, невосприимчивость к непроверенным идеям 0 + ++
Руководитель Способность без предубеждения выслушивать, рассматривать и оценивать достоинства всех предложений. + + +
Мотиватор Наличие большой импульсивности, готовность бороться с бездейственностью, самоуспокоенностью. ++ ++ +
Генератор идей Наличие изобретательности и интеллекта, но недооценивает практические детали ++ + +
Снабженец Всегда теряет интерес к работе, когда проходит ее первоначальная привлекательность ++ + +
Аналитик Рассудительность и хорошие аналитические способности, но отсутствует вдохновение и способность мотивировать других 0 + +
Вдохновитель Способен создавать и поддерживать командный дух, но может быть нерешительным в решающие моменты. ++ + +
Контролер Стремление добиваться совершенства во всем, наличие беспокойства по поводу мелочей. 0 ++ +

Таблица 1. Командные роли на разных этапах процесса управления изменениями.

Идеальное сочетание ролей должно определяется стоящими целями и задачами перед командной.

Цели команды

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

В таблице 2 представлены неотъемлемые характеристики целей согласно техники SMART (аббревиатура пяти английским словам), которые ставятся перед командной.

Характеристика цели Вопросы, которые помогают правильно сформулировать цель.
Specific Конкретность Достаточно конкретная поставлена цель? Насколько правильно понимает ее сотрудник?
Measurable Измеримость Как будет оцениваться степень достижения результатов?
Agreed Согласованность Согласны ли члены с постановленной целью?
Realistic Реальность Насколько достижимой является цель? Есть ли у членов команды ресурсы для достижения поставленной цели? Находится ли она в сфере их компетенции?
Time bound Ограниченность во времени Когда цель должна быть достигнута?

Таблица 2. Требования к формулированию целей для членов команды.

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

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

Помимо вышеописанных общепринятых характеристик цели должны быть:

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

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

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

Автор: Н.Г. Шаламова,канд.экономических наук, доц. Государственного Университета Управления, А.А. Ненахова,Консультант по управленческим технологиям компании Navision Group
Источник: http://www.iteam.ru

http://www.pmsoft.ru

Управление возможностями — инициация проектов

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

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

Инициация (старт) проекта проходит через следующие стадии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Финансовые показатели проекта

Показатель Комментарии
1. GM
(Gross Margin)
Валовая прибыль
Показывает разницу ($) между доходами и прямыми расходами проекта без учета корпоративных накладных расходов.

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

2. GMROI
(Gross Margin Return on Investments)
Валовая отдача на затраты
Показывает, какую валовую прибыль компания получила на каждый вложенный в проект рубль/доллар.

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

3. GMRODL
(Gross Margin Return on Direct Labor)
Валовая отдача на прямые трудовые расходы
Показывает, какую валовую прибыль компания получила на каждый затраченный час работы сотрудника.

Данная величина показывает, насколько эффективно Компания использует самый дефицитный ресурс- рабочее время сотрудников

Автор: Д. Шепелявый, Директор по управлению проектами, Информзащита

http://www.pmsoft.ru

Проектный менеджмент в рыночной экономике

1. ОПРЕДЕЛЕНИЕ

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

2. СВЯЗЬ ИННОВАЦИЙ И ПРОЕКТНОГО МЕНЕДЖМЕНТА

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

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

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

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

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

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

3. КАТЕГОРИИ ПРОЕКТА

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

Актуальное анкетирование в сфере исследований и разработок (ИР) Германии показали следующие результаты:

  • чистые проекты ИР 42 %
  • проекты по оборудованию и системам 26 %
  • организационные проекты и проекты по обработке данных по инвестиционным проектам 16 %-12 %
  • прочие проекты 4 %

4. КРИТЕРИИ УСПЕШНЫХ ПРОЕКТОВ

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

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

Были выведены следующие критерии, которые отличают успешные проекты от неудачных:

Общая готовность к изменениям

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

Культура конфликтов

При успешных проектах с конфликтами обходятся конструктивно и открыто. Царит свободный обмен информацией и мнениями, а также открытость для критики. Напротив, отрицательное влияние на успех в случае менее успешных проектов оказывает подавление критики («Не критикуй меня!»), проявление власти и скрытое напряжение.

Личная ответственность сотрудников проекта

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

Культура доверия

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

Отсутствие иерархии

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

Коммуникационная и информационная культура

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

5. ОРГАНИЗАЦИОННАЯ СТРУКТУРА, КОМАНДА ПРОЕКТА И МЕНЕДЖЕР ПРОЕКТА

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

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

Оптимальная величина команды составляет приблизительно 6 — 8 человек.

Проектные команды сводят к минимуму организационные потери при притирке и, прежде всего, притупляют «природный» конфликт между техниками и экономистами.

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

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

В качестве организационных форм в основном существует три возможности:

а) Работа над проектом как дополнительная задача

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

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

б) Классическая организация проекта («предприятие в предприятии»)

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

в) Смешанные формы

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

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

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

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

Работа над проектом будет успешной тогда, когда будут устранены следующие препятствия:

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

6. РАБОТА НАД ПРОЕКТОМ

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

Работа над проектом тем самым подразделяется на три временные фазы:

  1. сбор информации;
  2. проверка спроса на рынке;
  3. реализация.

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

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

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

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

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

7. ИНСТРУМЕНТЫ ДЛЯ ПРОЕКТНОГО МЕНЕДЖМЕНТА

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

Описание проекта

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

Структурный план проекта

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

Техника творчества

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

Проектный контроллинг

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

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

Автор: Х.Берр, Восточно-Европейская Консалтинговая Компания
Источник: http://www.iteam.ru

http://www.pmsoft.ru

Шесть признаков корпоративных информационных систем управления проектами

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

В реализацию проектов вовлечено множество сотрудников организации, поэтому корпоративная система управления проектами (Enterprise Project Management — EPM) не может состоять из одного программного продукта «на все случаи жизни». Пользователям, находящимся в разных подразделениях на разных уровнях управления, для выполнения своих обязанностей в любой момент времени должна быть доступна необходимая информация о проекте. Высшему руководству, например, требуются лаконичные и удобные формы представления информации о портфеле проектов, отчеты по отклонениям, дающие возможность проследить за ходом выполнения отдельных проектов, соблюдением бюджетных и временных ограничений, а также позволяющие определить, что еще необходимо сделать. У руководителей проектов должна быть возможность разрабатывать различные сценарии развития событий, чтобы завершить проект в заданные сроки. Исполнителям конкретных работ нужно регулярно получать интерактивный список задач на отчетный период с возможностью отчитываться в их фактическом выполнении. Аналитикам требуются средства для моделирования всех возможных рисков и вероятных сценариев развития многих проектов в комплексе, с учетом их взаимного влияния друг на друга.

Решения компании Primavera Systems включают в себя как web-, так и Windows-приложения, и обеспечивают ролевой доступ к данным для удовлетворения потребностей всех пользователей в соответствии с их полномочиями и обязанностями. Они предоставляют на каждый уровень управления всестороннюю информацию о проектах — от укрупненных показателей выполнения до детальных графиков.

Поддержка глобальных иерархических структур

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

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

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

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

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

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

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

Обеспечение обмена информацией внутри команды проекта в режиме реального времени

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

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

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

Наглядное представление информации о состоянии проектов

Несомненно, Вы слышали фразы «Что не можешь измерить, тем не можешь управлять» или «Что измеримо, то выполнимо». Компании, использующие разнообразные методики оценки состояния проектов, имеют больший потенциал для достижения лидирующих позиций в своей отрасли. Поэтому EPM-система должна обладать хорошим функционалом в области контроля выполнения проектов.

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

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

Готовность к интеграции

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

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

Автор: Primavera Systems
Источник: http://www.primavera.com

http://www.pmsoft.ru

Практическая модель Управляющего проектами

Тезисы Доклада

«Мы имеем дело не с законами природы,
а с нашим представлением о них»
Вернер Карл фон Гейзенберг,
Нобелевский лауреат по физике

1. Введение

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

1.1. Профессиональный фенотип Управляющего проекта

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

Человек сформирован как совокупность всех признаков и свойств на момент его прихода в профессиональную среду (социальный фенотип). Эти признаки и свойства развиваются, изменяются и формируются новые в процессе «созревания» профессионала под воздействием окружающей профессиональной среды. Тем самым формируется его «профессиональный фенотип». Один и тот же человек будет иметь разный профессиональный фенотип через несколько лет проектной работы, например, в IT среде и в политических проектах. Иначе, профессиональный фенотип является характеристикой индивидуума.

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


Рис. 1. Модель Компетентности Управляющего в Деятельности (Фенотиповая модель)

Управляющий проекта использует в своей практической деятельности:

  • статичные характеристики (знания и опыт)
    • в динамике (в деятельности) посредством такого инструмента, как
      • его профессиональный личностный фенотип.

1.2. Компетентность Управляющего проекта

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

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

1.3. Деятельность Управляющего проекта

Результативность и эффективность конкретного Управляющего можно определить только в деятельности. А деятельность состоит из двух компонент – «мыслительной» и «физической». Их эффективность проявляется в результатах проекта. Но далеко не всегда эти результаты можно «измерить» или адекватно «оценить». Часто затраты на корректную (научно-обоснованную) оценку результатов проекта превышают затраты на осуществление самого проекта.

В своей деятельности Управляющий проекта использует различные инструменты, в т.ч. – из МП:

  • формализованные на уровне исполнения;
  • формализованные частично на уровне концептуальном и частнометодологическом (в виде подходов, принципов, моделей);
  • не формализованные (персональные технологии, личные техники, «know-how»).

Основой для целостного и эффективного использования инструментов на практике является:

  • Персональное видение и понимание сущности (природы, анатомии) проекта и проектной деятельности
  • Личность (индивидуальность) Управляющего проекта
  • Целостная, персональная структура деятельности (framework) Управляющего
  • Профессиональный фенотип Управляющего

1.4. Результаты построения Практической модели Управляющего проекта

Исходя из выше изложенного, перед Участниками Workshop был поставлен Базовый вопрос:

  • какие возникают ассоциации, есть мнения, какие компоненты и характеристики они видят по словосочетанию: «Практическая модель Управляющего проекта»?

Всего набралось 33 позиции, которые структурированы в рамках фенотиповой модели (см. Табл.1)

1.5. Резюме

  • Одной из целей обобщения собственной практики и чужого опыта с различных позиций является построение собственной модели деятельности, которая была бы адекватна личности Управляющего и была бы эффективна в практической работе
  • Основой для построения собственной модели может быть взята Практическая Модель Управляющего проекта, которая объединяла бы в «целое» множество разнородных компонентов (элементов, характеристик и проч.). Это требует поиска принципиально другого основания (структуры, фрейма) для классификации и построения целостной модели УпрП.
  • Не является очевидным, что существует единая модель УпрП для любого типа проектов. Возможно, что для разных проектов есть разные эффективные модели УпрП. Более того, возможно, они имеют разный background и разную основу для классификации.
  • Модель всегда связана с конкретной личностью (индивидуальностью) УпрП. Разные соизмеримо эффективные УпрП могут иметь разный набор инструментов и личных техник. Поэтому УпрП необходимо выстраивать (осознано или не осознано) собственную Модель Персональной Деятельности, исходя из личностных характеристик и мировозрения (картины мира).
  • У достигшего «зрелости» УпрП имеется в явном или неявном виде персональная структура деятельности (framework) и наборы адекватных инструментов и техник личной работы (менеджерских, социокультурологических, управленческих, технических и проч.), которые обеспечивают его эффективность и адаптируемость (гибкость) к конкретным проектам в конкретной окружающей среде.
  • В представлении участников Workshop с точки зрения практической модели, основное внимание уделено профессиональному фенотипу и деятельности. Иначе, видение участников, как «зрелых» управляющих, ориентирована на профессиональный фенотип и деятельность.
  • Основная направленность такого подхода – на достижение цели и результаты, поэтому процессный подход в принципе не подходит для описания деятельности УпрП.

Таблица 1

Практическая модель Управляющего проектами
Компетентность
Знания Опыт
  • Должна быть системность и комплексность
  • При управлении проектом — можно работать без творчества
  • Практическая модель УпрП должна передаваться, т.е. она д.б. повторяема
  • Баланс власти, денег и творчества
  • При управлении проектом — можно работать без творчества
  • Умение найти удовлетворении от реализации чужих «идей» и «мечт» и достижения чужих целей (проектных)
  • Здравый смысл

 

Профессиональный Фенотип
  • Управляющим Проектами не становятся, а рождаются
  • УпрП не ищет легких путей
  • УпрП получает удовлетворение от элегантных решений (кайф)
  • У УпрП преобладает интерес к сложным задачам
  • УпрП занимает «активную жизненную позицию» по проекту
  • Сущность УпрП – проектный подход к жизни вообще
  • Толерантность
  • Нонконформизм
  • Умение найти удовлетворении от реализации чужих «идей», «мечт» и достижения чужих целей (проектных)
  • Готовность к неудачам и срывам (приспособляемость к изменениям)
  • Гибкость
  • Целевая установка (ориентация на цель, а не на процесс)
  • Способность к актуализации
  • Чувство ответственности
  • Вера
  • Здравый смысл
  • Позитивная картина мира
  • Оптимизм
  • Способность держать цель
  • Способность держать удар
  • Предугадывать (предчувствовать), интуичить ситуацию, изменения
  • Быть гармоничным
  • Быть «Дирижером»
  • Быть адекватным ситуации
  • Практическая модель УпрП всегда связана с его Персональной Моделью Деятельности (ПМД)

 

Деятельность
Мышление Действия
  • У УпрП преобладает интерес к сложным задачам
  • Сущность УпрП – проектный подход к жизни вообще
  • Здравый смысл
  • Позитивная картина мира
  • УпрП не ищет легких путей
  • Важно, как действует УпрП
  • УпрП занимает «активную жизненную позицию» по проекту
  • Готовность к неудачам и срывам (приспособляемость к изменениям)
  • Сущность УпрП – проектный подход к жизни вообще
  • Мобильность
  • Быть «Дирижером»
  • Быть адекватным ситуации
  • Баланс активности и реактивности

2. Неэффективный Управляющий проектами

2.1. Исходные посылки

Достаточно много исследований, моделей, мнений отражают варианты ответов на вопросы:

  • «каким должен быть эффективный Управляющий (менеджер) проекта?»
  • «кто такой эффективный УпрП?»
  • «какова модель эффективного УпрП?»

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

2.2. Базовый вопрос

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

Результаты представлены в Таблице 2 в рамках фенотиповой модели УпрП.

2.3. Вопрос на «засыпку»

Список таков, что провоцирует задать вопрос:

  • Кто никогда не был «неэффективным» Управляющим хотя бы на время или по какому-либо вопросу?
  • А кто был всегда «эффективным» Управляющим проекта?

Список характеристик «неэффективности» таков, что под любого УпрП можно подобрать ту или иную характеристику «неэффективности». Следовательно, требуется очень осторожное использование данного материала с пониманием:

  • Только устойчивое воспроизводство ряда характеристик свидетельствует о «профессиональной» некомпетентности
  • Единичные случаи проявления «неэффективности» могут быть связаны с отсутствием опыта работы в аналогичной ситуации и часто не могут быть основанием для принятия решения
  • Надо использовать Принцип «Сущности»:Зри в корень!

2.4. Резюме

  • Если исследований, моделей, характеристик и проч. «эффективного» УпрП достаточно, то в области оценки и характеристики «неэффективного» УпрП есть вакуум.
  • Модель неэффективного Управляющего (менеджера) проекта не может быть получена из модели эффективного УпрП посредством подхода: позитивная характеристика – та же характеристика с приставкой «не».
  • На практике при подборе УпрП (менеджера проекта) прагматично использовать подход на наличие характеристик «неэффективного» УпрП.
  • Характеристики можно разделить на те, которые:
    • Являются характеристиками профессиональной непригодности;
    • Ошибками, которые совершают все и которые являются признаками деятельности;
    • Ряд характеристик является признаками неэффективного Управляющего (менеджера) проектами, если они повторяются систематически.
  • Нужно быть очень осторожным при использовании данного набора характеристик и с пониманием их использовать. Иначе, этот инструмент — для «зрелого» Управляющего.
  • В модели неэффективного УпрП можно выделить некоторые характеристики, критичные для его деятельности по проекту в позиции УпрП:
    • не позитивный взгляд на окружающий мир;
    • ориентация не на цель, а на процесс;
    • определенный фенотип, который противопоказан для проектной деятельности.

Таблица 2

Неэффективный Управляющий проекта
Воспроизводит систематически все из приведенного списка
Компетентность
Знания Опыт
  • Не знает среды и «правил игры»
  • Не умеет делегировать (задачи, полномочия, ответственность и т.д.)
  • Пренебрегает ценой вопросов
  • Не гибкий к изменениям, отсюда – не «считает» ситуацию, не предугадывает ее развитие и проч.
  • Допускает компромиссы, уводящие от целей проекта
  • Не знает среды и «правил игры»

 

Профессиональный Фенотип
  • Недоучитывает человеческий фактор (перекос в технические аспекты проекта)
  • Не достигает цели и нарушает баланс целей по проекту
  • Который «раздражает» всех участников проекта
  • Не извлекает уроков из предыдущего опыта
  • Не гибкий к изменениям, отсюда – не «считает» ситуацию, не предугадывает ее развитие и проч.
  • Допускает компромиссы, уводящие от целей проекта
  • Не берет ответственность за принимаемые им решения по проекту
  • Не принимает решения (уходит от решений)
  • Если он порождает потребность (у членов проектной группы) в «героизме» и «подвигу»
  • «Прячет» проблему (уходит от проблем, оставляя их неразрешенными)
  • «Заклинивается» на одной частной задаче (например, «паралич» анализа)

 

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

3. Значимость человеческого фактора в деятельности Управляющего проектами

3.1. Исходные данные

Ранжирование и выбор наиболее интересного аспекта. Из списка Аспектов (см. Доклад «Что такое Workshop?»), посредством «мягкого рейтингования» был выбран наиболее интересный для Участников – «психологический», в последующем дополненный «человеческим фактором».

Позиционирование Участников. Была выбрана позиция «Практическая».

Результаты. Была сформирована следующая конструкция для последующей работы:

Выбранная Позиция: Практическая для Управляющего проекта
Аспект: Психологический (человеческий)
Вопрос: Какие психологические (человеческие) аспекты в Менеджменте проектов имеют важное значение с практической точки зрения?

Перечень элементов (факторов): 20 позиций

Шкала: Критически важно – существенно важно – следует учитывать – не очень важно – не важно

Базовый вопрос

  • Какова значимость в Вашей практической деятельности Управляющего проекта ниже перечисленных элементов, связанных с «психологической» (человеческой) составляющей?

3.2. Результаты

В ранжировании приняло участие 11 «зрелых» управляющих проектов. Результаты ранжирования 20 элементов представлены в Таблице 3.

Таблица 3

№№ Элемент (фактор) Значимость
(в процентах
по шкале 0 — 100%)
1 2 3
Критически важно – Интервал: 80% — 100%
1 Мотивация участников проекта и приемы ее выявления 88.7
2 Актуализация членов Команды и участников 87.5
3 Зрелость управляющего (менеджера) проекта 84.1
Существенно важно – Интервал: 60% — 80%
4 Коммуникации в команде 77.3
5 Роли участников (человеческие и психологические) в проекте 75.0
6 Взаимодействие Команды проекта с окружением проекта 75.0
7 Интерфейсы (человеческие и психологические) с окружением 72.7
8 Стимуляция (поощрительные и наказательные действия по активизации мотивов людей) 70.5
9 Лидерство 68.2
10 Групповая динамика и психология в команде 65.9
11 Привязка используемых инструментов PM к психотипу управляющего и членов команды 61.4
Следует учитывать — Интервал: 40% — 60%
12 Межличностные отношения 54.5
13 Личностные психологические особенности участников проекта 50.0
14 Биологические аспекты психологической составляющей 50.0
15 Стресс и психологический ресурс (как мера того, когда человек сломается) 50.0
16 Конфликты (психологические аспекты возникновения и разрешения) 47.7
17 Талантливость и способности 47.7
18 Харизма 47.7
19 Пределы психологической совместимости в Команде проекта 47.7
Не очень важно — Интервал: 20% — 40%
20 Стандартизация психологических аспектов (в рамках корпоративной системы управления проектами) 38.6

3.3. Резюме

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

Заключение по Докладу

  1. Одной из целей обобщения собственной практики и чужого опыта с различных позиций является построение собственной Персональной Модели Деятельности Управляющего проектами, которая была бы адекватна личности Управляющего и была бы эффективна в практической работе.
  2. Основой для построения ПМД может быть взята Практическая Модель Управляющего проекта, которая объединяла бы в «целое» множество разнородных компонентов. Такой подход требует поиска принципиально другого основания для построения целостной модели УпрП. Иначе, основание для квалификации должно быть не из того «поля», в котором находятся входящие в модель компоненты.
  3. Не существует единой модели УпрП для любого типа проектов. Для разных проектов есть разные эффективные модели УпрП. Более того, они имеют разный background и разную основу для построения, в которую обязательно входит Профессиональный фенотип Управляющего. Модель всегда связана с конкретной личностью (индивидуальностью) УпрП. Разные соизмеримо эффективные УпрП могут иметь разный набор инструментов и личных техник.
  4. У достигшего «зрелости» УпрП имеется в явном или неявном виде персональная структура деятельности (framework) и наборы адекватных инструментов и техник личной работы (менеджерских, социокультурологических, управленческих, технических и проч.), которые обеспечивают его эффективность и адаптируемость (гибкость) к конкретным проектам в конкретной окружающей среде. Каждый УпрП выстраивает (осознано или не осознано) собственную Модель Персональной Деятельности, исходя из личностных характеристик и мировозрения (картины мира).
  5. В представлении участников Workshop с точки зрения практической модели, основное внимание уделено профессиональному фенотипу и деятельности. Иначе, видение участников, как «зрелых» управляющих, ориентировано на профессиональный фенотип и деятельность. Основная направленность деятельности УпрП – на достижение цели и результаты, поэтому процессный подход в принципе не подходит для описания его деятельности в принципе.
  6. Если исследований, моделей, характеристик и проч. «эффективного» УпрП достаточно, то в области оценки и характеристики «неэффективного» УпрП есть вакуум. Модель неэффективного Управляющего (менеджера) проекта не может быть получена из модели эффективного УпрП посредством подхода: позитивная характеристика – та же характеристика с приставкой «не». На практике при подборе УпрП (менеджера проекта) прагматично использовать подход на наличие характеристик «неэффективного» УпрП.
  7. В модели неэффективного УпрП можно выделить некоторые характеристики, критичные для его деятельности по проекту в позиции УпрП, в частности, не позитивный взгляд на окружающий мир; ориентация не на цель, а на процесс; определенный фенотип, который противопоказан для проектной деятельности и проч.
  8. Управляющий проектами, как профессиональный тип, ориентирован на преобразование окружающей среды и на «других», т.е. является явно выраженным экстравертом.
  9. Управляющий ориентирован на групповые цели, связанные с успехом проекта; он также явно ориентирован на командную работу.
Автор: Владимир Михеев, Cert. PMP IPMA, к.т.н., асессор IPMA, Руководитель Workshop, Вице-президент PM-Club

http://www.pmsoft.ru

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

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

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

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

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

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

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

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

Автор: Майк Ньюэлл
Источник: Директор ИС, #01/2001

http://www.pmsoft.ru

Технология самоорганизации команды менеджмента проекта: системный подход

Аннотация

Для того чтобы Команда Менеджмента Проекта (Project Management Team) была готова к совместной работе и, в последующем, к эффективной самоорганизации, требуется, чтобы каждый ее участник был интегрирован в команду и в проект.

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

В настоящем докладе рассматривается технология самоорганизации КМП на стадии исполнения проекта или его фазы с точки зрения самоорганизации систем.

Введение

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

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

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

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

  • стратегическим характером современного менеджмента проектов и соответствующего подхода к деятельности компаний в рыночных условиях [1-3];
  • многообразием типов проектных команд (самоуправляемые, самомотивирующиеся и т.п.), их культурой и современным подходом к созданию и деятельности команд проектов [4];
  • сущностью современной команды менеджмента проектов и ее многопозиционностью в проекте (как субъекта управления, как элемента технологии осуществления проекта и как группы индивидуумов) [5];
  • общим трендом к стандартизации проектной деятельности и унификации требований к профессионализму и мастерству менеджеров проектов [6,7].

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

Если использовать системный подход к формированию и использованию такой «технологии самоорганизации» (ТСО), то целесообразно:

  • рассмотреть КМП, как систему;
  • определить область и условия применимости ТСО КМП;
  • сформулировать метатехнологию самоорганизации КМП с точки зрения самоорганизующихся систем;
  • определить возможные наборы инструментов Project Management для разработки и реализации ТСО КМП.

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

  1. Команда менеджмента проекта, как система1.1. Системные характеристики КМП.

    КМП можно рассматривать как систему, обладающую определенными характеристиками. В этом случае, в качестве подхода к построению ТСО команды можно использовать основные положения теории самоорганизующихся систем [8-12].

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

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

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

    В КМП, как в системе, можно выделить:

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

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

    3. Свойства. КМП, как система, должна обладать следующими свойствами:.
    • Целесообразностью.
    • Иерархическим строением.
    • Адаптацией.
    • Памятью.
    • Разнообразием состояний.

    1.2. Интерпретация системных свойств применительно к КМП.

    Применительно к КМП свойств системы можно интерпретировать следующим образом:

    Целесообразность.

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

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

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

    Иерархическое строение.

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

    Адаптация

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

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

    Память

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

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

    Разнообразие состояний

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

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

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

  2. Технология самоорганизации КМП2. 1. Метатехнология и технология самоорганизации

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

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

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

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

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

    2.2. Область применимости

    На начальной стадии проекта (start-up) используется практика проведения стартовых семинаров, тренингов или интеграционных процедур для создания и организации работы команды (Team Building). На этой стадии понятие «самоорганизации» не применимо и не имеет смысла. На стадии расформирования и/или реорганизации команды сам термин «самоорганизация» выглядит странно. Поэтому «технология самоорганизации» применима только к процессу развития команды (Team Development).

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

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

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

    2.3. Условия применимости

    Самоорганизация возможна при определенных условиях:

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

    Иными словами, в рамках ТСО КМП:

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

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

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

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

    Вид проектной команды. Представление о самоорганизации применимо к управленческому звену проекта (команде или группе менеджмента проекта) или когда вся команда проекта не превышает 10-12 чел.

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

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

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

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

    Для запуска нужно иметь:

    • Сформированную КМП, прошедшую этап start-up и Team Building.
    • Заданные форматы и формы повторяемых (цикличных) действий.
    • Заданные правила: их наличие, принятие членами КМП и соблюдение.
    • Действия: обязательные периодические и регулярные.
    • Коммуникации: формальные, неформальные, личностные.
    • Информация: интегрированный информационный контекст проекта.
  4. Инструменты менеджмента проектов для ТСО КМПВозникающие трудности при выборе инструментов всегда связаны с уникальностью проекта (по определению). Уникальность проекта всегда требует создания уникальной команды проекта, т.к. вне проекта «команда проекта» не существует. Поэтому совокупность инструментов можно в той или иной степени определить, однако их набор и взаимосвязи в обязательном порядке формируются под конкретный проект в рамках групповой работы конкретных членов КП.

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

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

    В качестве регулирующих процесс самоорганизации инструментов можно использовать:

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

    Резюме

    1. При использовании системного подхода для построения ТСО КМП всегда следует учитывать неопределенности в проекте, которые связаны с влиянием человеческого фактора. Поэтому типовые подходы можно определить на уровне метатехнологии для групп проектов, обладающих сходными характеристиками.
    2. Для конкретного проекта всегда требуется построение уникальной ТСО на базе метатехнологии самоорганизации для определенного типа проектов с учетом особенностей конкретного проекта, «зрелости» компании-исполнителя, профессионального потенциала и особенностей индивидуумов, входящих в КМП.
    3. Целесообразность использования ТСО определяется в каждом конкретном случае и зависит от масштаба проекта (чем выше объемы, тем большая эффективность), его длительностью (чем продолжительней проект, тем большая экономия высокопрофессионального управленческого ресурса) и профессионализма индивидуумов (чем выше профессионализм и мастерство, тем больший эффект).
    4. Использование ТСО возможно только при определенных условиях: на стадии Team Development, при наличии достаточного для получения кумулятивного эффекта профессионального и человеческого потенциала членов КМП, установленных и выполняемых правилах и процедурах совместной и индивидуальной работы членов КМП.
    5. Использование ТСО возможно в такой КМП, совокупный потенциал членов который превышает необходимый совокупный профессиональный потенциал, требуемый для осуществления конкретного проекта (требование избыточности системы).

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

    2 Мета… (гр. meta после, за, через) – составная часть сложных слов, обозначающая переход к чему-либо другому.


    Литература

    1. Cleland David I. Strategic Management of Teams. John Wiley & Sons, Inc., New York, 1996. – pp. 292.
    2. Cleland D.I., Project Management: Strategic Design and Implementation. — New York, NY: McGraw Hill Publishing Company Inc., 1999. – pp.560.
    3. Михеев В.Н. Проектный Менеджмент для проектно-ориентированных компаний. «Консалтинг», № 1-2, 2002, с. 16-27.
    4. Verma V., Managing the Project Team. The Human Aspects of Project Management. – V.3, Pennsylvania, PA: PMI, 1997. — pp.296.
    5. Михеев В.Н. Современная команда менеджмента проекта. ComputerWorld. Директору информационной службы, май 2001г., сс. 14-21.
    6. ICB — IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee: Caupin G., Knopfel H., Morris P., Motzel E., Pannenbacker O.. — Bremen: Eigenverlag, 1999. — pp.112.
    7. Михеев В.Н., Товб А.С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.33-37.
    8. С.Н. Брайнес, Свечинский В.Б. «Принципы организации сложных биологических систем управления»,Москва, Наука, 1967г.
    9. Н.А.Бернштейн». Пути развития физиологии и связанные с ними задачи кибернетики. Биологические аспекты кибернетики»,Москва,Наука, 1969г.
    10. В.П.Кузнецов, М.А.Раков. «Самоорганизация в технических системах», Киев, НАУКОВА ДУМКА, 1987г.
    11. Завадский К.М.»К проблеме прогресса живых и технических сисием», Ленинград,Наука,1970г.
    12. У.Р.Эшби «Принципы самоорганизации», Москва,Мир,1966г.
Автор: В.Н. Михеев, Е.О.Пужанова

http://www.pmsoft.ru

Корпоративная система управления: бюджетирование и управление проектами

Введение

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

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

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

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

Бюджетирование и управление проектами: что первично?

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

  • Функциональные
  • Матричные
  • Смешанные
  • Проектные

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

В данном докладе мы не будем подробно останавливаться на особенностях систем бюджетирования функциональных организаций, так как они достаточно подробно описаны в [6, 7]. Доклад посвящен бюджетированию в проектно-ориентированных и матричных организациях.

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

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

Бюджетирование проектов

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

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


Рисунок 1. Пример формирования бюджета проекта

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

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

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

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

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

где

В финансовый баланс по проекту входят [методич. рекомендации]:

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

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

Эскиз графика финансового баланса представлен на рисунке 2.


Рисунок 2. Эскиз графика финансового баланса по проекту

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

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

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

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


Рисунок 3. Организация процесса бюджетирования

Если по проекту уже выполнено планирование работ и ресурсов, то все эти показатели должны приобрести финансовое выражение. Итак, бюджетирование проекта – это часть функции планирования, которая также обслуживает контрольный механизм, давая основу для сравнения, измерения, объяснения и корректировки фактических данных. Если основой планирования проекта является формирование структуры декомпозиции работ (WBS), то в основе финансового планирования (бюджетирования) проекта лежит определение структуры статей затрат. По каждому проекту в зависимости от его специфики определяются и устанавливаются статьи затрат, каждая из которых может состоять из нескольких статей, необходимых для оптимального планирования и контроля финансов по проекту. Основой формирования структуры статей затрат проекта является план статей затрат управленческого учета, «подстроенный» под нужды конкретного проекта. Пример структуры статей затрат проекта приведен на рисунке 4.


Рисунок 4. Пример структуры статей затрат проекта

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

Методики формирования бюджетов проектов

В проектах различных типов начальное планирование бюджета должно начинаться не менее чем за 1-3 года до начала выполнения проекта, задолго до того, как окончательно будет определен объем работ. Данный процесс называется составлением бюджета проекта сверху вниз. Составление бюджета сверху вниз включает определение затрат на проект на верхнем уровне. Обычно подобное определение затрат производится руководством, ответственным за материальные активы, либо группой планирования затрат, выполняющей схожие функции. Цель составления бюджета сверху вниз – долгосрочное планирование. Как правило, бюджеты, составляемые сверху вниз, не учитывают деталей проектов и поэтому не могут дать точного представления о затратах.

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

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

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

Реализация бюджетирования проектов Primavera Enterprise

Бюджетирование сверху вниз

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

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

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


Рисунок 5. Пример распределения бюджета сверху вниз

Также, при бюджетировании сверху вниз определяются планы финансирования, планы поступления средств и отклонения между этими показателями, позволяющие контролировать финансовую составляющую проекта. Логическая схема бюджетирования сверху вниз, реализованная в пакете Primavera Enterprise, представлена на рисунке 6.


Рисунок 6. Схема бюджетирования сверху вниз, реализованная в пакете Primavera Enterprise

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

Р3е позволяет сравнить ежемесячные суммы узла EPS (планы финансирования и планы поступления средств) с ежемесячными суммами проектов данного узла (распределенный план финансирования и распределенный план поступления средств). В том случае, если план финансирования узла EPS не совпадает с общей суммой планов финансирования отдельных проектов, производится расчет отклонений, как показано на рисунке 6.

Бюджетирование снизу вверх

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

В пакете Primavera Enterprise этот процесс построен следующим образом: для каждого ресурса в справочнике ресурсов указывается цена за единицу (расценка). Затем производится вычисление бюджетных затрат, для чего бюджетное количество умножается на расценку. Суммарные бюджетные затраты на работу включают также все расходы, назначенные на работу. Для объединения затрат на более высоком уровне создаются макеты, такие, как макет по WBS, проекту или EPS.

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


Рисунок 7. Пример бюджетирования снизу вверх в пакете Primavera Enterprise

Для просмотра затрат «более высокого уровня» можно создать макет, представляющий затраты на уровне EPS/проекта. Данные бюджеты определяются на основе оценок сверху вниз. Пример такого макета представлен на рисунке 8.


Рисунок 8. Сопоставление оценок бюджета, полученных с применением методик формирования бюджета снизу вверх и сверху вниз

Контроль бюджета проектов

Для осуществления эффективного контроля бюджета, в Primavera Enterprise включены инструменты анализа по методике освоенного объема. Методика освоенного объема и ее реализация в программном обеспечении Primavera более подробно описаны в [1].

После завершения проектов Р3е позволяет записывать и сохранять данные о прибыли, возврате инвестиций (ROI) и чистой приведенной стоимости (NPV) для каждого проекта. Данное значение облегчает процесс стратегического планирования при принятии решений о реализации схожих проектов в будущем. Пример отображения показателя ROI в Primavera Enterprise приведен на рисунке 9.


Рисунок 9. Пример отображения показателя ROI в Primavera Enterprise

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

Общие рекомендации для формирования бюджета проекта

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

Список литературы

  1. Колосова Е.В., Новиков Д.А., Цветков А.В. Методика освоенного объема в оперативном управлении проектами. М.:ООО «НИЦ Апостроф», 2000 – 153 с.
  2. Кочнев А. Преимущества системы бюджетного управления. www.iteam.ru
  3. Мазур И. И., Шапиро В. Д. И др. Управление проектами. Справочное пособие. М.: Высшая школа, 2001, 875 с.
  4. Тренев В.Н., Ириков В.А., Ильдеменов С.В., Леонтьев С.В., Балашев В.Г. Реформирование и реструктуризация предприятия. Методика и опыт. М.: Издательство ПРИОР, 1998. – 320 с.
  5. Хан Д. Планирование и контроль: концепция контроллинга: Пер. с нем./ Под ред. И с предисл. А.А. Турчака, Л. Г. Головача, М.Л. Лукашевича. М.: Финансы и статистика, 1997, 800 с.
  6. Хруцкий В.Е., Сизова Т.В., Гамаюнов В.В. Внутрифирменное бюджетирование: Настольная книга по постановке финансового планирования. – М.: Финансы и статистика, 2002 – 400 с.
  7. Щиборщ К.В. Бюджетирование деятельности промышленных предприятий России. – М.: Дело и Сервис, 2001 – 544 с.
  8. Planning and Managing Maintenance and Turnaround Projects. © 1997 – 2001 Primavera Systems, Inc.
Автор: А.А.Матвеев, Е.О.Пужанова, Ж.А. Малхасьян

http://www.pmsoft.ru

Внедрение систем управления. Что вначале — процессы или ПО?

  1. Введение

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

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

  2. ФАКТОРЫ, ВЛИЯЮЩИЕ НА ОБЪЕМ И ПОДХОД К ПРОВЕДЕНИЮ ВНЕДРЕНИЯ

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

    • наличие в организации формализованных и задокументированных бизнесс-процессов;
    • квалифицированность персонала организации и команды проекта внедрения АСУП;
    • диверсифицированность организации,
    • состав участников проектов, реализуемых в организации, и их территориальная распределенность (участников);
    • наличие в организации базы знаний в виде наработок по предыдущим проектами, классификаторов информации, статистических банков данных и т.д.;
    • другие факторы.

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

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

    • невысокой. В данном случае консалтинговая фирма выполняет:
      • поставку ПО;
      • обучение сотрудников организации и представителей команды проекта внедрения.
    • высокой. В данном случае консалтинговая фирма выполняет:
      • обследование организации и разработку технического задания на АСУП;
      • разработку модели функционирования АСУП;
      • формирование основных структур кодирования АСУП, в том числе структуры проектов предприятия и т.д.;
      • поставку программного обеспечения;
      • обучение сотрудников организации и представителей команды проекта внедрения;
      • разработку пилотного проекта;
      • разработку регламентов функционирования АСУП и инструкций для персонала АСУП.

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

    Рисунок 1. Виды внедрений, в зависимости от степени участия консалтинговой фирмы во внедрении2

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

  3. ОПИСАНИЕ БИЗНЕСС-ПРОЦЕССОВ И ПО

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

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

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

  4. ЧТО ПЕРВИЧНО — ПРОЦЕССЫ ИЛИ ПО? ВАЖНО ОПРЕДЕЛИТЬ КРИТЕРИИ

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

    4.1 КВАЛИФИКАЦИЯ ПЕРСОНАЛА

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

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

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

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

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

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

    4.2 КВАЛИФИКАЦИЯ КОМАНДЫ ПРОЕКТА ВНЕДРЕНИЯ

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

    • для представителей самой организации:
      • знание внутренних процессов на предприятии и его специфики;
      • способность донести до персонала организации важность работ по созданию АСУП;
      • наличие определенных должностных полномочий для продвижения решений, связанных с созданием АСУП;
    • для представителей консалтинговой фирмы
      • наличие опыта внедрения подобных АСУП;
      • умение говорить на языке «заказчика»;
      • если АСУП предполагается базировать на разрабатываемом/дорабатываемом ПО, то умение правильно интерпретировать требования к ПО в задачи для программистов.

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

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

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

    Итак, содержание проекта внедрения известно и команда проекта сформирована. Соответственно, можно сформировать структуру декомпозиции работ (далее СДР) по созданию АСУП. Следующим действием должно явиться закрепление ответственных из числа команды проекта за те или иные пакеты работ из состава СДР – формирование так называемой матрицы ответственности. Ускорить выполнение данной задачи можно с использованием программного продукта Project Manager (далее РМ) серии Primavera Enterprise разработчика фирмы Primavera Systems (Рис. 2).

    Рис. 2. Матрица ответственности проекта внедрения АСУП

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

    Рис. 3. Фрагмент графика внедрения АСУП. Назначение ресурсов в соответствии с ролями и квалификацией

Автор: К.В. ХАЛИМОВ, М.В. РЕЗНИК
Источник: ПМСОФТ, 2003

http://www.pmsoft.ru