ProjectProfy.ru
Имя: Пароль:
Забыли пароль?

Статьи

Методика управления проектами [86]

Методические пособия и книги [28]

Готовые отраслевые решения [60]

Обзоры программ для управления проектами [63]

События в мире Управлениия Проектами [128]

Сравнение разных программ для управления проектами [26]

Обучение и сертификация [53]

Управление рисками [4]

Опыт внедрения [37]

Разрешение проблем MS Project и др. системах [4]

Скачать Microsoft Project [3]

Администрирование MS Project Server [36]

Разработка для Microsoft Project [5]



20.09.2012

Комментарии к ISO 21500. Глава 3. Понятия проектного менеджмента

Владимир Иванов
 

Мои комментарии к понятийному аппарату ISO 21500. Забегая вперед скажу, что в целом разделяю оптимизм Билла Дункана. Это лучше, чем PMBOK. Точнее это The New PMBOK, который давно ждали.

3.1 Обзор понятий

Этот раздел описывает ключевые понятия, специфичные для проектов, которые описывают разные стороны выполнения проектов.

На рисунке 1 показано [см. стандарт], как понятия управления проектами связаны друг с другом. Стратегия организации определяет что такое возможные условия (возможности, благоприятные случаи) для начала проектов. Возможности оцениваются и формулируются в виде бизнес-плана  или иного аналогичного документа. Отобранные возможности могут породить проекты, которые обеспечивают желаемые результаты. Эти результаты могут быть использованы для реализации стратегических преимуществ организации на рынке. Эти преимущества могут стать вкладом фактическую реализацию стратегии организации.
 
Аннотация к рисунку:
  • Прямоугольники представляют собой понятия  управления проектами, которые описаны в следующих разделах
  • Стрелки представляют собой логическую последовательность в которой понятия связаны
  • Пунктирные линии представляют организационные границы процессов

3.2 Проект

 
Проект - это  уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определенным заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы.
 
Хотя многие проекты могут быть похожи, но каждый проект уникален, так как различия могут возникнуть при поставке конкретных результатов предусмотренные проектом, влияния заинтересованных лиц на проект, и то, как процессы адаптированы к созданию конкретных результатов.
 
Каждый проект имеет определенное начало и конец, и, как правило, делится на фазы (этапы) .Проект начинается и заканчивается, как это определено в пункте 4.3.1 Стандарта
 
 
Комментарии
В принципе ISO 21500 следует определению проекта по ультрасовременным методологиям, которое уже используется в других стандартах ISO по качеству и др. аспектам. Там полемика уже завершилась и мы видим просто благоприятные эффекты от интеграции стандартов ISO между собой в том числе по понятийному аппарату. В проектом сообществе только небольшая часть экспертов имеет практику работы по ISO, поэтому для многих свежая дискуссия. Давайте обсудим где тут копья ломают и почему. 
 
Оригинал определения проекта ISO 21500. "A project is a unique set of processes consisting of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective."
Оригинальное определение проекта в PMBOK данный Дунканом: "project is temporary endeavor undertaken to create a unique product, service" висит и на pmi.org

Как видим ISO 21500 вводит другое понятие проекта, чем PMBOK. В очевидно ГОСТ попытались перенести часть определения ISO. Но даже упоминание "совокупности видов деятельности" вместо "мероприятия" уже этого хватило, чтобы эксперты Московского PMI во время обсуждения ГОСТа это заметили и обвинили разработчиков ГОСТа на этом основании в некомпететности. Однако такое заявление исходит из того, что постулаты не обсуждают. Такое возможно только в теологии при обсуждении безошибочности Евангелия, но хочется верить, что эксперты готовы посмотреть на PMBOK как на документ созданный людьми.
 
И так, рпределение PMBOK базируется на том, что проект это (1) мероприятие (2) в ограниченный промежуток времени (3) с уникальным результатом. Определение в нескольких стандартах ISO (и 12500 в частности) говорит, что это не мероприятия, а уникальный набор процессов. Кто прав?
 
