Закрытие проекта или фазы. Завершение курса по управлению проектами

12.06.20

Управление проектом - Компетенции и навыки РП

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

Предыдущая часть курса: Управление интеграцией. Курс по управлению проектами, часть 35

Полный список публикаций есть в первой статье:

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера

 

Закрытие фазы

 

Крупные проекты часто дробят на фазы. Фаза с точки зрения проектного управления – это часть проекта. Таких частей может быть несколько, и они стоят друг за другом. Обычно они стоят именно друг за другом, хотя бывают исключения, и они идут параллельно.
 
Фазы – это части проекта, над которыми обязательно работают разные команды.
 
Представьте, вы строите дом. Сначала идет проектирование, потом стройка, потом отделка. Проектированием занимается одна команда. Когда эта фаза закончится, начнется стройка. И здесь будет работать уже совершенно другая команда. Когда стройка закончится, начнется отделка. Здесь работают, как правило, не строители, не те, кто носил кирпичи. Приходят отдельные маляры, электрики, другие люди.
 
В рамках проекта каждую фазу надо закрывать отдельно.

 

Закрытие проекта 

 

Но вернемся к закрытию проекта. На протяжении всего проекта у менеджера следующая загрузка:

  • на уровне планирования – 100%;
  • большую часть проекта – 30% с возможными всплесками;
  • к закрытию загрузка прыгает примерно до 70%, а потом опадает в три этапа.

 
Любой проект надо закрывать, даже если он провальный, если вы не смогли ничего доделать. Формально ставится какая-то точка. Если проект успешен, то в закрытии надо помнить о том, что надо сдать результаты заказчику, убедиться, что он доволен, подписать все бумаги.
 
Здесь многое зависит от корпоративной специфики. Например, с точки зрения военного заказчика не бывает неудачной сдачи-приемки. Вы можете только сдать проект, не сдать вы его не можете. Потому что у военного заказчика есть предварительная сдача, которую можно не сдать много раз. А если вы вышли на обычную сдачу, то она проходит автоматически.
 
Ключевое, на что обращаю внимание: сдача-приемка – это формальное мероприятие. Это не место для выяснения отношений, не место для знакомства с приемной комиссией. Если вы нормально управляли ожиданиями заинтересованных сторон, вы идете, как студент-отличник подписать зачетку, а не сдавать экзамен. Потому что все, что нужно было заказчику знать, до него доносится раньше. Для этого есть управление заинтересованными сторонами. Но если вы заказчика долгое время держали в неведении, то сдача-приемка будет похож на взрыв, на ад. Это история о том, что не так страшны первые 70% проекта, как вторые 70%.   
 
Следующий момент в закрытии – высвобождение команды. Это важный шаг. Когда проект закрыт, сдача-приемка прошла, я рекомендую провести kick-off meeting (первая общая встреча с командой) наоборот. Снова всех соберите и скажите, условно, «всем спасибо, все свободны». Почему это надо сделать? Для вас, как для менеджера, может, она не сильно важна. Но она важна для компании. Так вы дадите понять, что проект окончен, что вы благодарны людям, что им больше не надо работать на проекте. А если прилетит какая-то задача, связанная с ним, человек должен сказать, что больше не работает в этом проекте.
 
Вторая часть – символично отметить окончание проекта, устроить небольшой праздник. Это мощная вещь, потому что менеджеры редко организуют такие встречи по окончании проектов. Обычно бюджета на «пирожки» нет. Но вы можете купить их и за свой счет. И люди это запомнят. Вы можете получить в такой момент человека практически бесплатно, «за пирожок». Потому что никто так не делает, а вы сделаете, и вас запомнят.
 
Почему менеджеры обычно не сообщают, что проект окончен? Потому что они интуитивно понимают, что могут понадобиться доработки. А на них можно будет вызвать тех людей, кто участвовал в проекте. И все так делают. И в итоге к человеку прилетают задачки по проекту еще какое-то время, и он не понимает, работает он в проекте или нет, продолжается проект или уже завершился.
 
В чем проблема? Я – менеджер, начинаю новый проект, мне дали команду. А моих людей все время дергают то на один проект, то на другой, при этом проекты фактически завершены. В итоге мои люди заняты, но не тем, что нужно мне. Вот такой бардак. Но при этом мне тоже разрешается дергать бывших сотрудников по окончании проекта. В итоге на уровне компании люди перегружены, но проекты не двигаются.
 
Одна из практик, чтобы этого не происходило, – kick-off наоборот. Вы сообщаете своим людям, что проект окончен. Если будут какие-то задачки, пересылайте их мне, я, как менеджер проекта, с ними разберусь дальше.
 
