Spider Project — перша російська систему управління фаховий рівень

Spider Project — перша російська систему управління професійного уровня

1. Запровадження

На ринку програмних засобів управління проектами у Росії поруч із відомими зарубіжними пакетами, такі як Microsoft Project, Open Plan, Suretrak, Primavera Project Planner є і Російський пакет Spider Project. У Росії цей пакет найпопулярніший і використовується найбільшими корпораціями керувати найпрестижнішими проектами.

У пакета Spider Project багато відмінностей від своїх іноземних аналогів, які його на місце Російських споживачів. Це було пов’язано і з прийнятою у Росії технологією управління проектами, яка від тієї, що лежить в основі зарубіжних пакетів, і про те увагою, що у Росії традиційно приділяється оптимізації використання ресурсів немає і адекватності математичних моделей об'єктів. Взагалі, у Росії видається, що ні пакети управління проектами розробляються на підтримку технології управління проектами, а навпаки методологія управління проектами у тому числі A Guide tо the PMBOK виходить із можливостей програмних засобів. Приміром, у Росії практично у всіх галузях докладання управління проектами плануються фізичні обсяги будівельно-монтажних робіт, а тривалість розраховується з производительностей призначених ресурсів, а чи не є вихідної інформацією.

Пакет Spider Project розроблений компанією Spider Management Technologies, що є яка веде до Росії консалтингової компанією із управління проектами, тому його функціональність визначається реальними потребами проектів, у самих різних галузях. У статті ми розберемо відмінності підходів і функціональних можливостей пакета Spider Project з інших відомих пакетів. Такий розбір допоможе зрозуміти відмінності підходів до управління проектами, що далі міг виявитися важливим і досить корисним для менеджерів, що у управлінні проектами у Росії, і буде корисним до обговорення питань, що з глобалізацією управління проектами і застосування американських стандартів управління проектами у Європі. Оскільки пакет Spider Project успішно застосовується й у Голландії, можна вважати, що підходи, излагаемые далі, не визначаються суто Російської специфікою.

2. Структура даних

Структура даних дуже важливий. Саме він визначає можливості моделювання ситуацій, утворюють реальних проектах. За відсутності можливостей для використання вихідної інформації реальні характеристиках операцій, ресурсів і взаємозв'язків робіт проекту, і навіть обмежень, які впливають його план і бюджет, не можна отримати комп’ютерну модель проекту, адекватно яка відображатиме реальної картини, і використати цю модель до ухвалення управлінських рішень.

Основными елементами комп’ютерної моделі проекту є операції проекту, їх взаємозв'язку, ресурси проекту й їх призначення виконання операцій, і навіть ієрархічні структури робіт і інтелектуальних ресурсів і структури витрат. У цьому основними елементами управління є ресурси, і саме моделювання його роботи в найбільшою мірою впливає адекватність відображення у комп’ютерній моделі реальних ситуацій. Ми не говорити про деталі, а зупинимося лише з основних елементах структури даних, принципових розуміння ідеології й відмінностей підходів до моделювання проектів.

2.1. Операції

В більшості відомих пакетів операції характеризуються тривалістю їхнього виконання. У Spider Project поруч із длительностями можна ставити фізичні обсяги будівельно-монтажних робіт на операціях. Тривалість визначається пакетом у процесі складання розкладу робіт у залежність від продуктивності призначених ресурсів. Такий їхній підхід має багато переваг. Зокрема, вона дозволяє використовувати проектні бази даних, у яких закладено нормативи за витратами матеріалів і затратам на поодинокі обсяги будівельно-монтажних робіт різних типів, производительностям ресурсів на типових призначеннях.

2.2. Взаємозв'язку робіт

