 |
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif) tutunov | |
|
|
|
|
|
|
|
Есть известный закон управления сроками проекта:
90% объема работ, в среднем, занимает 90% отпущенного времени.
Завершение 10% работ занимает, как правило, еще 90% времени.
Когда очередной раз попался на глаза этот закон, я подумал, что в этой шутке заложена достаточно серьезная мысль и немалый опыт ее автора.
- При "продаже" проекта Заказчику и планировании работ делаются слишком оптимистичные прогнозы. Чем ближе окончание проекта, тем шире открываются глаза на реальные масштабы проблемы.
- Исполнители опасаются сообщать о существенных проблемах до тех пор, пока они неизбежно не выявляются при сдаче всего проекта.
- Ближе к концу проекта, как правило, расположены основные работы по интеграции результата в единое целое, а значит, выясняются многие проблемы. Например:
- Продукт проекта можно проверить на работоспособность только когда он практически готов. И только тут выясняется, какие неприятные сюрпризы заложенные при проектировании и небрежном управлении интеграцией в ходе проекта.
- Продукт проекта можно показать Заказчику только ближе к концу проекта, и тут выясняется, что он имел ввиду совсем другое. Показ отдельных элементов продукта проекта до этого момента может не иметь смысла.
- Вероятность задержки начала интеграции прямо зависит от количества входящих в эту работу цепочек предшествующих работ. Это закон теории вероятности. А ближе к концу проекта таких цепочек может быть очень много.
- Проекты могут быть такими длинными, что к их окончанию существенно изменяются внешние условия, а значит, приходится переделывать результат.
- На начальных этапах жизненного цикла проекта часто экономят на полноценном проектировании и планировании, что приводит к непредусмотренному этапу переделок, бывает, что очень трудоемкому.
- К концу проекта «съедается» большая часть заложенных в отдельных работах резервов времени и становиться нечем компенсировать неожиданные сбои.
- К концу проекта заканчивается бюджет и может, банально, долго изыскиваться новое финансирование.
- Команда проекта может «перегореть» и последние метры будут даваться с огромным трудом.
- Команда проекта может слишком расслабиться и «попасть в аварию перед самым окончанием путешествия».
Мог бы перечислять и дальше, но предлагаю желающим дополнить своими примерами или просто поразмышлять над ними. Tags: Управление проектами
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
From: tutunov |
Date: February 15th, 2008 10:27 am (UTC) |
| (Link) |
|
Я согласен, что качественное управление проектом призвано избавить его от подобных проблем. Но, к сожалению, по моим наблюдениям в реальных проектах подобные грубые ошибки не редкость и такие риски реализуются достаточно часто. Hазмышляя над этой дилемой я четче понял место и значение различных инструментов PM-a, да и самой дисциплины/профессии. Опубликовал, чтобы и другие могли получить такой опыт, возможность поразмышлять над этим.
Я часто видел этот закон/правило в формулировках выполнения задачи. Только вот в такой постановке я с ним не согласен. Если задача не анализируется и не планируется структурно, то там не могут появиться четкие оценки объема работ и сроков их исполнения. Т.е. речь идет скорее об ощущениях чем о таких четких числовых разультатах. кроме того, из-за меньших проблем с интеграцией внутри задачи, там отсутвует и большинство факторов, становящихся причинами такой длительности участков работ. Т.е. относительно задачи я не могу с ходу набросать такой перечень причин задержки завершения. Если Вы не согласны со мной, то буду рад увидеть Вашу версию с пояснением логики.
|
|
|
|
|
|
|
|
|
|
|
| From: yplakhov |
Date: February 20th, 2008 10:29 am (UTC) |
| (Link) |
|
Целиком согласен, что закон этот применим только к задачам или работам самого нижнего уровня (в терминах WBS). Собственно, для того проект и управляется как проект, чтобы синдром неосознанной некомпетентности с его уровня переместить "подальше вниз", где с ним легче бороться, и где его цена не столь болезненна.
Другое дело, если к проекту относиться как обычно относятся к унитарной задаче, которая "не анализируется и не планируется структурно". Тогда это - в полный рост. А так, к сожалению, случается очень часто, когда процессы ПМ не поставлены или не выполняются достаточно последовательно. Купили MSProject, почитали книжку (или справку к MSProject), нарисовали график, утвердили у начальства, полюбовались и... все.
Вот тогда, если речь, конечно же, не идет о проекте покраски забора, а о чем-то менее предсказуемом, после выполнения 90% запланированных работ Вам может "светить" сделать еще столько же ;)
|
|
|
|
|
|
|
|
|
|
|
|
From: tutunov |
Date: February 20th, 2008 11:27 am (UTC) |
| (Link) |
|
Мне кажется, что указанная проблема может появится даже если мы начинаем заниматься управлением проектом: разбиваем его на задачи, делаем оценку объема работ, определяем длительность.
Обращаю также внимание что, пока мы этого не сделаем, у нас не будет базы для оценки факта. А значит увидеть указанную проблему не получится. Согласен, что многие приемы проектного менеджмента нацелены на борьбу с подобными сложностями. Но только те же приемы и выявляют сам факт проблемы. Если заренее не определен объем и длительность, их связь, то и факт повышения длительности относительно объема работ не виден. А раз не видна, то ее по сути, для менеджера ее и нет.
С другой стороны согласен, что "незнание проблемы не освобождает от ее последствий".
Но даже при применении приемов проектного управления остается масса факторов, приводящих к затягиванию именно последнего участка работ. Большинство факторов связаны именно со сложностью внутренней организации проекта. Их я и старался перечислить.
В голову пришел еще один фактор: В большинстве проектов последний участок является "хвостом" критического пути. Там отсутсвует (минимально) распаралеливание, а значит автоматически соотношение объема работ и длительности выше чем в среднем по проекту. Любые сбои на этих работах автоматически приводят к удлинению проекта. Более того, если у вас имелись и критические и некритические работы в конце проекта, то небрежное расходование слэка (простоев работы), может превратить некритические работы в критические и у Вас к концу проекта может появиться сразу несколько критических путей. Т.е проблема может усилиться.
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
| From: yplakhov |
Date: February 21st, 2008 08:29 am (UTC) |
| (Link) |
|
Константин, Вы совершенно справедливо заметили насчет "критичности хвоста" сетевой диаграммы проекта. От природы не уйдешь: все притоки Волги заканчивают свой путь в Каспийском море :).
Правда, на этом "критическом" участке величина задержек уже никак не будет 90% длительности проекта. Скорее, 90% отдельной задачи. Конечно, если проектом все время до этого управляли. Другое дело, если к концу проекта станет ясно, что в расписании много чего отсутствует, что надо было сделать или спланировать ранее и без чего результат нельзя сдать заказчику. Вот тогда, можно 90% и всего графика, и бюджета огрести, а можно и по шее... Но для этого надо "Купить MSProject... ", как я писал в предыдущем посте.
PS. Откуда у меня "любовь" к "покупке MSProject". В свое время, я был приглашен участвовать в постановке программы обучения по специальности УП в Харьковском авиационном институте. Вот там от одной энергичной дамы постоянным рефреном звучало главное требование к будущему специалисту - "виртуозное владение MSProject". Как это "работает" на практике, я вижу постоянно. Но это уже совсем иная тема.
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
Previous