Бывает, что задача менеджера – просто выполнить проект, сдать результаты. В таком случае, как ни странно, вы не должны устранять какие-то недочеты, которые выявились после сдачи-приемки. Если же у вас в уставе предусмотрена гарантийная поддержка, то на этот период вы выделяете людей из команды, которые при необходимости будут решать проблемы. В таком случае на последней встрече можно сказать, что проект окончен, но остаются люди, которые продолжат работать. Но обязательно надо уточнить, что собой представляет такая работа. Например, что человек в месяц тратит не более 30 часов. Как правило, на поддержке нет полной загрузки. Если требуется больше времени, сотрудник обращается к менеджеру проекта.
 
Есть другой вариант. Когда проект заканчивается, вы передаете его на support другому отделу или команде. В IT-сфере проекты по окончании часто передают в службы эксплуатации.
 
Последний момент – сохранение информации. Вам нужно накопить на будущее информацию (примеры планов, шаблоны), которая упростит работы по планированию, выполнению новых проектов. Хороший менеджер отличается от плохого, в том числе тем, что у хорошего есть чемоданчик с базой знаний. Он может его расчехлить, и эти знания помогут ему ускорить проект на стадии инициации и других этапах.
 
База знаний бывает корпоративной, бывает личной. Но сама собой она не заводится. Если у вас нет корпоративной базы знаний, заведите личную. Ее можно вести на персональном компьютере, никто другой за вас это не сделает. Главное – вы должны знать, где найти информацию, это ключевой момент.
 
Многие опускают этот шаг. Потому что никто его не просит делать, никто за этим не смотрит. А для себя – часто бывает лень.
 
Можно сказать, что с «удавом» мы завершили. Мы прошли все инструменты, все алгоритмы, которые дает PMBoK менеджерам проектов.
 

 

Закрытие курса

 

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

  • представить алгоритм работы менеджера проекта, конкретную последовательность шагов (заинтересованные стороны, разработка устава, уточнение бюджета и работа с рисками);
  • рассказать про инструменты – с помощью чего работает менеджер (иерархическая структура, продолжительность и методы ее оценки, способы оценки рисков, пр.);
  • поведать про PMBok, чтобы можно было свободно читать стандарт управления проектами.

 
Напомню, что проектное управление работает, когда у вас есть задачи, ограниченные конечностью и неопределённостью. После этого курса вы сможете применить все, что слышали и узнали. Подчеркиваю: никаких других инструментов и алгоритмов нет.
 
Что касается PMBok, уверяю, что если вы откроете его, вы увидите, что целые его пласты вам понятны. Там есть узкие моменты, которые на курсе не освещались, но это нюансы. Ничего такого, о чем знают все менеджеры в мире, а вы после этого курса не слышали, не осталось: ключевые моменты мы разобрали.

 

Полный список публикаций курса:

 

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

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

5. Устав проекта - это скорлупа яйца

6. Алгоритм управления содержанием проекта

7. Сбор требований

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. Теория мотивации Дэвида Макклелланда

35. Управление интеграцией

36. Закрытие проекта или фазы

 

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"


 

См. также

Как быть эффективным руководителем проекта, а не экскурсоводом для команды стейкхолдеров

Компетенции и навыки РП Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    427    0    PChizhov    0    

5

Управление проектом Руководителем проекта со стороны Заказчика

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    778    0    user1270271    0    

11

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

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

02.02.2024    1187    0    otkalo    1    

6

5 основных внутренних ограничений руководителя

Компетенции и навыки РП Бесплатно (free)

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

22.01.2024    966    0    andmakarov    2    

13

Риски, роли, книги и светлое будущее для ПМов: проектный дайджест #35

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    804    0    Birby    0    

1

Методика оценки задач или Как «не угореть» по срокам

Компетенции и навыки РП Бесплатно (free)

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

31.08.2023    2250    0    Midzgun    4    

12

Практика построения проектного офиса в ИТ-компании

Компетенции и навыки РП Бесплатно (free)

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

18.08.2023    2234    0    Pryamonosov    2    

6

Национальные особенности управления

Компетенции и навыки РП Бесплатно (free)

Внедрение проектного управления в России и странах СНГ пробуксовывает, и причина этому – национальные особенности, в том числе национальные особенности управления. Перечислим пять основных особенностей, которые мешают системно использовать проектные подходы в России, расскажем о том, как с этим работать и что поможет предотвратить риски.

17.08.2023    1425    0    paalferov    2    

18
Оставьте свое сообщение