Управление проектом по Информационным Технологиям

Управление проектом по Информационным Технологиям
В качестве первого шага мы рекомендуем создание специальной команды в администрации, чья
единственная задача будет состоять в направлении данного проекта к успешной реализации.
Специальная команда должна включать в себя следующих лиц:

Один руководящий работник департамента, вовлеченного в работу – частичная занятость

Один сотрудник департамента, вовлеченного в работу – полная занятость

Один руководящий работник департамента по ИТ – частичная занятость

Два сотрудника департамента по ИТ – полная занятость
Работа данной команды будет включать в себя, кроме прочего, следующее:

Проверку/пересмотр архитектуры системы

Проведение полной и детальной инвентаризации имеющегося у организации, компьютерного
и телекоммуникационного оборудования

Проверку/пересмотр функциональных спецификаций и доработка указанных спецификаций до
уровня детальных функциональных спецификаций

Выявить те офисы, которым понадобится больше, или более современное компьютерное или
телекоммуникационное оборудование с тем, чтобы оно соответствовало минимальным
требованиям рассматриваемой системы

Выявить те подразделения организации, которые готовы провести экспериментальное
тестирование системы

Выявить бенефициаров, готовых сотрудничать при проведении тестирования системы

Выработать методологию сотрудничества с разработчиком системы, основанную на методе
качественного управления проектом, краткое описание которого приведено ниже в данном
отчете

Активно участвовать в регулярных собраниях руководства проектом

Организовать соответствующее распространение информации о пользе проекта по всей
организации

Содействовать в приготовлении бета тестирования (первое внедрение в реальной среде)

Организовывать обучение для бета тестирования

Готовить образовательный материал для полного внедрения системы

Разрабатывать план для полного внедрения

Организовывать телефонные центры для горячих линий (см. ниже)