На деле общий проектный менеджмент - это чисто административная дисциплина и сами продукты или услуги находятся все его компетенции. Это компетенция отраслевых методик, которые знают по какой технологии изготавливаются продукты, поэтому могут судить о том с какой степенью уникальны продукты или нет. ISO 21500 или PMBOK не формирует таких знаний о продуктах проекта, чтобы делать технологические заключения об степени их уникальности, а раз нет таких специальных знаний даже у PMP, то даже PMP не сможет определить это проект или нет во многих случаях и поэтому не сможет определить может ли он применять проектные методы управления обоснованно. Об том, что знания об продукте за пределами ISO 21500 в стандарте будет прямо сказано дальше.  Любая административная дисциплина не занимается продуктом и его атрибутами как уникальность. Она занимается процессами. Главное отличие операционного и проектного менеджмента совсем не в продукте, а в том как управляется изготовление продукта. Операционный менеджмент предполагает одинаковое выполнение операций по набору стандартных схем. Мощность проектного менеджмента в том, что он умеет управлять "хаосом", т.е. произвольными и сложными комбинациями операций, которые все время образуют новые комбинации, либо ввиду той самой уникальности продукта, либо ввиду просто вариативности стандартных изделий, либо ввиду сильных рисков влияющих на изготовление стандартных изделий. Тут как раз операционный менеджмент бессилен, он в "уникальном хаосе" работать не умеет. И наоборот, операционный менеджмент может успешно изготавливать уникальные продукты, которые могут отличаться ввиду неточности технологии изготовления или просто комбинаторики компонентов заказов. Например, ваш заказ в МакДональдс может быть уникален, если вы взяли себе уникальный набор еды по желанию. Заказ выполнили за ограниченное время. Дословно по определению PMBOK МакДональдс только что выполнил проект. Думаю многие усомнятся, что PMBOK правильно дает определение проекту на этом примере. Однако с точки зрения ISO все совпадает со здравым смыслом: МакДональдс может изготавливать уникальные поставки используя одни и те же процессы, которые имеют возможность управлять комбинациями опций. 
 
Продолжим. PMBOK определяет проект обязательно как с уникальным результатом. Методологи давно указывают, что эта аксиома сузила применимость проектных методик без каких либо рациональных оснований на то, а просто путем введения постулата. Поясню. Совсем не обязательно у проектов уникальные результаты. Например, строитель строит дома стандартной серии. Из слова "серийный" в определении PMI следует, что это не проекты, чтобы доказать обратное PMP нужно быть экспертом в таких строительных проектах, но необходимых отраслевых знаний PMBOK для этого не дает, поэтому формально PMP должен отказаться от внедрения проектного управления у традиционного клиента на такие решения. Аналогично машиностроитель может строить самолеты, вроде бы они одинаковые, но управлять таким производством как проектами на практике часто очень удобно ввиду большого количества процессов и главное дешевле, чем процессными методами через ERP-системы. На деле тут сразу начинался спор тупоконечников из проектных методологов и остроконечников из процессных методологов. Кто должен управлять такой деятельностью и у кого методики лучше. На деле не методологам решать это, их дело отрабатывать свои деньги, решать заказчику исходя из своей циничной материальной выгоды, а не ублажения асбтракных принципов. Проектные методики и инструменты могут быть часто эффективно применены для серийного производства, если заказы крупные, малосерийные, многооперационные и технически сложные. Тут проектные методики и EPM-инструменты могут быть существенно эффективней ERP-систем, т.к. при усложнении комбинаций процессов EPM-инструменты становятся эффективней - они для таких сложностей и разработаны. На деле это предмет анализа в каждом конкретном случае применить проектный или процессный (операционный) подход , об рекомендациях на основании уникальности это сделает и ISO 21500, но это будет рекомендация, а не постулат. Фактически ISO 21500 впервые снял табу на адаптацию проектной методологии к серийной продукции. 
 
Интересно как дали определение проекта в ГОСТ, там очевидно пытались вставить кусок определения из ISO, но перевели "coordinated and controlled activities" как "комплекс взаимосвязанных мероприятий". При всем моем уважении, но кажется тут неточность перевода в нашем ГОСТе. Дело в том, что activity имеет  основной смыла как "деятельность", но поскольку тут в предложении указаны конечная и начальная дата, то в профессиональном сленге английского проектного менеджмента это скорее по смыслу "задача" или "действие". Мероприятие в смысле проектного управления это endeavor.
 
Жаль, также что авторы нашего ГОСТа имея на руках драфт ISO 21500 не рискнули вставить полностью современное определение проекта, а только его часть. Все равно Московский PMI опасается самой идеи новых компактных стандартов, т.к. они могу пошатнуть монополию PMBOK, а это фундамент всех доходов. Поэтому можно было вписать в ГОСТ полное определение, а не его часть. Все равно даже за часть раскритиковали, терять уже нечего. 
Однако это не проблема, как я уже говорил, согласно ст. 7 ГК РФ в случае расхождений официально принятых Россией локальных и международных стандартов, в России действует принятый ей международный стандарт. Поэтому в России официально действует определение проекта по ISO 21500. 
 

3.3 Проектный менеджмент

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

3.4 Стратегия организации и проекты

3.4.1 Стратегия организации

