Работа в команде – главное условие успеха, поэтому руководитель проекта является ключевым элементом в структуре любой организации. Проектная деятельность присутствует практически во всех областях, и неважно, разрабатываем ли мы новую обувь или компьютерную программу, деятельность по разработке и созданию данных продуктов будет реализована через проект. Люди, занимающие пост руководителя проекта, играют роль особенную и стратегически важную. Поэтому для каждого сотрудника, который возложил на свои плечи эту интересную и одновременно сложную ношу, будут полезны данные рекомендации. Они помогут вам на первом этапе не совершать крупных ошибок.
1. Семь раз отмерь – один раз отрежь
Данная поговорка показывает основное правило проектной деятельности. Прежде чем с головой окунуться в проект, необходимо все очень хорошо спланировать. В будущем это избавит вас от различного рода переделок и изменений, которые потребуют дополнительных затрат. Поэтому опытный менеджер понимает, что время, потраченное на подготовку и тщательное планирование, обязательно принесет свои дивиденды.
2. Без стандарта никуда
Как и любая деятельность организации, проектная деятельность должна быть стандартизирована. Положение или регламент по организации проектной работы – это один из основных документов вашей компании. Он определяет ключевые роли, в том числе: заказчика, исполнителя, руководителя проекта, спонсора проекта и т.д. Этот документ является общим для всей организации. Он обеспечивает единство подходов, понимание целей и результатов, закладывает основу для всестороннего сотрудничества и сводит к минимуму организационные проблемы, на всех этапах реализации проекта.
3. У каждого своя роль
Для успешной реализации проекта вы должны максимально вовлечь все заинтересованные стороны. Чтобы правильно определить всех участников, нарисуйте небольшую схему или структуру всех заинтересованных сторон, с обозначением границ ответственности, основного функционала и ресурсов каждой стороны. После этого обязательно проведите личные встречи с каждым задействованным участником и обсудите тот вклад, который он внесет в общее дело.
4. Эффективные коммуникации
Поддержка и еще раз поддержка сотрудников, которые входят в состав рабочей группы проекта. Не стройте иллюзий по поводу успешной реализации проекта лишь только потому, что вы выпустили приказ о начале проекта и утвердили состав рабочей группы. Для выстраивания эффективных коммуникаций внутри команды поддержка необходима всем участникам. Не каждый сотрудник умеет выстраивать доверительные взаимоотношения в коллективе. Ваша задача – помочь сделать это быстро и без лишних негативных эмоций. Вы должны помочь каждому участнику понять свою роль, задачу, функционал и при необходимости дать обратную связь. А также вы должны понимать общие проблемы группы, и уметь вовремя их решить.
5. Береженого Бог бережет
Всегда оценивайте риск. Каждый руководитель проекта понимает, что риск есть в каждом деле. Поэтому никогда не останавливайте работу по оценке рисков и своевременной подготовке превентивных мер. Вы должны быть всегда готовы к тому, что что-то пойдет не так. В этом случае у вас должны быть разработаны несколько вариантов решения возникших проблем. Только в этом случае вы сэкономите и нервы, и деньги.
6. Будьте гибкими
Единых подходов к управлению проектами не существует, как не существует и абсолютно одинаковых проектов. Выбор методики зависит от целого ряда факторов, таких как характер проекта, опыт, навыки и образование участников группы, сфера деятельности компании, ее масштаб... Поэтому опытные руководители проектов выбирают тот путь, который применим в конкретных условиях и в конкретное время. Мотивируйте и поощряйте сотрудника, который предлагает и применяет различные подходы в своей деятельности. Предоставляйте возможность самостоятельно принимать то решение, которое подходит для проекта именно сегодня.
7. Помогать, но не делать
Роль руководителя проекта – руководить. Руководитель несет полную ответственность за результат, устанавливает требования, обучает, устанавливает доверительные отношения в команде, но только не делает работу за участников команды. Всегда помните это.
8. Отчеты бывают разные
Только необходимая отчетность. На определенных этапах проектной деятельности возникает необходимость подготовки отчетности по результатам деятельности проектной команды. Сведите к минимуму частоту и объем отчетной информации. Лучшее заранее определить контрольные точки и своевременно производить оценку состояния проекта, с привлечением всех заинтересованных сторон. Так вы сэкономите время, затрачиваемое для подготовки отчетности, которую никто не читает и которая не имеет целевого предназначения.
Это лишь основные советы, применяя которые вы повысите эффективность не только своего проекта, но и всей компании в целом.
Вот это неверно, на мой взгляд, в части единых подходов к управлению проектами.
Не совсем так: если Вы в курсе темы, то могли бы заметить, что PMBOK 7 почти в два раза "худее" PMBOK 6.
Это точно. Тут с Вами согласен. Но экспертиза авторов не ниже. чем в вашей организации. У вас может быть только учет местной специфики.
Ну эта логика не выдерживает критики! Ежели в Вашей конторе проектный офис или вообще работа с программами, проектами выстроена профессионально, то у вашей организации должны быть собственные утвержденные стандарты на основе - чего (стандартов, гостов) сочтете нужными. См. п. 2 статьи - автор совершенно справедливо и правильно на это указывает И руководители проекта и команды и советы по проектам - руководствуются именно действующими внутренними стандартами. Работают над проектами и не занимаются текущими глупостями типа "перечитывания какого-либо международного или отраслевого стандарта" и осмысления "как же нам жить дальше"? А иначе, если выбор будет делать каждый рук. проекта - то это просто анархия и отсутствуе политики, организации бизнеса и контроля. Но Вам - виднее, если хозяева оплачивают подобный творческий колхоз - почему нет? Это интересно и даже никакой Высший Разум (ему поклоняются некоторые участники данного ресурса, как недавно выяснилось) не сможет помешать.
Уважаемые коллеги! Вот что меня всегда тревожит в пресловутой проектной деятельности - это практически полное игнорирования или неучет бизне-архитектуры и ее динамики. Может я и преувеличиваю, но большинство причин крахов внешне "успешных проектов" лежит именно здесь. Что скажете?
Единообразие привлекательно, у него много сторонников. Реальность намного богаче.
Сравните например, классический Waterfall, Agile PM (начиная с причин появления и содержания Agile Manifesto) и CCPM. Дискуссии по этому поводу были достаточно жаркими.
С тех пор какие-то идеи пытаются объединить, и это нормально, но для конкретного проекта в конкретной отрасли что-то будет лучше. В другой проекте может быть совсем иначе. Даже без отсылок к неустранимым различиям между строительными проектами и проектами в IT.
Немного в теме.
Возможно, это была вынужденная мера. Я помню толщину и частично вес, начиная с PMBoK 3. Посмотрите на величину аналогичных разделов. В какой-то момент начались вопросы об осмысленности попыток описать в PMBoK всё, что только можно.
Если Вы читаете PMJ и аналогичные ресурсы, ругани было много.
Если мы всё еще о PMBoK, то экспертиза авторов не имеет отношения к проектам, которые мы ведем. Они, по понятным причинам, ничего о них не знают. Местная специфика существует в каждом проекте в каждой стране и отрасли. О ней эти авторы тоже не знают и не могут учесть, но обязан знать менеджер проекта.
PMBoK - хорошие и полезные рекомендации более высокого - по смыслу - уровня, и менеджер проекта может на них ориентироваться. Но, еще раз, его цель - успех проекта, а не формальное следование рекомендациям PMI.
Так и есть. Противоречий я пока не вижу.
О PMO можно поговорить отдельно. А содержание корпоративных документов максимально учитывает специфику организации и проектов, включая оценку и формирование бюджета и резервов, детали планирования, выделение ресурсов, подготовку контрактов, отчетность, процедуру эскалации и многое другое. То есть именно то, что организация считает нужным, как Вы совершенно правильно сказали выше.
Понятно, что на ГОСТы и нормы можно только сослаться - там, где это имеет смысл. Как и на PMBoK и прочие внешние рекомендации и стандарты в части PM. Мы их не пишем, но почему не пользоваться всем, что полезно.
И не будем забывать, даже в целях дискуссии, что перед PMI или ISO менеджер проекта не отчитывается.
Отлично. Кто против? Сотрудник организации не может не руководствоваться внутренними стандартами.Тем более - начинающий менеджер проекта, о котором написана статья.
Звучит ужасно. Но к реальности отношения не имеет. См. выше о корпоративных стандартах.
Зависит от отрасли. В каждой отрасли свои причины провалов проектов и их анализ, если есть соответствующая статистика.
Для IT посмотрите, например, отчеты CHAOS и журналы IEEE.
Дело не в названиях. Тем более - в рамках обсуждаемого.
Проект не существует без плана. Выброшенные на ветер деньги. А план проекта не имеет смысла без проекта. Так же, как проект не существует без реализации - то есть выполнения того, что показано в плане и детализировано в проектных документах.
Сколько в проекте этапов, как и содержание каждого этапа, детально обсуждается и определяется заказчиком и менеджером проекта (обычно) при подготовке контракта. Иногда заказчик даёт свои указания с самого начала.
Не уверен, что понимаю, какой смысл Вы вкладываете в слово "этап". Само по себе планирование не существует - это ближе к маниловщине.
Планирование - часть работы менеджера проекта, отвечающего за успех, а план - один из главных рабочих документов, который появляется до официального начала проекта и обновляется до момента завершения проекта и выполнения контрактных обязательств. Может быть в нескольких версиях одновременно.
Возможно, большая часть того, что Вы назвали исследованием свойств предмета проекта, учитывается при подготовке контракта и первых версий плана проекта. Иногда речь также идет о предпроектном обследовании, но там список конкретных работ менее формален и согласуется с заказчиком в результате переговоров.
Совершенно с Вами согласен. Без моих пояснений сказанное мною было не понятно. Моя вина. Попробую расшифровать что я имел ввиду под этапностью. Вы говорите об этапах, как о планах, а я говорю об этапах, как о процессе реализации. Наверняка в плагах, графиках мы не учитываем анализ предмета инвестиций. Например, мы имеем ТЗ на строительство крупного досугового центра. Там всё логично: эскизный проект, стадия "П", экспертиза проекта, стадия "Р", строительство, ввод в эксплуатацию. Подписывай Договор, бери и делай.
Но есть ещё алгоритм решения нестандартных задач в управлении который мы используем похожий на ТРИЗ Альтшуллера. По этому алгоритму первым этапом всегда следует изучение свойств предмета инвестиций (задачи). Мы это и так делаем, но не осознаём, а значит и не всегда фиксируем результат, и не используем результаты в дальнейшем. Например, без алгоритма или с ним любой профессионал начинает с изучения проектной и прочей документации. Приведённый пример реальный. Мы пошли по своему алгоритму и обнаружили, что Заказчик имеет только подсчёт основных объёмов работ. А генподрядчик получает оплату блоком.
Не буду расписывать все риски Заказчика при такой организации работ. Достаточно того, что при недостаточной проработке объёмов работ, материалов и их стоимости, генподрядчик вкладывает свои риски в увеличение цены. Из многолетней практики это около 30% к реальной стоимости объекта. Если стоимость объекта около 10млрд, Заказчик несёт потери приблизительно - 3млрд. Стоимость составления сметного массива - около 1,5млн., графиков работ и поставок ещё около 500тыс. Вот это разница в подходах по плану и по алгоритму.
Возможно, мы об этом говорили. На всякий случай:
В строительных проектах своя специфика и регламентирующие документы, как и состав работ. Я говорю - прежде всего - о том, что лежит в основе любого проекта. Анализ предмета инвестиций, кому это поручено, как это должно быть сделано и любая другая подготовительная работа выполняется до начала проекта и используется при принятии решения о дате начала и подготовке контракта на выполнение. Возможно обсуждение в нескольких вариантах в зависимости от сделанных допущений.
По итогам цели проекта, критерии успеха, желаемый объем работ и их содержание (Scope), первая версия плана проекта с необходимой в этот момент детализацией и этапностью (Schedule), общий бюджет и график платежей уже известны. Возможно, понятен и список подрядчиков и субподрядчиков.
Есть проекты из одного этапа, есть из нескольких. Это не так важно. На каждом этапе выполняется и передаётся заказчику согласованный объем работ. Может быть связано, например, с бюджетированием по финансовым годам, доступностью чего-то необходимого, графиком поставок, наличием ресурсов, обучением персонала и т.д.. Вариантов много.
Обычно для этого есть предпроектное обследование. Наполните его - вместе с заказчиком - правильным содержанием (это самое важное), используя любые алгоритмы. Лишь бы заказчик был с Вами согласен. Результат обследования - согласованный с заказчиком документ, из которого можно сделать все нужные выводы.
Нужно ли что-то изучать, но не фиксировать результаты - вряд ли. Выглядит странно.
Но проект начинается и выполняется на основании контракта. Именно там указаны взаимные обязательства сторон.
Здесь у нас принципиальные расхождения в понимании когда начало проекта. Мзыскательные работы, подготовка ТЭО это ещё не начало проекта? Допустим, не буду спорить. Но с началом любого проекта возникают непредвиденные влияющие факторы. Например, такой как я описал, или любой другой и мы опять возвращаемся на стадию изысканий и ТЭО и делаем это постоянно до следующего этапа. То есть выходим за рамки проекта и возвращаемся, выходим и возвращаемся. Теория функциональных систем однако.
Это опять дудки. Как Вам может быть известен график платежей, если Вы ещё не заключили договора с исполнителями? Да и детализация возникает после проработки графиков поставок необходимого оборудования и материалов. А если поставки могут иметь сроки отличные от Вашего желания? Особенно в условиях санкций. Нет, Вы будете иметь бюджет и первоначальные графики, которые потом с высокой вероятностью будут меняться.
Вы опять исходите из работ исполнителей, а не руководителя проекта. Даже если проект по графикам из одного этапа, Вы всё равно не минуете три основных эпата реализации любого проекта: исследование предмета инвестиций, выбора исполнителя, контроль выполнения + аудит эффективности. Можете конечно, как это обычно делается, похерить всё, но тогда получите неоптимальный результат. На те самые 30% потерь от стоимости работ.
"Предпроектные", это в системе координат проектной организации, но никак не у Собственника или Заказчика. Если Вы Заказчик, заказывая предпроектные, Вы уже реализуете проект. Возможно у Вас даже до изыскательских работ родится эскизный ПРОЕКТ, бизнес-план, ТЭО. Понимаете о чём я? Вроде и предпроектные, а эскизный проект уже есть.
Да в том то и суть алгоритмов, что они стандартны для некоторых процессов. Добавляя алгоритмы, Вы просто добавляете подпроцессы. А по сути они остаются такими же. Опять же отсылаю к базовым понятиям из теории функциональных систем.
А вот если Ваши мысли про любые алгоритмы иллюстрировать, то это уже из теории организационных систем. Базовые свойства систем неизменны, но при взаимодействии с действительностью нужны корректирующие действия для поддержания системы принятия решений по реализуемому проекту в устойчивом равновесном состоянии. Богданов, создатель теории, автор "Тектологии", очень не конкретен по поводу КАК обеспечить равновесие в реальных условиях. Его полностью поглотило обоснование развития частей систем в конкурентной среде, условиях борьбы противоположностей.
А здесь Вы рассматриваете проект уже с точки зрения Исполнителя, но не Заказчика.
Возможно несовпадение точек зрения, но вряд ли принципиальное - если для нас обоих важен успех проекта и достижение жедаемых результатов.
Далеко не всегда. Выводы делает заказчик. Вполне возможно, что результаты обследования и анализа не совпадут с первоначальными ожиданиями, и заказчик скорректирует свои планы. Если, конечно, делать эту работу честно.
Они есть всегда. Будущее никто не знает, и событий происходит очень много. Какая-то их часть может негативно влиять на параметры проекта.
В этой связи человечество придумало Project Risk Management. Разделы на эту тему присутствуют практически в любом зрелом стандарте и рекомендациях по управлению проектами. Максимально практическая работа, для которой крайне важны отрасль и специфика проекта.
Для меня это означает фундаментальные просчеты и ошибки в части управления проектом. Проект, по сути, так и не начался.
Если я - исполнитель, то мне важно знать заранее знать условия поставок и детали выполнения работ субподрядчиков. Это знание испольуется при подготовке контракта с заказчиком. Ничего особенного, обычная часть предварительной работы.
Не после, а до.
Все исходные данные, включая графики поставок третьими сторонами всего необходимого, собираются до подписания контракта с заказчиком. Если чуть выше мы говорили о деньгам, то здесь - о календарном планировании и этапности.
За поставки отвечают поставщики, включая сроки, объемы и цены. В контрактах с ними обычно есть соответствующие санкции. Они зеркально или близко к этому переносятся в контракт с заказчиком. Эти риски испонитель не может взять на себя.
Я исходу из реальности.
Руководитель проекта на стороне исполнителя планирует этапы вместе с заказчиком. Кто на стороне заказчика принимает участие в обсуждении - его выбор. Были бы полномочия.
Выбор исполнителя всегда на стороне заказчика. Проектов без исполнителя не бывает.
Я не знаю, что имеется в виду под аудитом эффективности. Для успеха проекта это не нужно. Промежуточные и окончательные результаты работ доступны заказчику в соответствии с планом проекта и обязательствами по контракту.
Всё остальное обсуждается выше.
Пока не понимаю.
Для меня, например, ЭП - конкретный документ с определяемым ГОСТом содержанием. Такой документ просто так не готовится и сам собой не появляется, ему предшествуют другие документы, обычно ТЭО и ТЗ. У них тоже есть авторы. И кто-то их работу оплатил.
Верю, что что-то зависит от отрасли. Иногда под проектом имеется в виду не набор активностей, а набор больших и сложных документы. Например, у строителей и архитекторов. Проект типового многоквартирного дома какой-то серии, к примеру. А финансисты часть смешивают проект и бизнес. Бывает.
Не знаю, о каких именно алгоритмах Вы говорите. Но - любой каприз. Если какие-то алгоритмы помогают сделать работу лучше, нет никаких причин не использовать их на благо общему делу.
Я не виноват. Почему "но"? Исполнитель не заключает контракт сам с собой. Как и заказчик.
Стороны контракта (заказчик и исполнитель) подробно и юридически корректно фиксируют на бумаге то, что для них является принципиальным и важным, и контракт может быть достаточно объемным с множеством приложений. Это нормально. Важно, что все проектные документы, которые создаются в ходе проекта по мере необходимости, не могут противоречить контракту - это нарушение.
И начинать проект без контракта - большие риски для всех участников.
Ваш ответ подтверждает мою точку зрения, не находите?
Он то конечно выводы делает, но не может оценить где начало проекта лучше, чем профессионал. Как правило, Заказчик рубит в теме проекта, но не в реализации. Там нужны другие компетенции. Например, он рубит в технологии переработки сырой нефти, но не рубит в строительстве технологических линий.
Риск-менеджмент только часть системы принятия решений при реализации проектов. Только отталкиваясь от рисков невозможно управлять проектом. Если "человечество" считает иначе, то оно ошибается, а я, такой выскочка-одиночка, прав.
Ну, раз он не начался, то и переживать неча. Только денежки уже тю-тю. Нет, по моему мнению, если Вы уже вложили рубль в идею, то проект уже начался. Иначе Вы потеряете деньги. Начало проекта не тогда, когда Вы думаете что первей - курица или яйцо, а когда Вы уже не можете выйти из процесса без потерь. Да, проект может закончиться весьма быстро, если идея завиральная и первичный анализ показывает слишком высокие риски.
Вы то как Исполнитель возможно будете знать важную для Вас информацию, если Заказчик сочтёт нужным проинформировать, но пока детали не будут зафиксированы Договорами, это будут только Ваши хотелки. Не факт, что Заказчик согласится. Да почти никогда не согласится. Интересы разные. Вы, как Исполнитель, хотите поменьше сделать, побольше заплатить, а Заказчик наоборот. И только Договор фиксирует объёмы и этапы финансирования. Заказчик, конечно, для себя будет иметь перспективный план, но Вам он его показывать не станет. Я бы не стал. Да это и не график платежей, помилуйте.
Это в идеале. Но за год или два ситуация может поменяться. Например, как в случае с СВО. Бац, и часть оборудования зависла. Но по сути здесь у нас нет противоречий.
Так и я из реальности. Но реальность какая-то разная. Хорошо, давайте возьмём простой пример - купить шариковые ручки для бухгалтерии. Если Вы их просто купите, то это не проект. Но если Вам нужны ручки тонко, стабильно пишущие, отвечающие каким-либо критериям, то у Вас всё равно будет три этапа.
1. Исследование свойств предмета закупки (определяете критерии предмета закупки).
2. Выбор поставщика (процедура отбора претендентов на заключение договора поставки).
3. Контроль исполнения условий договора поставки (любые проблемы в процессе использования ручек нарушающие условия договора + аудит эффективности).
Таких примеров у меня не было. Но был пример с средствами защиты - рукавицами и перчатками разных свойств. Продукция "Хайфлекс" была слишком дорога. Нужно было выявить потребности, найти альтернативных поставщиков без потери качества, провести испытания в цехах на соответствие качеств, подготовить аналитику по выбору и т.д. Затер провести конкурс по голландской системе, а затем подготовить отчёт по результатам проекта.
Попробую пояснить. Проект для Подрядчика - это реализация строительства по рабочей документации. Проект для Проектировщика - это предпроектные изыскания, разработка проекта и, обычно, авторский надзор. Проект для Заказчика - это составление ТЗ на предпроектные изыскания, ТЗ на проектирование, получение разрешительной документации, контроль строительства и ввод в эксплуатацию. Проект для Собственника - это формирование идеи, основных критериев предмета инвестиций, как результата стратегического маркетинга, организация системы принятия решений по инвестиционному проекту, принятие решений на каждом этапе и контроль неизменности замысла до завершения.
Мне нравится Ваш подход. А насчёт "о каких алгоритмах", возьмите хатя бы - три основных этапа реализации. Кибернетика, штука такая.
Пока нет - точку зрения на что? Возможно, Вы привыкли к другому порядку действий.
Удивительно. Кто кому даёт команду "На старт"?
Если контракт на подписан, а дата начала проекта должна быть указана именно там, то исполнитель может разориться. Нет никаких формальных оснований для платежей в его адрес.
Да, так часто бывает. Для этого и нанимают исполнителя и субподрядчиков. Или разных исполнителей для разных работ в разных проектах, объединённых общим замыслом.
Так и есть. Именно часть системы принятия решений, которые принимаются каждый день. Важная часть, к слову.
Для меня всё это не проект. Просто какая-то деятельность в свободном формате. Никакой исполнитель, думающий о своей репутации на рынке и благополучии, не будет реализовывать завиральные идеи. А заказчик может лишний раз подумать, прежде чем во что-то инвестировать.
Давайте проверим. Заказчик и исполнитель - это юридические лица. Они же - стороны контракта. Нет контракта - не о чем говорить, проекта нет. А содержание контракта и его приложений - предмет переговоров. Шлифовать текст, задавать вопросы и торговаться можно долго. Себе в убыток никто работать не будет. Вроде бы все просто, согласны?
Если я исполнитель в каком-то проекте, то без важной для меня информации я его не начну - мне нужен результат. Заказчик, в свою очередь, напрямую интересован, чтобы цели проекта и критерии успеха были исполнителю - то есть мне - максимально понятны. Дальше - дело техники. Буду стараться изо всех сил, смогу - сделаю.
Практически то же самое, если я заказчик. Мне нужен исполнитель, который меня понимает и доведет этот проект до успешного завершения в соответствии с контрактом. И он никак не сможет это сделать, если я буду скрывать от него что-то важное с точки зрения проекта. А все остальные мои планы исполнителя в конкретном проекте не касаются.
Это риски, их много. См. выше. Что-то в этой ситуации придется поменять или скорректировать планы. Тут главное - говорить друг другу правду и отслеживать ситуацию заранее. Project Risk Management в действии.
Отличная тема.
Пока еще не проект - если Вы как заказчик не нанимаете для этой работы внешнего исполнителя. Просто детали работы отдела закупок. Нужны ручки - найдёт и купит ручки. Нужны станки с ЧПУ - найдет и купит их. С тендером или без тендера - не так важно. А дальше кто-то может проверить, пишут ли эти ручки, и работают ли станки.
Что такое "аудит эффективности", и кто его в этом случае проводит - так и не знаю.
Замечательно. Вас наняли для всего перечисленного в помощь собственным службам и заключили с Вами контракт? Если так, то это можно назвать проектом, все формальные критерии выполнены. Не противоречит ничему из того, что я говорил выше.
Есть другие примеры?
Кто из них исполнитель по контракту? Чей менеджер проекта? Сколько заключается контрактов? Кто перед кем отчитывается?
Всё это само по себе не проект, если не нанимать исполнителей для подготовки каждого документа, но может быть частью работ в проекте. Тот же вопрос, что и выше - кто исполнитель? Если сам заказчик, то это может быть его внутренним проектом, почему нет. А может быть обычной работой для сотрудников соответствующих отделов, за которую они получают зарплату.
Отдельная роль собственника (чего?) в проекте мне не слишком понятна, в отличие от заказчика и исполнителя. В контракте он не упоминается.
Идеи - на здоровье и какие угодно, включая инвестиционные. Пусть себе формируются. Я бы это проектом пока не называл. Хотя как только это слово не используют, особенно финансисты.
У Вас три этапа, у меня бывало и больше. Хотя мы опять говорим о разном. Сколько в контракте этапов прописано, столько и будет выполнено.
Какие при этом используются алгоритмы - у каждого свои и для своих задач, точнее не могу сказать. Нужны ли, к примеру, алгоритмы для решения задачи о ручках?