Выбор структуры управления проектом

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава I. Структура управления проектами

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

1.2 Организация проектов по принципу независимых команд

1.3 Организация проектов в матричной организации

Глава II. Выбор подходящей структуры управления проектом

Заключение

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



Введение

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

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

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

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



Глава I. Структура управления проектам

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

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

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

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

Структура разбиения (декомпозиции) работ (WBS -- Work Breakdown Structure)-- иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ. СРР является базовым средством для создания системы управления проектом, так как позволяет решать проблемы организации работ, распределения ответственности, оценки стоимости, создания системы отчетности, эффективно поддерживать процедуры сбора информации о выполнении работ и отображать результаты в информационной управленческой системе для обобщения графиков работ, стоимости, ресурсов и дат завершения.

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

· определить работы, пакеты работ, обеспечивающие достижение подцелей (частных целей) проекта;

· проверить, все ли цели будут достигнуты в результате реализации проекта;

· создать удобную, соответствующую целям проекта структуру отчетности;

· определить на соответствующем уровне детализации плана вехи (ключевые результаты), которые должны стать контрольными точками по проекту;

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

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

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

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

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

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



Рис.1 Пример иерархической структуры работ

При построении ИСР необходимо соблюдать следующие принципы:

1. Работы нижнего уровня являются способом достижения работ верхнего уровня.

2. У каждой родительской работы может иметься несколько дочерних работ, достижение которых автоматически обеспечивает достижение родительской работы.

3. У каждой дочерней работы может быть только одна родительская работа.

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

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

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

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

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

· работы ясны и понятны менеджеру и участникам проекта (являются элементарными);

· понятен конечный результат работы и способы его достижения;

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

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

Основанием декомпозиции СРР могут служить:

· компоненты товара (объекта, услуги, направления деятельности), получаемого в результате реализации проекта;

· процессные или функциональные элементы деятельности организации, реализующей проект;

· этапы жизненного цикла проекта, основные фазы;

· подразделения организационной структуры;

· географическое размещение для пространственно распределенных проектов.

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

Искусство декомпозиции проекта состоит в умелом согласовании основных структур проекта, к которым относят, прежде всего, организационную структуру (OBS -- Organization Breakdown Structure), структуру статей затрат (ABS --- Account Breakdown Structure), структуру ресурсов (RBS--Resource Breakdown Structure), функциональную структуру, информационную структуру, структуру временных интервалов (порядок и состав фаз, этапов, ключевых событий проекта) и их возможные составные структуры. СРР служит основой для подобного согласования.

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

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

Правила, основные этапы построения и возможности использования СРР следующие:

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

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

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

Рис.2. СРР для смешанного подхода

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

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

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

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

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

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

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

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

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

· аналогично график и план по вехам может быть представлен с помощью СРР в виде главного, укрупненного графика (project master schedule), в котором указаны основные компоненты и этапы проекта. Он является всеобъемлющим и может включать в себя контрактные обязательства, ключевые контакты, порядок действий, важные события и отчеты о ходе выполнения работ.

Возможные ошибки структуризации проекта:

· пропуск стадии структуризации проекта и переход непосредственно к поиску и решению текущих, оперативных проблем проекта;

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

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

· повторение элементов структуры;

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

· излишняя или недостаточная детализация;

· невозможность компьютерной обработки результатов структуризации -- планов проекта из-за ошибок формального характера (каждый уровень или элемент плана должен быть определенным образом закодирован);

· неучет «неосязаемых» конечных продуктов, таких как услуги;

· информационное или программное обеспечение.

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 Организация проектов по принципу независимых команд

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

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

Рис. 3 Проектная команда

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

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

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

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

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

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

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

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

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

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

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

1.3 Организация проектов в матричной организации

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

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



Рис. 4 Структура матричной организации



Глава II. Выбор подходящей структуры управления проектом

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

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

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

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

Говоря о структурах управления проектами, нужно заметить, что это не всегда вопрос «или--или». Многие фирмы, занимающиеся именно управлением проектами, используют проектные команды для специальных проектов, а матричная структура используется для большинства других проектов. Например, Chaparral Steel, небольшой завод, производящий стальные брусья и балки из металлолома, классифицирует проекты по трем категориям: «продвинутые разработки», «основные» и «малого приращения». К «продвинутым разработкам» относятся проекты с высокой степенью риска, занимающиеся созданием качественно нового продукта или процесса. «Основными» называются проекты со средней степенью риска, занимающиеся модернизацией систем, в результате чего на свет появляются новые продукты и процессы. Проекты «малого приращения» -- это краткосрочные проекты с низкой степенью риска, связанные с внесением мелких изменений в существующие продукты и процессы. Постоянно Chaparral Steel занимается 40--50 проектами одновременно, из которых 1--2 относятся к «продвинутым разработкам», 3--5 являются «основными», а остальную часть составляют небольшие проекты «малого приращения». Почти все проекты «малого приращения» выполняются в рамках функциональной матрицы, где управляющий проектом координирует работу функциональных подгрупп. Проектная матрица используется для разработки «основных» проектов, а приверженные проектные команды создаются для выполнения «продвинутых разработок». Все больше компаний используют подобный подход подбора нужной структуры для управления проектом.



Заключение

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

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

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

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

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

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

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



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

1. Клиффорд Ф.Грей, Эрик У. Ларсон Управление проектами: Практическое руководство/ Пер. с англ. - М.: Издательство «Дело и Сервис», 2003. - 528 с.

2. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие/ Под общ. ред. И.И. Мазура. - 2-е изд. - М.: Омега-Л, 2004. - 664 с.

3. Сайт BiblioFond.ru

4. Сайт Bookzie.com

Размещено на Allbest.ru