развивающимся проектом можно назвать

Развивающимся проектом можно назвать

3.6. классификация проектного управления

Представленное выше описание различных типов проектов является, по сути, первой попыткой классификации не проектов, а разновидностей проектного управления. Необходимо повторить, что в том понимании про­екта и управления проектом, на котором базируется материал настоящего издания, говорить о различных типах проектов вообще не имеет смысла, можно рассматривать только разные модификации управления проектом, применимые для решения тех или иных экономических, политических, социальных, экологических задач. Но даже отталкиваясь от традиционного понимания проекта и базирующегося на нем управления проектами, мож­но обнаружить, что любая классификация проектов, не основанная на специ­фике управления различными проектами, противоречит сама себе. Во-пер­вых, в результате мы получаем классификацию всех видов общественной деятельности по определенным признакам. Это, с одной стороны, подтвер­ждает правомерность понимания проектного управления как особого вида управленческой деятельности, а с другой стороны, подчеркивает условный характер классификации проектов, которая целиком аналогична класси­фикации систем, существующих при реализации того или иного вида обще­ственной деятельности (социально-экономические системы, технические системы и т.д.; большие, средние и малые системы; сложные и простые системы и пр.). Во-вторых, даже исходя из традиционного пониманияуп­равления проектами, мы приходим к несколько неожиданным выводам. Можно ли говорить о различных типах проектов (не затрагивая сути принци­пиальных различий в управлении такими проектами), если любой проект сам по себе явление уникальное, направленное на достижение оригиналь­ной цели (это первая и главная характеристика любого проекта в рамках концепции управления проектом)? Естественно, можно сказать, что лю­бое явление жизни в некоторой степени уникально, а в некоторой степени схоже с некоторыми другими явлениями. На этом и построена научная классификация явлений. Но в таком случае мы придем к условному пони­манию уникальности проекта как основного его признака и условному пониманию проекта как особого вида деятельности. А на основе того, что проект как особый вид деятельности в рамках управления проектами не существует, можно заключить, что проектное управление — это не управ­ление какими-то специфическими объектами, а особый, специфический вид управления, потенциально применимый в любой сфере деятельности, что нет необходимости вести речь о неких типах проектов, а нужно гово­рить о различных видах управления проектом, их возможностях и ограни­чениях в рамках различных предметных областей.

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

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

Из описания типов проектов и характерных для них видов проектного управления можно сделать вывод, что отдельные виды имеют схожие чер­ты. Так, развивающиеся и открытые проекты не обладают конечными, терминальными целями. Но развивающиеся проекты, так же как и терми­нальные, все же имеют потенциальные ограничения длительности жиз­ненного цикла, которая в свою очередь определяется конечностью кон­цептуальных решений, заложенных в содержание проекта и его продук­ции. В открытых и развивающихся проектах на первый план выходит управление изменениями (в ранее принятых решениях, в ранее созданной продукции и пр.), в первую очередь управление изменениями содержания проекта и его продукции (управление конфигурацией). В фазе реализации управление изменениями происходит в той или иной степени в рамках всех подсистем управления проектом. Но в открытых и развивающихся проектах управление изменениями особенно важно. Здесь цель не элими­нировать, не минимизировать последствия изменений, а как бы быть на гребне волны этих изменений, максимально использовать их. В разви­вающемся проекте жизненный цикл проекта объединяется с жизненным циклом создаваемой продукции.

У мультипроектного управления и управления терминальными проектами также имеются общие черты. Оба этих вида управления проектом направ­лены на достижение конкретных целей, но при этом мультипроектное управление подразумевает неограниченное содержание и поэтому имеет постоянно возобновляемый жизненный цикл, а терминальный проект, достигнув своей цели, прекращает существование. Можно заметить, что при описании схожих черт присутствуют одни и те же признаки, свя­занные с конечностью целей и ограниченностью содержания. Терминаль­ный проект обладает конечной целью и ограниченным содержанием. Раз­вивающийся проект не имеет терминальной, однозначной цели, но огра­ничен по содержанию. Содержание развивающегося проекта предполагает некоторое развитие, но это развитие всегда ограничено как внутренними факторами — концептуальными решениями по проекту, так и внешни­ми — изменениями на рынке, в научно-техническом прогрессе и т.д. От­крытый проект не имеет конечной, терминальной цели и не ограничен по содержанию, так как оно определяется не волей руководителей проек­та, а тенденциями саморазвития управляемой системы. Мультипроектное управление направлено на достижение конечных целей, но его содержа­ние, определяемое совокупностью одновременно управляемых проектов, не ограничено, постоянно изменяется, и хоть не имеет автономного харак­тера саморазвития, как в открытых проектах, но не целиком контролиру­ется руководством. Обобщим эту классификацию и представим ее в гра­фической форме (рис. 3.2).

