Продукт VS проект: отличия подходов
На связи Factory5 (входит в группу Ctrl2GO) — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.
И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании, и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но Резеда Несынова, исполнительный директор Factory5, разложила всё по полочкам.
Продукт и проект — основные отличия
Начнем с азов продуктовой и проектной разработки. Ниже — сравнительная таблица, которая поможет определить важные составляющие подходов, например, временные промежутки, наборы операций, команду и другое.
Платформа анализа больших данных производственных предприятий Factory5, созданная для повышения эффективности бизнеса за счет аналитики и управления данными — это продукт. А создание алгоритма оптимизации производственной программы, функционирующий на этой платформе, для конкретного клиента — это проект.
Решение для мониторинга эксплуатации и прогноза технического состояния оборудования — это продукт, а внедрить инструмент расчета остаточного ресурса газотурбинной установки у конкретного клиента — это проект.
По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.
Объект управления
В проектном бизнесе объектом управления становятся проекты клиентов, идущие в определённом ритме. Рано или поздно каждый из них заканчивается, и результат проекта переходит в поддержку, либо передается в следующий проект для развития.
Задача руководителя — обеспечить максимальную, в идеале, конечно, стопроцентную, утилизацию ресурсов. Участники команды проекта задействованы неравномерно и не всегда 100% своего времени. Сотрудник может участвовать сразу в нескольких проектах — это возможность эффективно использовать ресурсы. Тут есть много нюансов и рисков, к этому нужно подходить правильно. Уверены, эта тема достойна отдельной статьи.
Создание продукта — это процесс, стремящийся к бесконечности. Объект управления — метрики успешности и качества продукта. Команда тоже работает ритмично, но эти ритмы складываются в циклы постоянного улучшения продукта. Схематично классический процесс продуктового управления выглядит так:
Для себя мы определили жесткое правило: между проектной и продуктовой разработкой нужно строить железобетонную стену, иначе срочные проекты гарантированно сместят все продуктовые задачи без заданного дедлайна «на потом». Ни один проект ещё никогда не шёл по плану, точнее шёл по плану, но только по другому.
В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».
Эффективность — на что ориентируемся
не превысить плановую себестоимость,
выполнить требования заказчика.
маржинальность, за счет монетизации и продвижения,
перспективы дальнейшего развития и тиражируемости.
Требования — как ими управлять
Проектная группа ожидает указаний заказчика, да бывает, что проектная команда может предложить какие-то решения, но конечное решение всегда за заказчиком. В любом проекте на старте мы получаем цель и требования к конечному результату, а зачастую заказчик диктует также методы и инструменты реализации.
А основная задача продуктовой команды — обнаружить проблему и потребности пользователей через мониторинг рынка, исследования, интервью с пользователями и так далее. Это главное отличие продукта от проекта. Команда ежедневно формирует гипотезы по развитию своего продукта и проверяет их с точки зрения влияния изменений в продукте или методах его продвижения на его масштабирование на рынок. Для этого используется множество различных методик: конкурентный анализ, аналитика рынка, customer development и др.
Как пример, в команде появляется гипотеза, что клиентам в продукте нужен определенный тип диаграмм. Дальше команда формирует перечень, интересующих нас клиентов, материал для представления — схемы, макеты, описание — планирует структуру интервью, определяют показатели, которые подтвердят или опровергнут их гипотезу и договаривается о встречах с клиентами. На основании проведенных интервью и анализа того, сколько дополнительной выручки мы сможем привлечь, принимается решение о реализации данного функционала в продукте.
Структура работы — как работаем
Реализацию проекта разбивают на маленькие задачи и выполняют их чаще всего последовательно. В целом, когда мы говорим о проектах для клиента — это перечень конкретных задач, сроки и методы реализации, о которых мы заранее договариваемся с заказчиком. Мы можем делать что-то параллельно и даже использовать методику работы по спринтам, но работы сдаются чаще всего по план-графику с жесткими сроками и стоимостью.
Основной принцип продуктовой работы — это проверка продуктовых гипотез, итерационная разработка и постоянный пересмотр приоритетов. Бэклог продукта имеет длину до луны и обратно, и задача менеджера не только генерить и проверять идеи, но и постоянно оценивать, какие из задач бэклога на текущий момент более приоритетные. А после сформировать стратегию релиза нового функционала.
Прежде, чем задача попадёт в бэклог, мы стараемся всеми правдами и неправдами проверить её до того, как начнется разработка. В ход идут и просто исследования, и ux-тестирования, а иногда приходится из дизайн макетов собирать прототип. Лишь после получения обратной связи от достаточного количества клиентов, гипотеза валидируется и берётся в разработку.
Таким образом, одновременно в продукте может быть в проработке несколько гипотез на разной стадии. Задача в разработку переходит тоже дополнительно обработанная. Сначала мы выделяем MVP — минимально-жизнеспособный продукт, который проверяется на некотором количестве клиентов. Если показывать схематично, то работа с продуктом выглядит так:
На данный момент многие проекты используют концепцию MVP в рамках реализации каждой функциональности. И это помогает избежать лишних затрат на разработку ненужной или неэффективной функции, тем самым снижая себестоимость проекта и повышая удовлетворенность клиента.
Ответственность — кто за что отвечает
В проекте клиент берёт на себя ответственность за выбор цели. Задача подрядчиков в данном случае быть профессиональными, быстрыми и системными в достижении этой цели. Не исключено, что команда проекта и клиент могут стать партнерами, которые договариваются об общих целях и способах их достижения, но окончательный выбор всегда за заказчиком.
В создании продукта за постоянный выбор и проверку цели несёт ответственность команда. Среди противоречивых требований и ожиданий многочисленных потребителей важно выявлять те, что позволят максимально масштабировать продукт. Клиенты в данном случае не разделяют с вами ответственность за результат. Продуктовая команда отвечает за окупаемость и масштабируемость, приоритеты в разработке, сервис, продвижение и выбор между быстрыми деньгами и долгосрочным развитием.
Особенности работы в продукте и проекте
Сравним, как отличается работа в продукте и проекте для команды. Возьмем за характеристики временные промежутки для работы, формат работы — постоянный, параллельный, переменный — время достижения результата и другое.
Проект не равно продукт
Есть мнение, что результатом проекта является продукт. Это не правда.
Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:
Проект ориентирован на одного клиента и его специфические требования.
Проект очень редко учитывает требования надежности и безопасности, необходимой для выхода на рынок.
ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:
материалы для продаж,
настроенная служба поддержки и т.д.
Для упаковки ПО в продукт, даже если Вам повезло и по результату проекта получился универсальный функционал, в любом случае нужны вложения и перестройка всех процессов компании для непрерывного развития продукта. После проекта, скорее всего, может появиться технология, которой ещё нужны клиенты и дополнительная ценность.
Резюмируем
В проектной работе вас ждут быстрые результаты, драйв от жёстких дедлайнов, работа в режиме многозадачности, следование требованиям клиента и ограничения в ответственности.
В продуктовой же разработке время уделяется генерации идей, здесь есть причастность к чему-то большому и значимому, много работы в неопределенности и условиях изменяющегося рынка и ответственность за свои решения.
Основы проектной деятельности
ID (номер) заказа
2391749
Бюджет проекта с учетом рисков
Оценка бюджета Сумма, рубПлановый бюджет 1 030 000
Страховой резерв (= уровень предвиденных рисков) 60 000
Резерв на непредвиденные обстоятельства (= 10% бюджета) 103 000
Ожидаемый бюджет 1 193 000
Список использованной литературы1. Ильина, О. Н. Методология управления проектами : становление, современное состояние и развитие : монография / О. Н. Ильина. — М. : Вузовский учебник, 2015. — 208 с.
2. Хелдман, К. Управление проектами : Быстрый старт / К. Хелдман. — Саратов : Профобразование, 2017. — 352 c.
3. Левушкина, С. В. Основы проектного менеджмента : учеб. пособие для вузов / С. В. Левушкина. — Ставрополь : Ставропольский государственный аграрный университет, 2017. — 190 с.
4. Поляков, Н. А. Управление инновационными проектами : учебник и практикум для академического бакалавриата / Н. А. Поляков, О. В. Мотовилов, Н. В. Лукашов. — М. : Юрайт, 2019. — 330 с.
5. Проектная деятельность как способ развития личности студентов и их профессиональной подготовки : метод. указания / сост. Е. А.Булатова. — Н. Новгород : Нижегородский государственный архитектурно-строительный университет. — 32 c.
6. Сурова, Н. Ю. Проектный менеджмент в социальной сфере и дизайн-мышление : учеб. пособие / Н. Ю. Сурова. — М. : Юнити-Дана, 2015. — 415 с.
Нет нужной работы в каталоге?
Сделайте индивидуальный заказ на нашем сервисе. Там эксперты помогают с учебой без посредников 
Разместите задание – сайт бесплатно отправит его исполнителя, и они предложат цены.
Цены ниже, чем в агентствах и у конкурентов
Вы работаете с экспертами напрямую. Поэтому стоимость работ приятно вас удивит
Что не является проектом?
IT-проекты
Проектный замысел
Уважаемые друзья, если вы открыли этот документ, значит, либо вы уже твёрдо решили, что в ближайший год вы будете делать проект в сфере IT, либо вы находитесь в процессе выбора. Ну или вам просто любопытно, что, в общем, тоже неплохо.
Итак, IT-проект. Думаем, слово «проект» вы уже слышали раз двести и вряд ли здесь имеет смысл давать какое-то определение. Хотя, c другой стороны, чтобы у вас не возникло ощущение, что мы относимся ко всему легкомысленно, приведём цитату из документа под названием “Национальный стандарт Российской Федерации ГОСТ Р ИСО 21500-2014 – Руководство по проектному менеджменту (англ. ISO 21500:2012 Guidance on project management)”:
“Проект состоит из уникального набора процессов. Процессы состоят из координируемых и контролируемых работ с датами начала и окончания, которые выполняются для достижения целей проекта. Достижение целей проекта требует получения определенных результатов, отвечающих конкретным требованиям. При реализации проекта могут действовать множество ограничений, включая описанные в подразделе 3.11.
Несмотря на возможное сходство каждый проект уникален. Проект может отличаться:
· составом влияющих на проект заинтересованных лиц;
· особенностями использования процессов проектного менеджмента для получения результатов. ”[1]
К моменту дедлайна у «заказчика» (а тут кавычки и несколько секунд позже вы поймёте, почему) проект должен быть уже полностью готов к работе. Что это значит?
Если у вас мобильное приложение, то оно в идеале оно должно присутствовать в AppStore / Google Play, но, если с этим возникнут разного рода сложности, то этот пункт можно смягчить до предоставления полностью готового проекта (в терминах той среды разработки, которой вы пользуетесь), который, опять же, будет собран и протестирован локально.
Если же у вас десктоп-приложение, то здесь всё просто: код и установочные файлы должны быть предоставлены тестировщикам к определённому дню.
Резюме: на защиту выносится полностью готовый продукт, требующий только установки и настройки параметров со стороны пользователя (конечно, если последнее предусмотрено самой концепцией проекта).
Возможно, вы уже спрашиваете себя или Вселенную: хм, а кто такой заказчик? Есть два варианта: заказчиком может быть реальный человек (родственник, друг, деловой партнёр, кто угодно), который попросил вас написать приложение/сайт/что угодно для своих задач. Он ставит перед вами задачу и, если она проходит этап предзащиты, вы приступаете к работе. В данном случае нам бы очень хотелось иметь возможность общения с вашим заказчиком (мы не будет отрывать его от дел и забот каждую неделю, конечно, речь идёт о разумной консультации).
Но, может так случиться, что к вам никто не обратится. Пожалуйста, в этом случае, не выдумывайте заказчиков. Не говорите нам, что ваш троюродный дедушка заказал вам игру-стрелялку, если, в действительности, у вас нет троюродного дедушки или он есть, но он просил вас написать ему игру-головоломку. Вместо этого будьте готовы поразмышлять на тему, какой могла бы быть целевая аудитория у вашего проекта. Целевая аудитория – это те люди, которые могли бы заинтересоваться вашим проектом и со временем стать заказчиками, например, обновлённой версии вашего продукта с дополнительным функционалом.
Что не является проектом?
1) Естественно, не является проектом результат чужой работы. Мы не будем говорить, что будет в случае, если кто-то попадётся на плагиате. И так понятно, что ничего хорошего.
Тем не менее, отметим важный момент: поскольку весь код с нуля, понятное дело, вы писать не будете, вам нужно будет в документации к проекту указать, какие именно библиотеки, фреймворки и т. п. вы используете. Это разумно, это не нарушает авторские права и отдаёт дань уважения тем, кто создал этот код до нас.
3) Не может быть представлен к защите проект, который трудно или даже невозможно протестировать в аудитории. Допустим, ваш проект предусматривает работу с геолокацией и отслеживанием координат общественного транспорта, например, автобусов. Как мы узнаем, что ваш проект, действительно, работает с геолокацией автобусов и работает правильно? Увы, отправиться в пешую прогулку по Москве вслед за автобусами у нас возможности не будет. Или, допустим, вы написали приложение, которое каждые сутки выполняет какую-то функцию. А защита длится всего 10-15 минут. В общем, думаем, намёк понятен. Функционал приложения должен демонстрироваться в отведённое на защиту время в обыкновенной лицейской среде.
Здесь же упомянем проекты, которые требуют необычной (нетипичной для нашего Лицея) экспертной оценки. Допустим, вы написали переводчик с русского языка на кхмерский. Подозреваем, в Лицее на кхмерском не говорит никто, и не факт, что мы сумеем найти быстро и к нужному времени эксперта в этой области. Поэтому обращаем ваше внимание на то, что, если ваш проект требует экспертной оценки со стороны, пожалуйста, согласуйте это с нами заранее. Если у вас возникли сомнения, что такая оценка понадобится, пожалуйста, проконсультируйтесь с нами.
4) Не является проектом и тот код, где вы выступили только пользователем каких-то библиотек, а сами только «прикрутили» к ним интерфейс. Пример: допустим, вы написали приложение, которое подсчитывает число котиков на фотографии, использовав для этого машинное обучение-глубокое обучение-нейросети и всё то, что сегодня гремит во всех медиа. Если же вы при этом нейросети и алгоритмы обучения взяли из библиотек, а ваша работа свелась к написанию интерфейса загрузки фотографий и вызову функции countCats(‘file.jpg’) (мы утрируем, конечно, но вы понимаете), то это не может быть признано проектом.
Значит ли это, что нельзя считать котиков посредством нейросети? Нет. Но будьте готовы:
1. писать нейросеть и все алгоритмы сами,
2. понимать математику, которая за ней стоит.
Разумеется, это не значит, что нужно вообще всё писать с нуля. Но должен быть разумный баланс между использованием своего кода и чужого, который достигается на этапе обсуждения проектной заявки.
6) Проекты без GUI – то есть, без графического пользовательского интерфейса. Причина всё так же: как правило, проекты без GUI – это что-то очень специфическое, не ориентированное на широкий круг пользователей.
7) Сайты-визитки, сайты-справочники, сайты для поклонников чего-либо и другие сайты, назначение которых – сообщение какой-либо информации для пользователя. Как правило, на таких сайтах может не быть никакого бэкенда или он очень примитивный. Функционал таких сайтов тоже очень простой. Как правило – это показ страниц с определённой информацией, иногда – примитивная гостевая книга, в которой можно оставлять комментарии.
8) Странные проекты. Хм, а что это такое? Мы, конечно, думаем, что таких проектов у нас не будет, но и обойти их своим вниманием мы тоже не можем. Представьте, что вы написали проект, который просит пользователя ввести число, а затем выводит столько кружочков, сколько было указано. Проект всем понятен, доступен, сами вы всё про него знаете и можете отчитаться за каждую запятую и точку с запятой в нём. Возникает, однако, один простой вопрос: зачем? Какую задачу решает вывод двадцати кружочков на экран? Кому это нужно?
Даже если бы вы нас убедили, что проект с кружочками сделает счастливым многих людей, он бы не прошёл по критерию сложности. Поскольку этот раздел оказался достаточно длинным, давайте передохнём, а потом продолжим.
Пример с кружочками довольного искусственный, но, допустим, вы решили написать программу, которая считает корни квадратного уравнения. Это полезно, вы понимаете, как происходят вычисления, но. это слишком просто. Для решения непосредственно задачи вычисления корней нужно несколько строк кода. Даже если вы никогда не изучали программирование до этого, вычислить корни квадратного уравнения вы сможете уже на втором-третьем занятии. Здесь нет ни сложной математики, ни трудоёмкого программирования, ни концептуально трудноосмыслимых понятий.
Тут можно спросить (мы поймём, если вы будете спрашивать с ехидной интонацией): а как вы будете измерять сложность проекта? Ответ: никак. Проект это не стол, его линейкой не измерить. Аршином общим тоже. Именно для этого нужен этап предзащиты и согласования проектной заявки: в процессе обсуждения мы сможем прийти к общему знаменателю и решить, как усложнить ваш проект, если заявка выглядит слишком простой, или, наоборот, предупредить вас о том, что стоящая перед вами задача потребует от вас слишком много временных затрат.
Первый раздел нашего документа подошёл к концу. Что нужно сделать сейчас? Совет: изложите «вольным стилем» в одном абзаце суть вашего продукта и посмотрите, насколько ваша задумка соответствует перечисленным выше требованиям.
Эти требования вам могут показаться очень строгими. На самом деле, они нужны для того, чтобы отсечь крайности. Если вам кажется, что приведённые выше требования слишком несправедливы или не могут применяться к вашему проекту, пожалуйста, сообщите нам об этом.
Управление проектами
Понятие проекта. Виды и классификация проектов
1. Понятие проекта. Виды и классификация проектов
В различных источниках можно найти разнообразные определения понятия «проект»; в целом, они не противоречат, а дополняют друг друга. Проект (англ. project)– это:
Ключевыми особенностями проекта являются:
Таким образом, многие проекты – уникальные в своем роде четко определенные действия, направленные на получение конкретных результатов в многофункциональном окружении в течение установленного срока и в рамках выделенных ресурсов с привлечением группы людей, обладающих разносторонними навыками и знаниями, работающих под специальным руководством.
1.2 Проект как объект управления
Проект как объект управления описывается совокупностью характеристик: назначение проекта, его стоимость, качество, сроки исполнения, риски и т.д. (табл. 1).
Предметная область проекта – содержательная сущность проекта: цели проекта, задачи, объемы работ и ресурсов, необходимых для их достижения.
Цель проекта – желаемый результат деятельности, достигаемый в пределах установленного интервала времени.
Стратегия проекта – центральное звено, как в подготовке, так и в оценке проекта, а также в построении соответствующей маркетинговой стратегии. Стратегия проекта – это комплекс целей и принципов, позволяющих распределить необходимые ресурсы на период времени, представляющий собой горизонт планирования проекта.
— описываются новые продукты или услуги, которые получит потребитель в результате реализации проекта
— сметные затраты, необходимые для выполнения работ проекта
Объемы работ проекта
— количественные показатели объема работ проекта
Сроки выполнения проекта
— время выполнения проекта (даты начала, окончания, продолжительность)
— соответствие характеристик проекта и его продукции установленным стандартам качества
— ресурсы, требующиеся для осуществления проекта, например, оборудование, материалы, персонал, программное обеспечение, информационные системы, производственные площади и др.
— специалисты и организации, привлеченные к выполнению работ проекта, их количественные характеристики, состав (назначение) и квалификация
— определение рискованных событий в проекте, вероятности их свершения и ущерба от их воздействия на проект
Понятие инвестиционный проект употребляется в двух смыслах. Инвестиционный проект:
– это комплексный план мероприятий, включающий проектирование, капитальное строительство, приобретение технологий и оборудования, подготовку кадров и т.д., направленных на создание нового или модернизацию (расширение) действующего производства товаров (продукции, работ, услуг) с целью получения экономической выгоды.
– это система организационно-правовых и расчетно-финансовых документов, необходимых для осуществления каких-либо действий или описывающих такие действия.
В «Методических рекомендациях по оценке эффективности инвестиционных проектов» приводится следующее определение: инвестиционный проект – обоснование экономической целесообразности, объема и сроков осуществления капитальных вложений, в том числе необходимая проектно–сметная документация, разработанная в соответствии с законодательством РФ и утвержденными в установленном порядке стандартами (нормами и правилами), а также описание практических действий по осуществлению инвестиций (бизнес-план). Проектно–сметная документация представляет собой пакет документов, определяющих место строительства (реконструкции) будущего объекта, его архитектурное и конструктивное решение, потребность в кадрах, строительных материалах, машинах и оборудовании, денежных средствах
1.3. Классификация проектов
Проекты различаются по уровню, масштабам изменений, широте охвата, по требованиям к качеству и способам его обеспечения, по совокупности проектов, по уровню участников, по характеру целевой задачи, по объекту инвестиционной деятельности, по главной причине возникновения проекта.
Проекты различаются в зависимости от:
Классификация проектов приведена в таблице 2.
По масштабу (размеру) проекта
По срокам реализации
По требованиям к качеству и способам его обеспечения
По совокупности проектов
По уровню участников
По характеру целевой задачи
По объекту инвестиционной деятельности
По главной причине возникновения проекта
Необходимость структурно-функциональных преобразований
Монопроект – это отдельный проект различного типа, вида и масштаба. Мультипроект представляет собой комплексный проект или программу, состоящую из ряда монопроектов и требующую применения мультипроектного управления. Мегапроекты – это целевые программы, содержащие множество взаимосвязанных проектов, объединенных общей целью, выделенными ресурсами и отпущенным на их выполнение временем. Такие программы могут быть международными, государственными, национальными, региональными межотраслевые, отраслевые и смешанные. Программы формируются, поддерживаются и координируются на верхних уровнях управления: государственном, республиканском, областном, муниципальном.
Краткосрочные проекты реализуются на предприятиях по производству нововведений различного рода, опытных установках, восстановительных работах. Бездефектные проекты в качестве доминирующего фактора используют повышенное качество.
Международные проекты обычно выделяются значительной сложностью и стоимостью. Их отличает важная роль в экономике и политике тех стран, для которых они разрабатываются. Эти проекты основаны на взаимодополняющих отношениях и возможностях партнеров.
В научной литературе выделяются также инновационные проекты. Абсолютное большинство инвестиционных проектов содержат в той или иной степени инновационную составляющую, поэтому разделение проектов на инвестиционные и инновационные достаточно условно. Проекты, которые обеспечивают разработку новых изделий или технологий и предполагают вложения в нематериальные активы, в большей мере претендуют на классификацию их как инновационных.
Несмотря на определенную трудность отнесения проектов к тому или иному виду, увеличение в них доли работ, направленных на создание инноваций, меняет характеристики проектов.
Так, инновационный проект отличается от инвестиционного следующим:
Классификация проектов позволяет достаточно четко ранжировать перспективные и реализуемые проекты, и как следствие, ставить выполнимые цели, задавать реальные сроки достижения целей, и привлекать оптимально необходимые ресурсы для их успешной реализации.
Определение проекта согласно PMBoK 5:
Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов указывает на определенное начало и окончание. Окончание наступает тогда, когда цели проекта достигнуты или когда проект прекращается в связи с тем, что его цели не будут или не могут быть достигнуты, либо когда в проекте больше нет необходимости. Проект также может быть прекращен, если клиент (заказчик, спонсор или ответственное лицо) желает прекратить проект. «Временный» не обязательно предполагает краткую длительность проекта. Это относится к вовлеченности в проект и длительности проекта. «Временный», как правило, не относится к создаваемому в ходе проекта продукту, услуге или результату. Большинство проектов предпринимается для достижения устойчивого, длительного результата. Например, проект по возведению памятника государственного значения создаст результат, который останется на века. Проекты также могут приводить к воздействиям на социальную, экономическую и окружающую среду, превышающим длительность самого проекта.
Каждый проект приводит к созданию уникального продукта, услуги или результата. Конечный результат проекта может быть осязаемым или неосязаемым. Несмотря на то что в некоторых операциях и поставляемых результатах проекта могут присутствовать повторяющиеся элементы, их наличие не нарушает принципиальной уникальности работ по проекту. Например, офисные здания могут строиться из одинаковых материалов или одной и той же строительной бригадой. Но каждый такой строительный проект будет уникальным ввиду разного местоположения, отличий в архитектуре, обстоятельствах, ситуациях, разных заинтересованных сторон и т. д.
Текущая деятельность, как правило, представляет собой повторяющийся процесс, который выполняется в соответствии с существующими в организации процедурами. И, наоборот, по причине уникального характера проектов, возможны неопределенности или различия в отношении продуктов, услуг или результатов, создаваемых в ходе проекта. Операции проекта могут быть новыми для членов команды проекта, что обусловливает необходимость более тщательного планирования, в отличие от рутинных работ. Кроме того, проекты предпринимаются на всех уровнях организации. В проекте может участвовать один или несколько человек, одно структурное подразделение организации или несколько структурных подразделений различных организаций.
Проект может создать: