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

Кейс из практики: как не натянуть сову на глобус Несколько лет назад меня пригласили внедрить MS Project + Project Server в одну крупную компанию. Масштаб серьёзный, задачи амбициозные, руководство воодушевлённое. На первой же встрече мне торжественно вручили документ под названием «Процесс управления проектами». Внушительный такой документ, с оглавлением, приложениями и печатью. Читаю. И понимаю, что человек, который это писал, со стандартами по управлению проектами знаком примерно так же, как я с практикой наращивания ресниц (то есть никак). На мой осторожный вопрос — а на чём основана методика? — мне гордо ответили: «У нас уникальные проекты. Поэтому стандарты нам не нужны». Хотел рассказать им что каждый проект уникальный, Ну, думаю, ладно. Читаю дальше. Планирование проекта в документе было описано одной фразой: «Разрабатывается план проекта». Всё. Ни ответственного, ни методов расчёта, ни инструментов, ни критериев качества. Просто «разрабатывается». Кем? Когда? Как? Зачем? Молчание. Зато процедура закупки занимала 20 страниц. С методиками, точками согласования и т.д. И процедура привлечения подрядчика — ещё 15 страниц. Похоже, в этой компании проекты не планировали, но закупали — с особым удовольствием и вдумчивостью. Дальше — интереснее. Спрашиваю: «А это работает? Процесс этот. В реальности?» Смотрят на меня с недоумением. — Ну как... документ есть. Утверждён. — А проекты по нему идут? — Ну... проекты идут. Но как бы... по-своему. Документ только утвержден, поэтому в проектах пока не используется. Короче, процесс существовал только на бумаге. В реальности никто им не пользовался. Просто был документ. Красивый, объемный. С печатью и подписью гендира. И вот тут наступает момент истины. Я объясняю: Project Server — как и любая система управления проектами — «заточен» под логику стандартов. PMI, ISO, PRINCE2 — неважно. Все они говорят на одном языке: есть WBS, есть связи, есть ресурсы, есть базовый план, есть освоенный объём. Если у вас «уникальный процесс», в котором ничего этого нет, — вы пытаетесь натянуть сову на глобус. Причём сова — Project Server, а глобус — ваш документ. Я честно сказал: ребята, так не получится. Давайте сядем, привлечём экспертов, разработаем нормальный внутренний стандарт — на базе PMI или ISO, но с учётом вашей специфики. Потом уже будем внедрять систему. Ответ был предсказуем: «Нет. У нас уникальные проекты. И вообще, у нас уже есть процесс. Вот он, в папке». Короче, за внедрение я не взялся. Мораль простая: «изобретать свой велосипед» — это не когда вы адаптируете стандарт под себя. Это когда вы с нуля изобретаете то, что уже давно изобретено, и удивляетесь, почему не едет. А потом зовёте консультанта, чтобы он «как-нибудь это внедрил». Не получится. Сначала изучите ноты. Потом пробуйте написать музыку. PS. Случай не единичный. Если кто узнал свою компанию - повод задуматься. #УправлениеПроектами #MSProject #ProjectServer #PMI #ISO21500 #PMO

Про стандарты управления проектами: разница есть, но не там, где вы думаете Есть устойчивое мнение, что выбор стандарта управления проектами — это чуть ли не стратегическое решение. PMI или ISO? IPMA или APM? Что лучше? Правда в том, что разница в эффективности проекта при использовании разных стандартов — на уровне статистической погрешности. Исследования это подтверждают уже не первый год. Если вы просто берёте PMBOK (6 или 8 версию), или ISO 21502:2020, или любой другой признанный подход и добросовестно его изучаете, адаптируете, применяете — результат будет примерно одинаковым. Потому что все они основаны на здравом смысле и десятилетиях практики. Другое дело — «свой изобретённый велосипед». Вот тут начинается самое интересное. Доморощенная методика, написанная «под себя» и не проверенная ни на одном проекте, кроме текущего. Назовите ее «Наш Agile» или «Уникальный путь в проектах нашей компании». И вот она-то как раз и даёт разброс результатов — от «случайно сработало» до «мы всё сломали». Вывод простой: прежде чем писать музыку — надо изучить ноты. Освойте документы PMI, ISO, IPMA или другие признанные стандарты. Поймите, почему они работают. А потом уже разрабатывайте внутреннюю методологию — но не с нуля, а на прочном фундаменте. Иначе есть риск изобрести велосипед с квадратными колёсами и удивляться, почему он не едет. #УправлениеПроектами #PMI #ISO21500 #PMO #Методология

Все стандарты управления проектами — это одна и та же цепочка. Просто разные картинки PMBOK, ISO 21ХХХ, PRINCE2, ГОСТы, и т.д. Кажется, что между ними пропасть. На деле — разница в терминологии, схемах и степени детализации. Суть одна. Вот универсальная логическая цепочка, к которой в итоге сводится любой стандарт: 1.    Постановка цели проекта и критериев успеха. Зачем мы это делаем? Что будет считаться победой? 2.    Сбор требований от заинтересованных лиц. Кто эти люди? Чего они хотят? Что для них важно? 3.    Понимание работ, которые нужно выполнить. Что конкретно надо сделать, чтобы цель стала реальностью? 4.    Определение последовательности работ. Что за чем идёт? Где можно параллелить, а где нельзя? 5.    Ресурсы, материалы, затраты. Кто это будет делать? Что необходимо для выполнения? Сколько это стоит? 6.    Оценка длительности. Сколько времени займёт каждая работа, этап, проект целиком? 7.    Риски и реагирование. Что может пойти не так? И что мы будем с этим делать? 8.    Контроль. Как мы поймём, что всё идёт по плану? А если нет — что делать? 9.    Приёмка результатов. Кто и как будет принимать и в итоге скажет «Да»? Всё. Дальше — детали. Где-то гейты обязательны, где-то нет. Где-то ИСР, где-то СДР. Где-то больше документов, где-то меньше. Где-то жёстче, где-то гибче. Но если вы честно проходите эти девять шагов — вам неважно, какой стандарт написан на обложке. Если пропускаете — никакой стандарт не спасёт. Так что выбирайте любой. Главное — не забудьте про первый пункт. Остальное — производные. #УправлениеПроектами #PMI #ISO21500 #PRINCE2 #Agile #PMO