Источник

Главная

Развивающиеся проекты

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

Иерархический характер модификации версий структуры содержания проекта и структуры продукции проекта можно продемонстрировать на конкретном примере. Вслед за созданием первой версии программы появляется подверсия с номером 1.1 или подверсия еще более низкого уровня — 1.1.1. В зависимости от потребностей могут создаваться подверсии 1.2, 1.3 и т.д. или же подверсии более низкого уровня — 1.1.2, 1.1.3. 1.1.10, 1.2.1, 1.2.2. 1.2.5 и т.д. После того как потенциал решений первой версии будет исчерпан, начинается развитие новой, второй версии программного продукта с последующим развитием ее подверсий (2.1, 2.2 и т.д.). Таким образом, по ходу развивающегося проекта складывается сложная иерархическая система последовательного (а иногда и параллельного) управления структурой продукции. Цифровой код той или иной версии определяется самым нижним уровнем структуры продукции, который не подвергался изменениям. Иными словами, версии 1.3.4 и 1.3.7 созданы на базе версии 1.3, т.е. на основе модификации третьего уровня; в данном случае второй уровень является нижним уровнем структуры продукции, который не подвергается изменениям при разработке этих версий. Этот нижний, не подвергаемый изменениям уровень является базовым для создания всех производных от него версий. Такая иерархическая модель наглядно демонстрирует особенности развивающегося проекта (конечно, реальная нумерация и кодификация различных версий продукции определяется не только логикой внесения изменений в конфигурацию продукции, но и содержанием проекта и его продукции).

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

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

Проект создания программного обеспечения — яркий пример развивающегося проекта. Однако развивающийся проект характерен и для других отраслей экономики. Именно развивающийся проект является наиболее распространенным в современной хозяйственной действительности. Со временная продукция отличается чрезвычайной диверсификацией товарного пространства и сокращением периода морального устаревания. Успех продукции определяется широтой ассортимента и интенсивностью его обновления. Динамизм развития продукции не просто оптимальная, а единственно возможная стратегия выживания в современном быстроразвивающемся мире. Показательность проекта создания программного обеспечения обусловлена тем, что в данном случае нет необходимости в налаживании серийного производства, а современные средства разработки программного обеспечения позволяют соединить проектирование программы и ее создание путем генерации программного кода. Например, при использовании так называемых CASE-средств проектирование программы осуществляется путем создания графической модели, описывающей логику информационных потоков и преобразований, затем без вмешательства специалиста преобразуется в программный код. Иными словами, программный проект является развитием продукции в чистом виде. В проектах же разработки и производства материальной продукции процессы развития могут в большей или меньшей степени скрываться за теми видами деятельности, которые сами по себе принципиальной новизной не обладают (серийное производство), но при этом вовлекают огромное количество ресурсов и весьма продолжительны по времени, поэтому не позволяют увидеть особые черты развивающегося проекта. Но тем не менее, даже не углубляясь в подробное описание примеров развивающихся проектов в области материального производства, анализ структуры модельного ряда, скажем фото- и видеотехники фирмы «Sony» или же автомобилей «BMW», даст необходимую информацию для вывода о широкой распространенности развивающихся проектов.

Развивающиеся проекты хоть и не имеют определенной конечной цели на момент начала проекта, но все же подразумевают завершение проекта, которое связано с конечностью заложенных технических и организационных решений или же с экономической нецелесообразностью развития проекта в ранее заданном направлении. Однако в настоящее время методология проектного управления находит применение и в управлении долгосрочным развитием больших и сложных социально-экономических систем — территориальных систем мегаполиса, экономического района, региона, области. В таких проектах на момент инициации также нет окончательной, терминальной цели, после которой проект перестает существовать, но в отличие от развивающихся проектов терминальная цель не возникает и в ходе управления проектом. Конечной цели у такого проекта просто не существует, так как развитие естественной социально-экономической системы длится неопределенно долго, и продолжительность проекта определяется не существованием конечной цели, а тенденциями саморазвития системы. Это заставляет отнести такие проекты к самостоятельному типу, имеющему свои характеристики и условия применимости.