Организации создают стратегии, в соответствии с  их миссией, видением и политикой. Проекты часто являются средства для достижения стратегических целей. Пример получения стратегической выгоды показан на рисунке 2.
 
Рисунок 2 - Пример получения стратегической выгоды
 
Стратегические цели могут управлять возможностями для начала проектов. Отбор возможностей для начала проектов  включает в себя рассмотрение различных факторов, например, как преимущества могут быть реализованы и как эффективно можно управлять рисками . Целью проекта является достижение измеряемых критериев применимых к возможностям для начала проектов. Цель проекта определяет создание необходимых результатов проектов. Цели проекта достигаются тогда, когда стратегические выгоды  организации реализуются. Проект не может выполняться целесообразно, после того как его цели уже достигнуты.
 
Комментарий
Хотя ISO 21500 начинает позиционирует себя как "новый PMBOK", т.е. для описания управления проектом. Однако с этого пункта пошло описание стандартного сценария управления портфелем проектов, который не просто методологическая абстракция, а давно реализован в Microsoft Project Server (модуль Portfolio) или в том же Attask или Daptive. Сценарий идет по шагам:
1) Стратегия
2) Атрибуты (характеристики) стратегии
3) Ограничения (ресурсные, денежные)
4) Измеряемые критерии достижения атрибутов стратегии
5) Возможности для открытия проектов и заявки на их открытие
6) Балансировка портфеля по измерямым критериям стратегии
7) Запуск отобранных проекто
Дальше ISO 21500 будет прописывать эти шаги, а в конце прямо укажет, что требуется автоматизированная система для реализации такой методологии.
Интересно, что такое портфельное управление это проектный модерн и родилось сравнительно недавно. Поэтому неудивительно, почему в том же Spider Project такой сценарий не поддерживается.
Правда отметим, что полностью такой сценарий могут реализовать на практике только крупные корпорации.
 
 

3.4.2 Идентификация возможностей для начала проекта и инициации проекта

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

3.4.3 Получение выгод

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

Комментарий
Интересный пункт. Почти как статья Гражданского Кодекса. Фактически разделена зона ответственности Исполнителя и Заказчика. Исполнитель совсем не обязан отвечать, что Заказчик получит выгодны от проекта. Он обязан поставить, что заказали. Управлять извлечением выгоды должна сторона Заказчика и на базе такого управления менеджер проекта принимает решения. 
Для сравнения отмечу, что есть другой подход в том же ISO. В стандартах качества ISO различают качество как "сортность" (grade) и как возможность удовлетворить ожидания заказчика по извлечению прибыли. На деле ISO 21500 опускает планку качества до  сортности. Это преднамеренное действие, т.к. процессы управления проектами могут только гарантировать исполнения задания. Превышение ожиданий заказчика находится в области отраслевого знания. Иными словами, менеджер строительного проекта отвечает за то что вам в спальню вовремя положат пол. Однако для того чтобы определить, что пол должен быть не из зеленой плитки, а из паркета нужен уже дизайнер.
Это важно. PMBOK фактически не предупреждает заказчиков проекта, что методология в нем не в состоянии обеспечить качество связанной с технологией изготовления продукта. ISO 21500 честно предупреждает, что тут описано только администрирование проектов, отслеживание качества Технического Задания на деле за рамками стандарта, но ISO 21500 предлагает конечно классический учет изменений в проекте и административную реакцию на них.

 

3.5 Среда в которой выполняются проекты

3.5.1 Общие положения

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

3.5.2 Проекты в рамках ограничений организации

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

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

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

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

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

3.6 Руководство проектом (Project Governance)

Руководство организацией - это система с помощью которой  организации направляется и контролируется. Управление проектами связано с теми областями управления всей организацией, которые конкретно относятся к проектной деятельности.
Проектное управления включает в себя такие аспекты, как определение структуры управления, политики, процессы и методологии, которые будут использоваться; ограничения полномочий для принятия решений; ответственность перед заинтересованными лицами и полномочия, а также взаимодействия, такие как отчетность и эскалации проблем или рисков.Ответственность за поддержание соответствующего управления проектом обычно возложена на спонсора проекта или руководящего комитета проекта.
 
Комментарий.
ISO 21500 разделяет понятия "верховного руководства" (governance) и исполнительного управления (management). Верховное руководство, например, спонсор определяет что проект будет делать. Исполнительное руководство, например, менеджер проекта определяет как проект это будет делать. Таким образом, ISO 21500 лишает менеджера проекта полномочий определить себе задание, что в целом правильно.

3.7 Проектная и операционная деятельность

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

3.8 Заинтересованные лица и организационная структура проекта

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

 

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

 

3.9 Компетенции проектного персонала

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