В Spider Project використовуються самі типи взаємозв'язків, що у інших пакетах. Відмінності є у визначенні затримок. Поруч із позитивними і негативними тимчасовими затримками, можна використовувати й об'ємні затримки. А вважаємо використання об'ємних затримок кращим. Справді, з тимчасовими затримками у тому, що й робота почалася, але виповнюється повільніше, ніж було заплановано, тимчасова затримка може вичерпатися раніше, чому виконано запланований обсяг робіт. Тимчасові затримки вимагають уваги і регулярної коригування.

2.3. Ресурси

Отличия в завданні ресурсів найбільш значними. Ресурси поділяються на поновлювані (люди, механізми) і невознобляемые (матеріали). У багатьох пакетів ті й інші задаються разом, відмінності зазвичай полягають лише завданні вартістю, їм використання — за годину чи одиницю. У Spider Project ці види ресурсів задаються окремо. У цьому можна поставити, що поновлювані ресурси споживають матеріали (приклад: автомобіль споживає бензин). Тоді призначивши ресурси на виконання операцій проекту ви автоматично враховуєте попутне споживання необхідних матеріалів. Крім окремих ресурсів можна поставити мультиресурсы і пули. Мультиресурсы — це групи ресурсів, які виконують роботи разом (наприклад, бригада, екіпаж, автомобіль із шофером тощо.). Мультиресурсы можна призначати виконання операцій повністю, що означає призначення всіх ресурсів, яким вони входять. Пули — це групи взаємозамінних ресурсів. Основне на відміну від підходів, які у інших пакетах, де є skill scheduling, у тому, що ресурси пулу може мати різні продуктивності.

2.4. Календарі

Календари можна поставити всім операцій, ресурсів немає і затримок. А вважаємо за необхідне для моделювання проекту наявність всіх згаданих календарів.

2.5. Призначення

Очень серйозні відмінності є у призначеннях ресурсів виконання операцій проекту. У Spider Project при призначеннях ресурсів виконання операцій проекту з’являється поняття команди, тобто групи ресурсів, які виконують роботи разом. У команду можуть входити як окремі ресурси, і мультиресурсы і пули. Якщо в операції вихідної інформацією є обсяг робіт, що необхідно дати продуктивність хоча самого із призначених ресурсів, щоб пакет обчислив тривалість роботи. У цьому зауважимо, призначаючи пулів тривалість роботи визначається у процесі складання розкладу робіт.

Spider Project вибирає які із ресурсів пулу призначити виконання операції з урахуванням можливої зайнятості ресурсів пулу інших операціях проекту. Призначаючи на виконання операції пул ресурсів, слід поставити або загальна кількість ресурсів пулу, необхідне виконання операції, чи їх сумарну продуктивність. Приклад: пул складається з самоскидів різної вантажопідйомності. Можна поставити необхідне виконання операції кількість самоскидів, або сумарну вантажопідйомність призначених самоскидів.

Ресурсы, належать різним командам, працюють для операцій незалежно. У цьому можна поставити обсяги чи тривалості робіт кожної команди, а можна цього й не робити. Останнє означає, що команда працюватиме, поки операція не буде виконано. У цьому до неї можуть приєднуватися та інші призначені команди, а може створитися і ситуація, коли робота буде закінчено доти, як із призначених команд розпочнуть виконання операції. Такий підхід дає змогу ефективно моделювати змінне роботу. Ресурси може бути призначені виконання операції частково. Тоді, у Spider Project задається відсоткова завантаження призначених ресурсів поруч із кількістю. Тим самим було не створюється ситуація, звичайна й інших пакетів, коли необхідну кількість ресурсів невідома (дві одиниці ресурсу з 50% завантаженням за іншими пакетах еквівалентні однієї одиниці, завантаженою повністю).

Как вже згадувалося, матеріали можуть споживатиметься ресурсами у процесі роботи, може бути призначені безпосередньо на операцію і призначення ресурсу (можна буде отримувати звітність про фактичне споживання матеріалів окремими ресурсами). Істотною відмінністю Spider Project є і те, що у пакеті моделюється як споживання, а й виробництво ресурсів немає і матеріалів на роздрібних операціях і призначеннях.