Организовывать текущее руководство системы
Команда разработчиков будет сформирована из представителей специализированной компанииразработчика программных приложений. Они определят свой гонорар на основе предполагаемого
количества человеко-часов, требуемого для выполнения данной работы. Поэтому важно, чтобы они
могли рассчитывать на полное сотрудничество со стороны специальной команды с тем, чтобы не
было задержек в получении одобрений и утверждений по конкретным ситуациям и элементам,
которые в любом случае возникнут в реализации данного проекта.
Мы рекомендуем чрезвычайной строгий подход к работе специальной команды на основе следующей
методологии. Заказчик потребует от разработчика системы, применения похожей методологии
контроля за качеством проекта.
Руководство проектом и контроль качества
Проекты по ИТ могут управляться различными способами. Однако все доказавшие свою
состоятельность системы имеют общую основу – четко определенную методологию.
В основном, четкое определение требований пользователя, регулярная корректировка работы,
выполняемой командой проекта, и постоянное выполнение поставленных задач позволяет выявлять
потенциальные отклонения от плана на наиболее ранней стадии реализации рассматриваемой
задачи. Четко определенные и за документированные требования по качеству ускоряют реализацию
каждой стадии проекта.
A.
Методология
Рекомендуемая нами методология в основном направлена на:
*
создание ясной и четкой схемы взаимоотношений между временным подразделением или
командой специалистов путем четкого определения функциональной структуры
*
установление стандартов терминологии, структуры процедур и документации для управления
проектом
*
увеличение шансов на успешную реализацию проекта путем обеспечения соответствия
требованиям администрации и бюджетного планирования
*
обеспечение прозрачности и контроля за текущими результатами проекта
Методология управления проектом должна быть основана на следующих принципах:
1.
разделение проекта:
с тем, чтобы упростить имеющуюся проблему следует разделить ее на несколько небольших частей,
имеющих наименьшее количество взаимосвязей.
Результатом этого должна стать иерархическая структура (дерево), состоящая из проектов/под
проектов/ стадий и промежуточных результатов/ задач/ мероприятий.
2.
Разделение проекта на стадии:
каждый этап проекта имеет четко определенную и неизменную последовательность стадий
реализации:
3.
*
определение требований
*
представление проекта
*
функциональная спецификация
*
анализ
*
дизайн
*
внедрение
*
тестирование дизайна
*
тестирование анализа
*
интеграция
*
приемка
*
тестирование на месте эксплуатации
*
поддержка при запуске
*
завершение проекта
*
техническая поддержка
стандарты качества:
стандарты качества относятся как к самому продукту, так и к процессу разработки. Будут выработаны
коды и документация, что потребует работы по поддержанию этих результатов. Процесс разработки
должен учитывать задержки и бюджет.
4.
подлежащие выполнению задачи:
каждый этап проекта должен давать результат. Результат выполняемой на этой стадии работы
становится спецификацией или вкладом в следующий этап.
Требуемые результаты проекта либо должны быть «барьерами проекта», а это означает, что они
потребуют утверждения получателя, либо «внутренними результатами», т.е. внутренними
документами проекта.
5.
контроль качества:
чем позднее будет выявлена проблема, тем больше она увеличит задержки и расходы, связанные с
такой корректировкой.
Контроль качества должен осуществляться на всех стадиях проекта с тем, чтобы выявлять проблемы
ранних стадиях. Каждый результат должен быть тщательно проработан перед тем, как запустить его
на следующей стадии.
В связи с тем, что стадии проекта последовательны, ошибки допущенные на одной стадии
автоматически создают ошибки в последующей работе. Поэтому, сертификация качества каждого
результата проекта по определению является одним из барьеров, которые предстоит пройти проекту.
Контроль за результатами проекта в промежутке между определением задач и стадией тестирования,
легализацией, происходит на различных стадиях проекта.
B.
Документация
Зачастую разработчики считают, что подготовка проектной документации это именно то мероприятие,
которое может быть отложено в случае сжатых сроков. Однако именно документация помогает
поддерживать контроль за проектом и предотвращает передачи большого объема работы на период
поддержки системы.
С тем, чтобы предотвратить потенциальные проблемы план проекта должен предусматривать время
на создание документации и ни одна стадия проекта не должна считаться завершенной до тех пор,
пока не будет подготовлена соответствующая документация.
C.
Проверки
Проверка является критичной оценкой результатов. Обычно она выполняется группой лиц, и поэтому
такие результаты должны предоставляться им заблаговременно.
Три типа лиц (минимально) должны входить в такую команду: один или более представителей
администрации специальной команды, старший специалист команды разработчиков и специалист,
ответственный за обеспечение качества проекта.
Задача проверки состоит в выявлении всех дефектов рассматриваемого результата, иногда команда
может предложить авторам пути исправления выявленных ошибок, но само исправление должно
быть обязанностью автора.
Каждая проверка должны завершаться отчетом, включающим список неразрешенных дефектов и
решений, принятых в ходе совещания.
Время, распределенное на проверки, должно быть занесено в план проекта; общее планирование
должно содержать дополнительное время на тот случай, если понадобится исправить какие-либо
серьезные дефекты полученного результата.
D.
Отклонения
Отклонения от стандартов и процедур могут быть разрешены только в том случае, если подобное
отклонение было аргументировано и утверждено администрацией команды разработчиков (запрос на
утверждение отклонений от заданных стандартов и процедур).
E.
Проектная документация
Кроме результатов, достигаемых проектом, он так же создает ряд важных документов.
Важно, чтобы администрация и команда разработчиков внедрила систему контроля
документооборота, позволяющую контролировать различные версии документации и обеспечивать их
неизменность без получения соответствующего полного утверждения.
Контроль документооборота позволяет идентифицировать всю проектную документацию и
результаты проекта, код будет показывать статус (проект документа или утвержденный документ), как
и номер версии.
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
Требования
пользователя
Завершение
проекта
Требуемый
результат
Легализация/ утверждение
Представление
проекта
Требуемый
результат
Требуемый
результат
Общее
определение
проекта
Функциональная
спецификация
Требуемый
результат
Тестирование
Включение
Требуемый
результат
Анализ
Дизайн
Требуемый
результат
Приемка
Требуемый
результат
Интеграция
Требуемый
результат
Требуемый
результат
Внедрение
Тестирован
ие анализа
Тестирование
дизайна
Требуемый
результат
Требуемый
результат
Требуемый
результат
Контроль за результатами между определением проекта и этапом тестирования, утверждением,
происходит на различных этапах проекта.
Левая половина диаграммы (“V”) показывает этапы определения решений во всех подробностях.
Правая половина диаграммы (“V”) показывает этапы работы от подробного описания до глобального
решения.
Подготовка представления системы.
Все люди в определенной мере противостоят каким-либо изменениям. Только когда
они убеждены в полезности этих изменений, их противодействие снижается, либо оно
даже превращается в активную поддержку.
Успех данного проекта среди многих прочих факторов, зависит от отношения
бенефициаров и работников администрации.
Как только будут утверждены функциональные спецификации системы, специальная
команда должна начать информационную программу для бенефициаров и работников
администрации в национальном масштабе. Данная программа должна быть создана
приблизительно в течение периода, который был определен для полной разработки
системы.
Обучение
Качество, интенсивность и сроки обучения всех этих лиц станет определяющим
фактором гладкого внедрения системы и успеха проекта.
Для обучения управляющих мы предлагаем разработать программу обучения – гид на
компакт диске. Данная программа должна начинаться с серий специальных сообщений,
подчеркивающих полезность различных функций системы для бенефициаров. Уроки
использования системы должны быть максимально простыми и привлекательными с
тем, чтобы включать в себя стимул для прохождения полного цикла обучения.
Обучение персонала администрации может быть организовано на основе обучения
работников тем специалистом, который был обучен на предыдущем этапе (‘train the
trainer’ method). По крайней мере, в каждом МТО должен быть специалист прошедший
интенсивный курс, обучающий пользоваться системой. Он/она в дальнейшем должны
обучать специалистов своего региона и стать местным центром поддержки системы
для отдаленных офисов администрации.
Как только специальная команда будет иметь четкий календарный план и методику
прогрессивной реализации системы, она должна будет создать подробный график
обучения.