Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Автоматизированные технологии управления проектами. Учебно-методическое пособие
.pdf
Проект
Задача
Подзадача
Комплекс работ
Работа
Операция
Рис. 1.12. Принципиальная схема структуры разбиения работ
Основные задачи построения СРР:
– повысить управляемость проекта за счет декомпозиции его на составные части;
– оценить стоимость работ, входящих в проект;
– создать дополнительные возможности для контроля и упростить его, в том числе добав-
ляя контрольные точки по проекту в соответствии со структурой разбиения работ;
– позволить рассмотреть не только общие характеристики и цели проекта, но и отдельные
подцели (их достижимость), свойства и составные части проектов;
– исследовать взаимосвязь работ за счет группировки их между собой в комплексы работ
и рассматривать такие комплексы как единое целое;
– упростить планирование работ и ведение отчетов в разрезе статей затрат и обеспечить
связь работ по проекту с системой ведения бухгалтерских счетов;
– согласовать план проекта с потребностями заказчика.
В зависимости от стратегии структурирования, применяемой при разработке СРР, используются различные подходы к разбиению проекта. Деление на работы осуществляется либо делением на составляющие (сверху вниз), либо обобщением (снизу вверх), либо
задействуются сразу два подхода. Выполняться деление может экспертным методом командой проекта с привлечением других его участников, например с применением методики «мозгового штурма». В результате должны быть учтены все цели и созданы необходимые предпосылки для облегчения коммуникации по проекту и лучшего понимания его
задач. Содержание проекта, квалификация и опыт руководителя проекта и его команды,
применяемая система управления, ориентация (на объект, функции, фазы и ход реализации) оказывают влияние на характер и уровень детализации СРР и, как следствие, на иерархическую структуру проекта. Осуществление процедур сбора, обработки информации
по структуре проекта в процессе его реализации производится в соответствии с уровнями
управления, пакетами работ, вехами по структуре проекта, что позволяет обобщать информацию по графикам работ, затратам, ресурсам и срокам. При этом работы в СРР могут выделяться в комплексы по различным признакам классификации, например по компонентам
товара (объекта, услуги), производимого в результате выполнения проекта; по составляющим направлениям деятельности, осуществляемой в рамках проекта. В некоторых случаях работы могут быть сгруппированы по функциям, процессам управления, этапам / фазам жизненного цикла проекта или по подразделениям, ответственным за их выполнение,
или по географическому прикреплению частей проекта, реализуемого не на одной территории. На практике используются СРР, построенные с использованием комбинированных
группировок (рис. 1.13).
21
Капитальный ремонт дома
Подготовка
документации
Подготовка
проектной
документации
1.1
1.0
Подготовка
сметной
документации
Монтажные
работы
1.2
2.1
Штукатурные
работы
2.2.1
Строительно-
монтажные
работы
2.0
Косметический
ремонт
2.2
Лакокрасочные
работы
2.2.2
Прочие
работы
2.3
Отделочные
работы
2.2.3
Приемка
фирмой
3.1
Сдача дома
заказчику
3.0
Приемка
заказчиком
3.2
Рис. 1.3. Пример структуры разбиения работ проекта «Капитальный ремонт дома»
Построение организационной структуры проекта (OBS — Organisation Breakdown
Structure) осуществляется с целью определения отделов организации, ответственных за выполнение соответствующих работ, и указания исполнителей работ (рис. 1.14). Ее уровни могут соответствовать уровням СРР (рис. 1.15).
Z
X
Y
A B
B1 B2
C D
D1 D2
E
Рис. 1.14. Обобщенная организационная структура проекта
Целью разработки структуры проекта является определение состава отделов и должностных лиц, необходимых для выполнения работ, определенных в СРР по проекту. Состав и порядок реализации работ оказывают влияние на форму организационной структуры проекта.
Администрация
Производственный отдел
Технические службы
Дизайнеры
Департамент экономики
Бухгалтерия
Плановый отдел
Рис. 1.15. Пример организационной структуры проекта «Капитальный ремонт дома»
22
При сопоставлении структуры разбиения работ с организационной структурой организации (структурной схемой организации — ССО) и построении на их основе матрицы ответственности по проекту происходит увязка работ со структурными подразделениями
и должностными лицами компании. Формирование матрицы позволяет распределить ответственность за работы, их комплексы и подпроекты между подразделениями и определить права и обязанности всех участников проекта (рис. 1.16). При построении матрицы распределения
ответственности в проекте важно помнить, что на практике связь между ССР и структурой
проекта всегда выходит менее понятной, чем это представлено на схеме. Список пакетов работ из структуры разбиения располагается в строках матрицы, а список подразделений и исполнителей, принимающих участие в выполнении работ, приведен в столбцах.
Рис. 1.16. Процесс заполнения матрицы ответственности
Организация работ в проекте и его специфика оказывают влияние на количество видов ответственности, выделяемых в проекте и указываемых в матрице ответственности. Для их описания не стоит применять сложные в понимании термины, которые могут иметь различные
толкования. Следует ограничиться небольшим набором понятных обозначений видов ответственности (например первый исполнитель, соисполнитель, проверка / оценка / приемка исполнения, согласование, участие: помощь, совет, обсуждение). Сформированная матрица ответственности позволяет четко определять права и обязанности участников проекта по каждому из
комплексов работ по нему. В табл. 1.2. приведен пример матрицы ответственности.
Назначение ответственных структурных подразделений или должностных лиц следует проводить поэтапно. Начинать следует с рабочей группы проекта, так как она служит ядром команды. После этого расстановку видов ответственности за работы продолжают для остальных членов команды проекта. Завершают распределение прав и обязанностей между исполнителями
только на начальной стадии реализации проекта после разработки и утверждения плана.
23
Таблица 1.2
Примерматрицыответственности
Направления
деятельности
Должностные
лица
и подразделения
Инжиниринг,
в том числе новые технологии
Мониторинг
Инженерные системы
Планирование
Маркетинг
Привлечение инвестиций
Контроль и анализ финансов
Бухгалтерский учет
НИОКР и ПИР
Исходно-разрешительная
документация
Кадры
Материально-техническое
обеспечение
Контроль за производством
Система менеджмента каче-
ства
Функции заказчика
Генеральный директор 3 3 3 3 3 2 3 3 3 3 3 3 3 3 2 3
Заместитель по инновациям 1 2 3 2 1 2 4 2 5 – 5 5 – 2 4 4
Заместитель
по технико-экономическому
планированию
Коммерческий директор – 1 – 2 5 1 2 2 – – 5 – – – – –
Исполнительный директор 4 4 2 2 2 – 5 3 5 2 5 1 1 1 1 5
Заместитель
по административным
вопросам
4 2 2 1 4 2 1 1 5 5 5 5 – 2 5 5
– 5 – 2 2 – – 2 5 – 1 2 5 – – 1
Юридическая поддержка
Условные обозначения: 1 — первый исполнитель; 2 — соисполнитель; 3 — проверка исполнения; 4 — согласование; 5 — участие (помощь, совет, обсуждение).
Цельработы
Анализ двух возможных вариантов формирования организационных структур управления проектом.
Краткоеописаниеработы
Ситуация демонстрирует необходимость анализа и изменения существующей организационной структуры как предприятия, так и управления проектом.
Вступление
Минпромэнерго России в 2007 г. была утверждена Программа создания в Восточной Сибири и на Дальнем Востоке единой системы добычи, транспортировки газа и газоснабжения с учетом возможного экспорта газа на рынки Китая и других стран АТР. Координатором
по реализации этой программы министерством назначено ОАО «Газпром», которое уполномочило свою дочернюю региональную газотранспортную компанию ООО «Газпромтрансгаз
Томск» на выполнение проектов по развитию газотранспортной системы на Востоке России.
Будучи эксплуатирующей организацией для создаваемых объектов транспорта газа,
ООО «Газпромтрансгаз Томск» должно выполнить значительный объем работ, основной из
которых является организация деятельности производственных подразделений — линейно-производственных управлений магистральных газопроводов (ЛПУМГ) и линейно-производственных управлений магистральных трубопроводов (ЛПУМТ). Согласно перспективной
программе развития компании «Газпромтрансгаз Томск» в период до 2020 г. планировалась
реализация целого ряда проектов создания новых ЛПУМГ и ЛПУМТ — от 4 до 10, в зависимости от выбранного сценария.
24
Существующая организационная структура ООО «Газпромтрансгаз Томск» реализована
в линейно-функциональной форме. Для выполнения перспективных проектов возможны варианты формирования:
1) рабочих групп из сотрудников линейно-функциональных подразделений;
2) матричной структуры управления проектами.
В частности, в проекте создания Сахалинского ЛПУМТ использовалась линейно-функциональная структура организации управления проектом, для чего была сформирована рабочая
группа из высшего руководства и руководителей линейно-функциональных подразделений
ООО «Газпромтрансгаз Томск». Каждый член рабочей группы согласно сформированному
и утвержденному плану являлся ответственным за реализацию конкретных мероприятий
в определенный срок.
Альтернативой организации проектных работ по описанному варианту является организация матричной структуры управления проектом.
Вопросы
1. Сформулируйте перечень мероприятий для реализации матричной структуры управле-
ния проектом создания Сахалинского ЛПУМТ.
2. Дайте предложения по составу проектной группы.
3. Проанализируйте достоинства и недостатки двух возможных структур управления дан-
ным проектом.
4. Предложите свой вариант структуры управления данным проектом.
5. Приведите примеры зарубежных или отечественных компаний с аналогичными струк-
турами управления.
Цельработы
Изучение вопросов управления жизненным циклом проекта, анализ проблем проектирования корпоративных информационных систем.
Краткоеописаниеработы
Ситуация рекомендуется к использованию в ходе изучения вопросов моделирования жизненного цикла проекта. Также в ситуации затрагиваются проблемы построения корпоративных систем управления (организационная структура проекта, использование стандартов, распределение полномочий и ответственности, процессы принятия решений).
Вступление
Руководитель ИТ-проекта в страховой компании «Радуга» только что получил сообщение,
что работы по его проекту полностью остановились. Вот уже как шесть часов никаких работ
по проекту не выполняется по причине разногласий среди специалистов по поводу требований и спецификаций к результатам проекта. Разногласия касались того, как выполнять одну
из задач по проекту, и потенциально приводили к отклонениям от изначально определенных
спецификаций.
Руководитель прекрасно понимал, что дальнейшее выполнение проекта невозможно без
разрешения сложившихся разногласий. Если результаты проекта не будут соответствовать
спецификациям, то это будет вскрыто во время промежуточных проверок. Или же потребуются усилия на согласования изменений в спецификации и требования, закрепленные в технической документации. В любом случае возникала серьезная опасность потерять время не
только на возникшие разногласия среди специалистов, но и на исправления или дополнительные согласования.
Компания «Радуга» представляла собой быстро растущую страховую компанию, предоставляющую широкий спектр услуг. Специфика деятельности компании предполагала сбор
большого количества информации от клиентов, проведения различного рода актуарных рас-
25
четов, исследований и анализов, прогнозирование затрат. В силу этого развитию информационной системы компании руководство уделяло большое внимание. В компании был организован свой собственный ИТ-департамент, который решал большое количество задач и управлял
практически всеми ИТ-проектами компании, привлекая в рамках аутсорсинга ограниченное
количество известных компаний для решения узкого спектра задач.
В ИТ-департаменте была принята понятная и простая линейная модель жизненного цикла проекта.
В последние два года компания «Радуга» стремительно развивалась. Руководство компании прогнозировало на ближайшую перспективу дальнейший рост клиентской базы и объема
операций. Расширение бизнеса и рост количества клиентов означали необходимость управлять все большим количеством информации. До начала проекта основным инструментом
управления данными о клиентах выступала разработанная сотрудниками ИТ-департамента
база данных, построенная на СУБД MS Access.
Руководство компании прекрасно понимало ограничения данной СУБД и поэтому инициировало проект создания новой базы данных и перенос всех старых данных в нее. После некоторого анализа руководство ИТ-департамента остановило свой выбор на СУБД Oracle, которая предоставляла необходимую гибкость, надежность, возможность управлять большими
массивами данных, возможность расширения. Создаваемая система должна была быть полностью совместимой с уже существующей системой, построенной на MS Access, так, чтобы обеспечить корректный перенос данных. Бюджет проекта был определен в 1 млн рублей. Плановая продолжительность проекта составила 15 недель. Проект было решено выполнять силами
ИТ-департамента без привлечения внешних контракторов.
Исполнители работ по проекту выделялись в проект из различных отделов ИТ-департамента и административно руководителю проекта не подчинялись, работая параллельно и над
другими проектами.
Как уже было сказано выше, все проекты ИТ-департамента осуществлялись в подавляющем большинстве случаев на основе линейной модели жизненного цикла разработки программных приложений. Проект разбивался на несколько этапов, каждый из которых завершался финальной проверкой. Переход к последующему этапу возможен только при успешном
прохождении финальной проверки предыдущего этапа. Финальная проверка осуществлялась
специально создаваемой комиссией, в которую входили руководители различных функциональных подразделений компании. Руководитель проекта в приемочную комиссию (даже по
промежуточным этапам), как правило, не входил.
Основная цель финальной проверки (в том числе и по промежуточным этапам) заключалась
в контроле соответствия созданных результатов задокументированным требованиям к создаваемому программному обеспечению, которые часто назывались спецификациями. Спецификации формулируются на основе предварительного анализа требований к программному обеспечению, проводимого за рамками проекта специалистами отдела системного анализа.
Общая схема принятой модели жизненного цикла проектов ИТ-департамента показана на
рис. 1.17.
Инициация Планирование Разработка Тестирование Внедрение
Рис. 1.17. Общая схема линейной модели жизненного цикла ИТ-проектов компании «Радуга»
Передача
в эксплуатацию
Этап инициации проекта прошел без особых проблем и разногласий. В рамках устава были
определены рамочные требования к продолжительности и стоимости проекта. Спецификация
закрепила основные требования к функциональности, эргономичности и другим характеристикам создаваемого программного продукта.
В ходе этапа планирования спецификации по проекту были проанализированы будущими
исполнителями. Один из программистов увидел возможности оптимизировать разработку базы
26
данных, что требовало внесения существенных изменений в уже утвержденные спецификации.
Его идея состояла в том, чтобы создать программный модуль, позволяющий новой системе безболезненно и корректно использовать данные старой системы без переноса их в новую. Потенциально такое решение может несколько упростить разработку новой системы, но не существенно. Наибольшая экономия усилий и времени от этого предложения могла возникнуть по
причине устранения необходимости переноса данных из старой системы в новую. Решение также снижало риски потерь и искажений данных при переносе, снижало затраты на обучение,
так как старая система могла использоваться на старых рабочих местах. Но при этом возникали
дополнительная сложность и риски в системе по причине использования более сложной архитектуры. Хотя по оценке других программистов эти риски были признаны как невысокие.
Руководителю Руслану данная идея пришлась не по душе, так как она явно входила в противоречие с уже утвержденными спецификациями и приводила к дополнительным потерям
времени на согласования и пересогласования уже принятых решений. Еще больше эту идею
он стал отвергать, когда увидел, что она действительно имеет под собой рациональное зерно
и поддерживается другими программистами. На проводимом руководителем специальном совещании программисты стали оказывать на него давление с целью инициализации пересмотра утвержденных специ фикаций с руководством функциональных подразделений компании
и отделом системного анализа. Руководитель решил не принимать новые идеи и настаивал на
том, чтобы все исполнители придерживались ранее утвержденных спецификаций и не искали идеальных вариантов решения задач. Отличное — враг хорошего. Данный тезис руководитель использовал как основной при аргументации своей позиции.
На устранение возникших разногласий ушло полтора рабочих дня. В первую очередь по
причине того, что несколько программистов видели рациональность в новом предложении,
хотя и понимали все административные сложности согласования изменений в спецификации.
В конечном итоге руководителю удалось всех убедить в правильности своей позиции, хотя несколько программистов так и остались при своем мнении, что, по видимости, серьезно снизило их лояльность к проекту.
После устранения всех разногласий руководитель разработал детальный календарный план
и бюджет, матрицу ответственности, которые были безболезненно согласованы и утверждены приемочной комиссией по второму этапу проекта. Проект успешно перешел на этап разработки базы данных.
Но в ходе выполнения работ программистами и тестовыми аналитиками была обнаружена
проблема при переносе данных из старой системы в новую. Решение проблемы требовало дополнительного времени программистов. Для того, чтобы завершить проект, который и так несколько опаздывал, с не очень большим отклонением по срокам требовалось увеличить загрузку двух программистов, Сергея и Евгения, которые были вовлечены в выполнение работ по еще
одному приоритетному проекту. Более того, Сергей и Евгений были из числа тех программистов, которые на стадии планирования были активными сторонниками идеи оставить старую
базу и не осуществлять переноса данных. Особого энтузиазма самостоятельно решать вопрос
их дополнительной загрузки по проекту они не испытывали, и руководителю ничего не оставалось, как пытаться согласовать данный вопрос с руководителем Сергея и Евгения.
Их руководитель, Иван, оказался серьезно занят по другому проекту компании и смог
встретиться с Русланом только три дня спустя после обнаружения проблемы с переносом старых данных. В течение этих трех дней опоздание проекта продолжало накапливаться. После
получасового разговора Иван согласился выделить Сергея и Евгения на большую часть времени в проект Руслана.
Но дополнительная загрузка Сергея и Евгения не помогла избежать серьезных нарушений
по срокам выполнения этапа разработки, так как на устранение проблемы ушло значительно больше времени, нежели ранее предполагалось. Этап разработки был завершен с опозданием на две недели. Более того, дополнительное время Сергея и Евгения привело к превышению бюджета проекта.
27
Устранить возникшие отклонения в ходе выполнения последующих этапов проекта руководитель практически не имел возможности, так как принятая модель жизненного цикла оставляла мало возможностей для запараллеливания работ в разных этапах. С пессимистическим
настроением руководитель приступил к реализации этапа тестирования, несколько нервно ожидая, какие проблемы и вопросы могут возникнуть в ходе выполнения процедур тестирования.
Вопросы
1. Каковы преимущества и недостатки линейной модели жизненного цикла проекта (как
вообще, так и применительно к рассматриваемому проекту)?
2. Какие аргументы вы бы использовали для убеждения программистов, уверенных в разумности изменений в спецификации проекта в соответствии с новой идеей на стадии планирования? Как бы вы поступили на месте Руслана в данной ситуации?
3. Согласны вы или не согласны с подходом руководителя к решению проблем по проекту?
4. Какие улучшения вы можете предложить для оптимизации управления ИТ-проектами
в компании «Радуга»?
5. Какие пути решения проблем еще можно предложить для решения сложившейся ситуации?
Управление стоимостью проекта включает в себя воздействие на факторы, вызывающие
изменения базового плана по стоимости. Существует множество факторов, которые оказывают существенное влияние на стоимость проекта. К таковым принято относить: аналоги строительного проекта (рыночное влияние); условия строительства (характеристики почвы, наличие инженерных сетей, транспортных коммуникаций, санитарно-защитной зоны, грунтовых
вод); фактор инфляции (для проектов с большой продолжительностью); график реализации
проекта (затянутые проекты приводят к увеличению косвенных затрат, а быстрореализуемые
требуют увеличения прямых затрат); качество проектной документации и спецификаций; необходимость привлечения инженерно-технического состава с высокой профессиональной репутацией; нормативные требования (влияние сроков согласования или их невыполнения);
наличие дополнительных требований к страхованию; размер и тип строительства (при необходимости большого количества квалифицированных или специализированных трудовых
ресурсов); экспертиза проектной документации; месторасположение площадки строительства относительно нахождения ресурсов (рабочих, оборудования, материалов, инструментов
и т.д.), а также влияние места нахождения стройплощадки на ставки оплаты труда и стоимость ресурсов; резервы для расходов, не заложенных в проект.
Стоимость проекта — это совокупность стоимостей ресурсов проекта, стоимостей и времени выполнения работ проекта. Для проектов в области строительства определяется та стоимость строительства, которая является частью стоимости проекта, куда входят денежные
средства, необходимые для капитального строительства.
Управление стоимостью проекта включает в себя процессы, необходимые для обеспечения гарантии выполнения проекта в рамках утвержденного бюджета. Целью системы управления стоимостью (затратами) является разработка политики, процедур и методов, позволяющих осуществлять планирование и своевременный контроль затрат.
Управление стоимостью (затратами) проекта включает следующие процессы:
− оценку стоимости проекта;
− бюджетирование проекта, т.е. установление целевых показателей затрат на реализацию
проекта;
− контроль стоимости проекта, постоянной оценки фактических затрат, сравнения с ранее
запланированными в бюджете и выработки мероприятий корректирующего и предупреждающего характера.
28
На рис. 1.18. представлена иерархия показателей стоимости, соответствующая иерархии
управления на фазах жизненного цикла проекта (табл. 1.3).
Стоимость
V
уровень
инвестиционного
проекта.
Стоимость
объектов-аналогов
IV
уровень
III
уровень
II
Конструктивные
элементы
Отдельные
комплексы,
этапы
Укрупненные показатели базисной стоимости.
Укрупненные виды работ
Показатели ресурсов и стоимости. Виды работ
Удельные
показатели
стоимости
уровень
I
уровень
Материалы.
Машины.
Оплата
труда
1 2
Материалы.
Машины.
Оплата
труда
Материалы.
Машины.
Оплата
труда
n
Элементные показатели ресурсов и стоимости
Рис. 1.18. Иерархия показателей стоимости с уровнями агрегирования
На уровне I находятся элементные показатели ресурсов и стоимости. На верхнем уровне V
находится обобщенный показатель — стоимость инвестиционного проекта в целом. При расчетах стоимости на определенном уровне необходимо сформировать порядок ее получения из
стоимостных оценок (показателей) более низкого уровня.
1 уровень
(элементные показатели
ресурсов и стоимости)
2 уровень
3 уровень
4 уровень
5 уровень
Таблица 1.3
Иерархияпоказателейстоимости
Стоимостные расчеты при разработке детальной проектной документации,
а также при взаиморасчетах за выполненные работы
Агрегирование, создание укрупненных сметных нормативов, основных показателей, используемых при разработке сметной документации на стадиях рабочей
и проектной документации при составлении актов выполненных работ для взаиморасчетов, при подготовке оферты подрядчика для участия в торгах
Внутрифирменное планирование — на стадии проведения подрядных торгов, при
разработке инвесторской сметы, при региональном планировании объемов инвестиций, а также при предварительных расчетах стоимости комплексов, этапов,
укрупненных показателей для определения сроков и авансирования работ
Агрегирование и стоимость расчетов рядом укрупненных, удельных показателей,
прейскурантами на строительство зданий и сооружений, показателями стоимости
конструктивных элементов. Показатели четвертого уровня используются на предпроектных и проектных стадиях, при разработке концептуальной и инвесторской
сметы, региональном планировании объемов инвестиций
Окончательное формирование договорной стоимости инвестиционного проекта,
что соответствует стадии концепции проекта. Пятому уровню должны соответствовать суммарные затраты и определенная прибыль всех участников инвестиционного цикла
29
Так, соблюдая процедуры укрупнения затрат и двигаясь вверх по стоимостным уровням,
определяют вариант минимальной стоимости из нескольких вариантов на конкретном уровне агрегирования.
На стадии формирования бюджета все ресурсы, привлекаемые для выполнения работы,
списываются на различные статьи затрат. Управление стоимостью осуществляется на протяжении всего жизненного цикла (ЖЦ) проекта, при этом, естественно, процессы управления
реализуются по-разному на различных этапах. Это находит отражение в современной концепции управления стоимостью проекта — управления стоимостью на протяжении жизненного
цикла проекта (рис. 1.19).
Концепция
стоимости
Обоснование
проекта
Планирование
проекта
Реализация
проекта
Завершение проекта
Укрупненная
оценка
стоимости
Детальная оценка
стоимости
Стоимостное планирование,
или бюджетирование
Контроль
стоимости проекта
Завершающая
оценка проекта
Рис. 1.19. Управление стоимостью на протяжении жизненного цикла проекта
Распределение стоимости проекта в течение его ЖЦ неравномерно (рис. 1.20, 1.21). Основная часть стоимости возникает на фазе реализации проекта. Но основные решения, обусловливающие показатели стоимости проекта, принимаются в его предынвестиционной фазе.
Возможность управления стоимостью также распределяется неравномерно на протяжении
ЖЦ проекта.
Предынвестиционная
фаза
Стоимость проекта
12 %
Рис. 1.20. Распределение стоимости проекта по фазам жизненного цикла
Инвестиционная
фаза
60 %
30
эксплуатации
Фаза
28 %
Время
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]