Реализация проекта строительства что это

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

По этому при планировании проекта Заказчик И исполнитель должны совместно найти ответы на следующие вопросы :

1. Цели проекта.

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

Примеры типовых целей проекта Вы можете увидеть на сайте компании в разделе «Корпоративное внедрение»

2. Ключевые результаты проекта

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

Локальные очистные сооружения ЦБК КАМА: от проекта до реализации

Очень важно получить ответ на вопросы: “А как мы определим, что проект закончился?; Что будет являться критерием успешности проекта?” Желательно разложить проект на составляющие и по каждой части определить методику оценки результативности, а также документ, которым будет производиться формальное закрытие результатов:

Пример :

Работа

Результат

Документ

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

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

Проток установки ПП

3. Технология внедрения.

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

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

4. Роли и силы участников проекта.

Определите, кто влияет на проект. От кого зависит результаты проекта? Найдите те результаты, которые будут интересны этим людям. Включите их в проект. Закрепите их ответственность (Приказ по предприятию).

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

5. Работы, сроки и последовательность

Определите перечень работ, которые обходимо выполнить для обеспечения достижения нужных результатов. Определите их последовательность. Закрепите их в виде план-графика. Назначьте ответственных за каждую работу. Определите контрольные вехи, по которым будет производить анализ контроль хода.

6. Границы проекта

Как реализоваться в сфере строительства? Алексей Ляльков, руководитель проектов компании «Донстрой»

Важно правильно и полно определить границы проекта – рамки проекта.

Ограничения — факторы, которые лимитируют возможности планирования команды.

Пример :

• Работы будут производиться только в рабочее время
• Будет производиться обучение только 20 пользователей

Предположения — факторы, от которых производится планирование

Пример:

• Заказчик обеспечивает необходимое время у ключевых сотрудников для выполнение работ по проекту

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

П ример :

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

7. Коммуникации

Очень важный пункт, особенно ест проект очень большой и участвует более 3-4 участников в команде. Важно определить, как будет производиться обмен информацией между участниками (когда, в какой форме: отчеты, совещания).

8. Риски проекта

Необходимо составить перечень причин (рисков), по которым проект может, не состояться – Карта рисков.

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

Пример карты рисков :

Риск

Стратегия управления риском

Уход членов проектной команды до конца Проекта

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

Изменения структуры Заказчика, и/или методов ведения бизнеса

При принятии решений по изменениям в компании руководство будет принимать во внимание влияние этих изменений на ресурсоемкость и сроки Проекта

Не соответствие квалификации пользователей требуемой для работы в системе

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

Возможность саботажа сотрудников

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

Не соответствие компьютеров техническим требованиям

Заказчик знаком с техническими требованиями к аппаратному обеспечению

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

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

Запуск, накладывание управляющих контуров.

Заказчик при разработке организационных изменении учитывает реализацию их в типовой системе

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

Ответственность заказчика. Заказчик или принимает меры по привлечению дополнительных сил или

Управляющий комитет принимает решение о пересмотре всего устава проекта изменения сроков и бюджета

9. Управление требованиями

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

Регламент исправления ошибок при тестировании разработанного модуля:

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

Руководитель проекта Исполнителя должен регулярно просматривать задачи и определять время их решения.

10. Формализуйте. Закрепите всё выше перечисленное в виде специального документа (Устав проекта, соглашение о проекте)

2. Основные этапы внедрения информационной системы

ОБСЛЕДОВАНИЕ .

Цель этапа:

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

Выполняемые работы:

• Интервьюирование руководства компании, руководителей подразделений и ключевых сотрудников.
• Описание структуры компании, учетной политики и укрупненных бизнес-процессов «как есть».
• Фиксация основных требований к ИС со стороны Заказчика, цели и задачи автоматизации
• Фиксация методологии ведения учета.

В случае внедрения несложных типовых решений достаточно провести анкетирование – экспресс — обследование.

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

Результат этапа:

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

Устав проекта – документ, описывающий цели внедрения, состав ИС, бюджет, сроки реализации проекта, требования к Эксплуатации ИС, риски проекта.

ПРОЕКТИРОВАНИЕ .

Цель этапа:

Ознакомить сотрудников предприятия с функционалом типового программного продукта. Сопоставить программный продукт и бизнес-процессы компании. Подготовить и согласовать список функциональных требований к будущей ИС. Описать изменяемые/добавляемые бизнес-процессы. Определить объем необходимых доработок и/или изменений в бизнес-процессах Заказчика.

Выполняемые работы:

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

На данном этапе важно определить, как и кем будет проверяться, и сдаваться работа по адаптации ИС. Один из способов прогон на контрольном примере.

Результат этапа:

