срок реализации проекта что это
Сроки реализации проекта и этапы выполнения
Основная цель вложения денежных средств в разные виды проектов – это увеличение капитала. До того как получить прибыль, необходимо изначально полностью окупить вложенные инвестиции.
Именно окупаемость является той отправной точкой, при которой проект будет генерировать прибыль для инвестора. Проанализируем специфику его срока окупаемости. Реализация проекта – это важный момент, который предполагает детальные пояснения.
Особенности понятия
Окупаемость инвестиций является тем периодом времени, что потребуется для полного перекрытия доходами изначальных инвестиционных расходов, вложенных в него. К примеру, если инвестиции составили порядка 500 тысяч долларов, а ожидается денежный поток по готовому проекту в сумме 100 тысяч рублей ежегодно, то срок реализации проекта (его окупаемости) составит пять лет.
Этот параметр является одним из основных показателей, которые используются при оценке инвестиционной привлекательности проекта. Часто специалисты осуществляют также расчет следующих показателей:
Сроки и этапы реализации проекта обозначают РР.
Классификация по срокам
В том случае, когда предполагаются равномерные поступления по внедряемой идее, используется несложная формула определения его окупаемости. В этой формуле начальные инвестиционные затраты на проект делят на ежегодный приток денежных средств, который им генерируется.
Срок реализации инвестиционного проекта – это показатель его результативности и эффективности. Любой проект имеет ограничения по времени, за которые он должен быть выполнен.
Принято выделять следующие виды проектов, в зависимости от срока реализации:
Расчеты при неравномерных денежных потоках
В таком случае используется другая математическая формула, в которой за минимальный временной промежуток кумулятивные денежные потоки должны превышать вложенные инвестиции.
Допустим, что в идею вложили 500 тысяч долларов, а рост денежных потоков указан в таблице.
Денежный поток по проекту
Денежный кумулятивный поток
Расчет срока реализации проекта показывает, что идея окупается за четыре года. Следовательно, денежный кумулятивный поток в сумме, которая превышает вложенные средства в идею в размере 500 000 долларов, можно достигнуть к концу четвертого года его реализации.
Метод расчета времени окупаемости считается в настоящее время востребованным. Профессионалы признают его удобным инструментом в осуществлении инвестиционного анализа, так как он прост в расчетах.
Среди недостатков, присущих ему, выделяют невозможность учета изменения во времени стоимости денег. Это приводит к существенному изменению расчетных данных.
Расчет дисконтированного срока окупаемости вложений
Такие вычисления проводят для того, чтобы оценить сроки реализации проекта. ДРР определяется как отношение денежного потока, генерируемого инвестиционным проектом к размеру начальных вложений.
При правильных вычислениях можно избежать многочисленных дополнительных затрат. Это особенно актуально на этапе монтажных и строительных работ, когда важно понимать, не сорвется ли срок реализации проекта строительства.
Важность управления сроками проекта
В законодательстве нашей страны под периодом реализации идеи понимают некоторое время, в течение которого осуществляется финансирование и сооружение объектов капитального строительства, предусмотренных замыслом.
Под плановым периодом инвестиционного проекта понимают пятилетний период, на протяжении которого государственная поддержка способствует реализации инициативы.
Так как основной срок реализации идеи состоит из суммы затраченного времени для осуществления работ на каждом этапе, нужно максимально точно выяснить бюджет (распределение затрат) времени на всех стадиях.
Важные детали
Сроки реализации проекта связаны и с уровнем ответственности подрядных организаций, которые выполняют определенные работы. Если необходимо реализовать масштабный замысел, в таком случае за каждый этап отвечает конкретный подрядчик. В случае сбоя работы одного из них существенно тормозится деятельность иной организации. В конечном итоге подобный процесс завершается существенными убытками инвестора.
На сроки реализации проекта влияет несколько факторов:
Современность
В настоящее время управленческая наука касается различных видов менеджмента, которые подразумевают существенные риски, изменение стоимости. Для того чтобы их избежать, специалисты-практики и различные исследователи применяют разные варианты решения проблемы. К примеру, предлагается продумывать планирование горизонта событий.
Методика календарно-сетевого планирования
Данный прием подходит для начинаний, которые связаны с капитальным строительством. Это модель, которая иллюстрирует, как будет проходить реализация идеи по процессорному и временному параметрам. Подобный график – это инструмент анализа, согласования, описания сторонами (заказчиком, инвестором, генеральным подрядчиком) технологического процесса осуществления строительных работ.
Также сюда включается возможность корректировки намеченного алгоритма действий, продумывание рисков и потенциальных проблем, сведение к минимуму негативных последствий.
Нельзя выпускать из внимания тот факт, что составлением подобных графиков занимаются обычные люди. Именно поэтому часто появляются разнообразные проблемы, наблюдается отклонение по срокам от намеченных временных рамок.
К примеру, если составляется схема, согласно которой осваиваются капитальные вложения, при проведении нескольких параллельных операций систематически появляются накладки отрицательного характера.
В подобных ситуациях критический путь часто выводят вручную, поэтому его трудно назвать экономически целесообразным расчетным показателем. Чаще всего величину просто «рисуют» к требуемой дате, периодически ее нарушая. Подобный график ставит только временные ограничения назначенным исполнителям, он не зависит от иных факторов: логистики, готовности коммуникаций, квалификации кадров.
У руководителя проекта в подобном случае нет возможности прогнозировать с высокой вероятностью сроки и качество реализации идеи, влиять на ход событий. В связи с этим процесс затягивания сроков завершения конкретных этапов всех строительных работ в наши дни является весьма распространенным явлением. Приходится искать дополнительные материальные ресурсы для того, чтобы завершить начатый проект, сдать объект в эксплуатацию.
Важные аспекты
Для того чтобы избежать существенных разногласий с выбранным для проекта подрядчиком относительно продолжительности осуществления определенных операций, часто заказчики вынуждены обращаться за дополнительными консультациями по плану в инжиниринговые компании.
Их специалисты анализируют работу, связанную с составлением определенных баз данных или справочников, в которых определяется продолжительность проведения стандартных либо типовых строительных работ. Подобные материалы дают заказчику возможность избегать существенного затягивания сроков работ со стороны подрядчиков.
В некоторых случаях заказчику приходится делать выбор: воспользоваться быстрым, но дорогим вариантом или подобрать подрядчика за меньшую стоимость, но настроиться на длительные строительные работы.
В тех ситуациях, когда конечным результатом внедряемой идеи становится получение материальной прибыли, инвестор выбирает первый вариант, что способствует существенному сокращению времени предварительной и инвестиционной фаз, позволяет ему в минимальные сроки окупить вложенные ресурсы.
Заключение
При реализации социального проекта его стоимость становится ключевым моментом. Именно поэтому заказчик использует календарно-сетевое планирование, которое базируется на технологии осуществления необходимых действий.
При правильном и подробном описании технологии, ее согласовании с инвестором и подрядными организациями вполне можно распределить и сроки проведения конкретных действий. Подобное планирование способствует избежанию затягивания строительных работ, поэтому не потребуются дополнительные расходы на содержание персонала, выплату процентов, обслуживание и ремонт техники, оплату дополнительной аренды. Оно позволяет выявлять те организации, которые виновны в затягивании сроков строительства, применять к ним меры воздействия.
Расчет сроков и стоимости проектов: как это делается и можно ли упростить процесс?
Если вы когда-либо занимались разработкой приложений на заказ, то наверняка знакомы с довольно рутинным процессом расчета стоимости и сроков реализации проекта. И ладно бы, если расчет проекта выполнялся лишь единожды, но зачастую потенциальные заказчики не могут уложиться в бюджет, и начинают на ходу менять требования к продукту:
— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?
Стандартные пути упрощения расчетов, такие как установка фиксированной стоимости дня работы сотрудника или компании, как правило ведут к потере точности результатов и все равно не избавляют нас от ручных вычислений.
Но, как и любой другой процесс, характеризующийся словами “рутина”, “точность” и “вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.
Процесс расчетов
Прежде всего нам следует определиться с тем, как в общем случае формируются конечные сроки и стоимость проектов.
Шаг 1: Оценка задач
Первое, что необходимо сделать после изучения требований заказчика, это разделить проект на независимые друг от друга функциональные части (задачи). К примеру, если мы выполняем оценку мобильного приложения для стандартного интернет-магазина, то деление может выглядеть примерно следующим образом:
Шаг 2: Расчет сроков разработки проекта
Как бы ни старалась разработчики, но их оценка сроков крайне редко соответствует действительности. Так что, первым делом, отталкиваясь от сложности проекта и опыта команды, мы определяем страховку: количество дополнительного времени, необходимого для разрешения различных непредвиденных обстоятельств. Обычно страховка выглядит как некоторый множитель (процент), на который увеличивается общий срок разработки.
Далее нам следует определить очередность этапов выполнения работ (workflow). Вне зависимости от используемой методологии (agile или waterfall) нам нужно знать в каком порядке нашей командой выполняются различные виды работ. В рассматриваемом нами примере с мобильным приложением порядок мог бы выглядеть следующим образом:
То есть, сначала независимо друг от друга выполняется разработка бэк-энда и пользовательского интерфейса, и при их завершении начинается параллельное программирование приложения под разные платформы. После того, как все этапы будут завершены, проект будет считается выполненным.
Теперь мы располагаем всей необходимой информацией и можем приступить к расчету сроков:
В случае с Waterfall: суммируем количество времени для каждого вида работ (UI/UX, Back-end, etc.), добавляем к ним страховку, и, учитывая их очередность, находим самую длительную последовательность работ, которая, собственно, и представляет общее количество времени, необходимое для реализации проекта.
В случае с Agile: учитывая очередность работ, мы определяем время на реализацию каждой из задач (каталог товаров, новости, etc.), после чего, путем их суммирования и добавления страховки, получаем конечный срок реализации проекта.
Шаг 3: Расчет стоимости разработки проекта
Следующее, что нам следует получить — это себестоимость проекта, которая обычно формируется из двух типов затрат: общих ежемесячных расходов (аренда офиса, оплата серверов, лицензий на ПО, etc.) и зарплат непосредственных исполнителей проекта. Что касается зарплат менеджмента, то они больше подходят к первой категории, так как являются более “пассивной” статьей расходов, и в некоторых случаях они могут быть опциональными (к примеру, если речь идет о небольшой команде фрилансеров).
“Общие ежемесячные расходы” рассчитываются предельно просто: делим их сумму на среднее количество дней в месяце и умножаем на количество календарных дней, необходимых для реализации проекта.
Расчет расходов на зарплаты исполнителей зависит от используемой методологии разработки:
В случае с Waterfall: для каждого сотрудника делим ежемесячную зарплату на среднее количество рабочих дней в месяце и умножаем результат на количество рабочих дней, необходимых для реализации этапа работ, за который он ответственен; в конце суммируем все выплаты.
В случае с Agile: для каждого сотрудника делим зарплату на среднее количество рабочих дней в месяце и умножаем на количество рабочих дней, необходимых для реализации всего проекта, в конце суммируем результаты.
Теперь, зная себестоимость проекта (выплаты исполнителям + общие расходы), мы можем получить конечную стоимость, добавив к ней ещё пару вещей:
1. Прибыль: здесь все довольно просто, мы либо прибавляем желаемый процент от себестоимости проекта, либо добавляем соответствующий пункт к “общим расходам” (если желаем получать фиксированный ежемесячный доход).
2. Налоги: каждый считает их немного по-своему в связи с разнообразием систем налогообложения и способов уклонениях от них. В некоторых случаях можно считать налоги как некоторый усредненный процент от себестоимости проекта с включенной прибылью.
3. Комиссия менеджера по продажам: зависит от ваших условий сотрудничества, если вы выплачиваете процент от сделки, то это процент от суммы себестоимости, прибыли и налогов, и если вы выплачиваете процент от прибыли, то, очевидно, считаете ее как процент от заложенной прибыли, полученной в первом пункте.
Итак, теперь мы располагаем итоговой стоимостью проекта. Но что делать, если клиент, услышав результат, спросит нас: “А что если сделаем без X?”.
Автоматизация вычислений
Можно ли разработать приложение, которое бы производило подобные расчеты автоматически? Ознакомившись с процессом вычислений, теперь мы можем сказать, что да, это возможно, но не без пары нюансов. И первый из них — это расчет налоговой части.
Учет всех возможных вариантов налогообложения при расчетах требует не только значительных трудозатрат на разработку, но и на постоянную поддержку формул в актуальном состоянии. Вариантов решения проблемы здесь несколько: либо жертвуем точностью расчетов и считаем налоги как некоторый процент от стоимости проекта, либо же значительно усложняем систему расчетов, добавляя возможность ее ручной модификации.
Следующий нюанс — это способ безопасного хранения информации о всех расходах, зарплатах и проектах компании. Здесь тоже есть несколько возможных вариантов:
— Жизнь сотрудника, занимающимся расчетами, станет немного легче
— Клиенты смогут получать перерасчеты в считанные секунды
— Стоимость разработки станет чуть более справедливой и конкурентной
На сегодняшний день существует очень небольшое количество решений для подобного вида расчетов, и все они имеют достаточно высокий порог вхождения из-за своей монструозности. В связи с этим хотелось бы задать вопрос аудитории Хабра: а каким способом выполняются расчеты в вашей компании?
Раздел III. Порядок реализации проекта
Раздел III. Порядок реализации проекта
1. После утверждения паспорта проекта и календарного плана руководитель проекта совместно с командой проекта приступают к реализации проекта.
2. На стадии реализации проекта выполняются предусмотренные календарным планом работы проекта для получения продукта проекта и обеспечения достижения целей проекта.
3. При реализации проекта выполняются следующие действия:
— организация выполнения работ;
— контроль выполнения работ;
— приемка продукта проекта и (или) элементов продукта проекта.
4. Для документирования информации о текущем состоянии проекта готовятся статус-отчеты по проекту.
Статус-отчеты по проекту готовятся ежемесячно, если на стадии планирования проекта руководителем проекта по согласованию с проектным офисом и управляющим комитетом не определена иная периодичность подготовки статус-отчета по проекту.
5. Завершением стадии реализации является приемка продукта проекта, его элементов.
6. В целях организации выполнения работ:
6.1. Руководитель проекта дает обязательные для исполнения поручения участникам команды проекта, ставит задачи по выполнению работ участникам команды проекта, связанные с организацией проектной деятельности, координирует их действия.
Для этого проводятся стартовое совещание и регулярные совещания команды проекта, организуется взаимодействие участников команды проекта посредством письменных и устных коммуникаций.
Стартовое совещание команды проекта проводится в течение пяти рабочих дней с момента утверждения календарного плана. Руководитель проекта или администратор проекта уведомляют проектный офис о дате, времени и месте проведения стартового совещания. На стартовом совещании руководитель проекта информирует участников команды проекта об общем порядке реализации проекта, их задачах, ответственности и функциях, порядке осуществления коммуникаций внутри команды проекта, сроках подготовки отчетности по проекту.
Регулярные совещания команды проекта проводятся для обсуждения проблем, принятия решений внутри команды проекта, информирования участников команды проекта о текущем состоянии проекта, решениях, принятых в отношении проекта управляющим комитетом или проектным комитетом. Регулярные совещания могут проводиться на основании предложений управляющего комитета или проектного офиса.
Если проблема не решена командой проекта и (или) решение такой проблемы выходит за рамки полномочий руководителя проекта, то рассмотрение проблемы передается куратору проекта. В случае если проблема не решена куратором проекта, то ее рассмотрение передается в управляющий комитет. Если проблема не решена управляющим комитетом, руководитель проекта обращается в проектный офис для совместной работы по ее разрешению. При этом проектный офис рассматривает вопрос о возможности передачи проблемы на рассмотрение проектному комитету.
6.2. Администратор проекта осуществляет подготовку и организацию совещаний, документирование поручений, информирование участников команды проекта по всем необходимым вопросам, организует документооборот, осуществляет ведение архива проекта.
6.3. Исполнители обеспечивают выполнение работ и поручений, по которым они являются ответственными, качественно и в сроки, указанные в календарном плане либо установленные руководителем проекта, в обязательном порядке принимают участие в совещаниях, организуемых руководителем проекта.
7. В целях контроля выполнения работ:
7.1. Исполнители обязаны предоставлять администратору проекта информацию о выполнении поручений и работ (о фактических и прогнозных сроках выполнения, степени завершения работ, отклонениях фактических показателей от запланированных и их причинах) по факту их выполнения в срок не позднее одного рабочего дня, следующего за днем выполнения работы, поручения.
Исполнители обязаны информировать администратора проекта о проблемах, рисках по мере их возникновения в проекте.
7.2. Администратор проекта осуществляет сбор информации, поступившей от исполнителей, ее анализ, отмечает достижение контрольных точек и исполнение поручений на основании предоставленной исполнителями информации готовит статус-отчет по проекту. Администратор проекта вправе дополнительно запрашивать у исполнителей информацию и материалы, необходимые для подготовки статус-отчета по проекту.
7.3. Руководитель проекта осуществляет постоянный мониторинг выполнения работ для обеспечения реализации проекта в запланированные сроки, с соблюдением параметров, зафиксированных в управленческих документах по проекту.
Руководитель проекта рассматривает статус-отчет по проекту, анализирует информацию о фактическом выполнении работ и достижении контрольных точек, исполнении поручений, проблемах, рисках, возникших в проекте. При наличии прогнозируемых и (или) возникших отклонений выявляет причины их возникновения, оценивает их влияние на проект, принимает решение о корректирующих методах воздействия.
В качестве корректирующих методов воздействия руководитель проекта может перераспределить ресурсы между работами, организовать выполнение нескольких работ одновременно, перенести часть наименее важных для завершения этапа работ на более поздние сроки, использовать дополнительные методы мотивации исполнителей работ и (или) внести изменения в управленческие документы в порядке, установленном разделом V настоящего регламента.
Руководитель проекта фиксирует в статус-отчете по проекту информацию о принятом решении, о корректирующих методах воздействия, а также о связанных с данным решением изменениях сроков выполнения работ.
7.4. Администратор проекта обеспечивает направление статус-отчета по проекту в проектный офис и управляющий комитет в срок не позднее четырех рабочих дней по окончании отчетного периода. Администратор проекта является ответственным за соблюдение срока направления статус-отчета по проекту в проектный офис и управляющий комитет.
7.5. Проектный офис, управляющий комитет, заинтересованная общественность на основании статус-отчета по проекту осуществляют контроль выполнения работ, достижения контрольных точек, поручений по проекту, на основании чего делают вывод о своевременности достижения промежуточных результатов проекта.
Управляющий комитет, заинтересованная общественность по результатам анализа статус-отчета по проекту направляет руководителю проекта замечания и (или) предложения по проекту в срок не позднее трех рабочих дней с момента поступления к ним такого статус-отчета.
Информация, поступившая от заинтересованной общественности, членов управляющего комитета подлежит направлению руководителем проекта в проектный офис не позднее чем за семь рабочих дней до даты очередного заседания проектного комитета.
8. В ходе реализации проекта куратор проекта по представлению руководителя проекта осуществляет оценку участников проектной деятельности в целях принятия в отношении них кадровых решений, решений о применении мер стимулирующего характера.
9. В случае если получен продукт проекта или элемент продукта проекта, а также в случае принятия решения о досрочном закрытии проекта, руководитель проекта организует приемку продукта проекта и (или) элементов продукта проекта.
10. В целях приемки продукта проекта и (или) элементов продукта проекта:
10.1. Руководитель проекта организует сбор и анализ документов, подтверждающих завершение работ по проекту и получение продукта проекта, элементов продукта проекта (например, протоколов приемосдаточных испытаний, актов приема-передачи результатов), а также проводит оценку соответствия полученного продукта проекта, элементов продукта проекта требованиям, содержащимся в паспорте проекта.
10.2. Руководитель проекта организует заседание управляющего комитета (с обязательным участием заказчика проекта), на котором осуществляется рассмотрение документов, подтверждающих завершение работ по проекту и получение продукта проекта, элементов продукта проекта, на основании чего осуществляется приемка продукта проекта и (или) элемента продукта проекта.
Результаты рассмотрения документов приемки фиксируются в протоколе заседания управляющего комитета. К протоколу прикладываются все документы, на основании которых осуществлялась приемка продукта проекта, элементов продукта проекта.
Контрольная точка по приемке продукта проекта, элементов продукта проекта считается достигнутой в момент подписания протокола заседания управляющего комитета, зафиксировавшего их приемку. К статус-отчету по проекту, содержащему информацию о получении продукта проекта, элементов продукта проекта и направляемому в проектный офис, управляющий комитет, должны быть приложены протоколы заседаний управляющего комитета, иные документы, подтверждающие осуществленную приемку.
10.3. В случае если по итогам заседания управляющего комитета продукт проекта и (или) элементы продукта проекта не приняты по причине несоответствия требованиям, содержащимся в паспорте проекта, руководитель проекта обеспечивает устранение таких несоответствий в срок, установленный управляющим комитетом.
Откройте актуальную версию документа прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.