2. Поведение

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

3. Дальнейшие действия

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

Обязательно в протоколе должны быть подписи сторон и дата встречи.

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

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

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

В этом случае у него пропадает желание манипулировать исполнителем.

Планирование проекта

На этой стадии определяются цели проекта и подход к области его применения, качество работ, их срокам и стоимости.

План управления проектом

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

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

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

1. Вспомогательные планы (планы управления) :

1. Содержанием проекта

2. Расписанием проекта

3. Стоимостью проекта

Транш – это определенная доля от общей суммы платежа, часть платежной суммы.

4. Качеством проекта

5. Обеспечение персоналом

6. Коммуникацией проекта

7. Рисками проекта

8. План управления конфигурацией проекта

2. Базовая линия проекта, состоящая из

1. Базового расписания проекта

2. Базового плана по стоимости

3. Базового плана по качеству

4. Базового плана по конфигурации

5. Реестра рисков

3. Результатов анализа, проведенного проектной командой в отношении содержания, объема и сроков проектов.

Формирование иерархической структуры проекта

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

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

Существует два способа разработки ИСП – «сверху вниз и снизу вверх».

Подход «сверху вниз» (от общего к частному) включает :

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

2. Выбор типа ИСП. Хороший пример такого типа структурирования ИСР-проект разработки программного обеспечения, состоящий из таких фаз, как:

• Определение требований

• Высокоуровневое проектирование

• Низкоуровневое проектирование

• Написание кода

• Тестирование

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

Критические факторы успеха

1. Наличие спонсора из числа высшего руководства компании

2. Компетентный состав команды

3. Межфункциональная координация

4. Обеспечение «умного» реинжиниринга бизнес-процесса

5. Привлечение конечных пользователей

6. Принятие системы сотрудниками

7. Мотивация сотрудников и членов проектной команды

8. Продуманные стратегии коммуникаций

9. Обеспечение обучения и тренингов

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

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

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

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

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

6. Позволяют в короткие сроки получить запланированный эффект от ее внедрения и следовательно сократить срок окупаемости проекта. (принятые системы пользователями)

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

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

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

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

Владелец процесса.

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

Владелец процесса имеет право:

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

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

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

4. Разрабатывать и вносить изменения в документацию проекта.

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

Основная обязанность ВП – контроль за результатом процесса.

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

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

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

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

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

Персонал ВЗАИМООТНОШЕНИЯ «ИСПОЛНИТЕЛЬ - ЗАКАЗЧИК»

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

Также проект может выполняться командой из представителей Исполнителя и Заказчика проекта.

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

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

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

Предполагается, что договор должен быть подписан до начала осуществления проекта.

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

Все эти аспекты взаимоотношений «Исполнитель—Заказчик» надо иметь в виду в процессе управления проектом.