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

Mr Marmelad,

Все ни чего, только схема с началом и концом нормально уживается в проектах, где есть разделение между ними и отсутствуют множественности стадий. Если по русски, то вход можно представить входом, а можно продолжением (ответвлением) другого процесса. В зависимости от взгляда может поменяться полностью все планирование. Поэтому не компетентный руководитель может завести весь проект в такие дебри... конечно, потом виноваты будут все остальные.
Кстати, схема "начало, продолжение, конец" это вроде как стандарт продажников, а не руководителей проектов.
Десятки непонятных ролей и десятки неправильных ролей, это разные вещи. К сожалению даже маломальский проект в первый же месяц покажет весь список ролей. Гораздо эффективней предусмотреть все роли и распределить их между имеющимися сотрудниками (на каждую роль свою степень ответственности), чем пытаться в последствии растыкивать появившиеся потребности. Это как делать деталь по чертежу: за ранее продумываются размеры и алгоритмы изготовления, вместо того, что бы все это уточнять когда она уже под фрезой.
Очень интересно развивать эту науку на ошибках соседей. Например продукт немного неудачный, потом выясняется, что забыли про роль "тестер". В итоге тестировал сам разработчик, что в корне не верно и гарантировано наличие ошибок, т.к. разработчик думает как сам код.
В общем повторюсь еще раз: автор, лучше посмотри на провалы соседей и посмотри, что они сделали не так.
P.S. Совсем забыл, в моей копилке уже есть примеры удачных и неудачных проектов, а так же работа с продажниками в качестве руководителей и с руководителями ни чего не понимающих в специфике предметной части проекта. Поэтому могу позволить себе немного поспорить

Mr Marmelad,

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

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

Petro123: Наверное я неправильно выразился по аналогии с деталью. Данное сравнение было сделано только для показа важности планирования ролей, а не схожести продаж продуктов и услуг.
Mr Marmelad: Про остальное, скорее тут опять у нас немного недопонимание из-за разных источников информации. Представление процесса "начало-тело-конец" очень удачное решение, но не для предоставления ИТ услуг. Конечно, ту схему которую я пытаюсь описать тоже можно заключить в эти рамки, но при этом разные руководители по разному установят границы между стадиями. Например стадию "начало" будет сложно определить для описанного примера в прошлом моем сообщении. Конечно, сейчас любой сможет провести эту границу, но, если потом сравнить 2 мнения от людей разной квалификации, то выяснится, что понятие "начало" будет разным. Уверяю, именно это и сказывается на проблемность проектов.
Если принять модель процесного подхода ISO9000, то можно значительно сократить "провалы" и, как следствие, увеличить КПД всей деятельности. Именно согласно этому стандарту кроме цепочки "начало-тело-конец" имеется еще упр.воздействие и ресурсы. В этой схеме проще оперировать "непонятным началом" или несколькими стартами на языке доступном и бывшему программисту и простому бухгалтеру. Мое несогласие вызвано тем, что в приведенной Вами схеме трудно учесть распараллеливание, например начала или размытость границы между телом и концом. Хотя, может я и ошибаюсь.
По моему личному мнению, что бы выбрать вариант представления процесса, надо испробовать обе схемы, но лучше все таки посмотреть со стороны какая надежней. Хотя может и лучше "на своей шкуре" пробовать все.

Petro123,

По Вашей ссылке много интересного. Но опять же не до конца согласен, из-за чего не могу опираться на данный источник, как на авторитетный. Если я правильно понял, то автор текста за основу взял дискретное представление отношений заказчика с исполнителем, при этом "уходы в сторону" он тоже пытается описать в рамках своей теории. Тогда как мне кажется необходимо за основу брать приближение. Например фраза:
" ...Процедура известна: вы объясняете компании-разработчику, что нужно сделать, они называют цену, вы ее принимаете, после чего вся ответственность ложится на плечи разработчиков, которые должны создать требуемый программный продукт... "
почти сразу приведет к неудаче. Это отношение необходимо рассматривать со стороны разности опыта и представления (своего рода карты мира) обеих сторон. Если изначально это предусмотреть, то можно максимально минимизировать риски непопадания в обозначенные границы. Согласно теории автора конечная точка определяется заказчиком и до конца проекта, по возможности, она должна быть неизменна, хотя я точно уверен, что эта конечная точка будет располагаться далеко не там, где ее изначально располагает заказчик. Для подтверждения моих слов достаточно просто сравнить на любом оконченном проекте, что хотели и что получили, а после попробовать смоделировать весь ход событий заново.
Может я не правильно понял идею "новой методологии программирования", но ИМХО, не желательно сей документ брать за основополагающий особенно при начале карьеры в проектной деятельности.

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

iscrafm
а что с ИТ услугами не так? у них нет тела или нет конца? Непонятная мысль
В этой схеме не излишество, а нехватка