Kitobni o'qish: «MS Project vs маржа. Как превратить ваш MS Project в союзника в битве за прибыль»
Оглавление
Беличье колесо в День сурка (предисловие)
Лестница зрелости (как компании расти вместе с технологиями)
Часть 1. Детектор дыма
Глава 1. План? Модель!
Глава 2. Планирование и перепланирование
Глава 3. За и против ресурсного плана
Глава 4. Деньги в модели проекта
Глава 5. Маржинальность
Часть 6. Как не профакапить маржу
Часть 2. Контроль и прогноз
Глава 1. План-фактный анализ
Глава 2. Как получить объективные ответы о состоянии проекта
Глава 3. Прогресс по физике: натуральный или денежный?
Глава 4. Цифры, которые расставят все точки над «ё»
Глава 5. Как математически обосновать прогнозную дату завершения задачи
Глава 6. Как купить время за деньги
Глава 7. Вместо или вместе?
Глава 8. Достучаться до небес
Часть 3. Под капотом
Раздел 1. Настройка графических индикаторов сравнения дат финиша
Раздел 2. Макрос для расчета физического процента завершения
Раздел 3. Формулы для прогноза по выработке
Раздел 4. Макрос для ES
Раздел 5. Настройка дашборда с S-кривой
Зачем вы всё это читали? (послесловие)
Беличье колесо в День сурка (предисловие)
Для кого эта книга
Для начала, я хочу попросить вас ненадолго посмотреться в зеркало.
Ваш рабочий день похож на тысячи других: вы постоянно заняты. Телефон, почта, совещания, стройплощадка, переговоры, десятки решений каждый день. Если посмотреть на весь день целиком, то окажется, что большая часть этих действий – это реакция на возникающие ситуации. Это «тушение пожаров».
Вы уже привыкли к пожарам, они уже превратились в рутину: «пожар, который всегда со мной».
Узнали себя?
За годы работы мне довелось участвовать во внедрении систем управления проектами в компаниях разного масштаба. Почти каждый раз я видел одну и ту же картину: люди покупали хорошие инструменты, проходили обучение, создавали отличные планы-графики, даже аккуратно вводили факт… и продолжали жить в режиме постоянного тушения пожаров.
Проблема заключалась в том, что проект существовал одновременно в двух разных средах:
в плане-графике;
в реальности.
Чем дальше от старта, тем больше они различались, и тем больших усилий требовала их синхронизация. Постепенно план сам по себе становился чемоданом без ручки. В какой-то момент происходило принятие того, что план уже не помощь, а обуза, и PM бросал его вести, либо начинал вести спустя рукава. Это приводило к тому, что о проблемах становилось известно слишком поздно, когда изменить что-либо уже дорого, сложно или вовсе невозможно.
Эта книга для вас, если вы руководитель отдела или собственник бизнеса.
Вам надоело слушать на совещаниях «всё под контролем», а потом получать убыток. Вы хотите видеть по каждому проекту две цифры: прогнозную дату финиша и текущую маржинальность. И вы очень хотите, чтобы эти цифры брались не из головы ваших сотрудников, а из системы.
Эта книга для вас, если вы руководитель проекта или инженер-планировщик.
Вы уже умеете работать в MS Project: создавать задачи, связывать их, назначать ресурсы. Но внутри есть ощущение, что вы используете программу на 20% возможностей, а остальные 80% – это «что-то там про деньги и прогнозы», до чего руки так и не дошли. Вы ведете календарные планы, вводите факт, пересчитываете даты. Вы уже устали вручную перепланировать проект каждый раз, когда подрядчик срывает сроки или меняется цена на материал. И вообще вы хотите заполучить классного помощника
О чем эта книга
Эта книга не о том, как быстрее построить диаграмму Ганта или освоить очередную функцию Microsoft Project. Она не о том, как сделать сложные проекты проще или вашу работу легче.
Эта книга о том, как построить план проекта таким, чтобы вы узнавали о проблемах раньше, чем они вызовут пожар.
Для этого мы будем говорить не только об использовании функций MS Project. Мы будем говорить о том, как должен быть устроен план проекта, чтобы он помогал принимать решения, а не только лишь фиксировал последствия уже произошедших событий.
Хотя большинство описанных подходов не зависят от конкретной программы, я выбрал MS Project как инструмент реализации. Объясню почему:
По моему опыту Microsoft Project – это один из самых недооцененных инструментов управления проектами. Не потому, что он способен решить любые задачи. Но потому что его реальные возможности значительно шире того, как его используют в большинстве организаций.
MS Project остается самым массовым инструментом управления строительными и инжиниринговыми проектами в SMB в мире. По факту MS Project – это стандарт, который еще длительный период времени не утратит своих позиций.
Эта книга – не справочник функций программы. Человеку, не умеющему работать в MS Project и не знающему его функций, будет сложно. Поэтому книга рассчитана на читателей, имеющих базовые компетенции в использовании MS Project. Иначе пришлось бы писать непомерно большой объем текста, большая часть из которого была бы тысячу раз уже описана в других книгах.
Структура книги
Часть 1. Детектор дыма
Эта часть для тех, у кого пожар.
Конечно, вы не потушите пожар на площадке (это невозможно, работая за компьютером). Но вы перестанете бегать по участку, потому что будете знать всю обстановку:
Эта задача ушла в отставание на 3 дня. Если сегодня не добавить смену, то она потянет за собой другие задачи, и мы опоздаем на 2 недели.
Цена на этот материал выросла на 15%. Новая маржинальность уже 17% вместо плановых 20%. Требуется принять управленческое решение, чтобы выправить маржу. Например, найти другого поставщика.
У нас 5 проектов. В трех маржа в норме, один чуть просел, а четвертый уже убыточен. Весь фокус внимания направить на убыточный проект.
В результате вы заходите в MS Project уже не для того, чтобы «сделать отчет». Вы заходите, чтобы принять решение: отправить смену на этот объект, дернуть поставщика по этому материалу, перебросить прораба с того проекта на этот. И эти решения уже не интуитивны, но основаны на цифрах. С «детектором дыма» вы видите проблему до того, как она превратилась в пожар.
И вот вы уже не просто тушите пожар, но начинаете управлять.
Часть 2. Контроль и прогноз.
Эта часть для тех, кто уже выдохнул и хочет системность. Тут мы копаем глубже, но только если вы этого хотите. В этой части вы понимаете:
как перестать быть «заложником проекта» и стать его «архитектором»;
как применить технологичные практики прогнозирования и визуализации;
как перестать доказывать свою правоту на пальцах, но показываете цифры, с которыми не поспоришь.
И теперь вы не просто знаете, что проект идет не по плану. Вы знаете, когда он закончится, во что он обойдется и что нужно сделать прямо сейчас, чтобы не провалить маржу.
И вот вы уже предвидите ситуацию, и начинаете действовать на упреждение.
Часть 3. Под капотом.
Эта часть для технарей. Здесь расположены макросы, формулы и прочие технические аспекты реализации. CEO необязательно это читать. Но, если будет интересно, можно заглянуть.
Цель книги
И последнее, что я здесь хочу сказать. Цель этой книги – чтобы вы однажды поймали себя на мысли: «Об этой проблеме я узнал не потому, что она уже начала портить мне жизнь, а потому, что мой план предупредил меня заранее.»
Если это случится, значит книга написана не зря.
Лестница зрелости (как компании расти вместе с технологиями)
«Прыгать через ступеньки – это забавно.
Но не удивляйтесь, если вы вдруг расшибете себе лоб.»
(народная мудрость)
Я хотел бы поднять одну очень важную, и как мне кажется, спрятанную от лишних глаз тему: готовности компаний что-либо внедрять.
Представьте ситуацию. CEO говорит: "Мы будем внедрять EVM!" При этом в компании:
нет специалиста, который готовит нормальную структуру задач проекта;
PM не умеют назначать ресурсы на задачи;
прорабы докладывают факт раз в месяц, а не каждый день.
Консультант пыхтит. CEO осуществляет массовые репрессии. Исполнители рвут на себе волосы во всех местах вплоть до увольнения. Однако, в подавляющем большинстве случаев результат бывает примерно следующий:
система умирает и все возвращается в точку «А»;
CEO разочарован во всем и вся;
исполнители на местах ненавидят консультанта открыто и люто;
бухгалтерия подсчитывает затраты, понесенные в процессе внедрения.
Хорошо, если CEO возвращается к теме автоматизации управления проектами через год-два. Часто все настолько плохо заканчивается, что такие компании начинают обходить любых «консультантов-автоматизаторов» десятой дорогой.
И вместо win-win получается loss-loss.
Если же вам интересно не только войти в очередную авантюру, но и повысить вероятность ее успеха (стопроцентной гарантии вам никто в этом мире не даст), вам необходимо определить:
насколько вы готовы решать те задачи, которые вас заинтересовали (то есть на какой ступени «лестницы зрелости» управления проектами вы в данный момент находитесь);
как далеко от вашего текущего состояния готовности находится та цель, которую вам предлагает достичь очередной консультант (то есть через сколько ступенек этой лестницы он предлагает вам перепрыгнуть).
Каждая ступень «лестницы зрелости» – это набор инструментов MS Project, а также приемов и методик, которые дают ценность на своем уровне. Важно отдавать себе отчет в том, что органичное перемещение между ступенями происходит только когда в этом есть объективная потребность (например, контракт с новым большим контрагентом, у которого есть собственные стандарты управления проектами, и который закладывает их в контракт с вами), а не потому, что это «стильно, модно, молодежно», и вообще это уже давно работает в фирме у Василия Петрова, с которым CEO пьет пиво по вечерам (нетворкается).
Я приведу мою версию лестницы зрелости. Так как она родилась из личного опыта, то ни в коем случае не может рассматриваться как истина в последней инстанции. Но если вы найдете ее небесполезной для определения путей развития своей компании – я буду рад.
Ступень 0. Управление по ощущениям (хаос)
Характерные признаки:
все процессы «в голове» у одного человека;
решения принимаются только на основе опыта сотрудников;
PM отвечает на вопрос «Как дела?» фразами: «Нормально», «Всё под контролем», «Немножко отстаем, но догоним»;
часто в проекте нет детализации задач, только крупные блоки работ;
ресурсы на задачи не назначаются (редко назначаются только трудовые и то, только чтобы зафиксировать исполнителя по задаче);
прогресс по задачам не считается, а оценивается только экспертно (пальцем в небо).
При попытке автоматизировать работу в MS Project происходит коллапс. Сотрудники не понимают, зачем это нужно. Данных нет. Процессов нет. У руководства нет понимания, что и как требовать, и каким должен быть результат работы сотрудников в MS Project. Всё разваливается.
Это стартовая точка. Здесь не нужно внедрять системы. Здесь даже с осторожностью нужно наводить порядок. На этом этапе хорошо стандартизировать типовую структуру проекта. Начать с чек-листа задач по проекту (чтобы PM ни о какой задаче не забыл), а потом связать блоки задач вместе.
Ступень 1. Прогресс по длительности (календарный план)
Характерные признаки:
для оценки прогресса уже требуются любые количественные характеристики, а не только экспертная оценка;
календарный план по проекту утверждается как внутренний документ компании;
задачи детализированы до уровня работ, которым уже можно назначить физобъемы, материалы или трудозатраты (и на некоторые задачи они уже назначаются);
большинство задач связано между собой (сетевой график есть, но не везде);
прогресс по задачам вводится вручную в поле «% завершения» (по длительности);
создается базовый план, но только для цели отслеживания смещения сроков.
Что дает эта ступень:
появляется первая объективность: «Мы отстаем на 3 дня» (это уже лучше, чем «мы отстаем на несколько дней»);
PM перестают «экспертно» оценивать сроки, и уже опираются на график;
PM и CEO могут посмотреть на диаграмму Ганта и понять, где узкое место.
Главные ограничения:
прогресс по задаче не отражает выполненный объем работ;
ресурсы реально не учитываются;
PM могут манипулировать датами и прогрессом, чтобы скрыть отставание.
Когда переходить на следующую ступень:
CEO перестал верить значению поля «% завершения», потому что оно не бьется с реальностью;
стало необходимо планировать и отслеживать задачи с разными типами ресурсов (трудовые, материальные, затраты).
Ступень 2. Ресурсный план 1 уровня (в натуральном выражении)
Характерные признаки:
CEO необходимо знать не только когда закончим задачу и проект, но еще и сколько физических объемов выполнено и осталось выполнить;
на проектах появились отдельные сотрудники, отвечающие за производство работ на участке, которые, кроме прочих обязанностей, отчитываются о физическом выполнении работ;
основанием для разработки плана работ является смета (пока только в части физических объемов);
на задачи назначаются ресурсы требуемых типов (трудовые, материальные);
прогресс уже рассчитывается автоматически;
прогресс все еще рассчитывается в поле «% завершения» (по длительности).
Главное, что дает эта ступень: прогресс начинает показывать признаки объективности, потому что он основан на реальном объеме выполненных работ (пусть даже пока рассчитывается в поле «по длительности»);
Главные ограничения:
расчет прогресса все еще далек от объективности (он все еще выполнен «по длительности», а не «по физике»);
все ресурсы одинаковы с точки зрения влияния на прогресс: нет учета удельного веса ресурсов как в рамках одной задачи, так и в рамках проекта.
Когда переходить на следующую ступень: приходит понимание, что необходимо учитывать удельный вес ресурсов в проекте;
Ступень 3. Ресурсный план 2 уровня (учет стоимости ресурсов, прогнозирование по средней выработке)
Характерные признаки:
компания перестала спорить о том, что «важнее»: фундамент или кровля, человеко-часы или кубометры. Универсальным мерилом веса признана стоимость;
CEO требует ответа не на вопрос «Сколько физических объемов мы выполнили?», а «На какую сумму мы выполнили работы от общего бюджета проекта?»;
разные уровни руководства учатся мыслить в единообразно и в категориях освоенного бюджета: «Мы освоили 30% сметы, хотя по календарю должны были освоить 40%»;
появляется историческая статистика по стоимости единицы работы: компания знает, сколько «стоит» ей тот или иной физический объем, и использует это для оценки («влезаем» в бюджет или нет);
каждому ресурсу (трудовому, материальному) назначена ставка (стоимость единицы ресурса);
прогресс задачи теперь считается не по длительности и не по количеству каждого ресурса в отдельности, а через деньги: «% завершения» = «Освоенный объем в деньгах (Earned Value)» / «Плановый объем в деньгах (Planned Value)» × 100;
пока это выглядит как автоматический расчет в стандартном поле «% завершения» (через трудозатраты или сумму затрат), но PM уже понимает, сколько стоит проект и каждая задача в нем;
начинается прогнозирование по средней выработке в деньгах: «В неделю мы осваиваем в среднем на 800 тысяч. Осталось освоить 4 миллиона. Значит, финиш через 5 недель».
Что дает эта ступень:
Появляется единая система координат. Больше не надо спорить, что считать «весом». Стоимость сама всё взвесила. Дорогая работа «весит» в прогрессе больше дешевой – ровно так, как это и должно быть с точки зрения бизнеса.
Мост к финансам. Впервые проект начинает говорить на языке денег, что понятно и CEO, и бухгалтерии (хотя не стоит думать, что деньги в MS Project должны иметь отношение к бухгалтерии – не должны, и об этом будет одна из глав). «Отстаем на 3 миллиона рублей» звучит гораздо более отрезвляюще, чем «отстаем на 500 кубов щебня».
Зачатки прогнозирования. PM видит тренд: если средняя скорость освоения бюджета падает, проект затягивается и, скорее всего, выйдет за рамки сметы или дедлайна. Появляется раннее предупреждение без лишней (пока что) математики.
Главные ограничения:
«Стоимость» ≠ «ценность» прямо сейчас. Освоение 50% бюджета не означает 50% готовности проекта к сдаче. Может быть, мы потратили деньги на бюрократию, а стены еще не начали класть.
Средняя выработка в деньгах – это грубый инструмент. Она не различает, куда именно мы тратим деньги: на высокомаржинальные или низкомаржинальные работы. В начале проекта мы тратим копейки на бумагу, а в середине – миллионы на металл. Усреднение может врать.
Прогресс всё еще в поле «по длительности». Несмотря на то, что данные для него берутся из денег, PM может технически манипулировать датами, чтобы «подкрасить» график.
Когда переходить на следующую ступень:
CEO говорит: «Я вижу, сколько денег мы освоили. Но я не вижу, эффективно ли мы их тратим. Мы освоили 50% бюджета, а физически объект готов на 30%. Почему каждый вложенный рубль дает только 60 копеек ценности?»
Появляется запрос на разделение понятий: «сколько освоили» и «сколько планировали освоить».
Ступень 4. Ресурсный план 3 уровня (учет изменения стоимости ресурсов)
Характерный признак: начинаются попытки руководства компании привлечь бухгалтерию или экономистов к расчету текущей маржинальности с учетом динамики цен.
Что дает эта ступень: максимальную точность расчета текущей маржинальности и адекватность ее сравнения с базовой маржинальностью.
Главные ограничения: трудозатраты на отслеживание и ввод изменений цен.
Когда переходить на следующую ступень: критерии аналогичны предыдущей ступени.
Ступень 5. EVM 1 уровня (CPI, SPI, S-кривая, прогнозирование по EVM)
Характерные признаки:
CEO требует отчет по отклонениям: «На сколько рублей мы уже отстали или опережаем график?».
в компании появляется человек, который понимает, как считать освоенный объем и отличает его от фактических затрат;
прогресс рассчитывается только автоматически и по физобъему (где он есть);
рассчитываются основные параметры и индексы EVM;
считаются и анализируются базовые индексы: «индекс отклонения сроков» (SPI) и «индекс отклонения стоимости» (CPI);
автоматически формируется S-кривая проекта (отчет).
Что дает эта ступень:
Раннее предупреждение о финансовых рисках задолго до того, как бухгалтерия зафиксирует убыток.
Оценка эффективности использования денег на лету.
Общий язык с крупными заказчиками (где EVM уже встроен в стандарт работы).
Главные ограничения:
Критически важна дисциплина (достоверность и своевременность) ввода факта, без нее нет смысла пытаться работать по EVM.
SPI, рассчитанный стандартно (в деньгах), к концу проекта всегда стремится к 1.0, даже если проект катастрофически опаздывает. CEO видит «зеленый» индекс, и впадает в ложное успокоение.
Система видит просто освоенные объемы, не видя природы отклонений.
Когда переходить на следующую ступень:
CEO смотрит на SPI = 0.9 и говорит: «Этого не может быть, мы же твердо знаем, что опоздаем на 4 месяца, а у вас отставание всего на 2 недели!».
Появляется запрос на прогноз не только «на сколько проект подорожает», но и «на сколько точно опоздаем», с гарантией, что срок не «схлопнется» математически в конце проекта.
Ступень 6. EVM 2 уровня (Earned Schedule)
EVM 2 уровня может быть совмещена по времени с EVM 1 уровня.
Характерные признаки:
компания осознала главную ахиллесову пяту классического EVM – несостоятельность SPI в финале проекта, для прогноза сроков внедряется метод «Earned Schedule» (ES, освоенное расписание);
выполняется переход от расчета SPI к расчету SPI(t) (от денег обратно к датам);
Рассчитывается прогноз срока завершения по ES.
Что дает эта ступень:
трезвый взгляд на сроки: «время = деньги», и здесь это буквально (мы точно знаем, что если SPI(t) проекта упал до 0.7, то нужен сверхурочный бюджет, потому что чуда не произойдет);
появляется возможность точечно исправлять отставание: PM видит, на каком именно временном отрезке произошла потеря времени, и больше не полагается на «авось»;
существенно повышается точность и интерпретируемость отчетности (отставание считаем по времени, а не по деньгам; в конце проекта отставание синтетически не обнуляется).
Главные ограничения:
высокий порог входа в аналитику: сотрудники категорически отказываются понимать, что такое «Earned Schedule», требуя не усложнять им работу;
прогнозы все еще строятся на агрегированных индексах, которые чувствительны к аномалиям (модель может дать сбой на нестандартных проектах, либо где нет стабильной выработки).
Переходить на следующую ступень нужно, когда начали наблюдать, что прогноз по ES ведет себя по-разному на разных стадиях и уровнях проекта.
Ступень 7. Продвинутая прогнозная модель (прогнозирование по набору моделей с учетом контекста проекта)
Характерные признаки:
компания преодолела веру в «единственно правильную формулу» (догмы больше не работают);
в компании понимают: нет универсального способа предсказать финал, есть набор прогнозных моделей, каждая из моделей адекватна своему контексту;
PM перестал быть просто «сборщиком факта»; он стал аналитиком, который обязан обосновать выбор прогнозной логики прежде всего перед собой, и потом перед стейкхолдерами;
в распоряжении PM библиотека из нескольких прогнозных моделей: он обязан «примерить» каждую и выбрать адекватную ситуации, а не ту, что «красивее выглядит»;
появляется внутренний документ (регламент или памятка) «Правила выбора прогнозной модели», в которой описываются критерии выбора прогнозной модели в зависимости от фазы проекта, уровня детализации или характера отклонений.
Что дает эта ступень:
осознанное управление, а не гадание на кофейной гуще (компания не просто получает прогноз, она понимает, почему он именно такой и при каких условиях он сбудется или развалится);
защита от «единственного числа» (CEO больше не гипнотизирует одна цифра, он видит диапазон и может управлять рисками, а не реагировать на факт срыва);
гибкость: сменился подрядчик – меняем модель, прошли экватор – меняем модель, вышли из кризиса – меняем модель (система подстраивается под жизнь, а не жизнь под систему).
Главные ограничения:
требует высокой квалификации PM.
PM может выбрать не адекватную, а «удобную» модель, которая рисует красивую картинку (это лечится формализацией критериев выбора модели и аудитом выбора модели со стороны руководителя).
Когда переходить на следующую ступень: появляется запрос на интеграцию проектного прогноза с динамической финансовой моделью компании.
Это верхняя ступень моего варианта «лестницы» управления проектами в рамках использования возможностей MS Project. Дальше начинаются вещи, невозможные без букета интеграций со смежными системами, что уже сильно выходит за рамки MS Project.
Теперь приступим к делу.
