Назначение фазы проекта. Взаимосвязи между фазами

I СУЩНОСТЬ, ОСНОВНЫЕ ПОНЯТИЯ И ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЕКТАМИ 11. Назначение фазы проекта. Взаимосвязи между фазами. Концептуальная фаза. На этой фазе должен быть определен проект, разработана его концепция, включающая следующие стадии: 1) инициацию проекта – определяет и авторизует проект или фазу проекта; 2) формирование бизнес-идеи, постановку целей; 3) назначение руководителя проекта и формирование ключевой команды проекта; 4) установление деловых контактов и изучение рынка, мотивации и требований заказчика и других участников; 5) сбор исходных данных и анализ существующего состояния; 6) определение основных требований, ограничительных условий, материальных, финансовых и трудовых ресурсов; 7) сравнительную оценку альтернатив; 8) представление предложений, их экспертизу и утверждение. Фаза «Планирование» служит для определения и уточнения цели, планирования действий, необходимых для достижения цели. Планирование в том или ином виде производится в течение всего срока реализации проекта. В самом начале жизненного цикла проекта разрабатывается предварительный план – грубое представление о том, что потребуется выполнить в случае реализации проекта. Разработка плана управления проектом включает в себя операции, необходимые для формирования, координации всех вспомогательных планов и их интеграции в единый план управления проектом. Как правило, план проекта не остается неизменным, и по мере его осуществления он постоянно корректируется с учётом текущей ситуации. Фаза «Осуществление». После утверждения плана следует фаза его реализации. По мере осуществления проекта основная задача руководителя проекта заключается в управлении ходом работ проекта и установлении различных технических и организационных связей. С этой целью проводится постоянный мониторинг и контроль за работами проекта. Фаза «Завершение». Проект заканчивается, когда достигнуты поставленные перед ним цели. Последним процессом, входящим в управление интеграцией проекта, является Закрытие проекта (фазы проекта). Закрытие проекта (фазы проекта) – завершение всех операций по всем группам процессов проекта для формального завершения проекта. На этой фазе разрабатываются процедуры по формальному закрытию проекта (фазы проекта) и закрытию контрактов. В процессе закрытия проекта: • проверяются и документируются продукты проекта; • определяются и документируются причины досрочного завершения проекта; • издается распоряжение о закрытии проекта (формально закрывающее проект так же, как устав формально начинает проект); • документируются «усвоенные уроки» пo проекту; • оформляется и закрывается архив проекта. Связи между фазами Существует три основных типа взаимосвязей между фазами: • Последовательная связь, когда фаза может начинаться только после завершения предыдущей фазы. Пошаговый характер такого подхода уменьшает неопределенность, но может исключать варианты для сокращения сроков. • Перекрывающаяся связь, когда фаза начинается до завершения предыдущей фазы. Иногда это может применяться в качестве примера метода сжатия сроков, называемого «быстрый подход». Перекрывающиеся фазы могут повысить риск и привести к повторению работ, если последующая фаза начнется прежде, чем будет получена точная информация о результатах предыдущей фазы. • Итерационная связь, когда на любое заданное время планируется только одна фаза, а планирование следующей осуществляется по мере выполнения работ в рамках текущей фазы и получения результатов. Данный подход полезен в значительной степени в неопределенных, непостоянных или быстро меняющихся средах, таких как исследования, но он может уменьшить способность обеспечения долгосрочного планирования. В проектах, состоящих из многих фаз, на протяжении жизненного цикла может существовать несколько связей между фазами. Связи, применяемые в периоды между фазами, определяются такими соображениями, как требуемый уровень контроля, эффективность и степень неопределенности. Исходя из этих соображений, в периоды между различными фазами одного проекта могут применяться все три вида связей. 12. Применение итеративного подхода в управлении проектом Итерация (лат. iteratio — повторяю) — повторение какого-либо действия. Основой итеративного подхода является непрерывный анализ выполненных работ, последующее проектирование и физическое воплощение результатов проектирования. Итеративный подход акцентирует работу команды в более предсказуемом и повторяемом направлении. На рис.1 представлен пример применения итеративного подхода. Рис. 1 Пример применения итеративного подхода. Основные преимущества итеративного подхода: - нивелирование воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами; -возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям; - акцент усилий на наиболее важные и критичные направления проекта; -непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом; - раннее обнаружение несоответствий между требованиями, моделями и программным кодом; - более равномерная загрузка участников проекта; -эффективное использование накопленного опыта; - реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении. Применение итеративного подхода может снизить уровень риска проекта путем предоставления отдельных готовых частей системы в сжатые сроки. В конце каждого цикла разработки исполнитель должен продемонстрировать заказчику результаты и получить отзывы пользователей о функциональности, работоспособности системы и ее стабильности. Использование такого подхода снижает уровень риска проекта с самого начала разработки. Это происходит по той причине, что команда проекта фокусируется на ключевой функциональности системы и снижает риски с высоким уровнем на ранних этапах разработки (например, разработка ПО). Пример из проектирования ПО Что такое итерационная разработка? Проект, в котором применяется итерационная разработка, имеет жизненный цикл, состоящий из нескольких итераций. Итерация включает приблизительно последовательный набор задач бизнес-моделирования, требований, анализа и проектирования, реализации, тестирования и развертывания в различных пропорциях, в зависимости от расположения итерации в цикле разработки. Итерации на начальном этапе и этапе уточнения фокусируются на управлении, требованиях и проектировании; итерации на этапе построения фокусируются на проектировании, реализации и тестировании; а итерации на этапе внедрения фокусируются на тестировании и развертывании. Итерациями следует управлять как timeboxed, то есть расписание итерации следует считать фиксированным и управлять областью содержимого итерации, чтобы она соответствовала этому расписанию. Зачем нужна итерационная разработка? В начальном проекте по отношению к его ключевым требованиям с большой вероятностью будут содержаться ошибки. Позднее обнаружение дефектов проекта приводит к дорогостоящим затратам и, в некоторых случаях, даже к прекращению проекта. Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков. В водопадном жизненном цикле невозможно убедиться в отсутствии рисков на ранних этапах жизненного цикла. В итерационном жизненном цикле вы на основании списка ключевых рисков выбираете инкремент для разработки в итерации. Поскольку в итерации создается протестированный исполняемый продукт, то можно проверить, были ли в результате снижены риски или нет. Преимущества итерационного подхода Итерационный подход в целом имеет преимущество перед линейным или водопадным подходом по целому ряду причин. • Риски снижаются ранее, поскольку интеграция элементов выполняется постепенно. • Поддерживается изменение требований и тактики.  • Облегчается улучшение и отладка продукта, что позволяет получить более надежный продукт. • Возможно обучение организаций в этом подходе и улучшение их процессов.  • Увеличивается возможность повторного использования. Однажды заказчик сказал: "При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду." Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей существует некоторый объем повторяющихся действий, однако это также тщательно контролируется. Снижение рисков Итерационный подход позволяет снизить риски раньше, поскольку многие риски обнаруживаются только во время интеграции. При развертывании ранней итерации вы проходите через все разделы, изучая многие аспекты проекта: инструменты, готовое программное обеспечение, навыки сотрудников и так далее. Предполагаемые риски могут не подтвердиться, в то время как могут быть обнаружены новые, неожиданные риски. Интеграция не является одним "большим шоком" в конце - элементы объединяются постепенно. В действительности, итерационный подход представляет собой практически непрерывную интеграцию. То, что является длительным, неопределенным и сложным - что отнимает до 40% общих усилий в конце проекта - и что сложно точно спланировать, делится на от шести до девяти меньших интеграций, которые выполняются с гораздо меньшим числом элементов. Внесение изменений Итерационный подход позволяет учитывать изменения в требованиях, поскольку обычно они будут изменяться по мере работы над проектом. Изменения в требованиях и "смещение" требований всегда являются первичными источниками нарушений для проекта, ведущими к задержке поставок, сбоям в расписании, неудовлетворенности заказчиков и разочарованию разработчиков. Двадцать пять лет назад Фред Брукс написал: "Заранее планируйте выкинуть первую версию - все равно придется." Мнение пользователей будет изменяться по мере продвижения работы над проектом. Такова человеческая натура. Неверным было бы принуждать пользователей принять систему такой, какой они представляли себе первоначально. Мнение пользователей меняется, поскольку меняется контекст - они больше узнают о среде и технологии и видят промежуточную демонстрацию разрабатываемого продукта. Итеративный жизненный цикл обеспечивает управление путем внесения тактических изменений в продукт. Например, для того чтобы составить конкуренцию существующим продуктам, вы можете принять решение выпустить продукт с ограниченным набором функций раньше, для того чтобы опередить действия конкурента, либо можно адаптировать другого вендора для данной технологии. Итерации также поддерживают технологические изменения по мере продвижения работы над проектом. Если какая-либо технология изменяется или становится стандартом при появлении новой технологии, то это может дать проекту определенные преимущества. Это в особенности относится к изменениям платформы и изменениям инфраструктуры на более низких уровнях. Достижение более высокого качества Итерационный подход позволяет получить более устойчивую архитектуру, поскольку ошибки исправляются на протяжении нескольких итераций. Первые дефекты обнаруживаются уже в первых итерациях продукта. Обнаруживаются узкие места в производительности, которые можно исправить сразу, а не непосредственно перед доставкой. Итерационная разработка, в отличие от выполнения тестов в конце проекта, позволяет протестировать продукт более тщательно. Наиболее важные функции можно протестировать в нескольких итерациях. Обучение и улучшение Разработчики могут обучаться по мере продвижения работы, и различные умения и специализации более полно используются в течение всего жизненного цикла. Тестеры, вместо длительного ожидания, в течение которого они только строят планы и оттачивают свои навыки, начинают выполнять тестирование раньше, раньше начинается создание технической документации и так далее. При оценке ранних итераций можно обнаружить необходимость в дополнительном обучении или помощи извне. Также можно улучшить сам процесс. Оценка в конце итерации не только дает обзор состояния проекта с точки зрения планирования продукта, но также позволяет проанализировать, что необходимо изменить в организации и проекте для улучшения работы в следующей итерации. Увеличение возможностей повторного применения Итерационный жизненный цикл облегчает повторное применение. Облегчается идентификация стандартных компонентов, если они разрабатываются или реализуются по-отдельности, по сравнению с идентификацией всей общности. Идентификация и разработка многоразовых компонентов является сложной задачей. Обзоры проекта в ранних итерациях позволяют архитекторам программного обеспечения обнаружить возможность потенциального повторного применения, и в последующих итерациях они могут далее разрабатывать и развивать этот стандартный исходный код. Применение итерационного подхода облегчает использование преимуществ коммерческих готовых продуктов. На протяжении нескольких итераций можно выбрать такие продукты, интегрировать их и убедиться, что они соответствуют данной архитектуре. 13. Влияние характеристик организации (структура, культурные нормы, базы знаний и т.д.) при реализации проекта. Ключевые положения влияния организационной структуры компании. Влияние организации на управление проектами Организационная культура, стиль и структура влияют на то, как выполняются проекты. Степень полноты управления проектами организации и ее системы управления проектами также могут оказывать влияние на проект. Если в проект вовлечены сторонние организации в рамках совместного предприятия или партнерства, на проект будут оказывать влияние несколько предприятий. Организационная культура и стили Культура и стили обычно называются «культурными нормами». «Нормы» включают общие знания о том, как подходить к выполнению работы, какие средства считаются приемлемыми для выполнения работы и кто имеет решающее влияние в содействии выполнению работы. Большинство организаций разработали уникальную культуру, которая проявляется различными способами, включая, среди прочего: • общие взгляды, ценности, нормы, убеждения и ожидания; • правила, методы и процедуры; • взгляд на взаимоотношения руководства; и • рабочую этику и часы работы. Организационная культура представляет собой фактор среды предприятия. Следовательно, менеджер проекта должен понимать различные организационные стили и культуры, которые могут оказывать влияние на проект. Например, в некоторых случаях лицо, указанное во главе организационной структуры, на практике может являться лишь номинальным главой, не имеющим фактических полномочий. Менеджер проекта должен знать, кто из сотрудников организации принимает решения, и сотрудничать с ними для содействия успеху проекта. Организационные коммуникации Успех управления проектами в организации в значительной степени зависит от результативного стиля организационных коммуникаций, особенно в свете глобализации профессии управления проектами. Возможности организационных коммуникаций оказывают огромное влияние на то, как выполняются проекты. Как следствие, руководители проектов, находящиеся на расстоянии, способны наладить более результативные коммуникации с соответствующими заинтересованными сторонами внутри организационной структуры с целью содействия принятию решений. Заинтересованные стороны и члены команды проекта также могут использовать электронные средства связи (включая электронную почту, текстовые, мгновенные сообщения, социальные сети, видео- и веб-конференции и другие электронные средства коммуникации) для формального и неформального общения с руководителем проекта. Активы процессов организации Активы процессов организации включают все без исключения активы, относящиеся к процессам, во всех организациях, участвующих в проекте, которые могут быть использованы для оказания влияния на успех проекта. Эти активы процесса включают формальные и неформальные планы, правила, процедуры и приказы. Кроме того, активы процесса включают базы знаний организации, такие как накопленные знания и историческая информация. Активы процессов организации могут включать выполненные сроки, данные о рисках и данные о заработанной стоимости. Обновление и дополнение активов процессов организации по мере необходимости на протяжении проекта, как правило, является обязанностью членов команды проекта. Активы процессов организации могут быть разбиты на две категории: Процессы и процедуры Процессы и процедуры организации для проведения работ включают, среди прочего: • организационные стандартные процессы, такие как стандарты, правила (например, политика безопасности и охраны здоровья, правила этики и политика управления проектом), стандартные жизненные циклы продуктов и проектов, а также правила и процедуры контроля качества (например, проверки технологических процессов, целевые объекты усовершенствования, контрольные списки и описания типовых процессов для использования в организации); • типовые приказы, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения; • шаблоны (например, риск, иерархическая структура работ, сетевая диаграмма проекта и шаблоны договоров); • приказы и критерии для подгонки набора стандартных процессов организации с целью удовлетворения конкретных потребностей проекта; • требования организации к обмену информацией (например, имеющаяся конкретная технология связи, допустимые среды передачи данных, политика сохранения записей и требования по безопасности); • приказы или требования к завершению проекта (например, окончательные проверки проекта, оценки проекта, подтверждения продуктов и критерии приемки); • процедуры финансового контроля (например, отчетность по времени, необходимый анализ расходов и трат, коды бухгалтерского учета и стандартные положения договоров); • процедуры управления открытыми вопросами и дефектами, определяющие средства контроля над открытыми вопросами и дефектами, выявление и разрешение открытых вопросов и дефектов, а также отслеживание мероприятий; • процедуры управления изменениями, включающие действия, согласно которым будут модифицироваться официальные стандарты компании, политики, планы и процедуры или любые проектные документы, а также порядок одобрения и утверждения любых изменений; • процедуры управления рисками, включая категории рисков, определение вероятности и последствия, а также матрицу вероятности и последствий; и • процедуры расстановки приоритетов, утверждения и выдачи разрешений на выполнение работ. Корпоративная база знаний Корпоративная база знаний организации для хранения и извлечения информации включает, среди прочего: • базы данных измерений процессов, используемые для сбора и обеспечения доступа к данным измерений по процессам и продуктам; • файлы проекта (например, содержание, стоимость, сроки, а также базовые планы обеспечения качества, базовые планы исполнения, календари проектов, сетевые диаграммы проектов, реестры рисков, запланированные мероприятия по реагированию и определенные последствия рисков); • историческая информация и базы накопленных знаний (например, записи и документы проекта, вся информация и документация по завершению проекта, информация о результатах решений по отбору предыдущих проектов наряду с информацией о выполнении предыдущих проектов, а также информация о трудоемкости управления рисками); • базы данных по управлению открытыми вопросами и дефектами, содержащие сведения о статусе открытых вопросов и дефектов, информацию об управлении, данные о разрешении открытых вопросов и дефектов, а также результаты проведенных мероприятий; • базы знаний по управлению конфигурацией, содержащие версии и базовые планы по всем официальным стандартам компании, политикам, процедурам и любым проектным документам; и • финансовые базы данных, содержащие такую информацию, как данные о человеко-часах, понесенных затратах, бюджете и любом перерасходе средств по проекту. Факторы среды предприятия Факторы среды предприятия — условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Факторы среды предприятия считаются входами для большинства процессов планирования, могут расширить или ограничить возможности управления проектом, а также положительно или отрицательно сказаться на результате. Факторы среды предприятия широко различаются по типу или характеру. Факторы среды предприятия включают в себя, среди прочего: • организационную культуру, структуру и руководство; • географическое распределение оборудования и ресурсов; • государственные и промышленные стандарты (например, предписания контролирующих органов, кодексы поведения, стандарты на продукцию, стандарты качества, стандарты изготовления); • инфраструктуру (например, существующие сооружения и основное оборудование); • имеющиеся человеческие ресурсы (например, навыки, знания, специализации, такие как проектирование, разработка, юридические вопросы, заключение договоров и закупки); • управление персоналом (например, руководящие указания по приему на работу и увольнению, анализ эффективности и результативности работы и записи об обучении персонала, политика вознаграждений и сверхурочной работы, а также учет рабочего времени); • корпоративная система авторизации работ; • ситуация на рынке; • толерантность к риску заинтересованных сторон; • политический климат; • каналы коммуникаций, принятые в организации; • коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков); • информационная система управления проектами (например, автоматизированные системы, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распределения информации или веб-интерфейсы к другим автоматизированным системам, работающим в режиме онлайн). Структура организации и её влияние на процесс управления проектами Под организационной структурой обычно понимается совокупность элементов организации (должностей и структурных подразделений) и связей между ними. Идеальных организационных структур управления проектами не существует, однако есть несколько базовых типов включения проекта в вышестоящую организацию: функциональная структура, проектная структура, матричная структура. Функциональная структура. Самой распространенной структурой в России на сегодняшний день является функциональная структура , представляющая собой иерархию, в которой для каждого служащего четко определён один вышестоящий руководитель. При этом сотрудники сгруппированы по специальностям: маркетинг, производство, закупки и т.п. Такая структура оптимальна для хорошо налаженного циклического производства, однако вызывает ряд трудностей при выполнении проектов. Основным недостатком при реализации проектов является её неповоротливость, так как все распоряжения любой сотрудник может получать только от своего функционального руководителя, что вызывает длительные задержки при принятии решений. Такая структура может успешно использоваться в том случае, когда проекты носят рутинный типовой характер, а также в случае, если проекты выполняются в рамках функциональных подразделений. Проектная структура организации отдаёт предпочтение проектам. Каждый сотрудник организации прикреплён к какому-то одному проекту. Такая структура эффективна в крупных проектах продолжительностью более 2 лет, а после завершения проекта команда проекта может потерять работу. Матричная структура организации – это синтез функциональной и проектной структур. В этом случае персонал подотчётен и руководителю отдела, и руководителю проекта. Применяются несколько типов матричных структур, которые различаются соотношением в них функционального и проектного принципов управления: • слабая; • сбалансированная; • сильная. Слабая матричная структура фактически представляет собой функциональную структуру с той лишь разницей, что функции по координации проекта передаются одному из членов команды проекта. Все полномочия по-прежнему остаются в руках функциональных руководителей. Сбалансированная матричная структура представляет собой баланс полномочий между руководителем проекта и руководителем функционального отдела Сильная матричная структура предполагает в дополнение к существующим функциональным подразделениям образование отдела менеджеров проекта. Сотрудники этого подразделения заняты исключительно руководством вверенных им проектов. При этом менеджер проекта обладает значительными полномочиями по управлению ресурсами в проекте. Матричная структура нацелена на конкретный проект, который должен быть выполнен к определенному сроку в пределах установленной сметы расходов. Такая структура обычно появляется при наличии повторяющихся задач, требующих использования сходных ресурсов. Матричная структура способна обеспечить гибкость и инновационность при дальнейшем усложнении технологий, но может оказаться для организации затратной, т.е. двойные полномочия требуют дополнительного администрирования и увеличения накладных расходов. Каждый тип структуры проекта имеет свои плюсы и свои минусы. Используя критерии выбора организационной структуры, можно подобрать тип организационной структуры, наиболее подходящий для данного проекта (табл. 1). Вопрос выбора структуры стоит только перед теми организациями, которые занимаются проектной деятельностью. Для организаций с циклическим и регулярным бизнесом идеально подходит матричная структура, что подтверждает многолетний опыт ее использования подавляющим большинством организаций во всем мире. Таблица 1 Выбор организационной структуры проекта Критерий выбора Структура проекта Функциональная Матричная Проектная Уровень неопределенности Низкий Средний Высокий Технология Типовая Сложная Инновационная Комплексность Низкая Средняя Высокая Продолжительность Малая Средняя Большая Значение для компании Малое Среднее Ключевое Уровень взаимосвязей между частями проекта Низкий Средний Высокий Важность фактора времени (наличие критических сроков) Низкая Средняя Высокая Зависимость от вышестоящей организации Высокая Средняя Низкая Таким образом, организационная структура является наиболее важным механизмом управления проектом. Она дает возможность реализовать всю совокупность функций, процессов и операций, необходимых для достижения поставленных перед проектом целей. Библиографический список к Лекции №2 (Тема 1): 1. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 2. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. 3. Итерационная разработка [Электронный ресурс] URL: http://dit.isuct.ru/Publish_RUP/core.base_rup/guidances/supportingmaterials/develop_iteratively_1F6AE780.html (дата обращения 22.08.2016) 4. Управление проектом разработки информационной системы [Электронный ресурс] URL: http://sergeeva-i.narod.ru/inform/page12.htm (дата обращения 22.08.2016)