Преподаватель который помогает студентам и школьникам в учёбе.

Стандарты управления проектами (.Общие вопросы создания стандарта)

Содержание:

ВВЕДЕНИЕ

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

Обратимся к результатам всероссийских конференций «Стандарты в проектах современных информационных систем», где содержание стандартов управления проектами была представлена довольно обширно и вызвала живой интерес и дискуссии, как в зале заседаний, так и в кулуарах. В решениях конференций было признание роли стандартов в организации выполнения отдельных проектов и в постановке проектного дела в целом на предприятиях. Тема курсовой работы является актуальной потому, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, Pricewater house Coopers, Andersen Consulting, SAP AG, Siemens и других. Все эти соображения и позволяют предположить, что тема стандарта управления проектами актуальна и должна вызвать интерес.

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

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

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

Объектом исследования курсовой работы будут являться непосредственно сами стандарты управления проектами в различных компаниях.

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

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

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

Общие вопросы создания стандарта

1.1.Специализация и детализация стандартов

Стандарты управления проектами уровня предприятия в части методологии, как правило, имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют «рамочными»). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый большинством международных стандартов де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее весомых положений PMBoK статус стандарта де-юре. Значение и сοдержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще бοльшей степени ISO 10006) к стандарту предприятия сοстоит в их специализации и детализации.

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

Прοекты кοмпании мοгут отнοситься к различным профессиοнальным οбластям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и так далее), иметь разную сложность с точки зрения решаемых задач, всевозможный масштаб с точки зрения привлекаемых ресурсов и предполагаемого результата. Могут отличаться некоторые категории проектов, специфические с точки зрения определенных отраслей. К примеру, в стандарте компании Энрон, специализировавшейся в своё время в области электроэнергетики, порознь рассматривались международные (overseas) проекты, как предъявляющие особые запросы к законодательной базе, к персоналу, оборудованию, экономической инфраструктуре, логистике и так далее

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

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

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

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

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

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

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

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

Управление проектами – это приложение знаний, навыков, инструментов и способов к работам проекта для удовлетворения требований, предъявляемых к проекту.^[3]

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

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

Для удачной и действенной работы управленческого персонала проекта должны быть сделаны конкретные обстоятельства (организационные, программные, технические), совокупность некоторых и представляет собой систему управления проектами предприятия. Система управления проектами включает три ведущих блока – субъекты управления, объекты управления и процессы управления^[5].

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

Базовым определением для понятия объекта управления система управления проектами считается проект, понимаемое как какое-то ограниченное во времени предприятие с изначально установленными целями, достижение коих определяет окончание проекта. В качестве объекта управления рассматриваются: портфель проектов – совокупность проектов, которые находятся в компетенции одного центра ответственности; программа – группа взаимосвязанных проектов и всевозможных событий, объединенных совместной целью и критериями их выполнения.^[6] Программа, как правило, включает в себя элемент непрерывной деятельности; проект – это комплекс взаимосвязанных событий, специализированный для достижения целей с установленными требованиями к качеству итогов в течение заданного времени и при установленном бюджете; стадии жизненного цикла программ и проектов – комплект логически взаимосвязанных работ проекта, в процессе окончания которых достигается один из основных результатов проекта. Жизненные циклы проектов во всевозможных областях деятельности имеют возможность существенно отличаться.

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

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

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

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

Информационно-технологический элемент системы управления проектами обычно представлен одним из промышленных пакетов управления проектами (Примавера, Open Plan, Спайдер, MS Проджект), в которых в большей или же меньшей степени реализованы инструменты во всевозможных областях проектного управления.

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

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

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

Концепция управления проектами является основополагающим документом системы управления проектами организации, обосновывающим деловую необходимость создания систем управления проектами (включая финансовую эффективность внедрения), определяющим ее главные характеристики и итоги, стратегию реализации и становления, объем автоматизации и применяемые информационные технологии.^[8]

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

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

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

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

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

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

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

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

Сколько бы детализированным не был стандарт в него нельзя вложить весь объем знаний, необходимых руководителю проекта. Да стандарт и не специализирован для этого. Стандарт определяет, что и когда нужно сделать, в какой форме и кому представить результат. Но как сделать это уже вопрос не стандарта, а профессиональной компетентности менеджера. Ответ на вопрос как нужно искать в учебниках и справочниках, хотя их и не так много на русском языке, но всё же они существуют.^[10]

Стандарт не поменяет данной литературы, но роль его в целенаправленном обучении персонала организации может быть очень значимой. Здесь, на мой взгляд, будет уместной следующая модель. В части процессов управления проектами стандарт компании специализирует и детализирует требования рамочных стандартов (таких как ISO 10006 или PMBOK PMI). Точно также в части квалификации управленческого персонала стандарт организации специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или НТК).

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

