Сегодня 23 декабря, понедельник ГлавнаяНовостиО проектеЛичный кабинетПомощьКонтакты Сделать стартовойКарта сайтаНаписать администрации
Поиск по сайту
 
Ваше мнение
Какой рейтинг вас больше интересует?
 
 
 
 
 
Проголосовало: 7278
Кнопка
BlogRider.ru - Каталог блогов Рунета
получить код
PMGuide | Гид проектного управления
PMGuide | Гид проектного управления
Голосов: 1
Адрес блога: http://www.pmguide.info/
Добавлен: 2011-11-02 00:28:35
 

3.1 Общие взаимодействия процессов управления проектами (PMBoK 4ed)

2012-10-17 07:54:18 (читать в оригинале)

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

Рис. 3-1. Группы процессов управления проектами

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

Рис. 3-2. Взаимодействие групп процессов в рамках фазы или проекта

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


2.4 Влияние организации на управление проектами (PMBoK 4ed)

2012-10-15 06:50:00 (читать в оригинале)

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


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

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

Таблица 2-1. Влияние организации на проекты

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

 Рис. 2-7. Функциональная организация

Матричные организации, как показано на рис. 2-8 – 2-10, представляют собой сочетание функциональных и проектных характеристик. Слабые матрицы сохраняют многие из характеристик функциональной организации, а роль менеджера проекта больше напоминает роль координатора или диспетчера, нежели роль фактического менеджера проекта. Сильные матрицы обладают многими характеристиками проектной организации и могут иметь менеджеров проектов с полной занятостью, имеющих существенные полномочия, а также административный персонал проекта, занятый полный рабочий день. Хотя сбалансированная матричная организация и признает необходимость существования менеджера проекта, она не наделяет его всей полнотой власти над проектом и его финансированием. В таблице 2-1 представлена дополнительная подробная информация о различных матричных организационных структурах.
Рис. 2-8. Слабая матричная организация

Рис. 2-9. Сбалансированная матричная организация

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


Рис. 2-11. Проектная организация


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

2.4.3 Активы процессов организации
Активы процессов организации включают все без исключения активы, относящиеся к процессам, во всех организациях, участвующих в проекте, которые могут быть использованы для оказания влияния на успех проекта. Эти активы процесса включают формальные и неформальные планы, правила, процедуры и приказы. Кроме того, активы процесса включают базы знаний организации, такие как накопленные знания и историческая информация. Активы процессов организации могут включать выполненные расписания, данные о рисках и данные об освоенных объемах стоимости. Обновление и дополнение активов процессов организации по мере необходимости на протяжении проекта, как правило, является обязанностью членов команды проекта. Активы процессов организации могут быть разбиты на две категории:
.1 Процессы и процедуры
Процессы и процедуры организации для проведения работ включают, среди прочего:
         стандартные процессы организации, такие как стандарты, правила (например, политика безопасности и охраны здоровья, правила этики и политика управления проектом), стандартные жизненные циклы продуктов и проектов, а также правила и процедуры контроля качества (например, проверки технологических процессов, целевые объекты усовершенствования, контрольные списки и описания типовых процессов для использования в организации);
         типовые приказы, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;
         шаблоны (например, описание риска, иерархическая структура работ, сетевая диаграмма проекта и шаблоны договоров);
         приказы и критерии для подгонки набора стандартных процессов организации с целью удовлетворения конкретных потребностей проекта;
         требования организации к обмену информацией (например, имеющаяся конкретная технология связи, допустимые среды передачи данных, политика сохранения записей и требования по безопасности);
         приказы или требования к завершению проекта (например, окончательные проверки проекта, оценки проекта, подтверждения продуктов и критерии приемки);
         процедуры финансового контроля (например, отчетность по времени, необходимый анализ расходов и трат, коды бухгалтерского учета и стандартные положения договоров);
         процедуры управления открытыми вопросами и дефектами, определяющие средства контроля над открытыми вопросами и дефектами, выявление и разрешение открытых вопросов и дефектов, а также отслеживание мероприятий;
         процедуры управления изменениями, включающие действия, согласно которым будут модифицироваться официальные стандарты компании, политики, планы и процедуры или любые проектные документы, а также порядок одобрения и утверждения любых изменений;
         процедуры управления рисками, включая категории рисков, определение вероятности и последствия, а также матрицу вероятности и последствий; и
         процедуры расстановки приоритетов, утверждения и выдачи разрешений на выполнение работ.
