Заявка на іспит PMP®: уникаємо помилок

filling a formОдин із обов’язкових етапів сертифікації PMP® – це подання заявки (Application Form). Процес подання заявки досить простий та добре документований. PMI навіть супроводив його відеороликом, який можна побачити тут. Тим не менш, у заявці є розділ Experience, який супроводжено лише поверхневими рекомендаціями щодо заповнення. Як правило, більшість помилок заповнення заявки на сертифікацію PMP® пов’язані саме з цим розділом. На них ми зараз і зупинимося.

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

Єдина мета заповнення вашої заявки є вкрай обмеженою. Ви повинні показати, що ваш досвід відповідає вимогам до претендента на сертифікацію PMP®. Крім певної кількості місяців, ваш досвід повинен стосуватися саме управління та саме проєктом.

Почнемо з останнього. Ви претендуєте на сертифікат PMP® – Професіонал управління проєктами. Не програмами, не портфелями, не мультипроєктами, а п-р-о-є-к-т-а-м-и. Тому рев’ювер або аудитор, що читає вашу заявку, повинен легко і однозначно ідентифікувати кожен ваш опис роботи як окремий проєкт. Для цього робота має бути (згадуємо визначення, що таке проєкт) обмеженою за часом та спрямованою на створення унікального результату, продукту чи послуги.

Тому помилка перша, вона ж найфатальніша – неправильна назва роботи, на участь в управлінні якою ви посилаєтеся. У назві не повинно бути слів Program, Portfolio, Multiple project тощо. Правильний варіант – вказати, що це Project. Наприклад: Wind Turbine Project for ABCD.

Підкріпити впевненість, що ви посилаєтеся на проєкт мають рядки Project Goal(s), з якого варто почати опис у полі Project Description, та Project Outcome(s), яким опис варто закінчити. Project Goal повинна полягати у створенні чогось очевидно унікального, а Project Outcome підтверджувати, що саме це унікальне “щось” і отримано. Цілком нормально, якщо це буде слово в слово. Якщо проєкт не завершено, відповідно пишемо Expected Outcome.

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

Тепер повернемося до підтвердження, що ви роботою керували. Нагадаю, що менеджер – це той, хто доягає результату чужими руками. Тому описуйте свої обов’язки в проєкті (для зручності у вигляді перерахування з дефісами), застосовуючи правильні “менеджерські” формулювання та без сорому підкреслюючи вашу керівну роль у команді проєкту та у спільноті стейкхолдерів: I managed, I lead, I facilitated etc.

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

І нарешті “вишенька на торті” вашого опису – перерахування Project management deliverables, яке може йти відразу після ваших обов’язків і в чомусь їм відповідати. Наприклад, якщо ви очолювали розробку Плану управління проєктом (як ми пам’ятаємо, це колективна робота), то логічний Deliverable – Project Management Plan. Якщо ви фасилітували команду Agile проекту, то логічними будуть такі Deliverables як Team Charter, Agile Procedures etc. У жодному разі в даному перерахуванні не варто вказувати артефакти та результати хоч скільки-небудь технічного, технологічного чи виробничого характеру: специфікації вимог, дизайни, ПКД тощо. Це не ваше, не менеджерське.

Отже, підіб’ємо підсумок. На що слід звернути увагу, щоб не переживати перед можливим аудитом вашої заявки:

  • Правильна (характерна) назва проєкту
  • Project Goal
  • My (project) responsibilities
  • Project Management Deliverables
  • Project Outcome (expected)

І щоб двічі не підводитися. Іноді нас просять не розумничати, а надати приклади вдало складених заявок. Колись ми так і робили. Але з деяких пір PMI запровадив перевірку всіх заявок на плагіат, і було відзначено масові випадки дискваліфікації. Алгоритм перевірки дуже суворий, тому краще щоб ваші описи були максимально унікальними. Тим більше, що зробити це зовсім не складно.

Тож успішної вам сертифікації!