«Техническое задание – документ, описывающий перечень необходимых доработок системы, согласно требований Заказчика и порядок их приема и тестирования.

Уточненный документ «План проекта»- в части сроков, бюджета, рисков и требований.

РЕАЛИЗАЦИЯ .

Цель этапа:

Максимально настроить ИС под специфику работы Заказчика в соответствии с «Техническим заданием». Подготовить ИС к опытной эксплуатации.

Выполняемые работы:

• Доработка ИС – конфигурирование согласно ТЗ
• Подготовка к началу опытной эксплуатации
• Разработка руководства по эксплуатации Разработка регламента переноса начальных остатков и обработок по переносу начальных остатков (в случае, если это необходимо).

Результат этапа:

• Программный продукт настроенный и протестированный в соответствии с «Техническим заданием».
• ПО, установленное на рабочих местах пользователей, готовое к началу опытной эксплуатации Системы
• Руководства пользователей
• Регламент по переносу начальных остатков и обработки по переносу начальных остатков.

ТЕСТИРОВАНИЕ .

Цель этапа:

Проверить соответствие ИС требованиям и ожиданиям Заказчика. Кроме того, на этом этапе уточняется/утверждается дата ввода в эксплуатацию ИС.

Выполняемые работы:

• Тестирование системы.
• Исправление недостатков работы системы Исполнителем на основании тестирования.

Результат этапа:

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

ВВОД В ЭКСПЛУАТАЦИЮ .

Цель этапа: обучение конечных пользователей и запуск ИС в эксплуатацию.

Выполняемые работы:

• Обучение пользователей
• ПереносВвод остатков
• Организация запуска
• Пост пусковое сопровождение (методическое консультирование)
• Закрытие проекта

Результат этапа: ИС, принята Заказчиком, запущенна в эксплуатацию, проект передан на сопровождение.

Источник: www.soft-servis.ru

Способ доставки проекта — Project delivery method

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

Общие методы реализации проекта включают:

Design-Bid-Build (DBB) или Design-Award-Build (DAB)

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

DBB с управлением строительством (DBB с CM)

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

Design-Build (DB) или Design-Construct (DC)

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

Дизайн-Построение-Эксплуатация-Обслуживание (DBOM)

DBOM ​​делает DB еще один шаг вперед, включая операции и обслуживание завершенного проекта в один и тот же исходный контракт.

Комплексная реализация проекта (IPD)

Комплексная реализация проекта стремится вовлечь всех участников (людей, системы, бизнес-структуры и практики) на всех этапах проектирования, изготовления и строительства с целью повышения эффективности проекта и сокращения «отходов» при его реализации (т.е. любых процессов, которые напрямую не добавляют ценность для конечного продукта). [1] [2] [3] IPD тесно связан с философией Бережливое строительство.

Контракт наряд-заказ (JOC)

Форма комплексной реализации проекта (IPD), специально предназначенная для ремонта, обновления, технического обслуживания, устойчивого развития и «небольшого» нового строительства. В каждом контракте на заказ на выполнение работ используется книга расценок за единицу продукции для определения цены каждой работы в рамках многолетнего зонтичного контракта.

Государственно-частное партнерство (ГЧП, 3P или P3)

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

Строительство-Финанс (BF)

Частный субъект строит объект и финансирует его стоимость в течение периода строительства, после чего ответственность передается государственному предприятию. С точки зрения риска и вовлеченности частного сектора эта модель снова находится в нижней части спектра для обеих мер. [4]

Сборка-работа-передача (BOT)

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

Сборка — владение — эксплуатация — передача (BOOT)

Структура BOOT отличается от BOT тем, что частное лицо владеет работами. В течение периода концессии частная компания владеет и управляет объектом с основной целью возместить затраты на капиталовложения и техническое обслуживание, одновременно пытаясь добиться более высокой маржи по проекту. BOOT использовался в таких проектах, как автомагистрали, дороги общественного транспорта, железнодорожный транспорт и производство электроэнергии. [5]

Строить – владеть – эксплуатировать (BOO)

В проекте BOO право собственности на проект обычно остается за проектной компанией, например, сеть мобильной связи. Таким образом, частная компания получает преимущества любого остаточная стоимость проекта. Эта структура используется, когда физическая жизнь проекта совпадает с периодом концессии. Схема BOO включает в себя большие объемы финансов и длинные Период окупаемости. Некоторые примеры проектов BOO относятся к водоочистным сооружениям. [6]

Строительство – аренда – передача (BLT)

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

Дизайн-Строительство-Финансирование-Обслуживание (DBFM)

