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

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
11 февраля 2016 Все для начинающего РМа
18 658 6

Допущения проекта

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

Очень часто, практически в каждом проекте находится человек (и хорошо еще, если это не руководитель проекта), который искренне не понимает, что такое допущения проекта и зачем их писать в устав. Поэтому давайте разбираться.

Допущения проекта (assumptions) – это наши предположения о том, какова будет окружающая среда проекта, на основе которых мы этот проект планируем. Зачем это надо? Элементарно, на основе допущений проекта мы а) получим инструмент управления заинтересованными лицами и «договоримся на берегу» б) лучше оценим окружение проекта в) будем управлять рисками.
Допущения вносятся в устав проекта и могут уточняться и дополняться в ходе

Пример из жизни! Например, проект «ремонт в квартире» я буду планировать, исходя из следующих допущений:

  1. Я буду искать бригаду рабочих по знакомым (у меня точно есть знакомые, которые эту бригаду посоветуют, я в этом практически не сомневаюсь).
  2. В ранее согласованный дизайн-проект не будет вноситься изменений, касающихся перепланировки или расположения коммуникаций и сантехники.
  3. Муж сможет уделять ремонту минимум 20 часов в неделю, а я – минимум 15.
  4. У соседей нет маленьких детей, поэтому ограничений по времени проведения работ нет (ну кроме «не шуметь с 8.00 до 23.00, в строгом соответствии с законодательством РФ).
  5. Доставка штукатурки, пескобетона и прочих тяжелых сыпучих вещей из магазина будет стоить не больше 2000р. за машину за один раз с максимальной загрузкой 3,5 тонны (это я специально сходила и спросила в магазине, чтобы понимать, во сколько в целом доставка обойдется).

Как определить допущения проекта?

  1. Включить голову. Правда, на самом деле нужно просто абстрагироваться. Особенно если вы делаете первый проект в этой компании или с этими стейкхолдерами. Просто подумайте на минуту, что ваши представления о том, что вокруг вас и в каких условиях этот проект будет делаться – это не истина в последней инстанции. Например, если на прошлом месте работы чтобы купить ноут новому участнику проекта достаточно было подписать служебную записку у начальника отдела, сходить за ноутом в магазин и потом оформить авансовый отчет, то в новой компании это может быть процесс длительностью 3-4 месяца. Подобные базовые представления желательно «прокрутить» в голове, понять, какие из них с большой вероятность могут быть ошибочны, уточнить и записать сюда. Ну например, если вы еще ни разу не имели яркого опыта закупки оборудования в новой компании, а только почитали внутренний документ об этом, говорящий, что любая закупка – это максимум 2 месяца, напишите «Закупка ноутбуков потребует не более 2х месяцев в соответствии с Процедурой Компании».
  2. Посмотреть уставы ранее сделанных похожих проектов, поговорить с руководителями этих проектов (если это возможно). Заодно и список потенциальных рисков пополните.
  3. Подумать, влиять на какие параметры проекта вам важнее всего (в разумных пределах, понятное дело). Если вы знаете, что проект очень-очень-очень срочный и на словах вам Заказчик говорил, что все его люди будут всячески вам помогать 24 часа в сутки – самое время это тут записать в форме «такие-то сотрудники могут привлекаться на проект до 100% рабочего времени по решению руководителя проекта без дополнительного согласования со стороны Заказчика».
  4. Вспомнить все обещания, которые вам давали Спонсор и Заказчик, а также остальные стейкхолдеры. Обещали, что, т.к. проект срочный, вы сможете купить нужное ПО без тендерной процедуры, чтобы не затягивать? Пишите «Покупка ПО возможна без применения тендерной процедуры (исключение из процедуры будет организовано Заказчиком проекта Петровым П.П.)»!