Источник

Выберите один или несколько правильных ответов.

3.1. В современных классификациях проектов существуют следующие проблемы:

а) отсутствуют четкие критерии для классификации проектов;

б) выделение типов проектов носит условно-описательный характер;

в) выделяемые типы проектов покрывают практически все виды человеческой деятельности;

г) классификации проектов в современной литературе отсутствуют.

3.2. Терминальным проектом можно назвать:

а) проект организационного развития предприятия;

б) проект строительства автомобильной дороги;

в) проект по борьбе с незаконным оборотом наркотиков.

3.3. Терминальные проекты характеризуют:

а) неограниченность содержания;

б) четкость и терминальность цели;

в) гибкость организационной структуры.

3.4. Является ли девелопмент примером системы управления терминальным проектом:

3.5. Развивающимся проектом можно назвать:

а) разработку и внедрение корпоративной информационной системы;

б) управление социально-экономическим развитием мегаполиса;

в) строительство путепровода.

3.6. Девелопментом можно назвать:

а) приобретение объекта недвижимости для самостоятельного использования;

б) строительство маслобойного завода;

в) приобретение объекта недвижимости, его модернизацию и дальнейшую аренду.

3.7. К управлению конфигурацией можно отнести:

а) внесение изменений в проектную документацию;

б) контроль качества продукции проекта;

в) календарное планирование работ по проекту.

3.8. Открытым проектом можно назвать:

а) разработку и внедрение корпоративной информационной системы;

б) управление социально-экономическим развитием территориальной системы;

в) строительство кожно-венерологического диспансера.

3.9. Управление открытым проектом сложилось на основе:

а) скользящего планирования;

б) управления рисками;

в) диалектического материализма;

г) управления целями;

д) корпоративной политики открытых дверей.

3.10. Мультипроектное управление охватывает:

а) несколько одновременно реализуемых проектов;

б) один большой и сложный проект;

в) функциональную деятельность и деятельность по управлению проектами.

3.11. Ограниченным содержанием и конечной целью обладают:

а) открытые проекты;

б) терминальные проекты;

3.12. Неограниченным содержанием и конечной целью обладают:

а) открытые проекты;

б) терминальные проекты;

г) никакие из проектов, перечисленных выше.

3.13. Неграниченным содержанием и нетерминальными целями обладают:

а) открытые проекты;

б) терминальные проекты;

Источник: Управление проектом. Основы проектного управления : учебник / кол. авт.; под ред. проф. М.Л. Разу. — М.: КНОРУС, 2006. — С. 83-88 (768 с.)

Источник

Развивающимся проектом можно назвать

3.3. развивающиеся проекты

Развивающийся проект — проект, на момент инициации не имеющий конечных целей, достижение которых означало бы завершение проекта. Конечные (терминальные) цели в развивающихся проектах обязательно появляются, но момент их появления зависит от многих факторов, и в первую очередь от эффективности ранее осуществленной деятельно­сти и внешних условий. Иными словами, хотя момент завершения разви­вающегося проекта в отличие от терминального и неизвестен, но этот момент настанет, развивающийся проект рано или поздно завершится, так как рано или поздно исчерпается набор гипотез и концептуальных реше­ний, заложенных в проект при его инициации. Несмотря на то что про­граммные продукты могут иметь неограниченное количество версий, в конце концов наступает момент, когда разработчики понимают, что не­обходимо создавать совершенно иное решение, никоим образом не соот­носимое с предыдущим проектом.

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