.2 Корпоративная база знаний
Корпоративная база знаний организации для хранения и извлечения информации включает, среди прочего:
         базы данных измерений процессов, используемые для сбора и обеспечения доступа к данным измерений по процессам и продуктам;
         файлы проекта (например, содержание, стоимость, сроки, а также базовые планы обеспечения качества, базовые планы исполнения, календари проектов, сетевые диаграммы проектов, реестры рисков, запланированные мероприятия по реагированию и определенные последствия рисков);
         историческая информация и базы накопленных знаний (например, записи и документы проекта, вся информация и документация по завершению проекта, информация о результатах решений по отбору предыдущих проектов наряду с информацией о выполнении предыдущих проектов, а также информация о трудоемкости управления рисками);
         базы данных по управлению открытыми вопросами и дефектами, содержащие сведения о статусе открытых вопросов и дефектов, информацию об управлении, данные о разрешении открытых вопросов и дефектов, а также результаты проведенных мероприятий;
         базы знаний по управлению конфигурацией, содержащие версии и базовые планы по всем официальным стандартам компании, политикам, процедурам и любым проектным документам; и
          финансовые базы данных, содержащие такую информацию, как данные о человеко-часах, понесенных затратах, бюджете и любом перерасходе средств по проекту.


2.3 Заинтересованные стороны проекта (PMBoK 4ed)

2012-10-14 07:45:48 (читать в оригинале)

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


Рис. 2-6. Взаимосвязь между заинтересованными сторонами проекта и проектом
Заинтересованные стороны проекта имеют разные степени ответственности и полномочий при участии в проекте, которые могут меняться на протяжении жизненного цикла проекта. Их ответственность и полномочия могут варьироваться от периодического участия в опросах и целевых группах до полного спонсорства проекта, включающего предоставление финансовой и политической поддержки. Заинтересованные стороны проекта могут оказывать неблагоприятное влияние на цели проекта.
Выявление заинтересованных сторон проекта является непрерывным и зачастую трудоемким процессом. Например, можно доказать, что рабочий линии сборки, чья будущая занятость зависит от результата проекта по проектированию нового продукта, является заинтересованной стороной проекта. Выявление заинтересованных сторон проекта и понимание относительной степени их влияния на проект является критически важной задачей. Невыполнение этой задачи может существенно увеличить сроки и повысить стоимость. Примером может являться позднее выяснение того, что юридический отдел является важной заинтересованной стороной проекта, что приводит к задержкам и росту затрат в связи с правовыми ограничениями.
Проект может восприниматься заинтересованными сторонами как имеющий и положительные, и отрицательные результаты. Некоторые заинтересованные стороны проекта могут выиграть от успешного завершения проекта, тогда как для других заинтересованных сторон проекта могут наступить в результате его успеха негативные последствия, например руководители ведущих предприятий района останутся в выгоде после завершения проекта промышленного развития, который положительно отразится на экономике района. В случае, когда заинтересованные стороны проекта питают положительные ожидания в отношении проекта, в их интересах будет содействовать его успешному выполнению. Интересы отрицательно настроенных заинтересованных сторон проекта препятствуют выполнению проекта. Неспособность заметить отрицательно настроенных заинтересованных сторон проекта может привести к увеличению вероятности неудачи. Важной составляющей обязанностей менеджера проекта является управление ожиданиями заинтересованных сторон проекта. Это может быть трудной задачей, поскольку зачастую заинтересованные стороны проекта преследуют очень разные или конфликтующие цели. Одной из обязанностей менеджера проекта является поддержание баланса между этими интересами и обеспечение того, чтобы команда проекта взаимодействовала с заинтересованными сторонами проекта профессионально и с позиций сотрудничества. Ниже представлены некоторые примеры заинтересованных сторон проекта.
         Заказчики/пользователи. Заказчики/пользователи – это лица или организации, которые будут пользоваться продуктом, услугой или результатом проекта. Заказчики/пользователи могут быть внутренними и/или внешними по отношению к исполняющей организации. Также может существовать несколько уровней заказчиков. Например, в число заказчиков нового фармацевтического продукта могут входить назначающие его врачи, использующие его пациенты и оплачивающие его страховые компании. В некоторых прикладных областях заказчики и пользователи являются синонимами, тогда как в других под заказчиками подразумеваются органы, приобретающие продукт проекта, а под пользователями – те, кто непосредственно будет его использовать.
         Спонсор. Спонсор – это лицо или группа лиц, которые предоставляют финансовые ресурсы (деньгами или в любом другом виде) для проекта. Когда впервые возникает замысел проекта, спонсор поддерживает его. Сюда входит выступление в роли представителя перед руководством более высокого уровня, чтобы заручиться поддержкой по всей организации и содействовать получению выгод, которые принесет проект. Спонсор сопровождает проект на протяжении процесса вхождения в контакт и отбора до получения официального одобрения и играет важную роль в разработке первоначального содержания и устава.