2.6. Вартості

Другие підходи використовують і щодо призначення вартості операцій, ресурсів немає і матеріалів. Перш всього, пакет дозволяє вживати необмежена кількість складових вартості, причому у різних валютах. Це дозволяє окремо враховувати доходи, витрати, зарплатню, вартість механізмів тощо. Крім призначення вартості години работи поновлюваних ресурсів немає і ціні одиниці матеріалів, вартості можна призначати безпосередньо для операцій та призначення. Приміром, якщо робота виконується за контрактом із фіксованою ціною, то вартість години роботи ресурсу утрачає будь-який сенс і треба використовувати вартість призначення ресурсу (підрядчика) на операцію. Якщо вартість операції залежить від призначень, вартість призначається безпосередньо на операцію. Такий досить гнучкий, щоб моделювати будь-які життєвих ситуацій.

2.7. Центри

Часто буває необхідним контролювати групи матеріалів, ресурсів немає і витрат. З цією метою служать центру матеріалів, ресурсів немає і вартостей, які у Spider Project можна створювати в необмеженій кількості. До центру матеріалів можна включити будь-яку групу матеріалів, до центру ресурсів — групу ресурсів немає і отримувати звіти про загальній кількості ресурсів або матеріалів з відповідного центру. У вартісної центр можна включити певні вартісні складові, ресурси і матеріалів. Тоді будуть подсчитываться сумарні витрати по обраним стоимостным що становить, включаючи (або включаючи) фіксовані вартості робіт на операціях (призначені безпосередньо), або ті ресурси, і матеріали, які увійшли до вартісної центр.

2.8. Ієрархічні структури

В Spider Project можна використовувати необмежена кількість різних ієрархічних структур робіт і інтелектуальних ресурсів. Використання багатьох ієрархічних структур ми вважаємо принциповим, а суперечки навколо того, яку саме ієрархічну структуру вважати оптимальної, безпредметними. Тож нас незрозумілою є мета роботи тієї групи у фінансовому комітеті стандартів PMI, яка розробляє рекомендації по структуризації проектів. Використання багатьох ієрархічних структур дозволяє як отримувати звітність щодо проектів найрізноманітніших розрізах, а й проконтролювати повноту комп’ютерної моделі проекту.

Как правило, ми використовуємо в проектах по меншою мірою такі три ієрархічні структури робіт — з об'єктів проекту, по процесам проекту, по відповідальності виконавців. У цьому слід підкреслити, що структура відповідальності, з успіхом заміняє матрицю відповідальності, зазвичай розроблюваної у плані проекту. Відповідальності зазвичай розподіляються ієрархічно і лише у невеликих проектах структура відповідальності стає пласкою і то, можливо зведена до матриці. З іншого боку, у пакеті Spider Project можна та інші структури робіт, зокрема неповні (які містять всіх операцій проекту). Неповні структури — зручний інструмент на підготовку звітності та виваженості аналізу окремих аспектів проекту.

Примерами таких неповних структур можуть бути структура поставок, куди входять ті операції, які відбивають поставки матеріалів, чи структура Milestones, куди входять лише контрольні події проекту (Milestone schedule). Використання ієрархічних структур ресурсів особливо важливо при мультипроектном управлінні. У цьому матрична структура організації визначає необхідність отримання звітності за ресурсами як у проектної ієрархії, і по функціональної. Тому й нині для ресурсів корисно використовувати множинні ієрархічні структури.

2.9. Архіви

Для аналізу виконання проекту, і навіть для аналізу «що й» дуже важливо матимуть можливість зберігати колишні версії проекту й мати змогу порівняння і грунтовного аналізу відхилень поточної версії проекту попередніх. А вважаємо недостатнім зберігати лише базовий план. У Spider Project ви можете зберігати необмежена кількість версій проекту й аналізувати хід виконання робіт як проти якийсь базової версією, але й будь-який інший. Така можливість дозволяє оцінити як виконувався проект за останній тиждень, за за останній місяць, з початку року, проти базовим планом тощо. Якщо проводився аналіз ризиків, можна порівняти поточну версію з оптимістичною і песимістичній. Наявність архівів дуже важливо на завершення проекту щодо послепроектного аналізу та до розв’язання конфліктів.

