Что такое допущения и ограничения проекта

Что нужно сделать до старта проекта? Часть 2. Допущения проекта

В предыдущей статье цикла я написал о том, что одна из ключевых задач руководителя проекта – это снижение неопределенности в проекте (http://project-management.zis.by/planirovanie-proekta/chto-nuzhno-sdelat-do-starta-proekta.html). И первый шаг для снижения неопределенности – эта работа надо формулированием целей проекта и необходимых для их достижения результатов проекта, а также сбор и анализ требований к результатам.

Следующий важный шаг – формулирование допущений по проекту.

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

В одном из подходов к управлению проектами, PMBOK, дано следующее определение:

Допущение проекта – это фактор в рамках процесса планирования, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации.

Честно говоря, мне это определение не кажется четким и понятным. В одной из статей я увидел следующее определение:

Допущение проекта – это фактор, существенный для достижения целей проекта, на который команда исполнителей проекта не может повлиять.

Это определение, на мой взгляд, более точное, и в дальнейшем я буду использовать именно его. При формулировке допущений можно использовать следующий алгоритм:

Рассмотрим, как можно формулировать допущения на примере проекта внедрения в компании CRM-системы.

Напомню, что Заказчик сформулировал следующие цели для проекта:

И для достижения целей проекта были сформулированы следующие результаты проекта:

Изучив цели проекта и продукты, руководитель проекта CRM сформулировал следующие гипотезы, важные для достижения целей проекта и получения результатов. После чего руководитель проекта для каждой гипотезы ответил на вопрос: «Может ли команда проекта проверить гипотезу до старта проекта?»:

Таким образом, все сформулированные в таблице гипотезы, по которым был получен ответ «Нет», становятся допущениями проекта.

Как вы заметили, при ответе на вопрос «Может ли команда проекта проверить гипотезу до старта проекта?» могут возникать сложности. Если гипотеза касается внешнего по отношению к проекту фактора, то ответить на этот вопрос обычно достаточно просто: команда проекта не может повлиять на природные явления, экономические или политические условия. Поэтому все гипотезы, связанные с действием этих факторов, скорее всего, станут допущениями проекта.

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

Как только мы сформулировали допущение, его достоверность нужно поставить под сомнение и сформулировать риски.

Потренируемся на примере двух допущений из таблицы.

Это приведет к тому, что при сборе требований к программному продукту руководители не будут понимать границ системы CRM, а это приведет к непониманию рамок проекта.

Что дальше делать с допущениями? Алгоритм работы следующий:

Наверное, вы уже знаете, что работа с рисками приводит к тому, что в списке работ по проекту появляются дополнительные задачи, что приведет, скорее всего, к увеличению сроков и бюджета проекта по отношению к варианту плана проекта, в котором риски не были учтены.

Таким образом, анализ допущений помогает нам идентифицировать риски проекта и уточнить список работ по проекту для того, чтобы сделать расписание и бюджет проекта более адекватными и снизить неопределенность проекта до его старта. Надеюсь, суть работы с допущениями проекта стала понятной.

Но если у вас есть предложения или замечания, я готов их обсудить в комментариях к статье.

В следующей статье цикла я планирую написать о формировании ограничений по проекту как еще одном действии, которое нужно сделать до старта проекта.

Источник

Что такое допущения и ограничения проекта

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

Инициация состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Процессы инициации часто выполняются вне рамок проекта и связаны с организационными, программными или портфельными процессами. В ходе процесса инициации уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. На этом этапе также выбирается менеджер проекта, если он еще не назначен, и документируются исходные допущения и ограничения. Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется.

Устав проекта [1] — документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта.

В российской практике данный документ чаще называется Концепция проекта. Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.

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

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

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

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

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

Концепция проекта

У каждого проекта должна быть концепция. Если проект небольшой, то для изложения концепции часто достаточно несколько абзацев. Однако, стартовать проект без концепции, это все равно, что отправлять корабль в плавание, не определив для него пункт назначения.

Концепция проекта разрабатывается на основе анализа потребностей бизнеса. Главная функция документа — подтверждение и согласование единого видения целей, задач и результатов всеми участниками проекта. Концепция определяет что и зачем делается в проекте.

В качестве примера, который позволит иллюстрировать теоретическое изложение основ управления проектами, возьмем реальный проект разработки ПО для автоматизации одного из подразделений крупной производственной компании. Назовем его «Автоматизированная система продажи документации».

Краткая легенда проекта. Заказчик ОАО «XYZ» является одним из ведущих производителей сложных технических изделий. Отдел «123», входящий в ОАО «XYZ», отвечает за продажу дополнительной сопроводительной документации для клиентов ОАО.

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

Основная функция отдела «123» — получение и обработка заказов на дополнительную документацию, согласно ежегодно рассылаемому каталогу. В связи с переездом отдела «123» в новое здание, была поставлена задача на разработку и поставку системы, автоматизирующей основную деятельность отдела «123».

Текст документа Концепция проекта, который будет приводиться в качестве примера, будем выделять цветом фона.

Цели и результаты проекта

Цели должны быть значимыми (направленными на достижение стратегических целей Компании), конкретными (специфичными для данного проекта), измеримыми (т.е иметь проверяемые количественные оценки), реальными (достижимыми). Четкое определение бизнес-целей важно, поскольку существенно влияет на все процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Например, если реальные затраты на проект будут превосходить будущие доходы от его реализации.

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

4.1. Авторизация и аутентификация пользователей.
4.2. Просмотр каталога продуктов.
4.3. Поиск продуктов по каталогу.
4.4. Заказ выбранных продуктов.
4.5. Просмотр информации о статусе заказа.
4.6. Информирование клиента об изменении статуса заказа.
4.7. Просмотр и обработка заказов исполнителями из службы продаж.
4.8. Просмотр статистики поступления и обработки заказов за период.
4.9. Подготовка и сопровождение каталога продукции.

Допущения и ограничения

Данный раздел описывает исходные допущения и ограничения. Допущения, как правило, тесно связаны с управлением рисками, о котором мы будем говорить далее. В разработке ПО часто приходится формулировать риски в виде допущений, тем самым передавая его заказчику. Например, оценивая проект разработки и внедрения по схеме с фиксированной ценой, мы должны записать в допущения предположение о том, что стоимость лицензий на стороннее ПО не изменится, до завершения проекта.

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

Ключевые участники и заинтересованные стороны

Одна из задач фазы инициации проекта это выявить и описать всех его участников. Согласно [1] к участникам проекта относятся все заинтересованные стороны (stakeholders), лица и организации, например заказчики, спонсоры, исполняющая организация, которые активно участвуют в проекте или чьи интересы могут быть затронуты при исполнении или завершении проекта. Участники также могут влиять на проект и его результаты поставки.

7.1. Поставщик оборудования и операционно-системного ПО — ООО «Альфа».
7.2. Поставщик базового ПО — ООО «Бета».

Ресурсы

Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом:

Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО

Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы.

1 Проект стартовал в 2000 году, тема UML тогда была на слуху и даже оставались те, кто верил, что из модели на UML можно будет генерировать исходный код.

2 Таково было требование Заказчика, поскольку этот инструмент использовали его программисты, которым предполагалось передавать систему на сопровождение.

3 Еще один пример горячей темы и не оправдавшихся надежд — это объектно-ориентированные базы данных. У заказчика проекта уже были закуплены лицензии на эту базу данных и он очень хотел получить возврат от этих инвестиций. Поэтому ее использование в проекте стало одним из требований. К счастью, нам удалось быть достаточно убедительными и обосновать необходимость дополнительно использовать RDBMS Oracle для решения транзакционных задач. О том, к чему это привело, я подробно рассказал в своей книге: С. Архипенков, «Руководство командой разработчиков программного обеспечения. Прикладные мысли», Москва, 2008.

4 Мы в данном разделе оцениваем себестоимость проекта. Определение продажной цены проекта не входит в рамки данного курса.

Источник

Что нужно сделать до старта проекта? Часть 3. Ограничения проекта

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

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

В управлении проектами используется термин «проектный треугольник», для которого используют также название «тройное ограничение проекта». Проектный треугольник описывает взаимодействие ключевых ограничений проекта:

Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?

Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:

Качество – это степень соответствия результата требованиям к нему.

Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).

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