В решении вопросов, лежащих за пределами компетенции менеджера проекта, спонсор выступает в качестве источника расширения возможностей. Кроме того, спонсор также может участвовать в других важных вопросах, таких как одобрение изменений в содержании, завершающий анализ фазы и принятие решений «годен – не годен», когда риски особенно велики.
         Менеджер портфеля/комиссия по рассмотрению портфеля. Менеджеры портфеля отвечают за управление на высоком уровне набором проектов или программ, которые могут как зависеть, так и не зависеть друг от друга. Комиссии по рассмотрению портфелей – это комитеты, состоящие, как правило, из должностных лиц организации, которые выступают в качестве отборочной комиссии проекта. Они рассматривают каждый проект с точки зрения его рентабельности, ценности, рисков, связанных с выполнением проекта, и других аспектов проекта.
         Менеджеры программ. Менеджеры программ отвечают за управление связанными друг с другом проектами, координируя действия для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. Менеджеры программ взаимодействуют со всеми менеджерами проектов для предоставления поддержки и выдачи распоряжений по отдельным проектам.
         Офис управления проектами. Офис управления проектами (Project Management Office, PMO) – это подразделение организации или орган, осуществляющий различные функции, относящиеся к централизации и координации управления проектами, входящими в его компетенцию. Функции PMO могут варьироваться от предоставления поддержки в управлении проектами до фактического несения ответственности за непосредственное управление проектом. PMO может являться заинтересованной стороной проекта, если он несет прямую или косвенную ответственность за результат проекта. PMO может обеспечивать, среди прочего:
o   административную поддержку (например, правила, методологии и шаблоны);
o   обучение, наставничество и инструктирование менеджеров проектов;
o   поддержку проекта, руководящие указания и обучение управлению проектами и использованию инструментов;
o   корректировку ресурсов персонала проекта; и/или
o   централизованный обмен информацией между менеджерами проектов, спонсорами проектов, менеджерами и другими заинтересованными сторонами проекта.
         Менеджеры проектов. Менеджеры проектов назначаются исполняющей организацией для достижения целей проекта. Это заметная роль, требующая серьезных усилий, которая подразумевает большую долю ответственности и изменение приоритетов. Она требует гибкости, осмотрительности, сильных лидерских качеств и умения договариваться, а также солидного знания практики управления проектами. Менеджер проекта должен быть способен понимать проект до мелочей, но при этом управлять им, исходя из комплексного видения проекта. Являясь лицом, несущим ответственность за успех проекта, менеджер проекта руководит всеми аспектами проекта, включая, среди прочего:
