Предыдущая часть курса: Управление интеграцией. Курс по управлению проектами, часть 35
Полный список публикаций есть в первой статье:
Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
Закрытие фазы
Крупные проекты часто дробят на фазы. Фаза с точки зрения проектного управления – это часть проекта. Таких частей может быть несколько, и они стоят друг за другом. Обычно они стоят именно друг за другом, хотя бывают исключения, и они идут параллельно.
Фазы – это части проекта, над которыми обязательно работают разные команды.
Представьте, вы строите дом. Сначала идет проектирование, потом стройка, потом отделка. Проектированием занимается одна команда. Когда эта фаза закончится, начнется стройка. И здесь будет работать уже совершенно другая команда. Когда стройка закончится, начнется отделка. Здесь работают, как правило, не строители, не те, кто носил кирпичи. Приходят отдельные маляры, электрики, другие люди.
В рамках проекта каждую фазу надо закрывать отдельно.
Закрытие проекта
Но вернемся к закрытию проекта. На протяжении всего проекта у менеджера следующая загрузка:
- на уровне планирования – 100%;
- большую часть проекта – 30% с возможными всплесками;
- к закрытию загрузка прыгает примерно до 70%, а потом опадает в три этапа.
Любой проект надо закрывать, даже если он провальный, если вы не смогли ничего доделать. Формально ставится какая-то точка. Если проект успешен, то в закрытии надо помнить о том, что надо сдать результаты заказчику, убедиться, что он доволен, подписать все бумаги.
Здесь многое зависит от корпоративной специфики. Например, с точки зрения военного заказчика не бывает неудачной сдачи-приемки. Вы можете только сдать проект, не сдать вы его не можете. Потому что у военного заказчика есть предварительная сдача, которую можно не сдать много раз. А если вы вышли на обычную сдачу, то она проходит автоматически.
Ключевое, на что обращаю внимание: сдача-приемка – это формальное мероприятие. Это не место для выяснения отношений, не место для знакомства с приемной комиссией. Если вы нормально управляли ожиданиями заинтересованных сторон, вы идете, как студент-отличник подписать зачетку, а не сдавать экзамен. Потому что все, что нужно было заказчику знать, до него доносится раньше. Для этого есть управление заинтересованными сторонами. Но если вы заказчика долгое время держали в неведении, то сдача-приемка будет похож на взрыв, на ад. Это история о том, что не так страшны первые 70% проекта, как вторые 70%.
Следующий момент в закрытии – высвобождение команды. Это важный шаг. Когда проект закрыт, сдача-приемка прошла, я рекомендую провести kick-off meeting (первая общая встреча с командой) наоборот. Снова всех соберите и скажите, условно, «всем спасибо, все свободны». Почему это надо сделать? Для вас, как для менеджера, может, она не сильно важна. Но она важна для компании. Так вы дадите понять, что проект окончен, что вы благодарны людям, что им больше не надо работать на проекте. А если прилетит какая-то задача, связанная с ним, человек должен сказать, что больше не работает в этом проекте.
Вторая часть – символично отметить окончание проекта, устроить небольшой праздник. Это мощная вещь, потому что менеджеры редко организуют такие встречи по окончании проектов. Обычно бюджета на «пирожки» нет. Но вы можете купить их и за свой счет. И люди это запомнят. Вы можете получить в такой момент человека практически бесплатно, «за пирожок». Потому что никто так не делает, а вы сделаете, и вас запомнят.
Почему менеджеры обычно не сообщают, что проект окончен? Потому что они интуитивно понимают, что могут понадобиться доработки. А на них можно будет вызвать тех людей, кто участвовал в проекте. И все так делают. И в итоге к человеку прилетают задачки по проекту еще какое-то время, и он не понимает, работает он в проекте или нет, продолжается проект или уже завершился.
В чем проблема? Я – менеджер, начинаю новый проект, мне дали команду. А моих людей все время дергают то на один проект, то на другой, при этом проекты фактически завершены. В итоге мои люди заняты, но не тем, что нужно мне. Вот такой бардак. Но при этом мне тоже разрешается дергать бывших сотрудников по окончании проекта. В итоге на уровне компании люди перегружены, но проекты не двигаются.
Одна из практик, чтобы этого не происходило, – kick-off наоборот. Вы сообщаете своим людям, что проект окончен. Если будут какие-то задачки, пересылайте их мне, я, как менеджер проекта, с ними разберусь дальше.
Бывает, что задача менеджера – просто выполнить проект, сдать результаты. В таком случае, как ни странно, вы не должны устранять какие-то недочеты, которые выявились после сдачи-приемки. Если же у вас в уставе предусмотрена гарантийная поддержка, то на этот период вы выделяете людей из команды, которые при необходимости будут решать проблемы. В таком случае на последней встрече можно сказать, что проект окончен, но остаются люди, которые продолжат работать. Но обязательно надо уточнить, что собой представляет такая работа. Например, что человек в месяц тратит не более 30 часов. Как правило, на поддержке нет полной загрузки. Если требуется больше времени, сотрудник обращается к менеджеру проекта.
Есть другой вариант. Когда проект заканчивается, вы передаете его на support другому отделу или команде. В IT-сфере проекты по окончании часто передают в службы эксплуатации.
Последний момент – сохранение информации. Вам нужно накопить на будущее информацию (примеры планов, шаблоны), которая упростит работы по планированию, выполнению новых проектов. Хороший менеджер отличается от плохого, в том числе тем, что у хорошего есть чемоданчик с базой знаний. Он может его расчехлить, и эти знания помогут ему ускорить проект на стадии инициации и других этапах.
База знаний бывает корпоративной, бывает личной. Но сама собой она не заводится. Если у вас нет корпоративной базы знаний, заведите личную. Ее можно вести на персональном компьютере, никто другой за вас это не сделает. Главное – вы должны знать, где найти информацию, это ключевой момент.
Многие опускают этот шаг. Потому что никто его не просит делать, никто за этим не смотрит. А для себя – часто бывает лень.
Можно сказать, что с «удавом» мы завершили. Мы прошли все инструменты, все алгоритмы, которые дает PMBoK менеджерам проектов.
Закрытие курса
Подведем короткий итог, что мы пытались сделать. У меня было три задачи:
- представить алгоритм работы менеджера проекта, конкретную последовательность шагов (заинтересованные стороны, разработка устава, уточнение бюджета и работа с рисками);
- рассказать про инструменты – с помощью чего работает менеджер (иерархическая структура, продолжительность и методы ее оценки, способы оценки рисков, пр.);
- поведать про PMBok, чтобы можно было свободно читать стандарт управления проектами.
Напомню, что проектное управление работает, когда у вас есть задачи, ограниченные конечностью и неопределённостью. После этого курса вы сможете применить все, что слышали и узнали. Подчеркиваю: никаких других инструментов и алгоритмов нет.
Что касается PMBok, уверяю, что если вы откроете его, вы увидите, что целые его пласты вам понятны. Там есть узкие моменты, которые на курсе не освещались, но это нюансы. Ничего такого, о чем знают все менеджеры в мире, а вы после этого курса не слышали, не осталось: ключевые моменты мы разобрали.
Полный список публикаций курса:
1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
2. Три фундаментальных принципа проектного управления
3. Роли в проектном управлении
4. Управление заинтересованными сторонами
5. Устав проекта - это скорлупа яйца
6. Алгоритм управления содержанием проекта
8. Создание концепции проекта (project scope statement)
9. Иерархическая структура работ (ИСР)
10. Управление качеством – ключевые термины
11. Управление качеством – диаграмма Ишикавы (Ishikawa diagram)
12. Управление качеством: блок-схемы, чек-листы и контрольные карты Шухарта
13. Управление качеством – гистограмма, диаграмма Парето и диаграмма разбрасывания
14. Алгоритм управления сроками
15. Алгоритм управления сроками с использованием специального софта
16. Управление сроками – определение продолжительности
17. Управление сроками – пэддинг и кривая обучения
18. Критический путь в расписании, продолжаем тему управления сроками
19. Методы сжатия расписания и вехи в проекте
20. Методы определения себестоимости и способы отслеживания прогресса проекта
21. Контроль прогресса – метод освоенного объема (earned value management – EVA)
22. Закупки на проекте: алгоритм, планирование и осуществление закупок
23. Закупки по контрактам Fixed Price - с фиксированной ценой
24. Закупки по контрактам "Время и материалы" и "С возмещением затрат". Закрытие закупок
25. Управление рисками – алгоритм
26. Риски – идентификация и качественный анализ
27. Риски – количественный анализ
28. Планирование реагирования на риски
29. Коммуникации в проекте: шумы и подсчет количества каналов
30. Матрица RACI
31. Развитие команды проекта и командообразование (тимбилдинг)
32. Теория мотивации МакГрегора
33. Теория мотивации – пирамида Маслоу
34. Теория мотивации Дэвида Макклелланда
Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"