Иногда допущения в уставе пишут нумерованным списком, иногда делают табличку, где рядом с каждым допущением указывают «Влияние, если допущение окажется неправдой». Например, для допущения «Сотрудники будут уделять 50% времени проекту» влиянием будет «Увеличение сроков проекта» (не будут люди работать сколько обещали – проект затянется) или «Снижение качества разработки» (если увеличивать сроки нельзя – придется взять других разработчиков, которые «не в теме» и могут где-то накосячить, а времени перепроверять у нас не будет). Практика неплохая, делать так или нет – обычно зависит от принятых в компании стандартов оформления устава. К слову, как правило, если этого в шаблоне нет, то, добавив, можно получить плюшку за улучшение процессов Компании.

Как использовать допущения в ходе проекта:

  1. Сначала – надо еще суметь подписать устав, в который вы все эти допущения внесли. А без устава, как вы помните, работу мы не начинаем. С вероятностью 146% заинтересованные лица очень удивятся, увидев все это на бумаге. Тут же начнется что-то типа «нет, 100% времени сотрудников мы не можем выделить!», «ну кому мы врем, в Процедуре по закупке 2 месяца, но еще никому меньше чем за 4 месяца купить не удалось», «я тут подумал, не факт, что мы сможем без тендера обойтись» и прочие радости. В общем, после пары циклов согласований у вас таки будет подписанный устав с реальными допущениями и мнооого материала для управления рисками.
  2. После того, как список определен – это отличная вводная для управления рисками, т.к. любое допущение – это нечто, в чем вы не уверены, т.е. потенциальный риск. Просто берем список допущений на первую сессию управления рисками и вуаля! Ну и во время согласования списка допущений отмечаем для себя наиболее болезненные области, чтобы потом посмотреть туда внимательнее.
  3. В ходе проекта устав с допущениями используем как аргумент во всем, что касается этих допущений. Мол, на проект надо 2х юристов на 2 недели, что значит «нет»? Устав проекта предполагает, что я могу привлечь их на 100% времени! Нет? Ок, пошли вместе к Заказчику. Скорее всего, Заказчик, подписавшийся под этими допущениями, юристов вам все-таки найдет, или какие-то разумные обходные пути предложит или, на крайний случай, запрос на изменение согласует (но это надо аккуратно делать все, опасное развлечение).

Типовая ошибка! Когда начинающий руководитель проекта наконец разбирается в том, что же такое допущения проекта, его обычно тянет написать туда все-все-все! Ну чтобы максимально прикрыть попу и быть «в белом». На выходе получаем не то устав, не то реестр рисков, который никто не читает или читает и недоумевает, почему он, топ-менеджер, читает такую ерунду и не ошибся ли он с кандидатурой руководителя проекта. Не надо так! Устав – это документ, который высокоуровнево описывает проект и его допущения и дает вводные для планирования. Этот документ подписывается как минимум спонсором и заказчиком, которые не захотят читать многостраничные фантазии. Поэтому в уставе допущения проекта указываются в общем виде, они нужны именно для того, чтобы договориться на берегу, а не чтобы рассмотреть все возможные варианты развития событий. Например, в примере с ремонтом допущение «в магазине точно будут обои того цвета, который указан в дизайн-проекте» точно будет лишним. Зато это отличный риск, который надо учитывать – когда будете детально планировать поездки по магазинам и закупку обоев, нужно учитывать, что обоев и правда может не оказаться, и вы потратите время и бензин (т.е. деньги) на их поиски. А если не найдете в тот же день – так еще и расписание поклейки обоев поедет… но об этом в отдельной статье.

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

6комментариев

сначала новые
по рейтингу сначала новые по хронологии
1

Один из немногих ресурсов с отличной подачей качественного материала по управлению проектами. Спасибо!

Автор2
Юлия Бажанова

Спасибо, здорово, что полезно!

3

Спасибо за статью! Очень интересно и доступно изложено, с интересными примерами.

Автор4
Юлия Бажанова

Виталий, спасибо! Цель сайта – именно интересное и доступное изложение основ управления проектами, рада, что получается:)

5

Благодарю Вас, крайне интересно и живо! Очень доволен, что набрел на ваш ресурс!

Автор6
Юлия Бажанова

Спасибо, рада, что статья оказалась полезной.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: