Введение
Актуальность темы исследования. Для большинства российских компаний, которые стремятся использовать проектно-ориентированный подход, важнейшей задачей является разработка корпоративной методологии управления проектами (КМУП), определяющей основные понятия, принципы, механизмы и процессы функционирования корпоративной системы управления проектами (КСУП). КСУП наряду с проектами может включать программы и портфели проектов. Эффективность дальнейшего функционирования КСУП во многом определяется решениями, принятыми на этапе формирования методологии (КМУП). Таким образом, вопросы качественного методологического обеспечения разработки, функционирования и совершенствования управления проектами, программами и портфелями проектов в организации имеют определяющее значение для обеспечения эффективного выполнения проектно ориентированных задач компании.
Что касается управления портфелем проектов, то на сегодняшний день известен единственный стандарт, разработанный Институтом управления проектами США (PMI). Стандарт называется Standard for Portfolio Management (SPfM). SPfM определяет организационный контекст управления портфелем, основных участников, жизненный цикл и процессы, которые подразделяются на две основные группы - процессы выравнивания портфеля и процессы мониторинга и контроля.
Все перечисленные стандарты объединяются стандартом ОРМЗ (Organizational Project Management Maturity Model), разработанным PMI. Стандарт позволяет диагностировать зрелость организации в области управления проектами, программами и портфелями проектов. Под зрелостью организации понимается степень проникновения проектного подхода, включая методы, средства, процессы формального, классического, управления проектами в практику работы организации. В свою очередь, зрелость организации в стандарте ОРМЗ определяется в трёх измерениях: управление проектами, управление программами, управление портфелями проектов.
Разработка корпоративной методологии управления проектами, программами и портфелями проектов на основе предлагаемой «методологической пирамиды» позволит обеспечить системность, структурированность, полноту и соответствие корпоративной методологии соответствующим международным стандартам.
С 1 сентября 2012 года на территории РФ официально начали действовать российские национальные стандарты по управлению проектом, программой и портфелем проектов. ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом», ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов», ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой».
В составе управления проектами (контрактами) важное место занимает администрирование контрактов.
Цель работы - характеристика процесса администрирования контрактов в управлении проектами.
Основные задачи работы включают характеристику:
Основ организации;
Основных моделей;
Основополагающих принципов - администрирования контрактов.
Глава 1. Организация администрирования контрактов и управления изменениями
Стратегия управления проектом определяет, как сделать его успешным. Нередко на ранних этапах мало внимания уделяется вопросам, которые впоследствии вызывают проблемы. На первых стадиях руководителям необходимо задуматься о том, что влияет на успех их проектов, и управлять теми внутренними, внешними и стратегическими факторами, которые обеспечивают его. На рисунке показана модель стратегического управления проектами, разработанная на основании модели П. Мориса. На проекты воздействуют семь групп факторов.
Внешние условия.
Внешнее окружение воздействует на проект в двух направлениях:
) финансирование и календарный план - финансы, выделенные владельцем, ожидаемые выгоды и отрезок времени, который делает эти выгоды реальными и окупает финансовые вложения;
) внешние воздействия - политические, экономические, социальные, технические, законодательные и природоохранные факторы.
Внутри родительской организации действуют два фактора, а именно: стратегическое значение, придаваемое проекту, и стратегия его реализации:
) определение - уточнение того, что требуется сделать в рамках проекта, каков подход к проектным решениям и технологии их реализации;
) отношение участников - значение, придаваемое проекту, и поддержка на всех уровнях, от руководителей до исполнителей.
Внутри проекта действуют три движущих фактора:
) люди - управление ими, лидерство, командная работа и производственные отношения;
) системы - планирование, отчетность и контроль, при помощи которых будет оцениваться и регулироваться ход работ;
) организация - роли, ответственность и договорные взаимоотношения между участниками.
Прежде чем выбрать стратегию реализации проекта, важно знать, как следует оценивать его успешность.
Исследования показывают, что если руководитель проекта, его команда и другие заинтересованные стороны перед запуском проекта договорятся о том, как оценивать его успешность, то они тем самым максимизируют свои шансы на успех. Если же они этого не сделают, возрастет вероятность того, что участвующие в проекте люди воспользуются им для достижения своих скрытых целей.
Среди руководителей проектов распространено убеждение, что последние предназначены для соблюдения сроков, стоимости и качества. В лучшем случае это слишком упрощенно, а в худшем - просто вредно для успешного управления проектом. Сроки, стоимость и качество являются ограничениями, которые оказывают влияние на оценку проекта владельцем, но не являются ключевыми критериями. Однако подрядчик заинтересован в своевременном окончании проекта, потому что получит оплату, в выполнении проекта в пределах бюджета, т. к. получит прибыль, и в соблюдении технических условий, потому что владелец примет объект и рассчитается с подрядчиком. Участники проекта могут иметь множество скрытых целей, которые препятствуют объективной оценке. П. Морис и Дж. Хью проанализировали выполнение восьми крупных проектов в 1960-х, 1970-х и 1980-х гг. и выявили четыре критерия успеха:
) соответствие проекта функциональному назначению;
) своевременное выполнение в пределах заданных стоимости и качества;
) прибыльность для подрядчика;
) при необходимости - досрочное окончание.
Р. Дж. Тернер предлагает более обширный перечень для оценки успешности любого проекта:
соответствие заявленной миссии;
прибыльность для владельца;
удовлетворение нужд владельца, пользователей и участников;
соответствие заявленным целям создания данного объекта;
возведение объекта в соответствии с техническими условиями, в пределах бюджета и своевременно;
удовлетворение нужд команды проекта и всех, кто его поддерживал;
прибыльность проекта для этих сторон.
В этом контексте имеется несколько интересных моментов. Во-первых, большинство критериев являются субъективными: объективны только время и стоимость. Во-вторых, на оценку оказывают влияние скрытые цели оценщика. В-третьих, оценки не обязательно совместимы, но не являются взаимоисключающими, однако начинать следует с цели и через стратегию выполнения добираться до результата. Нельзя совместить оценки в конце проекта. И наконец, эти оценки не рассматриваются одновременно. Первые две могут быть получены только после того, как объект будет введен в эксплуатацию и будет выпущена продукция. Иногда на это могут уйти годы после окончания проекта.
Для неудачных проектов можно предложить следующие критерии:
спонсор думал только о прибыли;
пользователи хотели получить непродуманные функциональные характеристики;
аналитик хотел разработать «умное решение»;
руководители стремились любой ценой закончить проект в пределах плановой стоимости и сроков.
Показательно, что в успешных проектах люди согласованно добивались общих целей, а в неуспешных каждый «тянул одеяло на себя». Печально, что в неудачных проектах люди вроде бы сосредоточиваются на важных вещах: на функциональности проекта, на разработке эффективных решений или на окончании проекта в пределах заданной стоимости и сроков. Ф. Хартман предлагает в процессе старта задать команде проекта три вопроса.
. Какой результат выдаст команда проекта в день его завершения?
. Как оценить успешность достижения этого результата?
. Кто будет голосовать по вопросам 1 и 2?
Остановимся на недостатках, которые препятствуют успешному осуществлению проекта. Недостатки являются не рисками, а ошибками в управлении, допущенными руководителями проектов. Они возникают на стадии инициации проекта или на этапах его планирования, организации, выполнения или контроля. На основании своей практической деятельности в качестве генерального директора фирмы, разрабатывающей компьютерные программы, К. Груд перечисляет следующие недостатки.
. Недостатки при инициации проекта
Недостатки на стадии инициации проекта внутри родительской организации включают в себя следующее.
Планы проектов не совпадают с бизнес-планами. Планы проектов должны следовать из бизнес-планов. Этот недостаток возникает на старте детального планирования, и именно он обычно приводит к провалу проекта.
Процедуры управления проектом не определены. Для выполнения новых заданий в проектах используются временные команды. Для успешного выполнения этих заданий такие команды формируются оперативно. Поэтому большое значение имеет правильно организованный процесс запуска проекта. Может помочь также последовательный, единый для всей фирмы подход к управлению проектом. Однако необходимо учитывать и индивидуальные особенности типов проектов.
Приоритеты не доведены до сведения участников проекта. В этом случае у людей появляются собственные приоритеты, как правило, не совпадающие с желаемыми, результатом чего является отсутствие координации и невыполнение работ.
Отсутствие согласия. Общая точка зрения может быть мощным стимулом к принятию обязательств по проекту и его задачам.
. Недостатки в планировании.
Недостатки в способе определения работ, расчетах календарных планов и затрат и доведении их до сведения команды проекта включают в себя следующее.
Планы проекта разрабатываются для одного уровня. Использование структурной декомпозиции является инструментом, обеспечивающим желаемый результат проектных работ. Обычным недостатком является планирование только на детальном уровне. К сожалению, современные программные продукты обладают тем же недостатком. Иногда работа планируется только на очень высоком уровне, но при этом отсутствуют координация и взаимосвязь между планами разной степени детализации.
Между достижением конечной цели путешествия и его первым шагом существуют по меньшей мере два уровня планирования: контрольные события («города и деревни») и дорожная карта («дороги»). Первое из них - это стратегический план, содержащий промежуточные цели или результаты, а второе - тактический план. На уровне контрольных событий мы делаем свой план ясным, но гибким, содержащим ключевые фиксированные точки для оценки хода работ относительно нашей цели, сохраняем возможность вносить изменения на более низком уровне, не меняя определения контрольных событий. Дорожную карту мы также пытаемся сохранить в неизменном состоянии, пользуясь при этом двумя способами обеспечения гибкости. Если видно, что дорога заблокирована, можно совершить объезд, однако нашей целью при этом все еще будет достижение следующего контрольного события. Использование громоздких инструментов планирования. За последние 30 лет сложность инструментов планирования проектов возросла в связи с развитием программных средств и информационных технологий. Однако сложные планы в лучшем случае не работают, а в худшем - приводят к путанице.
Планы и отчеты о ходе работ должны строиться по иерархии, соответствующей схеме структурной декомпозиции работ проекта.
Препятствия для проявления креативности. Реальностью современных проектов является то, что руководитель проекта не может быть специалистом во всех его областях. Но нередко руководители проектов посредством планов диктуют людям, более грамотным, чем они сами, как им выполнять их работу. Это может демотивировать специалистов и оттолкнуть их от проекта.
Существует несколько объяснений того, почему оценки бывают нереалистичными. Обычно при выполнении расчетов предполагается, что владелец может не согласиться с ними и сократить их. Работы же выполняются в соответствии с первоначальными оценками, что приводит к преднамеренному срыву. Кроме того, фактических данных за прошлый период может быть недостаточно для точной оценки работы. В этом случае должны быть выявлены риски и добавлены соответствующие непредвиденные расходы. Помимо этого, люди обладают разными способностями, следовательно, и планы следует строить именно для вашего персонала, а не для «идеального» сотрудника. Наконец, иногда полагают, что команда проекта может работать 260 дней в году. Сотрудник, работающий над проектом полное время, реально отрабатывает гораздо меньше рабочих дней. Возникают потери времени, обусловленные праздниками, нерабочими днями, болезнями, производственным обучением, групповыми совещаниями и т. п. Эти потери должны учитываться при планировании.
. Недостатки в организации и выполнении проекта
К недостаткам в построении организации проекта и распределении работ между сотрудниками относятся следующие.
Недостаточное сотрудничество. В проектах обычно все работают на одну и ту же организацию, и в процессе реализации скрытые цели становятся явными. Сотрудничество достигается двумя путями: созданием ясного видения проекта и обсуждением при согласовании планов.
Необязательность распорядителей ресурсов. Руководители проектов часто используют ресурсы, передаваемые им другими руководителями. Если последние не связаны обязательствами с проектом, то они неохотно передают свои ресурсы.
Отсутствие ресурсов в тот момент, когда они требуются. Нельзя просто направить распорядителям ресурсов какой-либо план и рассчитывать на безоговорочное его выполнение. Даже если они взяли на себя обязательства, следует убедиться в том, что требования им понятны. Это можно обеспечить путем использования простых планов, обсуждения требований плана с распорядителем ресурсов. Они должны также планировать передачу своих ресурсов в надлежащее время.
При распределении ролей в проекте принято рассматривать только тех, кто выполняет конкретную работу - скажем, режет металл или пишет компьютерные программы. Однако люди должны выполнять и управленческие функции, которые могут отнимать время или приводить к задержке проекта (например, принятие решений, управление потоками информации и ходом работ).
Подмена управления проектом техническим управлением. Часто руководители проекта являются в первую очередь техническими руководителями, отвечающими за управление проектированием - разработкой проектно-сметной документации. Все еще можно слышать, как руководители дизайнерских проектов (особенно информационных систем) называют себя руководителями проектов. Им часто не удается делегировать свою работу. Они полагают, и совершенно справедливо, что могут выполнить эту работу лучше, чем кто-либо другой, и поэтому окружают себя «простаивающим» персоналом, в то время как сами работают на износ.