«Частный сектор проектирует, строит и финансирует активы, а также предоставляет услуги по управлению и техническому обслуживанию оборудования в соответствии с долгосрочным соглашением». Владелец (обычно государственный сектор) управляет объектом. Эта модель находится в середине спектра рисков и вовлеченности частного сектора. [4]

Дизайн-строительство-финансирование-обслуживание-эксплуатация (DBFMO)

Дизайн – строительство – финансирование – эксплуатация — это метод реализации проекта, очень похожий на BOOT, за исключением того, что здесь нет фактической передачи прав собственности. Более того, подрядчик принимает на себя риск финансирования до конца срока действия контракта. Затем владелец берет на себя ответственность за техническое обслуживание и эксплуатацию.

Эта модель широко используется в конкретных инфраструктурных проектах, таких как платные дороги. Частная строительная компания отвечает за проектирование и строительство объекта инфраструктуры для государства, которое является истинным владельцем. Более того, частное предприятие несет ответственность за привлечение финансирования в период строительства и эксплуатации. [7] Обычно государственный сектор начинает выплаты частному сектору за использование актива после завершения строительства. Это наиболее часто используемая модель в Европа по данным Европейской Счетной палаты. [8]

Проектирование – сборка – эксплуатация – передача (ДБОТ)

Этот вариант финансирования распространен, когда клиент не знает, что влечет за собой проект. Поэтому он заключает контракт с компанией на проектирование, строительство, эксплуатацию, а затем передает его. Примеры таких проектов — строительство НПЗ. [9]

Дизайн – строительство – управление – финансирование (DCMF)

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

Тенденции в распространенности способов доставки

Хотя DBB в настоящее время используется для большинства частных проектов и большинства государственных проектов, исторически он не был основным методом выбора. В мастера-строители прошлых веков выступали как проектировщики и конструкторы как для государственных, так и для частных клиентов. в Соединенные Штаты, Почтовый тракт Зейна в Огайо и IRT в Нью-Йорк оба изначально были разработаны с использованием более интегрированных методов реализации, как и большинство инфраструктурных проектов до 1933 года. Комплексная реализация проекта предлагает новый метод реализации, позволяющий удалить значительные отходы в процессе строительства при одновременном повышении качества и возвращении к более совместным методам из прошлого. Стремясь помочь профессионалам отрасли в выборе подходящей системы реализации проекта, исследователи в области управления строительством подготовили метод закупок и модель выбора контракта, которые можно использовать для принятия решений на высоком уровне по строительным проектам в каждом конкретном случае. [10]

Концептуальные различия между способами доставки

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

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

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

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

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

Источник: wikidea.ru

Реализация проекта – один шаг за один раз

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

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

Одна из таких методик заключается в следующем: делать один шаг за один раз.

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

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

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

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

В результате в процессе завершения проекта не будет «финишных рывков». Не будет коренных изменений и перестроек системы. Будет лишь спокойное завершение последних элементов и введение их в производство.

Как этот принцип можно использовать для более мелких по объему задач? Что бы вы ни начинали делать, будь то проект или отдельная задача, подумайте над тем, как разделить ее на небольшие этапы, которые бы соответствовали следующим критериям:

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

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

Но это не всегда определяющий фактор.

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

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

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

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

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

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

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

Источник: habr.com

Технологии внедрения и управления проектом

Процессы реализации проектов имеют схожий алгоритм, известный нам из свода знаний по управлению проектами (PMBoK ─ Project Management Body Of Knowledge). Однако 100% следование стандартам не всегда целесообразно: они могут не соответствовать масштабам и типам проектов и не вписаться в корпоративную культуру той или иной организации.

Общая схема работы над проектом

Реализация проекта состоит из нескольких этапов:

• Инициация
• Планирование
• Исполнение
• Мониторинг
• Завершение

Это и есть жизненный цикл проекта.

Для каждого этапа характерны свои активности:

• Планирование графика работ, ресурсов, бюджета, рисков
• Постановка задач
• Контроль качества
• Управление коммуникацией
• Управление закупкой
• Формирование отчетности

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

В таком случае коммуникации происходят через ответственных за выполнение определенных задач или вех проекта.

В крупных рабочих группах складывается своя уникальная культура – правила, обычаи, модели поведения.

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

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

Для диагностики необходимо:

• Сопоставить планы внедрения с имеющимися наработками
• Составить перечень проблем и причин провалов проектов
• Сформировать оргструктуру проектного офиса
• Подготовить перечень критериев успешности проектов
• Составить перечень программного обеспечения, которое используется в проектном управлении

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

Как должен работать настроенный процесс проектного управления «От цели к результатам»

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

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

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

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

В системе ADVANTA большинство процессов управления проектами происходит автоматически. Не тратьте время на составление таблиц и отчетов. Принимайте решения на основании оперативных данных.