3. Обчислення

Задачи, можуть бути вирішені з допомогою пакетів управління проектами зазвичай мають: n розробку розкладу виконання проекту не враховуючи обмеженості ресурсів, n розробку розкладу виконання проекту з урахуванням обмеженості ресурсів (leveling), n визначення критичного шляху й резервів часу виконання операцій проекту, n визначення потреби проекту на фінансуванні, матеріалах немає жодного устаткуванні в будь-які періоди часу, n визначення розподілу у часі завантаження поновлюваних ресурсів, n аналіз ризиків і планування розклади і інших характеристик проекту з урахуванням ризиків, n ведення обліку виконання, n аналіз відхилень ходу робіт від запланованого (зокрема Earned Value Analysis) і прогнозування основних параметрів проекту.

Задача складання розкладу виконання проекту не враховуючи обмеженості ресурсів має точне математичне рішення (метод критичного шляху) й у аналогічних вихідних даних вирішується усіма пакетами однаково. На інших завданням є суттєві відмінностей у підходах, і одержуваних результатах.

3.1. Розклад виконання проекту з урахуванням обмеженості ресурсів

В більшості пакетів під розписом з урахуванням обмеженості ресурсів розуміється розклад, у якому враховується обмеженість поновлюваних ресурсів. У цьому традиційно використовуються найпростіші евристики, які забезпечують ні отримання розкладу, близького оптимального, ні стійкості цього розкладу. У разі користувачам дають можливість вибору критеріїв щодо призначення ресурсів у процесі складання розкладу, що дозволяє виконати перебір, і вибрати найкраще з отриманих рішень. Але й такий перебір не забезпечує отримання прийнятних результатів. У Spider Project використовуються значно більше скоєні евристики, що дозволяють стійко отримувати коротші розкладу виконання проекту за ті самі ресурсних обмеженнях, ніж у сусідніх пакетах. Як приклад наведемо простий проект — придбання комп’ютерної программы.

Хоч як дивно, але при цьому проекту розкладу, составляемые іншими пакетами за умови, що є лише одне Аналітик і тільки Менеджер, втричі тижня довші. У багатьох реальних проектів розкладу Spider Project істотно коротше розкладів, який складають іншими пакетами за ті самі обмеженнях на ресурси проекту. Так само важливою є і стійкість розкладу, особливо у фазі виконання.

В процесі виконання решта планові тривалості операцій змінюються, тому й розкладу, складені пакетами в автоматичному режимі може стати зовсім іншими. Приміром, змінивши планову тривалість операції «Negotiations with Vendors» у нашій прикладі з 15 днів 14, ви отримаєте зовсім інше розклад у пакеті Microsoft Project. Зміна тривалості операції у одного дня тягне зміну планового терміну завершення проекту втричі тижні на той чи інший бік! Нове розклад буде оптимальним, відповідним розкладу Spider Project, проте виникає запитання — що, якщо вже уклали контрактів, запланували постачання російської та т.д. З цієї моменту ви зможете використовувати автоматичний розрахунок розкладу проекту, якщо ви не перегляньте свої угоди. Саме у пакеті Spider Project є додаткова опція — підтримка розкладу попередньої версії проекту, як така ви можете вибрати будь-яку версію з архіву проекту.

3.2. Критичний шлях збереження та резерви

