Итоговая работа по программе профессиональной переподготовки MINI-MBA Professional Тема: Использование принципов эффективного управления проектами на практике.
Руководитель: Шмайлов Александр «10» февраля 2014 г. Выполнил: студент группы М3-16РМ Калиев Ержан « 05 » февраля 2014 г.
Москва 2014 г.
Содержание 1 2 3 4 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11. 4.12. 5 5.1. 5.2. 5.3. 5.4. 5.5. 6 6.1. 6.2. 6.3. 6.4. 7 7.1. 7.2. 7.3. 7.4. 7.5. 7.6.
Введение Сокращения и обозначения Общие положения Технические компетенции Успешность управления проектом Заинтересованные стороны Требования и задачи проекта Проектный риск и возможности Качество Проектная организация Работы команды Разрешение проблем Структуры проекта Время и фазы проекта Затраты и финансы Закрытие проекта Поведенческие компетенции Лидерство Самоконтроль Открытость Ориентация на результат Переговоры Контекстуальные компетенции Управление персоналом Здоровье, безопасность, охрана труда и окружающая среда Финансы Юридические аспекты Заключение Приложения Приложение А - WBS Приложение Б - OBS Приложение В - Календарный план Приложение Г - Журнал рисков Приложение Д - Матрица ответственности Приложение Е - План управления качеством 2
Стр. 3 4 5 7 7 8 9 10 11 12 13 14 15 16 18 19 20 20 21 22 23 24 25 25 26 27 28 29 30 30 32 33 35 37 38
1. Введение В данной итоговой работе я постараюсь раскрыть тему эффективного управления проектами, основываясь на примере из собственной практики. Приведу примеры использованных в проекте технических, поведенческих и контекстуальных компетенции, которые, по моему мнению, обеспечили эффективное управление данным проектом. Предыстория проекта: Программисты ТОО Центр автоматизации "Жетысу" в 2007 году по замыслу
Директора
начали
разрабатывать
новую
медицинскую
информационную систему «Жетысу». В 2008 году началось внедрение и автоматизация городских и районных больниц Алматинской области Республики Казахстан. За эти годы были дополнены, существенно модернизированы и отработаны многие модули информационной системы «Жетысу» под лечебные заведения Алматинской области. 24 февраля 2009 года в Комитете по правам интеллектуальной собственности
Министерства
юстиции
Республики
Казахстан
был
зарегистрирован объект интеллектуальной собственности под названием «Медицинская информационная система Жетысу» автором, которого является программист компании Центра автоматизации "Жетысу" - Харлов В.В. В апреле 2012г. Главный врач Областного Кардиологического центра совместно с коллегией, приняли решение о внедрении Медицинской информационной системы Жетысу в Областном Кардиологическом центре для создания единого информационного пространства для ключевых подразделений, административно-управленческого и медицинского персонала Кардиологического центра, что в свою очередь позволит повысить эффективность управления лечебно-диагностическим процессом.
3
2. Сокращения и обозначения Использованные в настоящем документе термины и сокращения трактуются следующим образом: МИС Жетысу - Медицинская информационная система Жетысу ЛПУ – Лечебно профилактическое учреждение АРМ – Автоматизированное рабочее место Заказчик- Областной Кардиологический Центр(ОКЦ) Исполнитель – ТОО «Центр автоматизации Жетысу» ИСР – Иерархическая структура работ(WBS) ТЗ – Техническое задание ПП – Программный продукт
4
3. Общие положения 3.1. Название проекта «Внедрение Медицинской информационной системы в Областном Кардиологическом центре». 3.2. Заказчик проекта: ГКП на ПХВ «Областной кардиологический центр» ГУ «Управления здравоохранения Алматинской области» акимата Алматинской области», 3.3. Исполнитель проекта: ТОО «Центр автоматизации Жетысу». 3.4. Миссия проекта: «Способствовать построению надежной и эффективной системы управления в Кардиологическом центре путем внедрения современных информационных технологии» 3.5. Цель проекта: Внедрить Медицинскую информационную систему «Жетысу» в Областном Кардиологическом Центре до конца 2012 года, общей стоимостью 15 000 000 тенге. 3.6. Срок проведения проекта: Общий период проведения с 23.04.2012г по 31.12.2012г. включительно. 3.7. Задачи проекта: 3.7.1. Разработка плана управления проектом 3.7.2. Разработка Технического задания 3.7.3. Установка необходимого программного обеспечения 3.7.4. Настройка программы МИС Жетысу 3.7.5. Создание базы данных 3.7.6. Тестирование программного продукта 3.7.7. Обучение программе медицинского персонала ОКЦ 3.7.8. Передача МИС Жетысу в эксплуатацию 3.7.9. Закрытие проекта.
5
3.8. Ожидаемые показатели результатов по Проекту: 3.8.1. Анализ накопленных данных и формирование любых отчетов может выполняться в реальном масштабе времени за любой период. 3.8.2. Уменьшение затрат рабочего времени при работе с медицинской документацией до 60%. 3.8.3. Уменьшение до 20% затрат на закупку медикаментов за счет персонифицированного учета медикаментов 3.8.4. У заведующего отделением, главного врача и специалистов по организации
здравоохранения
появляется
возможность
получения количественных оценок качества работы конкретного врача или подразделения.
6
4.
Технические компетенции
4.1. Успешность управления проектом Я считаю, что одним из самых важных частей проекта является его планирование. Именно поэтому реализацию данного проекта, после Инициации со стороны Заказчика и моего назначения на должность Руководителя проекта, я начал с планирования, разработал Устав проекта, на основании него разработал план управления проектом, и, после нескольких изменений и дополнений он был принят и одобрен Заказчиком и моим Руководством. На протяжении всего жизненного пути проекта, данный план был пересмотрен и изменен еще не один раз благодаря контролю и мониторингу по всем пунктам данного плана, а также за счет выполнения отчетов перед Заказчиком по вехам данного плана. Все изменения были задокументированы и подписаны всеми заинтересованными сторонами. Так как был заложен резерв на непредвиденные расходы 15% от бюджета проекта, по срокам реализации проекта 12%, за рамки выделенных средств и требовании по срокам проект не вышел. «Проект успешен, если выполнен согласно утвержденным критериям: объему, сроку, качеству». Данный проект по этим критериям может считаться успешным, так как Договор был подписан, исполнен и закрыт в срок, бюджет не был превышен, а Заказчик был доволен нашей работой и работой информационной системы. Судя по результатам анкетирования пользователей программы, последние также были довольны результатом внедрения, так как одно из преимуществ использования МИС - время на выполнение рутинных работ (как заполнение истории болезни) сокращалось более чем вдвое, так как во многом используются уже готовые шаблоны.
7
4.2. Заинтересованные стороны Вначале я идентифицировал всех заинтересованных лиц, имеющих отношение к проекту, и занес их в такого вида реестр: Название Проекта: «Внедрение Медицинской информационной системы в Областном Кардиологическом центре». Руководитель проекта: Калиев Е.Ж. Таблица 1 – Реестр заинтересованных лиц ID
Ф.И.О.
Роль
в Должность
проекте st-
Аканов
Пользова-
1
А.А.
тель
хируг
Отделение/
Конт.
Предпочитае-
отдел
информация
мый вид связи
Кардио
Тел,
Эл. почта
хирургия
Далее я сформировал из ключевых сотрудников компании, а также из тех, кто определенно будет работать над этим проектом, команду экспертов для участия в мозговом штурме, где каждый участник в течении 5-10 минут фиксировал на бумаге все предполагаемые ожидания заинтересованных сторон, по итогам которой я смог идентифицировать ожидания всех заинтересованных сторон с их точки зрения, задавая такие вопросы как: Каково Ваше ожидания от проекта (будь я Главным врачом, Пользователем МИС и т.д.)? Какую пользу Вы приобретете от успешного завершения проекта? И т.п. Такого рода вопросы позволили провести анализ по
ожиданиям
заинтересованных участников. Проанализировав
их
интересы
и
требования,
я
сообщил
всем
заинтересованным сторонам какие из требований будут выполнены, а какие нет. Также я разработал план по управлению заинтересованных сторон, в котором, среди прочих, был план коммуникации заинтересованных сторон и стратегия их взаимодействии.
8
По окончании каждой фазы проекта, я предоставлял информацию в виде отчета о ходе проекта всем заинтересованным участникам по выполненным задачам, чтобы удостоверится об их удовлетворении результатами фаз проекта. 4.3. Требования и задачи проекта После определения конкретные,
всех задокументированных ожиданий, наиболее
измеримые
и
подлежащие
оценке
ожидания
были
преобразованы в требования проекта, и после оценки данных требований, некоторые из них были включены в текущий план проекта как задачи. Далее я разработал матрицу требований, которая была связана с реестром заинтересованных лиц по ID: Таблица 2 – Реестр заинтересованных лиц ID
st-1
Главные
Главные
Влияние на Отношение к Комментарий
ожидания
требования
проект
проекту
Упрощение
Безбумажный
Среднее +
Сторонник
ввода/вывода
вид работы
Заинтересован в проекте.
информации st-2
После утверждения данных требований Заказчиком, необходимо было приступить к определению содержания проекта, разработке Иерархической структуры работ и Технического задания. На стадии инициации были определены
некоторые
задачи,
которые
после
определения
всех
задокументированных требовании, были пересмотрены, была проведена оценка задач и анализ их осуществимости. В итоге были определены следующие основные задачи проекта: 1. Разработка Технического задания 2. Установка Программного обеспечения.
9
3. Создание базы данных на сервере. 4. Тестирование МИС Жетысу. 5. Обучение медицинского персонала. 6. Ввод в эксплуатацию МИС Жетысу. 7. Передача МИС Жетысу на техническое сопровождение. 8. Завершение проекта. 4.4. Проектный риск и возможности Возможные
риски,
связанные
с
данным
проектом,
начали
формироваться с той поры, как поступило предложение о внедрении МИС Жетысу в ОКЦ и не прекращались до самого завершения проекта, так как по опыту, если управлять рисками грамотно на протяжении всего проекта, это может сэкономить существенное время и деньги проекта, а реализованный риск может открыть для компании новые перспективы и показать неиспользуемые ранее возможности. Для идентифицирования всевозможных рисков я привлек команду экспертов со своей компании и, после мозгового штурма, каждый участник зафиксировал на бумаге все риски, которые по его мнению, могли произойти в ходе реализации проекта. Все данные были озвучены, оценены и были определены их последствия. Для более удобного управления рисками все данные были внесены в Журнал рисков (См. Приложение В) Для себя я понял, что очень важно не только определять всевозможные риски проекта, но и оценивать их влияние на результаты процесса, задачи и всего проекта, а также своевременно принимать решения об уменьшении рисков, реализовывать управление ими во всех фазах жизненного цикла проекта. Также необходимо контролировать план ответного реагирования на риски и возможности.
10
4.5. Качество Я считаю, что качество во всех процессах, на всем жизненном пути проекта имеет большое значение, как для текущего проекта, так и для всех будущих проектов и качество необходимо повышать с каждым проектом, для чего я использую концепцию Джозефа Джурана. Для разработки плана управления качеством в данном проекте (см. Приложение Е) я использовал такие входные данные как план управления проекта и Техническое задание, где прописал критерий приемки работ (Выше требований, соответствует требованиям, ниже требовании). При наборе команды проекта я разработал матрицу ответственности, где назначил ответственного за каждое задание, так как вопросами качества должна заниматься вся команда. В данном проекте я использовал цикл Деминга- PDCA(Plan, Do, Check, Act), сначала планировал, потом выполнял, затем проверял и действовал. Если же на стадии проверки качество работ меня не устраивало, круг начинался заново. На стадии обучения пользователей, цикл Деминга был многократно применен внедренцами проекта, и это оказалось нашей слабой стороной, так как увеличивало срок проекта, вследствие чего я вынес для себя решение о переобучении внедренцев новым методам обучения. Я считаю, что качество не может состояться без контроля со стороны Руководителя и соответствия требованиям конечного пользователя, поэтому я составлял еженедельные отчеты о состоянии проекта, и требовал краткие отчеты по существу от команды проекта, которые содержали ответы на следующие вопросы: А) Выполненные задачи на прошлой неделе. Б) Задачи, которые требуются выполнить на следующей неделе. Все задачи были внесены в матрицу Эйзенхауэра, и решались в порядке важности и срочности.
11
4.6. Проектная организация При реализации такого рода проектов как внедрение, наша компания использует матричную структуру управления проектом (См. Приложение Б). Главный недостаток такой структуры, это то, что участники проекта, иногда не могут определить, кому же они подчиняются, своему руководителю отдела или мне. В данном проекте данная проблема решилась благодаря тому, что я согласовал стратегический план с руководителями отделов, и совместно с ними мы расстановили приоритеты по задачам и ресурсам. Контроль осуществлялся мной с помощью руководителей отделов, при этом я согласовал с руководством компании и руководителями отделов, что выделенные сотрудники для проекта, не могли привлекаться к иным работам без согласования со мной. Но в такой структуре был риск того, что могла появиться возможность внесения
изменении
в
программу,
а
так
как
сотрудники
отдела
программирования были постоянно перегружены, то проект мог быть не завершен в срок. Риск я минимизировал с помощью подробно составленного технического задания. Для успешной реализации данного проекта, я определил участников команды проекта и разработал матрицу ответственности команды, расписал их роли и ответственности в проекте, а также точки их взаимодействии методом RACI (см. Приложение Д)
12
4.7. Работа команды Для выполнения работ по данному проекту не требовалось привлечения сторонних человеческих ресурсов, так как в организации имелись требуемые квалифицированные сотрудники, у которых было достаточно свободного времени для привлечения на данный проект. Для формирования команды из 7 сотрудников, один из которых был со стороны Заказчика, я использовал целеполагающий подход, разъяснил им основные цели, задачи проекта и ясные критерии достижения успеха. Далее я приступил к распределению ролей с помощью матрицы ответственности. Своих сотрудников я изучил достаточно хорошо в предыдущих аналогичных проектах, и по концепции доктора Р.М. Белбина, среди них был я, как председатель, были генераторы идей, рабочие пчелки, критик и опора команды. В ходе реализации проекта выяснилось, что сотрудник со стороны Заказчика по этой концепции подходил на роль критика, что было удобно для меня, так как он, сам того не зная, давал оценку качества работ по проекту, а я, на основании этого, анализировал и принимал соответствующие решения. Сотрудники
нашей
организации
были
нацелены
на
достижение
общекомандных целей и ориентированы на собственное профессиональное развитие, поэтому тип формы управления я избрал Демократический. Мотивация для команды была достаточно интересной – в пределах 5% от общей суммы проекта, разделенная по трудозатратам, при достижении цели проекта в срок, в укладывании в бюджет и в достижении всех критерии качества. И это не считая меня, так как моя денежная мотивация была отдельной. К сожалению, в этом проекте не обошлось без конфликтов среди команды, произошел конфликт горизонтальный, межличностный, диструктивный, что привело к снижению эффективности работ. После изучения и оценки данного конфликта, я сумел его устранить, воспользовавшись стилем сотрудничества.
13
4.8. Разрешение проблем Из опыта работ по различным проектам, путь от постановки целей до завершения проекта, заключается в решении задач и преодолении возникающих проблем, этот проект не был исключением. Данный проект помог понять, что любая проблема, возникшая в ходе реализации проекта, это личная проблема Руководителя проекта, так как он ответственен за всѐ в проекте. Найденное решение, это внедрение эффективной системы по управлению проблемами. Всѐ нужно записывать и сохранять: разговоры, переговоры, переписки и так далее, пусть лучше стол будет завален бумагами, а электронный ящик забит всякими предложениями и идеями, и искать готовое решение среди них, чем сидеть и думать над возникшими проблемами. Также для себя я вынес, что Мозговой штурм является очень действенным методом получения ответов на вопросы, в том числе и возникших проблем. А если проблем много? Тогда нужно найти ту ключевую проблему, которая может не находиться на поверхности, она подобна дереву с корнями, а найдя причину можно уже решить проблему и как правило в этой причине скрывается и решение. В этом случае очень эффективен Метод поиска ключевой проблемы, когда пишутся все причины данной проблемы и устанавливается связь между ними, и та причина, к которой ведут все связи, в итоге оказывается ключевой причиной/причинами, а решив их, можно решить и саму проблему.
14
4.9. Структуры проекта В данном проекте я разработал следующие структуры: 4.9.1. Иерархическая структура работ (Приложение А) 4.9.2. Организационная структура проекта (Приложение Б) 4.9.3. Структура команды проекта 4.9.4. Матрица ответственности (Приложение Д) 4.9.5. Структура затрат 4.9.6. Календарный план (Приложение В) 4.9.7. План управления качеством (Приложение Е) После разработки ИСР, я подготовил сжатую презентацию содержания работ и ИСР по проекту для презентации Заказчику, с целью получения задокументированного утверждения на продолжение работ. Также данная презентация была призвана выявить недопонимания и скрытые цели между Исполнителем и Заказчиком, которые могут привести к изменениям содержания проекта после того, как работа уже начнется. После определения конечного результата проекта и основного пакета работ, были внесены все необходимые изменения в содержание проекта. Полностью структуры работ приведены в Приложениях к данному отчету.
15
4.10.
Время и фазы проекта Вначале я определил все ключевые задачи, которые необходимо
исполнить для получения результатов, определенных в Иерархической структуре работ. Далее я задокументировал связи между операциями проекта с видом зависимости «Финиш - Старт», после чего команда проекта произвела оценку ресурсов собранных данных на основе аналогов проекта, предположении и реальной цены за данный проект методом мозгового штурма. Теперь мне предстояло оценить длительность каждого задания. Основываясь на данных из предыдущих аналогичных проектов, я определил критический путь проекта, который составлял 147 рабочих дней. В то же время каждый проект отличается от других проектов, с которыми сталкивалось наше подразделение раньше, так как известно, что непредвиденные события (болезни, стихийные бедствия, забастовки, производственные аварии, текучесть кадров и т.п) могут происходить, но нельзя точно предсказать их появление при реализации конкретного проекта или задания. Тем не менее, их нужно как-то учитывать, и я оценил длительность заданий, используя метод PERT: 1. Оптимистическое время выполнения (О) - 147 рабочих дней 2. Пессимистическое время выполнения (Р) – 169 рабочих дней 3. Наиболее вероятное время выполнения (М) - 155 рабочих дней По формуле: (Р + 4М + О) 6 По методу PERT, продолжительность проекта составляет – 156 рабочих дня. Резерв времени составлял 30 календарных дней, и даже при пессимистическом времени выполнения я должен был завершить проект в срок.
16
А при необходимости, я мог прибегнуть к методу сжатия, чтобы обеспечить своевременное завершение проекта. Календарный план проекта, приведен в Приложении В Нижеприведенный отчет по вехам показал, что отклонений по плану на 07.07.2012г не было.
ОТЧЕТ ПО ВЕХАМ
ОТ 07.07.2012Г
24.04.12 01.05.12 08.05.12 15.05.12 22.05.12 29.05.12 05.06.12 12.06.12 19.06.12 26.06.12 03.07.12 10.07.12 17.07.12 24.07.12 31.07.12 07.08.12 14.08.12 21.08.12 28.08.12 04.09.12 11.09.12 18.09.12 25.09.12 02.10.12 09.10.12 16.10.12 23.10.12 30.10.12 06.11.12 13.11.12
60 50 40 30 20 10 0
Оставшиеся задачи
ВЕХИ С ЗАДЕРЖКОЙ
Просроченные вехи
Оставшиеся фактические задачи
СЛЕДУЮЩИЕ ВЕХИ
ЗАВЕРШЕННЫЕ ВЕХИ
Вехи со сроком в этом месяце. Вехи, завершенные на 100%.
17
4.11.
Затраты и финансы
На стадии Инициации я сделал сметное предположение стоимости проекта и оценил весь проект приблизительно в 15 000 000 тенге, в том числе был заложен резерв на случай непредвиденных расходов в размере 15%. После того как были просчитаны стоимости всех задач по методу «снизувверх» т.е. по стоимости и срокам длительности задач, согласно календарного плана, был составлен Бюджет по завершению(BAC), который составил: 12 550 000 + 1 882 500 (резерв 15%) = 14 432 500 тенге. В данную стоимость проекта были включены все текущие расходы проекта, а также планируемые дополнительные пункты, такие как расходы на дорогу, на содержание офиса, заработная плата сотрудников и т.п. Также был составлен и задокументирован план по изменениям, согласно которому, в случае изменения программного обеспечения или добавления новых требований, соответственно будет изменена стоимость и срок завершения проекта. Благодаря структуре затрат в программе 1С:Бухгалтерский Учет, я отслеживал каждое движение денег касающееся этого проекта, анализировал и оценивал на соответствие плана по затратам. Контракт был заключен с 30% предоплатой, остальная сумма рассчитывалась по завершении фаз проекта, этих денег было достаточно на все текущие требуемые расходы по проекту.
18
4.12.
Закрытие проекта
Проект, завершился успешно, вид завершения проекта - Продолжение. Наша команда уложилась в требуемый срок, выделенный бюджет был полностью освоен, качеством работ и самого программного продукта пользователи, в общем, были довольны. Программу МИС Жетысу начали использовать пользователи, для которых она была разработана. В анкетах пользователей в основном были положительные отзывы. Передача программы Заказчику состоялась. После чего состоялся небольшой банкет на котором команда проекта получила свой бонус за успешную работу. На этом проектная команда, кроме меня, была распущена в свои структурные подразделения. Я оставался на должности Руководителя проекта, но уже на новом проекте «Техническое сопровождение МИС Жетысу в ОКЦ», с новой командой проекта. Данный договор был закрыт и был открыт новый договор на техническое сопровождение. Акты оказания услуг были подписаны обеими сторонами и формально проект теперь можно было считать закрытым.
19
5.
Поведенческие компетенции 5.1. Лидерство
Для меня очень близко следующее выражение Уинстона Черчилля «Чтобы влиять на других, лидер должен быть искренним. Прежде чем вдохновлять других, он должен сам пережить эти эмоции. Чтобы другие рыдали, он должен заплакать сам. Чтобы убедить других, он сам должен поверить». В данном проекте, я придерживался демократического стиля руководства в соответствии с квалификацией команды, в которых я был уверен. Решения принимались коллегиально, но окончательное решение всегда оставалось за мной. Инициативу со стороны своих сотрудников я стараюсь всегда поддержать, так как это может повлечь за собой новое, более эффективное решение, которое мы могли внедрить в данном, либо последующих проектах. К объективной критике со стороны окружающих отношусь положительно, воспринимая критику как способ улучшения своих личных и профессиональных качеств, этому стараюсь учить и своих подчиненных. Так как я уже раньше работал с этой командой, я знал, что лучшая для них мотивация, это денежное вознаграждение по результатам работы, знали это и они, поэтому каждый стремился к эффективному выполнению поставленных задач. Проблема появилась, когда в команду пришел работник, системный администратор со стороны Заказчика, и если в работе со своей командой я использовал управленческую роль лидера, то со вновь прибывшим, я использовал роль «надсмотрщика», контролируя выполнения всех задании, так как от результата работы каждого в команде зависел успех всего проекта.
20
5.2. Самоконтроль По типу темперамента я - флегматик, поэтому от природы я спокоен, могу контролировать свои эмоции, положительно реагирую на критику, при стрессовых ситуациях либо во время кризиса, когда все вокруг шумят и орут, я могу сохранять спокойствие, анализировать и принимать правильные решения. Перед тем, как сформировать данную команду, я провел опросник среди предполагаемых работников по методике В.В.Бойко, для определения уровня эмоционального выгорания, в итоге, одного предполагаемого работника среди внедренцев пришлось заменить на менее квалифицированного, но зато без «синдрома эмоционального выгорания». Для проверки уровня стресса в команде, а также для установки более тесных взаимоотношении в команде, мы обычно вместе обедали, и так как вся команда была почти одинакового возраста, мы позволяли себе открыто разговаривать и шутить друг с другом на различные темы, в том числе и о проблемах на работе. В результате чего, я для себя выяснил, что лучшее определение будущих возможных проблем и рисков для проекта дают именно такие посиделки с дискуссиями и активным слушанием, а не многочасовые разборки и совещания. Также я стараюсь всегда разделять работу и личную жизнь, к этому веду и своих подчиненных, стремлюсь, чтобы они, как и я, находили баланс, не забывали о личной жизни и в то же время не пренебрегали своей работой.
21
5.3. Открытость Принцип открытости приветствуется в нашей компании и лично мной, так как открытостью можно предотвратить некоторые проблемы до начала еѐ наступления. И если взять данный проект, то некоторые из участников команды, а именно программисты и внедренцы, в своих сферах деятельности имеют больший опыт, нежели я, и при реализации проекта именно их знания и опыт в определенной ситуации могли помочь мне. Поэтому я только приветствую и стараюсь приобщить открытую форму общения, когда команда может открыто делиться своими решениями или возникающими проблемами и при этом стараюсь чтобы каждый член команды, вне зависимости от должности и квалификации, знал о том, что он и его информация была услышана и оценена по заслугам. При этом конфиденциальные сведения, о которых должны знать только те, для кого они созданы, по моему мнению, разглашать никто не имеет права.
22
5.4. Ориентация на результат Так как Заказчик платит не за действия во время проекта, а за достижения результатов, по завершении каждой фазы проекта я старался сосредотачивать внимание команды проекта, на результат пройденной и предстоящей задачи, а также на общий результат проекта. Во время инициации проекта были определены требования и ожидания Заказчика, по которым были определены задачи и результат каждой задачи, а также сроки их исполнения, которые я разделил между командой проекта с помощью матрицы ответственности, по следующим уровням: R – Ответственный, А – подотчетный, С – консультации, I – информирование, на каждую задачу были определены один подотчетный и один ответственный, а так как руководитель проекта ответственен за всѐ в проекте, в матрице ответственности меня нет. Также, согласно вехам проекта, Заказчик был постоянно в курсе дел продвижения по проекту. Во время идентифицирования всех ожидании клиента, я не поставил в известность Заказчика о некоторых выгодных преимуществах данного ПО, таких например как, предстоящая экономия бумаг для ОКЦ до 80% , МИС предоставляет возможность перехода на безбумажный вид работ для ЛПУ, а потому по завершении проекта, главврач и пользователи ПО были довольны результатами внедрения.
23
5.5. Переговоры Переговоры, это неотъемлемая часть любого проекта, на котором достигаются или не достигаются различного рода соглашения, данный проект не был исключением, и переговоры заняли достаточно много времени. Именно по результатам первичных переговоров Заказчик принял решение о начале запуска проекта в целом, а в последующих переговорах были определены цели, задачи, ограничения, предварительный бюджет и так далее, то есть все составляющие Устава проекта. Первичные переговоры носили только презентационный характер, Заказчик изучал нас как возможных исполнителей его идеи. Стратегия переговоров отличалась от предыдущих аналогичных проектов, так как главврач был в курсе об IT индустрии Казахстана и осведомлен об аналогичных продуктах, соответственно у него был выбор исполнителя. Так как именно первичные переговоры решали, быть проекту или нет, я подготовил стратегию ведения первичных переговоров, которые включали в себя: - подробный анализ оппонента; - план ведения переговоров; - использование тактических приемов на основе интересов. Способ ведения переговоров был выбран принципиальный, место проведения переговоров - у Заказчика, с возможностью демонстрации продукта на проекторе. Так как было известно, что Заказчик был настроен доброжелательно по отношению к нам, я сначала предоставлял слабые аргументы, такие как программа формирует все отчеты по установленным стандартам и т.д. а в конце переговоров выдвинул сильные аргументы, такие как уменьшение затрат рабочего времени при работе с медицинской документацией до 60%, снабдив примером из другой организации.
24
6.
Контекстуальные компетенции 6.1.
Управление персоналом
Несомненно, что управление персоналом занимает важное место в Управлении проектами, ведь от эффективности команды, в конечном счете, зависит как качество реализации проекта, так и его результат. В данном проекте были задействованы как внутренние сотрудники организации, так и работник со стороны Заказчика, но все были подчинены Руководителю проекта. При разработке календарного плана проекта я определил потребности в количестве и качестве сотрудников, а также время их фактического использования в проекте. В нашей компании развито профессиональное развитие сотрудников и данный проект не исключение. Я применил метод наставничества по отношению к работнику Заказчика, но прежде я попросил его пройти тест оценки личности Майерса-Бриггса, по итогам которой выяснилось, что он экстраверт, сенсорного типа, в принятии решении чувствующий тип и воспринимающий тип в образе жизни. Удобство данного проекта проявилось в месторасположении Заказчика, оно находилось буквально в 5 минутах ходьбы от офиса компании, что позволило оптимально использовать рабочее время членов команды. Для повышения мотивации, а также ориентации на результат в процессе планирования я привлекал к участию исполнителей задач проекта. После того как проект завершился и команда была распущена в свои линейные отделы, я, а также главврач со стороны Заказчика, дали качественную оценку каждого сотрудника который участвовал в проекте, оценки были разделены по трем направлениям: - оценка квалификации сотрудника (сравнение характеристик с эталоном) - анализ результатов работы (качество выполнения работ) После чего передал результаты оценок с собственными рекомендациями (повышение, обучение, понижение) руководителям отделов.
25
6.2.
Здоровье, безопасность, охрана труда и окружающая среда
Для того чтобы поддерживать уровень знаний по вопросам обеспечения здоровья, безопасности и охраны труда в соответствующих инструкциях для сотрудников прописаны все правила и процедуры. С этой инструкцией был ознакомлен работник со стороны Заказчика в данном проекте. Все выявленные зоны риска были прописаны в инструкции, в которой были определены основные требования по исполнению охраны труда, здоровья и техники безопасности при проведении работ. По вопросу охраны здоровья в данном проекте были прописаны нормы по труду обеспечивающие нормальное выполнение работ без перегрузки. По завершению обучения пользователей, каждому была выдана Инструкция по пользованию, в которой среди прочих содержалась информация по безопасному использованию ПО. В идентификации рисков несколько пунктов содержали возможные угрозы безопасности, в том числе безопасность данных, возможность кражи медицинских данных пациента и так далее, там же были прописаны стратегии их смягчения или предотвращения. Анализ существующего компьютерного парка у Заказчика на стадии инициации показал, что большая часть используемой техники соответствует техническим характеристикам и удовлетворяет требованиям техники безопасности. На основном сервере уже используется предложенная операционная система, конфигурация сервера позволяет говорить о соответствующей производительности и надежности системы, а также о техническом «запасе» для внедрения МИС Жетысу. Анализ локальной сети Заказчика показал, что сеть находиться в удовлетворительном состоянии. Пропускная способность сети 100мб. Существуют свободные гнезда на коммутаторах при необходимости развития сети и соответствует всем требованиям по технике безопасности.
26
6.3.
Финансы
Для расчета стоимости разработки проекта на этапе техникоэкономического обоснования проекта я использовал Методику расчетов трудоемкости и стоимости работ на разработку информационных систем утвержденных приказом Министра связи и информации Республики Казахстан от 2011г. Согласно условиям договора я предоставлял Заказчику ежемесячную, а также по требованию, финансовую отчетность о результатах деятельности, которая включала в себя следующие показатели: AC, SPI, EAC. Руководителю организации предоставлял оценки по методу освоенного объема. На стадии Инициации, когда я сделал предположительную стоимость всего проекта я использовал метод оценки «сверху-вниз», а также оценку по аналогам, по итогам которых предположительная стоимость проекта составила 15 000 000тг. Однако позже, при составлении Бизнес-плана по этому проекту, сумма на основании ИСР, по методу оценки проекта «снизувверх» сумма была скорректирована в сторону уменьшения. Для контроля стоимости проекта, я все время корректировал бюджетный план, основываясь на учете фактических затрат и согласно прогнозу будущих затрат. Для того чтобы узнать отставание от графика, сколько работ выполнено, есть ли отклонения от плана и т.д. я использовал метод освоенного объема, по показателям: EV, AC, PV, по ним я вычислял отклонение по стоимости CV=EV-AC, и если CV>0, то в проекте была экономия, если меньше то перерасход, вычислял отклонения по расписанию SV=EV-PV и SV>0, то было опережение, если меньше 0, то отставание. Для прогноза дальнейшего хода проекта, я использовал показатели индексов выполнения стоимости и расписания, CPI=EV/AC и SPI=EV/PV, а также ETC, EAC и BAC.
27
6.4.
Юридические аспекты
Для определения всех юридических рисков, я привлек к проекту штатного юриста компании, который используя метод аналогов, просчитал все риски связанные с данным проектом. При составлении контракта я руководствовался Законом о государственных закупок, статьи 4, пункта 1, подпункт 25 (приобретение товаров, услуг, являющихся объектами интеллектуальной собственности, у лица, обладающего исключительными правами в отношении приобретаемых товаров, услуг), так как МИС Жетысу является объектом ИС, а наша компания является владельцем данного объекта. Все документы относящиеся к правовым аспектам такие как: Договор, приложения к договору, дополнительные соглашения к договору и т.п., обязательно рецензировались у штатного юриста.
28
Заключение В заключении я бы хотел рассказать о приобретенном опыте в проекте: Основная Цель и главные ожидания по проекту были достигнуты и, благодаря успешности данного проекта, в текущем году запускается аналогичный проект внедрения в Кардиологическом центре другой области. Нашу компанию и разработанную нами МИС порекомендовал главврач ОКЦ, а это уже говорит о качестве проекта. В данном проекте я использовал разные техники, приемы и методы для достижения каких-либо результатов, такие например как: - технику ведения переговоров - мягкий стиль, достижение результата по заинтересованности оппонента; - матрицу Эйзенхауера, для определения и выполнения по срочности и важности дел; - SWOT анализ, для общей оценки проекта на стадии планирования; - метод освоенного объема, который был очень полезен при управлении и контроле стоимости; - метод RACI, при разработке Матрицы ответственности; Все они показали свою результативность и эффективность в управлении, поэтому во всех следующих проектах я планирую только расширять методы эффективного управления проектами.
29
7. Приложения 7.1. WBS Приложение А Название задачи 1. Создание плана проекта 1.1. План проекта у Заказчика утвержден 2. Сбор и анализ требований 3. Разработка технического задания 3.1. Обсуждение ТЗ с Заказчиком 3.2. Корректировка ТЗ 3.3. Согласование ТЗ 3.4. ТЗ у Заказчика утвержден 4. Определение содержания работ. 4.1. Создание иерархической структуры работ(ИСР) 4.2. Описания содержания работ и ИСР у Заказчика утвержден 4.3. Подготовка сжатой презентации 4.4. Презентация описания содержания проекта 4.5. Внесение необходимых изменений в содержание проекта 4.6. Управление планом содержания работ 4.7. Определение конечного результата проекта 4.8. Определение основного пакета работ 5. Создание расписания проекта 5.1. Определение операции 5.2. Определение последовательности операции 5.3. Произвести оценку ресурсов операции 5.4. Произвести оценку длительности операции (PERT) 5.5. Разработка расписания проекта 5.6. Создание календарного плана проекта 5.7. Расписание проекта с Заказчиком согласовано 6. Произвести оценку стоимости проекта 6.1. Определение бюджета проекта 6.2. Условия и порядок оплаты с Заказчиком согласован 7. Планирование качества 7.1. Осуществление обеспечения качества 7.2. Осуществление контроля качества 7.3. Проверка на соответствие стандартам (анализ по аналогам) 7.4. План качества Заказчиком Утвержден 8. Разработка плана управления человеческими ресурсами 8.1. Набор команды проекта 30
8.2. Управление командой проекта 8.3. Разработка организационной структуры проекта 8.4. Разработка матрицы ответственности (метод RACI) 8.5. План управления человеческими ресурсами утвержден 9. Определение заинтересованных сторон 9.1. Планирование коммуникации заинтересованных сторон 9.2. Распределение коммуникации 9.3. Управление ожиданиями заинтересованных сторон 10.Подготовка отчетов об исполнении 10.1. Отчеты об исполнении утверждены Заказчиком 11.Планирование управления рисками 11.1. Идентификация рисков 11.2. Качественный анализ рисков 11.3. Количественный анализ рисков 11.4. Планирование реагирования на риски 11.5. Мониторинг и контроль рисков 11.6. Риски определены 12.Управление по внедрению ПП 12.1. Установка ПП на сервере 12.2. Установка ПП на компьютеры пользователей 12.3. Настройка ПП 12.4. Создание базы данных 12.5. Тестирование ПП 12.6. Тестирование ПП успешно завершена 12.7. Обучение медперсонала 12.8. Медперсонал обучен 13.Управление по завершению внедрения ПП 13.1. Внесение исправлений и изменений 13.2. Ввод МИС Жетысу в эксплуатацию 13.3. Передача МИС Жетысу на техническое сопровождение 13.4. ПП в эксплуатацию передана 13.5. Закрытие внедрения МИС Жетысу 14.Завершение проекта 14.1. Акты сдачи услуг по проекту Сторонами подписаны
31
Приложение Б
7.2. OBS Заказчик
Директор
Руководитель проекта
Системный администратор
Разработчик
Специалист консультант
32
Тестер
Аналитик
Юрист
7.3.
Календарный план проекта
Название задачи Длительность Внедрение МИС Жетысу в ОКЦ 156 дней 1. Создание плана проекта 4 дней 1.1. План проекта у Заказчика утвержден 0 дней 2. Сбор и анализ требований (предпроектное 7 дней обследование) 2. Разработка технического задания 7 дней 2.1. Обсуждение ТЗ с Заказчиком 1 день 2.2. Корректировка ТЗ 5 дней 2.3. Согласование ТЗ 1 день 2.4. ТЗ у Заказчика утвержден 0 дней 3. Определение содержания работ. 8 дней 3.1. Создание иерархической структуры работ(ИСР) 3 дней 3.2. Описания содержания работ и ИСР у Заказчика 0 дней утверждены 3.3. Подготовка сжатой презентации 1 день 3.4. Презентация описания содержания проекта 1 день 3.5. Внесение необходимых изменений в содержание проекта 1 день 3.6. Управление планом содержания работ 2 дней 3.7. Определение конечного результата проекта 1 день 3.8. Определение основного пакета работ 1 день 4. Создание расписания проекта 8 дней 4.1. Определение операции 1 день 4.2. Определение последовательности операции 1 день 4.3. Произвести оценку ресурсов операции 1 день 4.4. Произвести оценку длительности операции (PERT) 1 день 4.5. Разработка расписания проекта 2 дней 4.6. Создание календарного плана проекта 2 дней 4.7. Расписание проекта с Заказчиком согласовано 0 дней 5. Произвести оценку стоимости проекта 3 дней 5.1. Определение бюджета проекта 3 дней 5.2. Условия и порядок оплаты с Заказчиком согласован 0 дней 6. Планирование качества 6 дней 6.1. Осуществление обеспечения качества 3 дней 6.2. Осуществление контроля качества 2 дней 6.3. Проверка на соответствие стандартам (анализ по 1 день аналогам) 6.4. Планирование качества Заказчиком Утверждено 0 дней 7. Разработка плана управления человеческими ресурсами 6 дней 7.1. Набор команды проекта 3 дней 7.2. Управление командой проекта 3 дней 7.3. Разработка организационной структуры проекта 1 день 7.4. Разработка матрицы ответственности (метод RACI) 2 дней 7.5. План управления ЧР утвержден 0 дней 8. Определение заинтересованных сторон 7 дней 8.1. Планирование коммуникации заинтересованных сторон 2 дней 8.2. Распределение коммуникации 3 дней 8.3. Управление ожиданиями заинтересованных сторон 2 дней 9. Подготовка отчетов об исполнении 2 дней 9.1. Отчеты об исполнении утверждены Заказчиком 0 дней
33
Приложение В Начало Пт 27.04.12 Пт 27.04.12 Ср 02.05.12
Окончание Чт 15.11.12 Ср 02.05.12 Ср 02.05.12
Чт 03.05.12 Пт 11.05.12 Пн 14.05.12 Пн 14.05.12 Вт 15.05.12 Вт 22.05.12 Вт 22.05.12 Ср 23.05.12 Ср 23.05.12
Вт 22.05.12 Пн 14.05.12 Пн 21.05.12 Вт 22.05.12 Вт 22.05.12 Пт 01.06.12 Пт 25.05.12
Пн 28.05.12 Ср 30.05.12 Пн 28.05.12 Вт 29.05.12 Ср 30.05.12 Чт 31.05.12 Чт 31.05.12 Пт 01.06.12 Пн 04.06.12 Пн 04.06.12 Вт 05.06.12 Ср 06.06.12 Чт 07.06.12 Пт 08.06.12 Вт 12.06.12 Ср 13.06.12 Ср 04.07.12 Ср 04.07.12 Пт 06.07.12 Пн 09.07.12 Пн 09.07.12 Чт 12.07.12
Пн 28.05.12 Вт 29.05.12 Ср 30.05.12 Пт 01.06.12 Чт 31.05.12 Пт 01.06.12 Ср 13.06.12 Пн 04.06.12 Вт 05.06.12 Ср 06.06.12 Чт 07.06.12 Пн 11.06.12 Ср 13.06.12 Ср 13.06.12 Пт 06.07.12 Пт 06.07.12 Пт 06.07.12 Пн 16.07.12 Ср 11.07.12 Пт 13.07.12
Пн 16.07.12 Пн 16.07.12 Пн 16.07.12 Вт 17.07.12 Вт 17.07.12 Пт 20.07.12 Пт 20.07.12 Пн 23.07.12 Вт 24.07.12 Ср 25.07.12 Ср 25.07.12 Пт 27.07.12 Ср 01.08.12 Пт 03.08.12 Пн 06.08.12
Пн 16.07.12 Вт 24.07.12 Чт 19.07.12 Вт 24.07.12 Пт 20.07.12 Вт 24.07.12 Вт 24.07.12 Чт 02.08.12 Чт 26.07.12 Вт 31.07.12 Чт 02.08.12 Пн 06.08.12 Пн 06.08.12
10. Планирование управления рисками 10.1. Идентификация рисков 10.2. Качественный анализ рисков 10.3. Количественный анализ рисков 10.4. Планирование реагирования на риски 10.5. Мониторинг и контроль рисков 10.6. План управления рисками составлен 11. Управление по внедрению ПП 11.1. Установка ПП на сервере 11.2. Установка ПП на компьютеры пользователей 11.3. Настройка ПП 11.4. Создание базы данных 11.5. Тестирование ПП 11.6. Тестирование ПП успешно завершено 11.7. Обучение медперсонала 11.8. Медперсонал обучен 12. Управление по завершению внедрения ПП 12.1. Внесение исправлений и изменений 12.2. Ввод МИС Жетысу в эксплуатацию 12.3. Передача МИС Жетысу на техническое сопровождение 12.4. ПП в эксплуатацию передан. 12.5. Закрытие внедрения МИС Жетысу 13. Завершение проекта 13.1. Акты сдачи услуг по проекту Сторонами подписаны
34
8 дней 2 дней 2 дней 2 дней 1 день 1 день 0 дней 63 дней 1 день 2 дней 2 дней 3 дней 15 дней 0 дней 40 дней 0 дней 10 дней 5 дней 2 дней
Пн 06.08.12 Вт 07.08.12 Чт 09.08.12 Пн 13.08.12 Ср 15.08.12 Чт 16.08.12 Пн 06.08.12 Пт 17.08.12 Пт 17.08.12 Пн 20.08.12 Ср 22.08.12 Пт 24.08.12 Ср 29.08.12 Вт 04.09.12 Ср 05.09.12 Вт 30.10.12 Пт 30.10.12 Ср 31.10.12 Ср 07.11.12
Чт 16.08.12 Ср 08.08.12 Пт 10.08.12 Вт 14.08.12 Ср 15.08.12 Чт 16.08.12 Пн 06.08.12 Вт 13.11.12 Пт 17.08.12 Вт 21.08.12 Чт 23.08.12 Вт 28.08.12 Вт 04.09.12 Вт 04.09.12 Вт 30.10.12 Вт 30.10.12 Вт 13.11.12 Вт 06.11.12 Чт 08.11.12
2 дней
Пт 09.11.12 Пн 12.11.12
0 дней 1 день 1 день
Пн 12.11.12 Пн 12.11.12 Вт 13.11.12 Вт 13.11.12 Ср 14.11.12 Чт 15.11.12
0 дней
Чт 15.11.12 Чт 15.11.12
7.4. Журнал рисков
Приложение Г 7.4.1. Финансовые риски
Вид риска Ценовой риск
Описание
Меры по снижению риска
Вероятность
Тщательное Средняя исследование тенденций рыночной конъюнктуры на этапе подготовки бюджетной заявки, квалифицированное управление потоком наличности по спецификам соответствующих бюджетных программ Кредитный Заказчик не Соблюдение при Средняя риск выполнил своих заключении договоров обязательств по режима <30%-ной платежам предоплаты, и 100% оплаты по фазам проекта, контроль за выполнением обязательств по платежам. Валютный риск Потери при пересчете Заключение договоров в Низкая валюты контракта на национальной валюте национальную валюту Риск Затруднения с Заключение договоров и Низкая неплатежепогашением подписание актов способности долговых выполненных работ обязательств в силу только при наличии неблагоприятных финансовых разрешений внешних обстоятельств Инфляционный Потери стоимости Проводить постоянный Средняя риск активов (денежных контроль качества средств, аппаратного администрирования и программного бюджетной программы обеспечения) в результате увеличения инфляции
Увеличение оценки проекта
Изменения рыночных цен на приобретаемые услуги
35
~3%
~3%
0%
0%
~3%
7.4.2. Институциональные риски и мероприятия по их снижению Риски Риск того, что Исполнитель не будет определен в результате проведения конкурсных процедур Срыв сроков выполнения вследствие недооценки сложности проекта Риск срыва сроков выполнения работ по вине Заказчика Институциональные риски в общем
Предположения и мероприятия по снижению рисков Риск минимизирован разработкой Технических спецификаций, соответствующих современному уровню развития информационных технологий, существующих стандартов и нормативных документов. Согласование Технических спецификаций с уполномоченным органом. Составить подробное описание автоматизируемых бизнеспроцессов. Заложить резерв времени в план-график. Создать поэтапный план выполнения работ. Риск минимизируется четким отслеживанием результатов по плануграфику и принятием оперативных мер. Минимизация институциональных рисков за счет: разработки и утверждения детального плана-графика работ по проекту; формирования рабочей проектной группы, включающий руководителя со стороны Исполнителя, имеющего достаточные полномочия для принятия решений по проекту, а также квалифицированных специалистов от обеих сторон; периодических (не реже 2-х раз в месяц) совещаний рабочей группы (с обязательным оформлением протоколов), отслеживания прогресса в достижении запланированных результатов по проекту и соответствия плану-графику; анализ причин отставания на ранних этапах и принятия соответствующих мер; оперативные корректировки плана-графика в случае необходимости.
7.4.3. Социальные риски проекта Риски Риск ухода квалифицированного персонала, занятого по проекту Невыплата заработной платы участникам проекта Срыв сроков выполнения вследствие недостаточной компетентностью / профессионализмом членов команды Затруднение дальнейшего сотрудничества с Заказчиком вследствие неудобства использования системы конечными пользователями
Мероприятия по снижению рисков Мероприятия по проекту, направленные на обучение персонала новейшему оборудованию и программному обеспечению, будут способствовать сохранению заинтересованности в работе Строгий контроль за исполнением плана финансирования по платежам Прояснить компетентность членов команды до начала работ. Предусмотреть возможность привлечения сторонних экспертов по каждому этапу работ. Провести опрос пользователей и выяснить их ожидания от системы
36
7.5. Матрица ответственности (RACI) OBS
Приложение Д
Аналитик
Разработчик
Специалист консультант
Тестер
Системный администратор
Юрист
C
I
A
I
C
R
R
C
A
I
I
C
C
R
A
C
C
I
I
C
A
C
R
I
I
C
R
A
C
I
I
C
R
A
C
I
I
A
C
R
C
I
C
I
R
I
A
I
C
R
C
A
I
C
R
I
A
I
C
C
C
I
A
I
R
I
WBS
Разработка методологических документов Разработка технического задания Доработка необходимых документов в ПП Установка программного обеспечения Настройка МИС Жетысу Создание базы данных ЛПУ Тестирование МИС Жетысу Обучение пользователей Внесение исправлений в ПП Презентация МИС Жетысу Техническое сопровождение МИС Жетысу
R – ответственный A – подотчётный C – консультации I – информирование
37
7.6. План управления качеством
№ 1
2 3
Мероприятия Разработка методологических документов Разработка Технического задания Идентификация рисков
4
Установка Программного продукта
5
Тестирование ПП
6
Обучение пользователей
7
Внесение исправлений и замечаний в МИС Жетысу Закрытие проекта
8
Приложение Е
Форма завершения Ответственный Рецензия юриста Аналитик
Дата 01.06.2012
Утвержденное ТЗ у Заказчика Утвержденный План управления рисками Подписанный Акт приемки услуг по установке программного обеспечения со стороны Заказчика Подписанный Акт сдачи приемки испытаний ПП Подписанный акт обучения пользователей Подписанный акт исправления ПП Подписанный акт выполненных работ/услуг со стороны Заказчика
Аналитик
22.05.2012
Аналитик
06.08.2012
Системный администратор
21.08.2012
Тестер
04.10.2012
Специалист консультант
30.10.2012
Разработчик
06.11.2012
Менеджер проекта
15.11.2012
38