Логика формирования ограничений по проекту следующая:

Как работает проектный треугольник?

Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.

Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.

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

Многие из вас уже видели похожие картинки:

Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).

Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника, то он пытается передать руководителю проекта все риски, связанные с изменениями в проекте. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например, равными 100% от расчетных значений сроков или бюджета).

Какие еще типы ограничений могут быть?

В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:

Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.

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

Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.

Успешность проекта

По выполнению проекта в рамках его ограничений судят об успехе проекта.

Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.

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

Шаги по подготовке проекта к старту следующие:

Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!

Источник

Устав проекта

Шаблон 1. Устав проекта

ИНФОРМАЦИЯ О ПРОЕКТЕ

Строительство нефтедобывающей вышки

Другие участники проекта

Дата создания документа

Причины инициации проекта:

Нахождение природного месторождения;

Широкая необходимость рынка в нефтепродуктах.

Строительство нефтедобывающей вышки в Баренцевом море.

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

Разработка месторождения, добыча и реализация нефти.

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

Ограничения проекта и допущения проекта:

Ресурсные: нефти в месторождении хватит на 15 лет;

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

Финансовые: необходимо уложиться в 10 млн. рублей.

Календарные: строительство должно быть завершено к январю 2010.

Должность Дата Подпись

Шаблон 2. Описание содержания проекта

ИНФОРМАЦИЯ О ДОКУМЕНТЕ

Строительство нефтедобывающей вышки

ОПИСАНИЕ СОДЕРЖАНИЯ ПРОЕКТА

Разработка месторождения, добыча и реализация нефти.

Критерии достижения целей проекта

Строительство должно быть завершено к январю 2010 года. Производственная мощность – 11120 баррелей в месяц.

Задачи и результаты проекта

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

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

Ресурсные: нефти в месторождении хватит на 15 лет;

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

Финансовые: необходимо уложиться в 10 млн. рублей.

Календарные: строительство должно быть завершено к январю 2010.

Завершить проект к январю 2010 года, обеспечить объем добычи нефти в 11120 баррелей в месяц. Если строительство не будет завершено к намеченной дате, может не хватить финансирования, что может привести к заморозке на неизвестный срок. Если объем добычи будет меньше, проект может не окупиться в нужный срок, из-за чего может появиться необходимость в поиске дополнительных финансовых средств.

Идентифицированные риски проекта

Не уложение в указанные сроки – поиск дополнительного финансирования;

Меньший объем добычи – установка более мощного оборудования;

Отсутствие покупателей – проведение маркетинговой компании.

Источник

• ← Что такое скрайбинг по литературе
• Что такое верификаторы в стоматологии →