И, естественно же, освоение стандарта управления проектами фирмы является важнейшей ступенью для специалиста, претендующего получить международно признаваемый сертификат в области управления проектами. Сам прецедент использования стандарта управления проектами говорит о том, что на предприятии достигнут конкретный уровень зрелости процессов управления. Для того чтобы измерить данный уровень и определить направления дальнейшего развития могут применяться различные методы. Одним из популярных методов считается использование моделей зрелости, обширно популярна модель Capability Maturity Model (CMM), используемая для оценки зрелости организаций, разрабатывающих программное обеспечение.^[12]

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

В качестве иного примера можно привести пятиуровневую модель (PM) – Project Management Process Maturity Model.^[13]

В общепринятой практике определение Project Management понимается неоднозначно в зависимости от выбранной модели, подхода к структуре познаний, типа и вида проектов и иных факторов. Переводы самого термина Прожект менеджмент на русский язык еще более многообразны: управление проектом (проектами), проектный менеджмент (проект-менеджмент), менеджмент проекта (проектов), прожект менеджмент. Нередко многозначно также и само значение, вкладываемое в понятие «менеджмент проектов» и «управление проектами».

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

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

Понятие «проект» в различных моделях и стандартах трактуется с различных позиций. Рассмотрим некоторые из них:^[14]

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

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

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

Современные подходы к стандартизации в области Прожект менеджмент основаны на следующем: для международных и государственных стандартов по прожект менеджмент и качестве объектов выбираются, как правило, глоссарии, процессы и методы; для тех областей Прожект менеджмент, описание коих в виде объектов для стандартизации бессмысленно или же невозможно, применяются профессиональные квалификационные стандарты (требования) к деятельности специалистов по Прожект менеджмент (Project Management Professional) и менеджеров проектов (Project Manager).^[15]

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

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

Отдельные вопросы регулируются международными стандартами. К примеру, основным международным стандартом по менеджменту качества и конфигурацией в проектах являются ISO 9000:2000, 100005, 10006, 10007 и иные, которые приняты в ряде государств в виде национальных стандартов.

В области управления системами применяется ряд международных стандартов, поддерживаемых надлежащими международными организациями. Эти стандарты определяют нормы и правила по управлению процессами в проектах технических систем, процессами жизненного цикла системы, процессами проектирования, например ISO/IEC 12207, Information Technology – Software life processes (1995); ISO/IEC TR 15271, Information Technology – Guide for ISO/IEC 12207 (1998); ISO/IEC 15288 CD2, Life Cycle Management – System Life Cycle Processes (2000).^[16]

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

Одной из более презентабельных, исторически сформировавшихся и комплексных национальных систем стандартов считается британская национальная система по прожект менеджмент.^[17]

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

В 1984 году в состав комплекса стандартов вводится Руководство по использованию процедур управления, планирования, контроля и отчетности. Первые три стандарта, являются частями второго, третьего и четвертого, а последний – частью первого, то есть стандарты, определяющие использование сетевого планирования и управления в управлении проектов, появились существенно раньше, чем изначально предусмотренный в качестве основного стандарт, определяющий процедуры Прожект Менеджмент. Глоссарий терминов, применяемых в сетевом планирование проектов, был введен лишь только в 1987 году. «Вторая очередь» английских стандартов по Прожект Менеджмент была введена в 1992 году и считалась обновлением первых трех стандартов 1981 года. В 2000 году были введены первые три стандарта принципиально нового комплекса стандартов по Прожект Менеджмент.^[18]

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

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

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

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

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

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

2. Классификация проектов как первый этап создания стандарта

2.1. План управления проектом и рамочные стандарты

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

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

Это особенно важно для компаний, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения универсального руководителя проекта, и пути снижения стоимости его содержания, является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых под проектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и так далее. В крупных банках филиалы формируются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным для того, чтобы сформировать для каждого вида проектов (под проектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и так далее.^[19]

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

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

Главные вехи проекта – основные события проекта (milestones) и план их достижения, вполне вероятно, с использованием структуры декомпозиции работ (WBS).

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

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

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

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

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

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

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

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

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

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

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

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

Классификация по масштабности проекта позволяет специализировать разделы Организационная структура, Управление отклонениями, Обеспечение качества. Для построения данной классификации могут использоваться различные основания – территориальная разбросанность, как это принято в Энрон Корпорэйшн, или же стоимость проекта (IBM), возможно, какие-то другие основания и их комбинации.

Классификация по форме оплаты и, значит, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов как «Время и материалы» и «Фиксированная цена».

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

Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Впрочем, в реальной жизни встречаются и иные ситуации. К примеру, в IBM принята классификация проектов по сложности (комплексности). В соответствии с данной классификацией проекты делятся на обычный бизнес (Business as Usual – BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно данная классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов Плана.

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

Показать это можно на примере не самого сложного раздела плана «Организационная структура проекта». В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) – разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно.^[23]

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

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

2.2.Организационные структуры в проектах

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

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

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

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

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

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

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

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

3.Проектные отклонения. Риски, проблемы, изменения

3.1.Управление рисками и проблемами

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

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

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

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

Управление отклонениями в основном сводится к борьбе с проблемами, которая в общем случае может включать три стадии:^[27]

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

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

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

Самое несложное, и вместе с тем особо важное, что обязано быть отражено в стандарте – формальная сторона управления рисками, а конкретно:

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

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

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

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

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

Авторы в данном вопросе предпочитают следовать духу и букве этих стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых данный процесс именуется problems/issues management, что в русском переводе больше всего, на наш взгляд, выглядит точно как управление проблемами.^[28]

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

Как правило, проблемы делят на две категории – на проблемы, которые могут решаться в месте возникновения, то есть на уровне управления проектом – problems, и эскалируемые проблемы – issues, которые для их разрешения потребуется доводить на верхние уровни управления, в том числе, внешние по отношению к проекту.^[29]

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

Шаблоны документов, отражающих процесс работы с проблемами – карточка проблемы, журнал проблем проекта и так далее.

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

3.2. Управление изменениями

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Алешин А. В., Васильева С. С., Ильин Н. И., Полковников А. В., Попова Е. В. Управление проектами: фундаментальный курс / Под общ.ред.: О. Н. Ильина, В. М. Аньшин. М.: Издательский дом НИУ ВШЭ, 2013. – 410 с.
Водачек Л., Водачкова О. Стратегия управления инновациями на предприятии. — М: Экономика, 2009. — С. 20.
Волков О. И. Экономика предприятия. — М.: ИНФРА-М, 2009. — 255 с.
Голубицкая Е. А., Экономика связи. Учебник для вузов. — М: ИРИАС, 2006. -488 с.
Гуляев В. Г. Организация бизнеса. — М.: Нолидж, 2008. — 372 с.
Гургенидзе А. Т., Кореш В. И. Мультисервисные сети и услуги широкополосного доступа — Спб.: Питер, 2003. — 434 с.
Дубровин А. И., Бизнес-планирование на предприятии: Учебник.: ИТК Дашков и Ко: 2011. -432с.
Есауленко А. «Говорит и показывает IP»// Сети и системы связи. — 2008 — № 13. — С. 24−28
Инструкции по расчету основных технико-экономических и финансовых показателей и заполнению форм-таблиц бизнес-плана на стадиях проектирования для предприятий связи (3- я редакция).- М: Гипросвязь, 1999 — 68 с.
Иванова Т. Ю. Управление изменениями: учебное пособие. - Санкт-Петербург: «Издательство «Проспект», 2016 - 350 с. ISBN 978-5392-224-814
Кадацкий В. Т. Затраты и прибыль. // Экономист. — 2009. — № 7. — С. 79−83.
Круглова Н. Ю. Инновационный менеджмент/Под науч. ред. Д. С. Львова. — М.: «Ступень», 2010.
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009.
Медынский В. Г., Шаршукова Л. Г. Инновационное предпринимательство: Учебное пособие. — М.: ИНФРА-М, 2007.
Менеджмент организации: Учебное пособие/Румянцева 3. П., Саломатин Н. А., Акбердин Р. 3. и др. — М.: ИНФРА-М, 2010.
Молодцова Р. Г. Инвестиции и инновации в концепции экономического роста: Научное издание. — М.: Изд-во Рос. ЭА, 2007.
Морозов Ю. П. Инновационный менеджмент: Учебное пособие. -- Н. Новгород: Изд-во ННГУ, 2007.
Научно-технический прогресс: Словарь / Сост.: В. Г. Горохов, В. Ф. Халипов. — М.: Политиздат, 1987.
Окрепилов В. В. Управление качеством и конкурентоспособностью: Учебное пособие. - СПб.: Изд-во СПб.: ГУЭФ, 2007.
Панкратов Ф. Г., Серегина Т. К. Коммерческая деятельность: Учебник для студентов высших и средних учебных заведений. М.: ИВУ «Маркетинг», 2008. — 328 с.
Перевалов Ю. В. Инновационное предпринимательство и проблемы технологического развития/Общество и экономика, № 5, 2007.
Периодическое издание «Технологии и средства связи» № 4, 2001.- 48 с.
Портер М. Международная конкуренция/Пер, с англ., под ред. В. Д. Щетинина. — М.: Международные отношения, 2011.
Портфель конкуренции и управления финансами (Книга конкурента. Книга финансового менеджера. Книга антикризисного управляющего). Отв. ред. Рубин Ю. Б. — М.: «СОМИНТЭК», 2010.
Ребров П. «Видео для телекоммуникационных операторов» Сетевой, 2008. — № 1.
Савицкая Г. В., Теория анализа хозяйственной деятельности предприятия: учебник — М.: Инфра-М, 2007.
Сухова Л. Ф., Чернова Н. А. Практикум по разработке бизнес-плана и финансовому анализу предприятия: Учеб. пособие. М. Финансы и статистика, 2005. — 160 с.
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003.
Фунтов В.Н. Основы управления проектами в компании. – СПб.: Питер, 2008 – с.23
Яковлев Ю. В. Использование международных стандартов в управлении проектами // Проблемы современной экономики. – 2011. – № 1/2 (17/18).

Приложение 1

Пространство процессов управления

Приложение 2

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

Приложение 3

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

Приложение 4

Области потерь

Приложение 5

Стратегии изменений в проекте

Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», - 2009. С.73 ↑
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003. ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности // – М.: «Омега – Л», 2009, С.132 ↑
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003. 240с. ↑
Фунтов В.Н. Основы управления проектами в компании. – СПб.: Питер, 2008 – С.23 ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности // – М.: «Омега – Л», 2009, С.139 ↑
Дубровин А. И., Бизнес-планирование на предприятии: Учебник.: // ИТК Дашков и Ко: 2011. С.159 ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009. ↑
Иванова Т. Ю. Управление изменениями: учебное пособие. - Санкт-Петербург: «Издательство «Проспект», 2016 .С.310 ↑
Круглова Н. Ю. Инновационный менеджмент/Под науч. ред. Д. С. Львова. — М.: «Ступень», 2010. ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009. ↑
Яковлев Ю. В. Использование международных стандартов в управлении проектами // Проблемы современной экономики. – 2011. – № 1/2 (17/18). ↑
Гургенидзе А. Т., Кореш В. И. Мультисервисные сети и услуги широкополосного доступа — Спб.: Питер, 2003. С.158 ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009. ↑
Яковлев Ю. В. Использование международных стандартов в управлении проектами // Проблемы современной экономики. – 2011. – № 1/2 (17/18). ↑
Яковлев Ю. В. Использование международных стандартов в управлении проектами // Проблемы современной экономики. – 2011. – № 1/2 (17/18). ↑
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003. ↑
Фунтов В.Н. Основы управления проектами в компании. // – СПб.: Питер, 2008 – С.196 ↑
Сухова Л. Ф., Чернова Н. А. Практикум по разработке бизнес-плана и финансовому анализу предприятия: Учеб. пособие. М. Финансы и статистика, 2005. — С.86 ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009. ↑
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003. ↑
Сухова Л. Ф., Чернова Н. А. Практикум по разработке бизнес-плана и финансовому анализу предприятия: Учеб. пособие. М. Финансы и статистика, 2005. — С.78 ↑
Яковлев Ю. В. Использование международных стандартов в управлении проектами // Проблемы современной экономики. – 2011. – № 1/2 (17/18). ↑
Фунтов В.Н. Основы управления проектами в компании. – СПб.: Питер, 2008 ↑
Алешин А. В., Васильева С. С., Ильин Н. И., Полковников А. В., Попова Е. В. Управление проектами: фундаментальный курс / Под общ.ред.: О. Н. Ильина, В. М. Аньшин. М.: Издательский дом НИУ ВШЭ, 2013. – С.251 ↑
Портфель конкуренции и управления финансами (Книга конкурента. Книга финансового менеджера. Книга антикризисного управляющего). Отв. ред. Рубин Ю. Б. — М.: «СОМИНТЭК», 2010. ↑
Фунтов В.Н. Основы управления проектами в компании. – СПб.: Питер, 2008 – с.23 ↑
Круглова Н. Ю. Инновационный менеджмент/Под науч. ред. Д. С. Львова. — М.: «Ступень», 2010. ↑
Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности //– М.: «Омега – Л», 2009. ↑
Товб А.С. Ципес Г.Л. Управление проектами: стандарты, методы, опыт. // – М.: ЗАО «Олимп – Бизнес», 2003. ↑