3.10 Жизненный цикл проекта

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

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

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

Комментарии
В этом разделе ISO 21500 вводит понятия внешнего контроля проектов по контрольным точкам, обычно расставленным по фазам. В современных инструментах и методиках контрольные точки образуют "дорожные карты".  Причем в ISO 21500 указывается что это нужно в первую очередь для внешнего управления (governance), но не указано, что это необходимо для эффективного внутреннего управления проектом (project management, project organization). Последствия этого при практическом применении стандарта, в том, что если дорожная карта на котрольных точках это инструмент спорнсора. То инструмент менеджера проекта - это Гант. Разделение на внутренее и внешнее управление в ISO 21500 существенно более последовательно, чем в оригинальном PMBOK.

 

3.11 Ограничения проекта

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

 

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

3.12 Отношения между понятиями и процессами

Управление проектом осуществляется через процессы с оперированием сущностями, которые определены через понятия, и  с использованием компетенций, которые  описаны выше.Процесс представляет собой совокупность взаимосвязанных действий и мероприятий.
 
Процессы, используемые в проектах, как правило, делятся на три основных типа:
- процессы управления проектами, которые являются специфическими для управления проектами, определяющие с помощью каким мероприятий проект управляется;
- процессы производства продукта, которые не рассматриваются как отдельные и уникальные с точки зрения проектного менеджмента, результат таких процессов в описании и создание конкретного продукта, услуги или результата и варьироваться в зависимости от конкретного проекта результата,
- процессы поддержки среды осуществления бизнеса, которые не являются уникальными с точки зрения проектного менеджмента, результат таких процессов предоставить актуальную и ценную поддержку процессов создания продукции и управления проектами в таких дисциплинах, как логистика, финансы, бухгалтерский учет и безопасность.
 
Настоящий стандарт рассматривает только процессы управления проектами. Тем не менее, следует отметить, что продуктовые и вспомогательных процессы и процессов управления проектами, часто пересекаются и взаимодействуют на протяжении всего проекта.
 
Комментарии
Очень важный пункт. Проведена граница между отраслевой и общей методикой управления проектами. ISO 21500 заявляет отказ от отраслевых методик управления проектами и отказ от понимания в чем их различие. Постулируется, что с точки зрения ISO 21500 такие методики являются одинаковыми, это не означает что они одинаковые, а означает что менеджер проекта как администратор должен управлять одинаково и фабрикой по производству носков и разработкой программных продуктов и строительством дома. Для того чтобы это у администратора проекта получилось, ISO 21500 будет в своих процессах далее декларировать требования к процессам уже отраслевых методик, которые как вилка к розетке должны подходить друг ко другу. В этом одна из главный целей стандартизации - легкое соединение разных методик между собой за счет общего понятийного аппарата и одинаковой структуры процессов в той части, где методики интегрируются.
 
Кроме отраслевых проектных методик ISO 21500 заработает также при интеграции с процессными методиками. Принцип тут такой же.
 
Очень важный момент, что ISO 21500 декларирует это сразу же и фактически не дает заниматься "лохотроном" преподавателям проектного управления, когда тот же PMBOK позиционируется как самодостаточный. Хотя на деле без интеграции с отраслевыми и процессными методиками, ничего и никогда не заработает. Будет просто заседание религиозной секты с абстрактными понятиями, а не управление объектами реального мира.
 
Задачу интеграции отраслевых и процессных методик с проектными, на мой взгляд, ISO может выполнить лучше PMI. Как минимиум PMI не решило этой проблемы. Однако среди стандартов ISO огромное количество отраслевых и процессных, задача их интеграции между собой обычная деятельность ISO. Поэтому ISO 21500 небольшой шаг для многих проектных экспертов, но огромный шаг с точки зрения построения единой модели многранной производственной деятельности Человечества.
 
 
 
Продолжение комментариев следует, подпишитесь на рассылку

 

Расскажите о статье в Facebook и Twitter. Если статья понравилась, поставьте нам "плюс" Google.

Вы не вошли под своим пользователем на ProjectProfy.ru.
Рекомендуется нажать "Закрыть" и зарегистрироваться на сайте.
Зарегистрированные пользователи, выступающие как редакторы,
имеют различные бонусы по доступу к закрытым материалам.
Если Вам не важны бонусы, можете отправить правку прямо сейчас.

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

Если вы заметили любую ошибку в статье, вы можете сообщить об этой ошибке редакторам сайта, выделив мышью отрывок текста с ошибкой и нажав Ctrl+Enter. Ваша помощь в улучшении материалов для нас неоценима!

© 2003-2011, Портал ProjectProfy.ru. Все права защищены.

E-mail: обратная связь