Методология внедрения Microsoft Project Server/Online
Довольно часто в нашу компанию «Leo Consulting» обращаются Заказчики с запросами на внедрение «с нуля» Microsoft Project Server во всей его красе и полноте функционале, включая бюджетирование и ресурсное планирование, желая сразу получить максимальный результат от внедрения. Наши предложения о необходимости поэтапного внедрения не всегда находят отклик у Заказчика. Как показывает практика, внедрение у таких Заказчиков либо затягивается на долгие-долгие месяцы – компания (ее сотрудники) не способна сразу переварить такое количество новшеств, либо такое внедрение стоит неоправданно дорого для Заказчика.
В данной статье я поделюсь своим опытом и представлениями о том, что с чего нужно начинать, внедряя Microsoft Project Server, и когда переходить от одного этапа внедрения к другому в зависимости от уровня зрелости компании Заказчика.
Знакомство
Как правило, стандартный запрос на внедрение Microsoft Project Server выглядит следующим образом: приходит письмо с описанием следующих «хотелок» Заказчика:
- Постановка системы управления портфелем проектов;
- Автоматизация системы управления портфелем проектов;
- Автоматизация управления сроками, бюджетами, человеческими и материальными ресурсами в разрезе проектов / портфелей проектов;
- Обеспечение сценарного планирования «что-если» и прогнозирования отклонений в проектах;
- Обеспечение интеграции со сметными программами;
- Формирование и автоматизация аналитической отчётности в разрезе проектов и портфеля проектов; обеспечение возможности присоединять документы к работам в плане и просматривать их в проекте;
- Автоматическое формирование заявок на ресурсы и их согласование по маршрутам (ресурсное планирование).
Вроде бы все здраво. Но есть один нюанс. Заказчик хочет получить «с нуля» все и сразу. Это нормальное желание. Но давайте быть объективными – все и сразу не получится. А чем быстрее, тем дороже, причем в геометрической прогрессии.
Ухаживание
Не буду акцентировать внимание на описании процедур, связанных с переговорами, встречами, техническим заданиям и прочими. Представим, что Заказчик «нулевой» в управлении проектами. Итак, с чего мы начинаем?
Сразу узнаем, какими типами проектов управляет Заказчик. Какие проблемы в компании побудили его искать «счастье» в управлении проектами. Узнаем какие цели ставит Заказчик при внедрении управлении проектами и Microsoft Project. Важно понимать, что на самом деле Заказчику в лице собственников (инвесторов) не нужна система управления проектами как таковая, ему/им необходимо решение проблем компании. Поэтому мы как консультанты стараемся предложить построение такой системы, которая решит (хотя бы частично) его проблемы, по крайней мере, связанные с управлением проектами. А если в результате внедрения рядовые сотрудники Заказчика смогут уходить домой в 18:00*, то это решит и личные проблемы некоторых сотрудников.
Следующие шаг, это определение уровня зрелости компании в целом и ее уровень в управлении проектами, стараемся ощутить моральный дух/настрой сотрудников компании, что очень важно для успешного внедрения. Если в компании царит «организационный хаос» - все бегают туда-сюда, сегодня делают одно, завтра бросают и делают другое, то внедрить информационную систему управления проектами (ИСУП) будет очень тяжело, практически невозможно, так как любая система подразумевает некоторый порядок и договоренности. Условно говоря, ИСУП заработает при условии «что перед законом все равны», и не заработает (или заработает, но не в желаемом объеме и сроках) при условии «друзьям все, а врагам закон».
* - сначала написал 6:00, но подумал, то многие решат, что если человек уходит домой только утром, то это слишком:)
Предложение
Необходимо понимать, сможем ли мы решить проблемы Заказчика и предложить решение. Заказчику, совместно с Исполнителем необходимо произвести ранжирование результатов в предложенном решении, например, сначала мы делаем это, потом то, и пока по первому этапу (наиболее легко достижимому результату) мы не получим собственно удовлетворительный результат, мы не приступаем к внедрению второго этапа. «Слона нужно есть по частям».
Иногда Исполнителю нужно набраться мужества и отказаться от внедрения, если очевидно, что позитивного результата от внедрения не будет, а переубедить Заказчика двигаться поэтапно не представляется возможным, иногда нужно уметь выдвинуть условия Заказчику, что внедрение ИСУП возможно, только если они будут достигнуты определенные критические факторы успеха, а иногда нужно посоветовать другой программный продукт, который позволит решить проблемы Заказчика. Так, например, есть следующее величайшее заблуждение, что сама установка Microsoft Project Server сразу вылечит все проблемы в компании, при этом не уделяется должное внимание ни настройке самой системы под нужды Заказчика, ни обучению сотрудников работе с этой системой.
Методологическая прелюдия**
** - Вопросам методологии будет посвящена отдельная статья. Это отдельная тема, задача внедрения методологии первична по отношению к инструменту
Начинаем с малого, но очень важного. Необходимо провести обучение основам методологии управления проектами всех заинтересованных и пока не заинтересованных во внедрении сторон. Идеально, если первое вступительное слово возьмет собственник (генеральный директор) и скажет примерно следующее: «Так дальше жить нельзя. Мы начинаем курс на смену парадигмы управления и будет идти к прозрачности и открытости всех процессов управления. Я буду всех вести за собой. Кто против могут покинуть помещение…».
Результатом такого обучения должно быть следующее:
- Все сотрудники говорят на одном языке в части терминологии.
- Все договорились о том, что есть проект, а что не есть проект.
- Все договорились о том, какие типы проектов есть в компании (ИТ, организационные, строительные), какие есть проекты с точки зрения получения результатов проектов (известный результат, новый продукт).
- Все договорились о том, как нужно управлять проектами (кто за что отвечает, кто за что не отвечает, кто какие принимает решения и как быстро и пр).
И поверьте, после проведения обучения методологии управления проектами многие сотрудники будут думать про управление проектами совсем не то, что думали до обучения.
После обучения необходимо:
- Составить реестр всех проектов.
- Разработать и запустить процедуры инициации и закрытия проектов.
Важно понимать, что результаты, особенно касающиеся договоренностей, могут быть получен не сразу. Но получение результатов критически важно для дальнейшего внедрения системы управления проектами и Заказчик должен установить сроки, когда будут утверждены необходимые типовые документы (устав проекта, положение об управлении проектами, составлен реестр проектов и т.п.). Иначе не избежать ситуации – «Некогда думать, работать надо».
Пропустим теперь методологическую часть и представим, что все-таки Заказчик внедряет Microsoft Project Server/Online во всей его красе и полноте функционала. Итак, как же продвигаться через тернии к звездам?
Инструментальная кульминация
1.1. Устанавливается Microsoft Project Server и проводится его настройка. Если же Заказчик будет использовать Microsoft Project Online, то просто проводится его настройка. Настройка сразу должна проводиться под сценарии и методологию управления проектами Заказчика.
1.2. Внедрение календарного планирования без учета ресурсов с использованием Microsoft Project Server/Online.
Результатами данного шага должно быть следующее:
- Все проекты ведутся в Microsoft Project Professional с публикацией планов проектов на Microsoft Project Server/Online;
- Отчетность по проектам ведется с оценкой не только сколько сделано или времени прошло, а сколько еще нужно сделать, т.е. когда будет окончание задачи и/или проекта;
- Отчетность в систему вводится или руководителями проектов (администраторами, планировщиками) в Microsoft Project Professional или ответственными через веб-интерфейс Microsoft Project Server/Online (см. «Способы отчетности в Project Server и Project Online»);
- Работает система изменений (базовых планов);
- Информация о статусе проектов в Microsoft Project Server/Online соответствует действительным состоянием проектов и руководство верит тому что видит и может уже принимать решения на основе данных в ИСУП.
- Ведется отчетность по проектам в разрезе контрольных событий (Milestone) и результатов (Deliverable).
- Разработаны регламенты коммуникаций для всех участников информационной системы по управлению проектами.
- За счет прозрачности процессов должно начаться сокращение статистики отставаний по срокам.
- Для руководства разработана отчетность по проектам в разных информационных срезах, по которой оно может принимать решение и понимать суть происходящего.
Обучение сотрудников работе с функционалом Microsoft Project, должно быть посвящено не кнопкам и функционалу, а должно быть посвящено конкретным сценариям, по которым в компании Заказчика должны идти проекты. Сценарий должен проходить все этапы жизненного цикла – планирование, анализ, исполнение, управление и завершение. Основная масса времени обучения должна быть потрачена на центральные три этапа. Как показывает практика, пользователи без проблем смогут нарисовать диаграмму Гантта, основная проблема – это научиться управлять изменениями и отслеживать факт.
1.3. Внедрение календарного планирования с учетом ресурсов и затрат с использованием Microsoft Project Server/Online.
Результатами данного шага должно быть следующее:
- На всех задачах назначены исполнители. При назначении учитываются календари, загрузка ресурсов, типы задач;
- На задачи назначаются ресурсы (материальные, трудовые) с учетом плановой потребности;
- Отчетность по проектам ведется с оценкой не только сколько часов отработано или объем работ сделан (фактические трудозатраты), а сколько еще нужно сделать (оставшиеся трудозатраты), т.е. когда будет окончание задачи и/или проекта.
- Отчетность в систему вводится или руководителями проектов (администраторами, планировщиками) в Microsoft Project Professional (особенно это актуально для строительных и производственных проектов, где на задачи назначается несколько ресурсов) или ответственными через веб-интерфейс Microsoft Project Server/Online (см. «Способы отчетности в Project Server и Project Online»).
- Как вариант работает система уведомлений, напоминаний, настроены порталы проектов, пользователи работают с порталом проектов в части документов, вопросов, рисков.
1.4. Внедрение системы учета рабочего времени (расписания).
Результатами данного шага должно быть следующее:
- Пользователи заносят информацию об отработанных часах в повременном представлении «Задач» и «Расписания». Только введя отчетность в табелях рабочего времени, можно будет понять, куда уходит рабочее время сотрудников.
1.5. Внедрение ресурсного планирования. Внедряется только при условии, что уже есть база данных о загрузке ресурсов, их реальной занятости, и данным табелей можно верить.
Результатом данного этапа должно быть следующее:
- Решение о запуске проекта принимается на основе имеющихся ресурсов и их загрузке. Другими словами, руководство учится говорить «нет» новым проектам, если на их реализацию нет достаточного числа людей.
- Предварительное планирование трудовых ресурсов ведется по ролям. По мере приближения к учетному периоду, т.е. например за месяц, происходит замена ролей (универсальных ресурсов) на конкретных исполнителей. Замена происходит не основе личных предпочтений, а с учетом квалификации и доступности ресурсов.
- Планы ресурсов по проекту согласовываются с руководителями ресурсов, обязанность которых, выделить ресурсы на проект.
1.6. Внедрение системы портфельного управления.
Результатом данного этапа должно быть следующее:
- Сформированы четкие критерии выбора проекта. Каждый выбираемый проект, должен соответствовать стратегии компании;
- Решение о запуске проекта принимается на основе имеющихся трудовых ресурсов и имеющегося бюджета;
- Работает система приоритетов проектов, которая всеми неукоснительно соблюдается, и даже руководством;
- Работает система пересмотра портфеля, когда даже любимый проект генерального директора может быть закрыт, как не соответствующий стратегии. Коротко говоря – управление портфелем проектов, это умение говорить нет, это умение «отстреливать» проекты из-за их несоответствия.
1.7. Внедрение рабочих процессов. Данный шаг можно внедрять параллельно шагам 1.3-1.6.
Результатом данного этапа должно быть следующее:
- Разработаны и работают рабочие процессы жизненных циклов для всех типов проектов (см. «Управление рабочими процессами проектов в Microsoft Project Server 2010»).
- Разработаны и работают рабочие процессы по управлению изменениями, рискам, проблемам, согласованию ресурсов, согласованию типовых документов.
Для внедрения рабочих процессов лучше всего использовать конструктор рабочих процессов Nintex Workflow и Nintex Workflow для Project Server.
1.8. Кастомизация.
?? (KAIZEN)
Система управления проектами работает тогда, когда достигается экономический эффект от ее использования – сокращение сроков отставания, сокращение перерасхода бюджета, высвобождение ресурсов для реализации более приоритетных проектов, что в итоге должно приводить к экономическому росту компании. Ведь какой смысл реализовать в срок и в рамках бюджета проекты, если результат проектов не увеличивает благосостояние компании.
Вот так, пройдя вышеперечисленные шаги можно на выходе получить работающую информационную систему управления проектами. Если вам интересны детали, то милости просим на наш форум http://www.microsoft-project.com.ua/, а если вам нужна наша помощь, то вам нужно срочно с нами связаться http://leoconsulting.com.ua/company/contact-us. Мы всегда готовы к сотрудничеству.
Project Online