Традиционное поняття критичного шляху працює лише за наявності необмежених ресурсів. При обмежених ресурсах традиційні способи визначення критичного шляху втрачають сенс. Це саме можна сказати і до поняття повного резерву (total float). Повний резерв, визначається більшістю пакетів, показує резерв часу виконання операцій, якщо знехтувати обмеженнями кількості наявних ресурсів. Практично такі резерви використовувати не можна. Як приклад наведемо простий проект, трійка операцій — двох операцій планова тривалість до десятьох днів, у третьої - п’ятнадцять. Перші дві для свого виконання вимагають ресурсу А, третя — ресурсу У. Якщо операції не взаємопов'язані, то третя операція є критичною у сенсі, а й у двох перших є повний резерв до п’яти днів. Якщо ж розрахувати розклад з огляду на те, що є лише з однієї одиниці кожного із ресурсів, два операції можна виконувати лише з черги, а й у третьої виникає резерв до п’яти днів.

Поэтому в Spider Project обчислюється ресурсний критичний шлях збереження та резерви термінів виконання операцій із урахуванням обмеженості ресурсів. Ми досить давно пропонували цю концепцію (зокрема, в презентаціях на конференціях PMI і конгресі IPMA у Парижі 1996 року) й раді з того що зараз концепції ресурсного критичного шляху стали перейматися. Маючи можливість визначення й порядку використання ресурсного критичного шляху й ресурсних резервів, ми критично ми до теорії Critical Chain.

3.3. Визначення потреби проекту на фінансуванні, матеріалах немає жодного устаткуванні

В більшості пакетів обчислюються потреби проекту на фінансуванні, матеріалах немає жодного устаткуванні з урахуванням складеного розкладу проекту. Якщо необхідну фінансування чи поставки матеріалів неможливо знайти забезпечені, то користувачі змушені коригувати графіки вручну. У пакеті Spider Project можна моделювати як витрати фінансових коштів, а й доходи, як споживання матеріалів, а й поставки. Тим самим було можна визначити як витрати проекту, а й Cash Flow, відстежувати як потреби, а й рух матеріалів. З іншого боку, в Spider Project можна розрахувати розклад виконання проекту з урахуванням як обмеженості поновлюваних ресурсів, а й графіків постачання і фінансування, причому як по сумарним затратам, а й у окремим що становить і центрам витрат і матеріалів.

3.4. Визначення розподілу у часі завантаження поновлюваних ресурсів

Принципиальным відзнакою можливостей Spider Project з інших пакетів і те, що з розрахунках враховуються і кількість, і відсоткова завантаження ресурсів на операціях проекту. Отже, навіть за неповної завантаженні ресурсів на окремих операціях результати розрахунку розкладу робіт, за обмеженнях на загальне кількість ресурсів залишаються достовірними. Відповідно й звітність виходить тільки за часом завантаження ресурсів, а й у кількості завантажених ресурсів.

3.5. Аналіз ризиків і планування з урахуванням ризиків

У нас є серйозні зауваження до підходи до моделювання ризиків, що у більшості пакетів. Незалежно від цього, використовується чи метод PERT чи метод Монте Карло, під час моделювання ризиків передбачається, що тривалості операцій не коррелированы між собою. У житті тут інше. Зазвичай, відхилення тривалості виконання операцій пов’язані із неправильним визначенням продуктивності призначених ресурсів, отже, і відхилення тривалості виконання операцій, використовують самі ресурси взаємопов'язані. Тому, за моделюванні ризиків пакеті Spider Project ми, зазвичай, виходимо з оптимістичних, песимістичних і очікуваних оцінок длительностей операцій, а продуктивності призначених ресурсів. Тим самим було, моделюються не наслідки, а джерела ризиків, і вивести результати виходять значно більше зрозумілі й достовірними.

3.6. Ведення обліку виконання

