Основи проектного менеджменту 3 страница
• Ініціалізація (5.1) - рішення організації про те, щоб розпочати чергову фазу проекту.
Процеси планування
Планування є особливо важливим у проекті, оскільки проект включає певні дії, які не були зроблені раніше. Тому в даному розділі читач зустріне порівняно більшу кількість процесів. Проте, це не означає, що управління проектами - це в основному планування: кількість робіт з планування має бути сумірною зі змістом проекту і корисністю розробленої інформації.
Зв'язки між процесами планування проекту показані на малюнку 3—5(цей графік є розвитком еліпса «процеси планування» на малюнку 3—1). Ці процеси до завершення плану часто повторюються. Наприклад, якщо первинна дата завершення є неприйнятною, то може знадобитися перевизначити ресурси, вартості и навіть зміст проекту. Крім того, планування не є точною наукою - дві різних команди можуть згенерувати абсолютно різні плани одного і того самого проекту.
Базові процеси.Деякі процеси планування мають чіткі залежності, які вимагають від них виконання в певному порядку в більшості проектів. Наприклад, роботи мають бути визначені перед затвердженням календарного плану і кошторису робіт. Ці базові
процеси планування можуть повторюватися кілька разів протягом однієї фази проекту. Вони включають:
• Планування змісту (5.2) - розробка (письмово) документа про
зміст проекту, який буде основою для майбутніх проектних
рішень.
• Визначення змісту (5.3) - поділ основного компоненту проекту
на дрібніші, більш керовані компоненти.
• Визначення діяльності (6.1) - ідентифікація певних робіт, що
мають бути виконані для отримання результатів постачань і
окремих елементів по проекту.
• Завдання послідовності робіт (6.2) - ідентифікація і
документування взаємозв'язків між роботами.
• Оцінка тривалості робіт (6.3) - визначення кількості робочих
періодів, необхідних для завершення окремих робіт.
• Розробка календарного плану (6.4) - аналіз послідовності
робіт, тривалості їх та вимог до ресурсів з метою складання
календарного плану проекту.
• Планування ресурсів (7.1) - визначення того, які ресурси
(людські ресурси, обладнання, матеріали) і в якій кількості
мають бути задіяні для виконання робіт проекту.
• Оцінка вартості (7.2) - розробка приблизної оцінки вартості
ресурсів, необхідних для виконання робіт проекту.
• Визначення бюджету (7.3) - складання кошторису по кожній
роботі проекту.
• Розробка плану проекту (4.1) - отримання результатів інших
процесів планування та об'єднання їх в один узгоджений
чіткий документ.
Процеси удосконалення.Взаємодії між різними процесами планування в основному залежать від природи проекту. Наприклад, в деяких проектах ризик, що ідентифікується, може бути малий або взагалі відсутній до етапу завершення процесу планування і тоді команда проекту може усвідомити, що вартісні та планові цілі нереальні, а звідси, їх досягнення зв'язано із значним ризиком. Хоч процеси удосконалення виконуються переривисто і в разі необхідності у процесі планування проекту, не можна сказати, що вони необов'язкові. Вони включають:
• Планування якості (8.1) - визначення того, які стандарти
якості застосовні до даного проекту і як домогтися
відповідності їм.
• Організаційне планування (9.1) - визначення, документування,
розподіл обов'язків і відповідальностей, звітність у проекті.
• Комплектування штату (9.2) - отримання необхідних трудових
ресурсів для роботи в рамках проекту.
• Планування інформаційного зв'язку (10.1) - визначення
інформаційних і комунікаційних потреб зацікавлених осіб: хто
в якій інформації має потребу, коли вона їм знадобиться і як
вона до них надходитиме.
• Ідентифікація ризику (11.1) - визначення того, які ризики
можуть впливати на проект, і документування характеристик
кожного з них.
• Кількісна оцінка ризику (11.2) - оцінка ризику та ризикованих
взаємодій для визначення діапазону можливих наслідків для
проекту.
• Розвинення реакції на ризик (11.3) - визначення кроків для
підсилення сприятливих можливостей і реакцій на загрози.
• Планування закупівель (12.1) - визначення того, що і коли
необхідно придбати.
• Планування клопотань (12.2) - документальне оформлення
вимог до продукту та визначення потенціальних джерел його
отримання.
Процеси виконання
Процеси виконання включають базові процеси і процеси удосконалення, як це описано в пункті 3.3.2. Малюнок 3—6ілюструє, як взаємодіють такі процеси:
• Виконання плану проекту (4.2) - реалізація плану проекту
шляхом виконання робіт, що увійшли до нього.
• Перевірка змісту (5.4) - формалізація приймання змісту
проекту.
• Забезпечення якості (8.2) - оцінка загального виконання
проекту на регулярній основі для підтвердження того, що
проект задовольняє стандарти якості.
• Робота з командою (9.3) - удосконалення індивідуальних і
групових навичок для поліпшення роботи в рамках проекту.
• Поширення інформації (10.2) - своєчасне надання необхідної
інформації зацікавленим особам проекту.
• Клопотання (12.3) - отримання тендерної документації,
тендерних пропозицій або інших слушних пропозицій.
• Вибір джерела (12.4) - вибір серед потенціальних продавців.
• Адміністрування контракту (12.5) - управління зв'язком з
продавцем.
3.3.4 Процеси здійснення контролю
Виконання проекту має регулярно перевірятися для своєчасного визначення відхилень від плану. Розбіги ведуть до введення процесів контролю в різних прикладних сферах. У разі виникнення значних відхилень (тобто таких, які наражають на небезпеку саму мету проекту) до плану будуть внесені зміни з допомогою дублювання відповідних процесів планування. Наприклад, змінена дата фінішу роботи може зажадати внесення змін у поточний план по персоналу, використання понаднормових для досягнення планових і бюджетних цілей. Контроль також включає здійснення превентивних дій для запобігання можливим проблемам.
Група процесів контролю містить базові процеси і процеси удосконалення, як це описано в пункті 3.3.2.
Малюнок 3—7ілюструє, як взаємодіють такі процеси:
• Загальний контроль за змінами (4.3) - координація змін по
всьому проекту.
• Контроль за змінами змісту (5.5) - контроль змін у змісті
проекту.
• Контроль дотримання календарного плану (6.5) - контроль за
змінами в календарному плані проекту.
• Контроль вартості (7.4) - контроль за змінами в бюджеті
проекту.
• Контроль якості (8.3) - відстежування певних результатів по
проекту для встановлення того, чи відповідають вони певним
стандартам якості, і для визначення шляхів усунення причин
незадовільного виконання.
• Звітування про виконання проекту (10.3) - збір і поширення
інформації про виконання. Цей процес включає складання
звітів про стан, контроль виконання та прогнозування.
• Контроль за реакцією на ризик (11.4) - реагування на зміни
ризику в ході виконання проекту.
Процеси закриття
Малюнок 3-8ілюструє, як зв'язані такі процеси:
• адміністративне закриття проекту (10.4) - отримання, збір і
поширення інформації для документально оформленого
завершення всього проекту або однієї з його фаз;
• закриття контракту (12.6) - завершення і врегулювання
виконання завдань контракту, включаючи вирішення всіх
відкритих питань.
3.4 Настройка взаємодій між процесами
Процеси та взаємодії між ними, описані в підрозділі 3.3, задовольняють тести формального приймання - вони застосовуються вже давно для більшості проектів. Проте, не всі процеси потрібні в усіх проектах і не всі взаємодії застосовуються в усіх проектах. Наприклад:
• Організація, яка користується послугами підрядників, може
вже на стадії планування указати, де і який процес закупівлі
очікується.
• Відсутність у плані якогось процесу не означає, що останній не
буде здійснений. Команда менеджерів проекту повинна
визначити й управляти всіма процесами, необхідними для
успішного виконання проекту.
• У проектах, що залежать від унікальних ресурсів (проекти
розробки комерційного програмного забезпечення, проекти в
біофармацевтичній промисловості і т.ін.), до визначення змісту
бажано розподілити ролі й відповідальність кожного, оскільки
те, що може бути зроблено, залежатиме від виконавця.
• Деякі результати в процесах можуть бути заздалегідь задані як
обмеження. Наприклад, служби менеджменту можуть задавати
дату завершення цільового проекту, а не отримувати її в
результаті планування.
• Великі проекти можуть бути і більш детальними. Наприклад,
ідентифікація ризику може бути надалі розбита для того, щоб
окремо зосередитися на вартісних, планових, технічних
ризиках і ризиках якості.
• У підпроектах і менших проектах на результати, визначені на рівні проекту, можуть бути витрачені менші зусилля (наприклад, субпідрядчик може ігнорувати ризики, що мають відношення до головного підрядчика); це саме справедливе й відносно процесів обмеженого використання (у проекті з чотирьох чоловік може і не бути формального плану комунікацій).
Коли існує необхідність у внесенні зміни, то останню необхідно ясно визначити, ретельно оцінити и активно нею управляти.
II.Галузізастосуваннязнань
З проектного менеджменту
4. Управління інтеграцією в проекті
5. Управління змістом проекту
6. Управління часом у проекті
7. Управління вартістю проекту
8. Управління якістю проекту
9. Управління трудовими ресурсами проекту
10. Управління інформаційним зв'язком у проекті
11. Управління ризиком у проекті
12. Управління закупівлями в проекті
4.Управління інтеграцією в проекті
Управління інтеграцією в проекті включає різні дії, необхідні для того,
щоб основний процес був скоординований правильно. Воно включає
здійснення обміну між конкуруючими цілями й альтернативами для
того, щоб задовольнити або навіть перевищити очікування
зацікавлених осіб. Оскільки всі процеси управління проектами тією чи
іншою мірою є інтеграційними, то процеси, що описуються в даному
розділі, є суто інтеграційними. Малюнок 4-1містить огляд таких
основних процесів:
4.1 Розробка плану проекту- отримання результатів інших
процесів планування та об'єднання їх в один узгоджений
чіткий документ.
4.2 Виконання плану проекту- реалізація плану проекту шляхом
виконання робіт, що увійшли до нього.
4.3 Загальний контроль за змінами- координація змін по всьому
проекту.
Зазначені процеси взаємодіють як між собою, так і з процесами інших галузей застосування знань з проектного менеджменту. Кожний процес може включати зусилля одного чи кількох індивідуумів або груп індивідуумів, спрямовані на задоволення потреб проекту, і виконується, як правило, по одному разу на кожній фазі проекту.
Хоч тут процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб, що докладно тут не описується. Детально обговорені взаємодії між процесами в розділі 3.
Процеси, методи та засоби, використовувані для інтеграції процесів управління проектами, - центральні питання цього розділу. Наприклад, управління інтеграцією в проекті стає актуальним, коли необхідний кошторис з плану обліку невизначеностей в проекті або коли мають бути ідентифіковані ризики, зв'язані з різними альтернативами відносно використання персоналу проекту. Проте, для того щоб проект успішно завершився, інтеграція повинна мати місце і в інших галузях. Наприклад:
• Робота з виконання проекту має бути «вплетеною» в поточні дії
організації-виконавця.
• Зміст продукту і зміст проекту також мають бути «вплетеними»
(відміна між змістом продукту і проекту обговорюється у вступі
до розділу 5).
• Роботи різних функціональних фахівців (наприклад, будівельні,
електротехнічні та механічні креслення для інженерного
проекту) також мають бути «вплетеними».
Розробка плану проекту
При розробці плану проекту використовуються результати інших процесів планування для створення чіткого узгодженого документа,
яким можна було б керуватися для управління виконанням проекту і при здійсненні контролю за виконанням його. Цей процес майже завжди неодноразово повторюється. Наприклад, первинний план може включати загальні ресурси й недатовані строки, тоді як в заключному плані вказані певні ресурси й точні дати. План проекту використовується з метою:
• здійснення управління виконанням проекту;
• документування допущень при плануванні проекту;
• документування рішень планування з урахуванням обраних
альтернатив;
• полегшення зв'язку між зацікавленими особами;
• визначення основних режимів перевірки щодо змісту, вартості
та часу;
• забезпечення основи для контролю за виконанням проекту.
4.1.1 Вхідні дані для розробки плану проекту
.1 Результати інших процесів планування. Результати всіх процесів планування в інших галузях знань (у підрозділі 3.3 коротко описані ці процеси планування проекту) є вхідними даними для розробки плану проекту. Результати інших процесів планування включають як базові документи (наприклад, ієрархічна структура робіт), так і допоміжні деталі. Для багатьох проектів будуть необхідними вхідні дані, що залежать від певної прикладної сфери (наприклад, більшість проектів будівництва матимуть потребу в прогнозуванні руху грошових коштів).
.2 Інформація з архіву. Доступна інформація з архіву (наприклад, оцінка бази даних, записи виконання попередніх проектів) має бути врахованою при здійсненні інших процесів планування проекту. Ця інформація може знадобитися також при розробці плану проекту, щоб допомогти з перевіркою допущень і оцінкою альтернатив, визначених як частина цього процесу.
.3 Організаційна політика. Усі організації, що включені до проекту, можуть мати формальну та неформальну організаційну політику, результати якої обов'язково розглядаються. Види організаційної політики включають в себе (але не обмежуються цим):
• Управління якістю - процес аудиту, безперервне поліпшення
цілей.
• Керівництво персоналом - директива прийому на роботу,
звільнення, перевірки продуктивності працюючих.
• Фінансовий контроль - складання звітів за графіком про необхідні витрати і перевірки виплат, аналіз відшкодувань, коди обліку, стандартні умови контракту.
.4 Обмеження. Обмеження - це чинники, що обмежують дії команди менеджерів проекту. Наприклад, визначений наперед бюджет є обмеженням, яке, звичайно, досить жорстко лімітує дії команди, враховуючи зміст проекту, структуру персоналу та календарний план. Якщо проект виконується за контрактом, умови останнього в загальному випадку набувають чинності обмежень.
.5 Допущення. Допущення - це чинники, які для цілей планування розглядаються як істинні, реальні або визначені. Наприклад, якщо дата початку, яку має встановити керівник, ще не визначена, команда може призначити її сама. Звичайно, такі й будь-які інші допущення привносять певну міру ризику.
Методи та засоби для розробки плану проекту
./ Методологія планування проекту. Методологія планування проекту - це будь-який структурований підхід, що використовується командою менеджерів проекту для управління процесом розробки плану проекту. Підходи можуть бути простими, такі як стандартні форми і шаблони (на папері чи електронні, формальні чи неформальні), або складними, такі як групи необхідних методів моделювання (наприклад, метод
«Монте-Карло» для аналізу ризику по календарному плану). У більшості методик планування проектів використовується комбінація «жорстких» (наприклад, управління програмним забезпеченням проекту) і «м'яких» (наприклад, наради відносно запуску проекту)засобів.
.2 Знання та навички зацікавлених осіб. Кожна зацікавлена особа має знання та навички, які можуть виявитися корисними при розробці плану проекту. Команда менеджерів проекту повинна створити оточення, в якому зацікавлені особи можуть плідно співробітничати (див. також підрозділ 9.3). Хто співробітничає? Який внесок робить? Коли вводитимуться зміни? Наприклад:
• У будівельному проекті, що виконується по контракту з
фіксованою вартістю, під час підготовки пропозиції відносно
суми контракту головний внесок у розв'язання задачі
прибутковості проекту роблять інженери-фахівці з розробки
кошторису.
• У проекті, де штат службовців визначається заздалегідь, окремі
працівники, перевіряючи тривалість і оцінюючи трудові витрати
на предмет їх доцільності, можуть зробити значний внесок у
задоволення планових і вартісних цілей.
.3 Інформаційна система управління проектами (РМIS). Інформаційна система управління проектами складається з методів і засобів, що використовуються для збору, зведення і висвітлення результатів інших процесів управління проектами. Вона використовується від початку і до кінця для підтримки всіх сторін проекту і включає, як правило, і документацію, й автоматизовані системи.
Результати розробки плану проекту
.1 План проекту. План проекту є офіційно затвердженим документом, який використовується для управління проектом і здійснення контролю за його виконанням. Він має бути складений так, як це передбачалося в плані управління комунікаціями (наприклад, виконавча організація може вимагати загального висвітлення управління з незначною деталізацією, в той час як підрядчик може вимагати конкретизації з кожного окремого предмета). У деяких прикладних сферах термін «інтегрований план проекту» використовується при посиланні на цей документ.
Між планом проекту й основами контролю за виконанням його має бути чітке розмежування. План проекту - це документ або добірка документів, які повинні замінятися згодом, оскільки стає доступною більша кількість інформації відносно проекту. Основи контролю за виконанням проекту являють собою управлінський контроль і змінюватимуться тільки періодично й тільки у відповідь на прийняту зміну змісту проекту.
Існує багато способів організації і подання плану проекту, але найчастіше використовують такі (ці елементи описані більш детально в іншому розділі):
• Графік проекту.
• Опис підходу чи стратегії управління проектом (короткий
виклад індивідуальних планів управління з інших галузей знань).
• Опис змісту проекту, який включає роботи проекту і проектні
цілі.
• Ієрархічна структура робіт (WBS) для рівня, на якому
здійснюватиметься контроль.
• Оцінки вартості, планові дати старту проекту і призначення
відповідальних для рівня WBS, на якому здійснюватиметься
контроль.
• Основи контролю за дотриманням календарного плану й
запланованої вартості проекту.
• Головні віхи та цільові дати для кожної роботи.
• Основний або необхідний персонал.
• Основні ризики, включаючи обмеження та допущення, і
сплановані реакції на кожний.
• Допоміжні плани управління, включаючи план управління
змістом проекту, план управління календарним графіком і т.ін.
• Відкриті положення та невирішені питання.
• Результати інших процесів планування мають бути включені до
формального плану, що базується на потребах індивідуального
проекту. Наприклад, план проекту для великого проекту,
звичайно, включатиме структуру проектної організації.
.2 Допоміжні деталі. Допоміжні деталі до плану проекту:
• Результати інших процесів планування, що не ввійшли до
плану проекту.
• Додаткова інформація чи документація, отримана в процесі
розробки плану проекту (наприклад, обмеження та допущення,
які спочатку були невідомі).
• Технічна документація - вимоги, специфікації, креслення.
• Документація відповідних стандартів.
Цей матеріал має бути так систематизований, щоб ним можна було легко користуватися при виконанні плану проекту.
Виконання плану проекту
Виконання плану проекту - це головний процес, зв'язаний з реалізацією плану проекту і в результаті здійснення якого буде витрачено основну частину бюджету. У цьому процесі менеджер проекту і команда управління проектом повинні скоординувати та спрямувати різні технічні й організаційні зв'язки, усталені в проекті. Це процес проекту, на який найбільший безпосередній вплив чинить прикладна сфера проекту, для якої фактично і створюється продукт проекту.
4.2.1 Вхідні дані для виконання плану проекту
.1 План проекту. План проекту описаний у пункті 4.1.3.1. Допоміжні плани управління (план управління змістом, план управління ризиками, план управління закупівлями і т.д.), а також методи контролю виконання плану проекту є основними вхідними даними для його виконання.
.2 ДОПОМІЖНІ деталі. Див. пункт 4.1.3.2.
.3 Організаційна політика. Див. пункт 4.1.1.3. Будь-якій організації або всім організаціям, залученим до проекту, притаманна формальна чи неформальна політика, яка може впливати на виконання плану проекту.
.4 Коригуючі ДІЇ Коригуючі дії - це будь-які дії, спрямовані на упорядкування майбутніх показників виконання проекту відповідно до плану проекту. Коригуючі дії є результатом різних процесів контролю - вони забезпечують цикл зворотного зв'язку для здійснення ефективного управління проектами.
4.2.2 Методи та засоби для виконання плану
проекту
.1 Загальні управлінські навички. Загальні управлінські навички, такі як лідерство, комунікація і ведення переговорів, є обов'язковими для здійснення ефективного виконання плану проекту. Загальні управлінські навички описані в підрозділі 2.4.
.2 Знання та навички З продукту. Команда проекту повинна мати необхідні знання та навички, що стосуються продукту проекту. Необхідні навички задаються як частина процесу планування (особливо це стосується планування ресурсів, див. підрозділ 7.1) і забезпечуються під час комплектування штату (див. підрозділ 9.2).
.3 Система надання повноважень по роботах. Система надання повноважень по роботах - це формальна процедура санкціонування виконання робіт проекту з метою забезпечення їх виконання у необхідній послідовності та призначений час. Базова технологія звичайно включає в себе отримання письмових повноважень на виконання однієї або кількох робіт. Проектування системи надання повноважень по роботах повинне виходити з ідеї балансу між цінністю системи контролю та витратами на систему контролю. Наприклад, у багатьох невеликих проектах достатньо усного розпорядження про надання повноважень.
.4 Наради 3 огляду стану проекту. Наради з огляду стану проекту - це ті, що регулярно плануються і провадяться з метою взаємного обміну інформацією по проекту. У більшості випадків на такі наради збираються з різною частотою і на різних рівнях (наприклад, команда менеджерів проекту може збиратися раз на тиждень, а зустрічатися із замовником раз на місяць).
.5 Інформаційна система управління проектами. Див. пункт 4.1.2.3.
.6 Організаційні процедури. Будь-яка організація або всі організації, залучені до проекту, можуть мати формальні та неформальні процедури, корисні при виконанні проекту.
Результати виконання плану проекту
.1 Результати роботи. Результати роботи - це результати по всіх роботах, виконаних з однією метою - завершити проект. Інформація по результатах робіт - які роботи завершені, а які ні, в якому ступені додержані стандарти якості, наскільки перевищені або заощаджені витрати по проекту і т. ін. - накопичується як складова частина плану виконання проекту і надходить до звітів про виконання (див. підрозділ 10.3 для більш детального обговорення питань складання звітів з виконання).
.2 Запити на ЗМІНИ. Запити на зміни (наприклад, на розширення чи зменшення змісту проекту, на зміну вартісних або планових оцінок і т.ін.) часто задаються по мірі виконання роботи над проектом.
4.3 Загальний контроль за змінами
Загальний контроль за змінами зосереджують на (а) впливах чинників, що створюють зміни, для того щоб переконатися, що ці зміни є сприятливими, (Ь) визначенні того, що зміна сталася, (с) управлінні фактичними змінами тоді, коли вони відбуваються. Загальний контроль за змінами вимагає:
• Підтримки цілісності при контролі виконання — всі прийняті
зміни мають бути відображені в плані проекту, але тільки зміни
у змісті проекту впливатимуть на контроль виконання.
• Гарантування того, що зміни в змісті продукту відображені в
змісті проекту (відмінність між змістом проекту та змістом
продукту описана у вступі до розділу 5).
• Координації змін по галузях застосування знань, як це зображено
на малюнку 4—2. Наприклад, пропонована зміна календарного
плану часто впливає на вартість, ризик, якість і склад персоналу.
4.3.1 Вхідні дані для загального контролю за змінами
.7 План проекту. План проекту є основою, за ним контролюються зміни (див. пункт 4.1.3.1).
.2 Звіти про виконання. Звіти про виконання (див. підрозділ 10.3) надають інформацію щодо виконання проекту. Звіти про виконання можуть також підказати команді проекту «вузькі місця», які в подальшому можуть спричинити проблеми.
.3 Запити на ЗМІНИ. Запити на зміни можуть надходити в різних формах - усній або письмовій, прямій або непрямій, таких, що ініціюються зовні або зсередини, обов'язкові чи необов'язкові.
4.3.2 Методи та засоби для загального контролю за змінами
.1 Система контролю за змінами. Система контролю за змінами - це добірка формальних, документованих процедур, які визначають етапи і відповідно до яких офіційні проектні документи можуть змінюватися. Ця система включає роботу з документами, системи відстежування і рівні повноважень для підтвердження змін.
У багатьох випадках організація, що виконує проект, вже матиме систему контролю за змінами, яка потім адаптуватиметься під конкретний проект. Якщо такої системи не існує, команда управління проектом повинна її розробити як складову частину проекту.
Багато які системи контролю за змінами включають групу контролю за змінами (ГКЗ), що відповідає за прийняття або відмову на запити на зміну. Повноваження та відповідальність ГКЗ мають бути чітко визначені й узгоджені з основними зацікавленими особами. У великих відповідальних проектах можуть бути створені складні ГКЗ з різними повноваженнями.
Система контролю за змінами також має включати процедури для управління змінами, які можуть бути затверджені без попереднього
перегляду, наприклад у результаті аварії. Звичайно, система контролю за змінами дозволяє автоматичне прийняття певних категорій змін. Але такі зміни все одно мають бути задокументовані та збережені, для того щоб у подальшому вони не спричинили проблем у проекті.
.2 Управління конфігурацією. Управління конфігурацією - це будь-яка документована процедура, що використовується для технічного й адміністративного спостереження за:
• Визначенням і документуванням функціональних і фізичних
характеристик елементів або систем.
• Контролем будь-яких змін цих характеристик.
• Записом і звітом про зміни та стан їх здійснення.
• Перевіркою елементів і системи на відповідність вимогам [1].
У багатьох прикладних сферах управління конфігурацією є підмножиною системи контролю за змінами й використовується для гарантування того, що опис продукту проекту є правильним і повним. Проте, в деяких прикладних сферах термін «управління конфігурацією» використовується для опису будь-якої серйозної зміни системи контролю.