Имхо - на стадии запуска проекта. И имхо, человек, отвалившийся на старте, безопаснее человека, отвалившегося на финишной прямой.
Это я по свежему неумозрительному опыту, если что.

ninquenaro, а если запуск проекта при этом критически зависит от количества вписавшихся людей? Ну вот реально - слотов вот столько и они физически несовместимы на одном человеке при любом желании.

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

Мне кажется, чем раньше, тем лучше.

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

На счет второго вопроса - ну да, кто-то может сразу отказаться от участия в проекте. А с кем-то можно будет поговорить и решить, что «ок, мы все равно хотим работать на этим проектом вместе, и постараемся сделать так, чтобы интересы всех сторон при этом не пострадали». Информированность дает понимание необходимости заранее приходить и разговаривать в ситуациях, которые могут стать рискованными для проекта. Ну и вообще возможность всячески подстилать соломку заранее.

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

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

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

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

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

"Наш человек" (с)

*абстрагировалась от реальной ситуации*
В начале пути все заинтересованные заявят проект в приоритете, на то они и заинтересованные, но у одних "первичный приоритет" означает приоритет над другими приоритетами, а у других - над другими первичными приоритетами. А дальше начинается веселый тетрис про то, что является приоритетом по отношению к чему, что будет первичным приоритетом по умолчанию и прочее подобное. У каждого этот тетрис сойдется по-своему (за редкими исключениями, может быть), и с этим можно сделать примерно, ну, ничего. Просто один готов бросить общее дело, потому что завал на работе/учебе, а другой - потому что завязан в другом общем деле и его, например, форсмажорах. Кроме всего, кстати, есть еще всякие разные форсмажоры, как со стороны проекта, так и со стороны любого из его участников, и эти форсмажоры с тетрисом приоритетов взаимодействуют тоже по-разному.
Универсальный рецепт я знаю один, но он, спасибо все тем же форсмажорам, очень не всегда применим - оговаривать заранее сроки Всего и придерживаться оговоренного. Ничто так не помогает от конфликта приоритетов, как надпись "занято" в календаре.
Да, я написала много бесполезных букв в итоге ни о чем, но это та редкая тема, мимо которой я не могу пройти.
*закончила абстрагироваться от реальной ситуации*

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

Summerroush in Summershell, если не абстрагироваться от реальной ситуации, то это-то я понял, а запись "занято" в календаре появиться ранее чем за месяц не может в связи с тем, что залы, которые нам по карману, задолго не бронируют.
Но вернёмся к умозрительному, что ли, чтобы приоритеты-то не оценивать и не мериться ими.

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

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

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

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

Но вообще без конкретики очень сложно, общие принципы это одно, а в реальности очень может от нюансов зависеть.

Сверять приоритеты, как мне кажется, дело бесполезное. Потому что, если человек очень хочет остаться в проекте, он будет врать, что за него "маму родную продаст", но делать при этом не станет ничего. По моему (примущественно ролевому и ИТ-шному) опыту, в самом начале в проекты набирают (в основной и запасной составы) всех, кто хочет и может (про может см. ниже)
Как показала практика, важнее добиться от участников подтверждения, что они смогут уделить сколько-то часов в неделю этому проекту и обязуются посещать регулярные встречи для подведения текущих итогов (update meetings). На самом деле, посредством этих встреч уже на ранних этапах отсеиваются те, кто не может работать над проектом.
Возникает проблема: что с "неуспевающими" делать? В случае коммерческого проекта, все просто - "бить рублем". Или иной валютой, имеющейся в распоряжении менеджера. В случае проекта некоммерческого (например, подготовки большой ролевой игры и фестиваля), человек просто исключается из команды. Да, неприятно, но что делать. Тащить бездельника за собой очень накладно (потому что его работу приходится перекладывать на других членов команды, и те могут, в свою очередь, обидеться). Как правило, организаторы имеют при себе некоторый запас кадров (запасной состав), которым можно воспользоваться в подобной ситуации.
Тонкий момент здесь в умении руководителя проекта оценивать ожидаемый вклад от участников. Слишком писсимистичная оценка может отпугнуть новичков, зато она спасает от возможных проблем в будущем, когда от членов команды потребуют по 10-12 часов в неделю вместо 2-3, как оговаривалось ранее.
Если работы по проекту появляются "время от времени", то команду все равно нужно держать в тонусе. Встречаться, обсуждать планы, обсуждать какие-то параллельные проекты, прикидывать сроки. Главное, не дать участникам в затишье разбежаться.