Учет виконання і коригування розкладу решти операцій проекту на пакеті Spider Project також відрізняється від узвичаєного. Насамперед, облік грунтується на реєстрації не лише відпрацьованою тривалості, а й виконаних обсягів. Це дозволяє пакету розрахувати тривалості і розклад виконання решти операцій проекту, виходячи з об'єктивну інформацію. Облік виконаних обсягів продажів і відпрацьованою тривалості дозволяє відкоригувати початкові оцінки продуктивності ресурсів проекту й відповідно скоригувати розклад виконання решти операцій. Пакет веде архіви обліку, і надає користувачам можливість отримувати звітність у виконанні будь-яку проміжок часу й за якою ієрархічної структурі робіт проекту.

3.7. Аналіз відхилень ходу робіт від запланованого

Как вже згадувалося, ведення архівів проекту, зокрема архівів обліку, дозволяє аналізувати відхилення ходу реалізації проекту як проти базової версією, а й у порівнянню версією минулого тижня, минулого місяця і т.д. Архіви обліку дозволяють аналізувати роботу ресурсів немає і коригувати їх планову продуктивність. Наявність архівів дозволяє відстежувати тенденції і прогнозувати майбутні параметри, зокрема визначити коефіцієнт виконання, вживаний у Earned Value Analysis. Що ж до Earned Value Analysis ми вважаємо корисною можливість його проведення як для підсумкових витрат, але й окремих вартісних складових і вартісних центрів.

4. Бази даних

Характерной особливістю як пакета, а й технології управління проектами у Росії є інтенсивне використання у проектах різноманітних і стандартів. Раніше використання норм (особливо у будівництві) регламентувалося державою, нині всі більше використовуються корпоративні норми і стандарти. Такі норми зазвичай ставляться до одиничним обсягам робіт різних типів і производительностям ресурсів на типових призначеннях.

В пакеті Spider Project закладено можливість підтримки таких норм. Користувачі Spider Project можуть домовленість створювати пакеті чи імпортувати з деяких інших програм різноманітні довідники і зробити їх проектними базами даних. Типові довідники включають добові норми витрат матеріалів на одиничних обсягах робіт різних типів, вартості одиничних обсягів робіт (складниками), продуктивність і відсоткова завантаження ресурсів на типових призначеннях. Застосування проектних баз даних має цілу низку переваг. Приміром, це дозволяє розробити зважену та залучити до різних проектах корпоративні стандарти, уніфікувати всередині організацій оцінки продуктивності ресурсів, потреби робіт у матеріалах, вартісні оцінки одиничних обсягів робіт тощо.

Кроме того, використання проектних баз даних дозволяє швидко і ефективно вносити зміни до проектів за зміни вихідної інформації, значно полегшує ще й аналіз «що й», і аналіз ризиків (у своїй зазвичай створюються й закони використовують оптимістичні і песимістичні бази даних, почергове застосування яких дозволяє їм отримати оптимістичну і песимістичну версії проекту). Іншим ефективним інструментом для аналізу «що й» та внесення змін — у проект є використання мультиресурсов. Змінивши склад мультиресурса і застосувавши це й зміна нині проектом користувачі можуть невпізнанно змінити склад призначень всім операцій, де було використано цей мультиресурс.

Очень важливим інструментом до створення корпоративної культури та корпоративних стандартів управління проектами є бібліотека типових фрагментів. Типовий фрагмент — це невеличке проект, визначальний технологію виконання типового ділянки робіт певного обсягу. Проект охоплює всі необхідне включення їх у склад які ведуться компанії проектів — і матеріалів, і ресурси, і вартісні складові. Бібліотека фрагментів розробляється і підтримується у центрі управління проектами компанії (Project Office). Технології та інші дані, закладені у типових фрагментах, старанно відпрацьовуються і перевіряються, оскільки ці технологій і дані використовуватимуться переважають у всіх проектах компанії. Це підвищує достовірність і надійність розроблюваних моделей, при цьому досягається уніфікація даних, і підходів, так важлива при мультипроектном управлінні.