Кроме того, наша компания проводит экспресс-диагностику системы управления проектами, которая включает:

1. Описание текущего состояния системы УП
2. Перечень выявленных зон развития
3. Рекомендации для обоснования инвестиций в развитие системы
4. Конкретные рекомендации для организации основных процессов и получения первых результатов:
5. Запуск проекта
6. Определение плана
7. Регулярный мониторинг выполнения
8. Принятие решений и управление изменениями
9. Передача результата
10. Готовый план краткосрочного и долгосрочного развития проектного управления

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

Источник: www.advanta-group.ru

Разработка графика реализации проекта. Часть 5

Данная статья – пятая часть одной большой статьи по Управлению Проектами. Чтобы начать читать статью с самого начала, пожалуйста, перейдите по этой ссылке .

1. Как определить необходимые ресурсы для задач?
2. Что такое вехи проекта?
3. Понимание критического пути
4. Понимание критической цепи
5. Как сократить график проекта?
6. Базовая линия проекта

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

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

Поскольку у каждой задачи есть начало и конец, существует четыре типа зависимостей задач:

1. Зависимости между концом и началом являются наиболее распространенными. Завершение одной задачи контролирует, когда запускается другая.
2. Призависимости от начала к началу запуск одной задачи инициирует запуск другой.
3. Зависимость «От конца до конца» означает, что завершение одной задачи контролирует завершение другой.
4. Зависимости между началом и концом встречаются не очень часто. Это хорошо, потому что они могут сбить вас с толку. Начало одной задачи приводит к завершению другой. Таким образом, в этом случае контролируемая задача возникает после той, которую она контролирует.

Вы можете выяснить, какой тип зависимостей использовать, задав несколько вопросов:

• Какая задача контролирует другую? Это говорит вам, какая задача является первой в цепочке зависимостей.
• Дата начала или окончания первой задачи контролирует вторую задачу? Это определяет, начинается ли зависимость с начала или конца.
• Управляет ли первое задание началом или завершением второго задания? Это определяет, является ли вторая половина зависимости началом или концом.

Как определить необходимые ресурсы для задач?

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

Давайте посмотрим, как задачи меняются из-за назначения ресурсов. Продолжительность – это промежуток времени между началом задачи и ее окончанием. Работа, также называемая усилием – это количество часов или дней, когда кто-то работает над задачей. Если у вас будет больше или меньше людей, чем вы запланировали, продолжительность вашей задачи изменится. Посмотрим, как это работает.

Предположим, вы подсчитали, что на установку оборудования конференц-центра у пяти человек уйдет четыре дня. Это восемь часов в день на человека, а значит 40 рабочих часов в день в течение четырех дней, или 160 рабочих часов. Что случится, если вы получите только четыре человека? Сколько времени займет задание?

Теперь команда из четырех человек может работать только 32 часа каждый день. Если вы поделите 160 часов на количество часов в день, то есть 32, вы получите новую продолжительность в пять дней. Работа остается прежней, но продолжительность задачи варьируется. Тот же расчет применяется, если кто-то переключается на работу на полставки вместо полной. Поскольку вы делите объем работы на половину количества часов в день, задача займет вдвое больше времени.

С другой стороны, если вы получаете больше людей, продолжительность задачи уменьшается. Скажем, поставщик оборудования может дать вам восемь человек. Тот же самый объем 160 часов, команда из восьми человек работает 64 часа в день. Если вы разделите 160 часов на 64, ваша новая продолжительность составит два с половиной дня.

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

Когда назначенные ресурсы доступны, это также влияет на время выполнения работы. Например, в вашем графике указано, что установка оборудования начнется 9 февраля. Однако IТ-компания завершает другой проект, и команда не будет доступна до 18 февраля. Это означает, что вы должны отложить эту задачу в своем графике, чтобы отразить в нем, когда ресурсы доступны. Когда вы назначаете ресурсы для задач, вы, наконец, получаете четкое представление о том, когда в вашем проекте происходит работа.

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

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

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

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

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

Понимание критического пути

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

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

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

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

Например, какая-то конкретная задача может начаться уже 3 октября и завершиться 14 октября. Поздний старт и позднее окончание – это самые поздние возможные даты, когда задача может начинаться и заканчиваться, без задержки последующих задач. Даты позднего старта и окончания – 24 ноября и 7 декабря соответственно. Это означает, что задача имеет несколько недель, поэтому она не находится на критическом пути, а значит, имеет провисание. С другой стороны, если ранние и поздние даты совпадают, тогда эта задача не имеет провисания.

Понимание критической цепи

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

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

Как сократить график проекта?

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

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

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

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

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

Применение метода сбоя на критическом пути

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

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

Источник: www.your-mentor.ru