Існує певна кількість методів управління проектними активностями, включаючи Еджайл (англ. Agile), інтерактивні, послідовні та методи розподілу на етапи.

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

Традиційний метод[ред. • ред. код]

Традиційний метод поділу на етапи передбачає визначення послідовності дій, що мають бути завершені. В «традиційному методі» можливо визначити 5 складових проекту (4 етапи та контроль) розвитку проекту:

 

Типові етапи виконання проекту

1. Ініціювання.
2. Планування та розробка.
3. Виконання та впровадження.
4. Моніторинг та контроль.
5. Завершення.

Не всі проекти проходять кожен з етапів, так як проект може бути припинений до його завершення. Деякі проекти не мають етапів структурованого планування та/або моніторингу. Деякі проекти проходять стадії 2, 3 і 4 декілька разів.

Багато галузей використовують варіації зазначених етапів. Наприклад, будівельні проекти зазвичай проходять через приблизно такі етапи: Попереднє планування, Концептуальне проектування, Схематичне проектування, Розробка проекту, Будівельні креслення (або Договірні документи) та Управління будівництвом.

В розробці програмного забезпечення цей підхід відомий під назвою, дослівно, «модель водоспаду», (англ. waterfall model),^[16] наприклад, друга група завдань виконується після першої в лінійній послідовності. Для «моделі водоспаду» використовуватимемо назву «послідовна модель». З метою адаптації послідовної моделі при розробці програмного забезпечення багато організацій використовують методологію Раціональних уніфікованих процесів (англ. Rational Unified Process - RUP). RUP не вимагає та однозначно не вказує на необхідність використання послідовної моделі. Використання послідовної моделі управління проектами ефективне для невеликих, визначених проектів, але для більш великих, невизначених та нових проектів зазначена модель часто призводить до негативних результатів. «Конус невизначеності» (англ. Cone of Uncertainty) пояснює таке явище тим, що планування, яке виконується на початкових етапах проекту є не ефективним через значний ступінь невизначеності. Це особливо актуально для розробки програмного забезпечення, оскільки така розробка часто є новим продуктом. В проектах, де вимоги не були завершені і можуть змінюватися, використовується управління вимогами з метою розробки точного і повного визначення поведінки програмного забезпечення, що може бути базисом для його розробки.^[17] Тоді як визначення можуть змінюватися в залежності від галузі, фактичні етапи зазвичай відповідають загальним крокам вирішення проблем (англ. problem solving) — «ідентифікація проблеми, оцінювання варіантів вирішення, вибір шляху вирішення, впровадження та оцінювання».