По технології розробки розкладу проекту, що її впроваджуємо і який підтримується пакетом Spider Project, проекти складаються з фрагментів. У цьому, додаючи до проекту черговий фрагмент, користувач відповідає на запит про реальний обсяг робіт фрагмента у проекті і Spider Project автоматично змінює обсяги будівельно-монтажних робіт фрагмента при уставці до проекту, заодно коригуючи потреби у матеріалах немає жодного вартості робіт. Цікавим побічним ефектом використання бібліотек типових фрагментів є технологія формування ієрархічної структури робіт не згори донизу, звісно ж, а знизу вгору. У такій структурі типові фрагменти служать пакетами робіт. Оскільки ми звичайно використовуємо кілька структури одному проекті, то технології знизу вгору й за згори донизу використовуються паралельно і взаємно доповнюють одне одного.

5. Звіти

Наряду зі стандартними графічними звітами — діаграмою Гантта, мережевий діаграмою, діаграмами завантаження ресурсів, витрати матеріалів і графіками витрат з проекту і окремих фазам, Spider Project пропонує користувачам Ресурсну діаграму Ганта і Лінійну діаграму, які описані далі.

5.1. Ресурсна діаграма Ганта

Ресурсная діаграма Ганта аналогічна діаграмі Ганта операцій із тією різницею, що у ній відбиваються не періоди виконання операцій, а періоди завантаження ресурсів. У табличній частини відображається ієрархічна структура ресурсів, в графічної - періоди завантаження ресурсів немає і підрозділів.

5.2. Гистограммы завантаження ресурсів

Мы вже згадували, що у Spider Project користувачі задають і відсоткову завантаження, і кількість призначених ресурсів. Відповідно й звіти (зокрема гистограммы) з завантаження ресурсів складаються й за кількістю використовуваних ресурсів, й часово його роботи. Отже, користувачі можуть одержати звіт, із якого ясно, що попри те, що сумарна завантаження ресурсів становить вісім годин на день, необхідно використовувати чотири одиниці ресурсів із 25%.

5.3. Лінійна діаграма

Линейная діаграма — відвертий і компактний спосіб відображення розкладу робіт проекту. На цієї діаграмі за вертикаллю відображається час, а, по горизонталі - метрика проекту (що можуть бути кілометри, поверхи будь-який інший метрика, обумовлена користувачами). Користувачі можуть вибирати, які види робіт відображати на лінійної діаграмі. Лінійна діаграма показує, які праці та коли планується провести кожному місці траси. З іншого боку можна запустити анімацію і переглянути на лінійної діаграмі процес виконання проекту із кожним тимчасовим кроком. Можна виділити будь-яка ділянка і переглянути детальний план виконання проекту.

6. Укладання

В Росії вироблені власні підходи до управління проектами у Росії, які від які у інших країн і описаних у A Guide to the PMBOK. Ці відмінності відбилися й у Російському пакеті управління проектами Spider Project.

Из основних особливостей цього пакета відзначимо: — можливість складання розкладу проекту, виходячи з фізичних обсягах робіт і продуктивності ресурсів, — оптимізація використання ресурсів проекту й широкі можливості моделювання його роботи, — включення до модель проекту постачання і фінансування і розрахунок розкладу зі своїми урахуванням, — розрахунок і ресурсного критичного шляху й ресурсних резервів, — інтенсивне використання у проектах різноманітних баз даних, — використання багатьох ієрархічних структур робіт і інтелектуальних ресурсів проекту, — оригінальні підходи до моделювання ризиків, — додаткові форми графічних звітів.

Имеются і інші менш помітні відмінності. Цікаво, що Російським менеджерам важко використовувати Американські пакети управління проектами, які підтримують технологію управління, прийняту у Росії. Росіяни менеджери не вірять, які можна управляти серйозними проектами, відмовившись від такого типу фундаментальних у Росії понять, як обсяг робіт і продуктивність ресурсу. З урахуванням наявних тенденцій до глобалізації, необхідно створити порозуміння і уніфікацію підходів до процесів управління проектами.

Список литературы

Владимир Либерзон, Росія Ігор Лобанов, Нидерланды.