o   разработку плана управления проектом и всех сопутствующих составляющих планов;
o   обеспечение надлежащего выполнения проекта с точки зрения сроков и бюджета;
o   обнаружение, наблюдение и реагирование на возникающие риски;
o   предоставление своевременной и точной отчетности по системе показателей проекта.
Менеджер проекта является ведущим лицом, отвечающим за обмен информацией со всеми заинтересованными сторонами проекта, в частности со спонсором проекта, командой проекта и другими ключевыми заинтересованными сторонами проекта. Менеджер проекта находится в центре взаимодействий между заинтересованными сторонами проекта и самим проектом.
         Команда проекта. Команда проекта состоит из менеджера проекта, команды управления проектом и остальных членов команды, которые выполняют работу, но не обязательно участвуют в управлении проектом. Данная команда состоит из представителей различных групп, обладающих знаниями в конкретной предметной области или набором конкретных навыков и выполняющих работу по проекту.
          Функциональные руководители. Функциональные руководители являются ключевыми лицами, играющими руководящую роль в рамках административной или функциональной области предприятия, такой как отдел кадров, финансовый отдел, бухгалтерия или отдел поставок. Им выделяется собственный постоянный персонал для выполнения текущих работ, и они имеют четкие указания управлять всеми задачами в рамках своей функциональной области ответственности. Функциональный руководитель может предоставлять экспертную помощь в предметной области, или его функцией может являться предоставление услуг для проекта.
         Управление операционной деятельностью. Менеджеры по операциям – это лица, выполняющие управляющую роль в основной области деятельности предприятия, например в области исследований и разработок, проектирования, производства, подготовки к работе, испытаний или технического обслуживания. В отличие от функциональных руководителей, эти менеджеры имеют дело непосредственно с производством и обслуживанием реализуемых продуктов и услуг предприятия. В зависимости от типа проекта формальный переход происходит при завершении, чтобы передать техническую документацию по проекту и другие документы постоянного хранения в руки представителей соответствующей группы управления операциями. Затем группа управления операциями включит переданный проект в число стандартных операций и обеспечит ему долговременную поддержку.
         Продавцы/деловые партнеры. Продавцы, также называемые агентами, поставщиками или подрядчиками, – это сторонние компании, заключившие договор на предоставление компонентов или услуг, необходимых для проекта. Деловые партнеры также являются сторонними компаниями, но они имеют с предприятием особую связь, иногда приобретенную посредством процедуры сертификации. Деловые партнеры предоставляют специализированную экспертную помощь или играют отведенную им роль, например осуществляют установку, настройку в соответствии с требованиями пользователя, обучение или поддержку.


2.2 Проекты и операционная деятельность (PMBoK 4ed)

2012-10-13 22:24:33 (читать в оригинале)

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


2.1 Жизненный цикл проекта – обзор (PMBoK 4ed)

2012-10-12 05:05:50 (читать в оригинале)

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


2.1.1 Характеристики жизненного цикла проекта
Проекты различаются по размеру и сложности. Независимо от размеров и степени сложности, все проекты могут быть представлены в виде жизненного цикла со следующей структурой (см. рис. 2-1):
         начало проекта;
         организация и подготовка;
         выполнение работ проекта;
         завершение проекта.
Данная обобщенная структура жизненного цикла часто упоминается при обмене данными с вышестоящим руководством или другими органами, которые менее осведомлены о деталях проекта. Данное представление высокого уровня может дать основу для сравнения проектов, даже если они разнородны по своей природе.

Рис. 2-1 Типовые уровни затрат и обеспечения проекта персоналом на протяжении жизненного цикла проекта

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

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

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

2.1.3 Фазы проекта
Фазы проекта – это отдельные части в рамках проекта, требующие дополнительного контроля для эффективного управления достижением основного результата проекта. Фазы проекта обычно выполняются последовательно, но в некоторых случаях могут перекрываться. Высокоуровневый характер фаз проекта превращает их в элемент жизненного цикла проекта. Фаза проекта не является группой процессов управления проектом.
Структура фаз позволяет разделить проект на логические подгруппы для более легкого управления, планирования и контроля. Количество фаз, необходимость в них и степень налагаемого контроля зависят от размера фаз, сложности и потенциального влияния на проект. Независимо от количества фаз, составляющих проект, все фазы имеют схожие характеристики:
         При последовательном выполнении фаз завершение фазы сопровождается определенного рода передачей полученного продукта в качестве результата фазы. Такое завершение фазы представляет собой естественную точку для переоценки предпринимаемых усилий и, при необходимости, для изменения или досрочного завершения проекта. Эти точки называются выходами фаз, контрольными событиями, воротами фаз, воротами решений, воротами этапов, точками критического анализа или точками остановки.
         Как правило, работы фазы имеют свойства, которые отличают ее от других фаз. При этом могут привлекаться разные организации и использоваться разные наборы навыков.
         Для успешного достижения главного результата или цели фазы требуется дополнительная степень контроля. Повторение процессов во всех пяти группах процессов, как описано в главе 3, обеспечивает такую дополнительную степень контроля и определяет границы фазы.

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