Иерархический характер модификации версий структуры содержания проекта и структуры продукции проекта можно продемонстрировать на конкретном примере. Вслед за созданием первой версии программы появляется подверсия с номером 1.1 или подверсия еще более низкого уровня — 1.1.1. В зависимости от потребностей могут создаваться подвер-сии 1.2, 1.3 и т.д. или же подверсии более низкого уровня — 1.1.2, 1.1.3. 1.1.10, 1.2.1, 1.2.2. 1.2.5 и т.д. После того как потенциал решений первой версии будет исчерпан, начинается развитие новой, второй версии программного продукта с последующим развитием ее подверсии (2.1, 2.2 и т.д.). Таким образом, по ходу развивающегося проекта складывается слож­ная иерархическая система последовательного (а иногда и параллельного) управления структурой продукции. Цифровой код той или иной версии определяется самым нижним уровнем структуры продукции, который не подвергался изменениям. Иными словами, версии 1.3.4 и 1.3.7 созданы на базе версии 1.3, т.е. на основе модификации третьего уровня; в данном случае второй уровень является нижним уровнем структуры продукции, который не подвергается изменениям при разработке этих версий. Этот нижний, не подвергаемый изменениям уровень является базовым для со­здания всех производных от него версий. Такая иерархическая модель наглядно демонстрирует особенности развивающегося проекта (конечно, реальная нумерация и кодификация различных версий продукции опреде­ляется не только логикой внесения изменений в конфигурацию продук­ции, но и содержанием проекта и его продукции).

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

4 Управление проектом

ствах), то развивающийся проект построен на постоянном изменении, совершенствовании и управлении конфигурацией продукции проекта.

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

Развивающийся характер рассматриваемых проектов не сводится к после­довательному совершенствованию, постоянной модификации продукции проекта. Развивающийся проект включает в себя образование новых фун­кциональных областей, которые зарождаются в рамках проекта, а затем могут быть переданы в функциональные подразделения организации. Пример тому — уже упоминавшееся текущее исправление ошибок в вы­пущенной программе. После появления первой версии техническим со­провождением и устранением недостатков на постоянной основе начина­ет заниматься специально выделенный специалист (или группа). По мере увеличения количества версий и продолжительности эксплуатации про­граммы эта группа специалистов может быть выведена из проектной струк­туры и действовать как функциональное подразделение, работа которого сводится к текущей поддержке пользователей (тесная связь с проектом при этом, естественно, сохраняется для обеспечения информационного обмена, важного как для эффективного решения текущих проблем в ис­пользовании программы, так и для дальнейшего развития программы). Развивающийся проект может порождать новые проекты, которые по мере своего развития выделяются, отпочковываются в независимые и самосто­ятельные. Это означает, что с точки зрения содержания проект и продук­ция проекта развиваются не только путем последовательного выпуска но­вых версий продукции, итерационного возврата и перепроектирования конфигурации, но и путем образования новых ветвей дерева продукции, которые в дальнейшем могут отделяться от базового ствола и превращать­ся в структуры продукции самостоятельных проектов.

Проект создания программного обеспечения — яркий пример развиваю­щегося проекта. Однако развивающийся проект характерен и для других отраслей экономики. Именно развивающийся проект является наиболее распространенным в современной хозяйственной действительности. Со­временная продукция отличается чрезвычайной диверсификацией товар­ного пространства и сокращением периода морального устаревания. Ус­пех продукции определяется широтой ассортимента и интенсивностью его обновления. Динамизм развития продукции не просто оптимальная, а един­ственно возможная стратегия выживания в современном быстроразвива-ющемся мире. Показательность проекта создания программного обеспе­чения обусловлена тем, что в данном случае нет необходимости в налажи­вании серийного производства, а современные средства разработки про­граммного обеспечения’позволяют соединить проектирование программы и ее создание путем генерации программного кода. Например, при ис­пользовании так называемых САБЕ-сре&ств проектирование программы осуществляется путем создания графической модели, описывающей логи­ку информационных потоков и преобразований, затем без вмешательства специалиста преобразуется в программный код. Иными словами, програм­мный проект является развитием продукции в чистом виде. В проектах же разработки и производства материальной продукции процессы разви­тия могут в большей или меньшей степени скрываться за теми видами деятельности, которые сами по себе принципиальной новизной не облада­ют (серийное производство), но при этом вовлекают огромное количество ресурсов и весьма продолжительны по времени, поэтому не позволяют увидеть особые черты развивающегося проекта. Но тем не менее, даже не углубляясь в подробное описание примеров развивающихся проектов в области материального производства, анализ структуры модельного ряда, скажем фото- и видеотехники фирмы «Sony» или же автомобилей «ВМТУ», даст необходимую информацию для вывода о широкой распространенно­сти развивающихся проектов.

