BigEdu.ru
» » » Особенности управления проектами в функциональной оргструктуре
Вернуться назад

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

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

М. Якубович

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

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

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

Рисунок 1 – Особенности функциональных структур

Реализация проектов в таких структурах затруднена.

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

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

Что происходит в таких проектах?

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

Очень сложно соблюсти плановые сроки в проекте, где Заказчик «втихую» пытается расширить содержание проекта. Например, в проекте по описанию бизнес-процессов Заказчик к середине проекта заявляет, что он ожидает помимо диаграмм процессов, получить процедуры и должностные инструкции. Или в проекте по внедрению корпоративной системы управления проектами (КСУП) Заказчик заявляет о необходимости разработать или модернизировать модели описания бизнес-процессов, хотя в Уставе проекта (документ, с момента подписания которого начинается проект. Подробнее читайте в статье Управление проектами – инструмент развития компании, журнал Организационное консультирование, N9-10, 2007 год) ничего про них не упоминалось. Но по мере развития проекта Заказчик решает, что неплохо было бы «причесать» модели процессов, а там, где их не было, стоит их разработать. Содержание проекта в обоих случаях увеличивается, объем работ растет, а сроки проекта при этом не меняются. Классический пример попытки выйти за рамки тройного проектного ограничения. Суть тройного ограничения заключается в том, что руководитель проекта не может по просьбе Заказчика проекта , к примеру, сократить бюджет проекта, не увеличив при этом сроки проекта или не пожертвовав частью продуктов проекта (нужно отказаться от некоторых целей проекта или его продуктов). Или другая ситуация: Заказчик проекта хочет сократить сроки, но у руководителя проекта есть всего несколько вариантов: увеличить бюджет (за счет привлечения дополнительных ресурсов сделать проект быстрее), сократить объем работ (отказаться от части целей) или снизить качество продуктов проекта (часть требований не будут удовлетворены).

Рисунок 2 – Проектный треугольник (тройное ограничение)

Как решать проблему нечетких требований?

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

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

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

Результатом рассмотрения запроса на изменение содержания должен стать анализ последствий изменения на сроки, стоимость и качест

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать
Рефераты по менеджменту Особенности управления проектами в функциональной оргструктуре М. Якубович Идея написания статьи возникла, когда в очередном проекте, выполняемом
Оценок: 1006 (Средняя 5 из 5)

Наверняка у вас есть товары или услуги, продажа которых приносит вам максимальную прибыль. Для быстрого старта в сети вам необходимо создание посадочной страницы (одностраничного сайта), на которой будет размещена информация о маржинальных товарах/услугах интернет магазина. За 8 лет опыта разработки конверсионных страниц мы выработали оптимальную структуру, которая позволит привлекать через landing page больше продаж. На такую структуру «одевается» ваш контент — фирменный стиль, тексты, фотографии, уникальные торговые предложения, после чего страница выходит в свет. Разработка лендинга и запуск в сети — до 7 рабочих дней. Стоит отметить, что в разработку самой посадочной страницы входит и написание копирайтером продающих текстов для вашего бизнеса, чтобы каждый посетитель страницы захотел совершить покупку именно у вас. Результат: качественно разработаная продающая посадочная страница, которая готова приносить вам новых клиентов.

© 2016 - 2022 BigEdu.ru