Рис. 2-3. Пример однофазного проекта
Не существует единого способа для определения идеальной структуры проекта. Несмотря на общепринятую отраслевую практику стремления к использованию предпочтительной структуры, проекты в одной и той же отрасли (или даже в одной и той же организации) могут существенно отличаться друг от друга. Некоторые организации вводят правила, стандартизирующие все проекты, тогда как другие позволяют команде управления проектом выбирать наиболее подходящий вариант для каждого конкретного проекта. Например, одна организация может расценивать изучение выполнимости проекта как обычную предпроектную работу, другая может считать его первой фазой проекта, а третья может выделить изучение выполнимости в отдельный автономный проект. Аналогично, одна команда проекта может разделить проект на две фазы, тогда как другая команда проекта может принять решение об управлении всеми работами в единой фазе. Многое зависит от характера конкретного проекта и стиля работы команды проекта или организации.
.1 Руководство проектом на протяжении жизненного цикла
Руководство проектом представляет собой всесторонний последовательный метод контроля над проектом и обеспечения его успеха. Метод, предлагаемый для руководства проектом, должен быть описан в плане управления проектом. Руководство проектом должно вписываться в более объемный контекст спонсирующей проект организации или программы.
В рамках данных ограничений, а также дополнительных ограничений по времени и бюджету на менеджера проекта и команду управления проектом ложится обязанность по определению наиболее подходящего метода реализации проекта. Должны быть приняты решения относительно участвующих лиц, необходимых ресурсов и общего подхода к выполнению работ. Другой важный момент – выяснить, потребуется ли разбиение проекта на фазы и, если да, то какова конкретная фазовая структура для данного проекта.
Структура фаз обеспечивает формальную основу для контроля. Каждая фаза формально инициируется, чтобы указать, что допустимо и что ожидается для данной фазы. Зачастую с целью принятия решения о начале операций фазы проводится анализ управления. Это особенно актуально, если предыдущая фаза еще не завершена. Примером может являться ситуация, когда организация выбирает жизненный цикл с несколькими фазами проекта, выполняющимися одновременно. Начало фазы также является подходящим временем для перепроверки принятых ранее предположений, пересмотра рисков и более подробного определения процессов, необходимых для достижения результата (ов) фазы. Например, если конкретная фаза не требует приобретения новых материалов или оборудования, пропадает необходимость осуществления операций или процессов, связанных с закупками.
Фаза проекта, как правило, завершается и формально закрывается анализом результатов для определения ее завершенности и приемки. Завершающий анализ фазы может достичь комбинированной цели получения разрешения на завершение текущей фазы и на начало последующей. Завершение фазы представляет собой естественную точку для переоценки предпринимаемых усилий и, при необходимости, для изменения или досрочного завершения проекта. Анализ ключевых результатов и выполнения проекта на текущий момент с целью a) выяснения, следует ли продолжать проект с переходом в следующую фазу; и b) эффективного с точки зрения стоимости выявления и исправления ошибок, считается хорошей практикой. Формальное завершение фазы не обязательно включает разрешение на начало последующей фазы. Например, если риск продолжения проекта расценивается как слишком высокий или если цели больше не являются обязательными, фаза может быть закрыта с принятием решения о том, чтобы не инициировать никакие другие фазы.
.2 Связи между фазами
Если проекты содержат большое количество фаз, фазы, как правило, являются частью последовательного процесса, разработанного с целью обеспечения надлежащего контроля над проектом и получения желаемого продукта, услуги или результата. Однако существуют ситуации, когда проект мог бы выиграть от использования перекрывающихся или параллельно выполняющихся фаз.
Существует три основных типа взаимосвязей между фазами:
         Последовательная связь, когда фаза может начинаться только после завершения предыдущей фазы. На рис. 2-4 показан пример проекта с полностью последовательными фазами. Пошаговый характер такого подхода уменьшает неопределенность, но может исключать варианты для сокращения сроков.
         Перекрывающаяся связь, когда фаза начинается до завершения предыдущей фазы (см. рис. 2-5). Иногда это может применяться в качестве примера метода сжатия сроков, называемого "быстрый проход". Перекрывающиеся фазы могут повысить риск и привести к повторению работ, если последующая фаза начнется прежде, чем будет получена точная информация о результатах предыдущей фазы.


Рис. 2-4. Пример трехфазного проекта

Рис. 2-5. Пример проекта с перекрывающимися фазами

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


Страницы: ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 ... 

 


Самый-самый блог
Блогер ЖЖ все стерпит
ЖЖ все стерпит
по количеству голосов (152) в категории «Истории»


Загрузка...Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.