Развивающиеся проекты хоть и не имеют определенной конечной цели на момент начала проекта, но все же подразумевают завершение проекта, которое связано с конечностью заложенных технических и организаци­онных решений или же с экономической нецелесообразностью развития проекта в ранее заданном направлении. Однако в настоящее время методо­логия проектного управления находит применение и в управлении дол­госрочным развитием больших и сложных социально-экономических си­стем — территориальных систем мегаполиса, экономического района, региона, области. В таких проектах на момент инициации также нет окончательной, терминальной цели, после которой проект перестает суще­ствовать, но в отличие от развивающихся проектов терминальная цель не возникает и в ходе управления проектом. Конечной цели у такого проекта просто не существует, так как развитие естественной социально-экономи­ческой системы длится неопределенно долго, и продолжительность проек­та определяется не существованием конечной цели, а тенденциями само­развития системы. Это заставляет отнести такие проекты к самостоятель­ному типу, имеющему свои характеристики и условия применимости.

Содержание

Читать: Аннотация
Читать: Введение
Читать: Управляющая система
Читать: Основы управления проектом
Читать: 1.1. современная концепция управления проектом
Читать: 1.2. окружающая среда и участники проекта
Читать: 1.3. жизненный цикл проекта
Читать: 1.4. базовые элементы управления проектом
Читать: 1.5. характеристика видов деятельности по управлению проектом
Читать: 1.6. подсистемы управления проектом
Читать: Управление проектом. история и современность
Читать: 2.1. управление проектом на фоне развития теории и практики управления
Читать: 2.2. краткая история проектного управления за рубежом (30-е годы xx века — настоящее врем2.3. краткая история проектного управления в россии
Читать: 2.4. проблемы вхождения россии в мировое сообщество управления проектом
Читать: Классификация проектов и разновидности проектного управления
Читать: 3.1. проблемы классификации проектов
Читать: 3.2. терминальные проекты
Читать: 3.3. развивающиеся проекты
Читать: 3.4. открытые проекты
Читать: 3.5. мультипроекты
Читать: 3.6. классификация проектного управления
Читать: Организационная структура управления проектом
Читать: 4.1. понятие организационной структуры управления проектом
Читать: 4.2. организационная структура управления и система взаимоотношений участников проекта
Читать: 4.3. организационная структура управления и содержание проекта
Читать: Сетевые модели
Читать: 5.1. основные понятия и элементы сетевых моделей
Читать: 5.2. правила построения сетевых моделей
Читать: 5.3. упорядочение сетевых моделей
Читать: 5.4. укрупнение работ
Читать: 5.5. «сшивание» сетевых моделей
Читать: 5.6. аналитические параметры сетевых графиков
Читать: 5.7. определение ранних начал и ранних окончаний работ сетевой модели
Читать: 5.8. определение поздних начал и поздних окончаний работ сетевой модели
Читать: 5.9. определение работ, составляющих критический путь
Читать: 5.10. определение резервов времени
Читать: 5.11. определение коэффициента напряженности работы
Читать: 5.12. табличный метод расчета аналитических параметров сетевой модели
Читать: Сетевые модели (дополнительные методы)
Читать: 6.1. расчет сетевой модели методом диагональной таблицы
Читать: 6.2. секторный метод расчета сетевой модели
Читать: 6.3. другие методы расчета сетевой модели
Читать: 6.4. независимый резерв времени
Читать: 6.5. подкритические работы
Читать: 6.6. расчет многоцелевых сетевых моделей
Читать: 6.7. сетевые модели с вероятностной оценкой продолжительности работ
Читать: 6.8. проблемы использования сетевых моделей с вероятностной продолжительностью работ
Читать: 6.9. привязка сетевого графика к календарю и построение масштабных сетевых графиков
Читать: Оптимизация сетевых моделей
Читать: 7.1. оптимизация сетевых моделей по времени
Читать: 7.2. оптимизация сетевых моделей по ресурсам
Читать: 7.3. оптимизация сетевых моделей по времени и стоимости
Читать: Сетевые матрицы
Читать: Матрицы разделения административных задач управления (матрицы разу)
Читать: Информационно-технологические модели
Читать: Структура разбиения работ
Читать: Управление стоимостью и продолжительностью проекта
Читать: Управление качеством проекта
Читать: Управление рисками

Источник