Евгений Ленченков
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.

Теперь приступим к делу.

Часть 1. Детектор дыма

Глава 1. План? Модель!

«Рефлекс – признак жизни нервной системы.»

(медицинский принцип)

Почему мы выбрасываем в мусорное ведро наш план проекта? Потому что план становится неактуальным.

Что означает фраза «план стал неактуальным»? Это означает, что картина проекта, отраженная в плане, перестала соответствовать картине проекта в реальном мире.

Эта рассинхронизация происходит из-за того, что:

фактическая информация, введенная в план проекта, не соответствует объему работ, выполненных в реальности;

плановая информация теряет актуальность вследствие выполнения работ «не по плану» (опоздание, опережение, замена и т.д.).

Если корректный ввод фактической информации мы можем обеспечить, взяв в «ежовы рукавицы» сотрудников, которые этим занимаются (обеспечив тотальный контроль над процессом ввода фактической информации в план), то со второй проблемой все сильно сложнее по одной глобальной причине:

Проекты НИКОГДА не выполняются по плану.

Означает ли это, что PM обязан отслеживать взаимное влияние задач проекта, рассчитывать последствия отклонений, которые возникают вследствие выполнения задач не по плану? Да, и это его первостепенная задача, без ее выполнения он не сможет сдать проект в срок.

Означает ли это, что PM все свое время теперь должен посвятить этому анализу и расчетам? Вопрос открытый, но, как правило, на больших проектах работают целые отделы планировщиков, которые день и ночь анализируют факт и его влияние на план (рассчитывают отклонения сроков, бюджета и т.д.).

Может ли PM эффективно решить эту задачу самостоятельно? Может, если при разработке планов проектов он будет использовать три принципа:

сетевого графика;

материального измерения результата;

опорных точек.

Я не открыл Америку с этими принципами. Все, кто занимается планированием и отслеживанием проектов, о них слышали. Однако, одно дело знать термин и понимать, что он обозначает, и совсем другое – видеть, для чего он нужен здесь и сейчас, и почему без него в повседневной рутине никак нельзя обойтись.

Правила построения сетевого графика гласят:

начальная задача должна быть только одна;

конечная задача должна быть только одна;

все задачи, кроме начальной, должны иметь минимум одну предшествующую задачу;

все задачи, кроме завершающей, должны иметь минимум одну последующую задачу;

внутри плана не должно быть замкнутых контуров (групп задач со связями только внутри них самих).

Иными словами, сетевой график – это когда, ведя пальцем по графику от одной начальной задачи по тому или иному пути, последовательно, от задачи к задаче, мы обязательно доберемся к одной конечной задаче.

Рисунок 1. Не сетевой график

На рисунке выше красной линией обозначена задача, которая противоречит правилам сетевого графика: у «Задачи 4», не являющейся начальной или конечной, отсутствует один из обязательных элементов («выход»). Таким образом, график, приведенный выше, не является сетевым.

Рисунок 2. Сетевой график

Если же мы создадим связь у «Задачи 4», например, на «Задачу 5», то в графике все задачи будут удовлетворять правилам сетевого графика.

Что вы будете с этого иметь?

Представьте себе, что «Задача 4» из первого рисунка идет с большим опозданием (при этом вы точно знаете, да и логически это понятно, что «Задача 6» является последней в плане). В этом случае план будет выглядеть так:

Рисунок 3. Одна из задач в несетевом графике идет не по плану

Будьте уверены: если в плане много задач (к примеру, 500+), то эта ситуация будет для PM большой проблемой. А в варианте с соблюдением правил сетевого графика он будет выглядеть так:

Рисунок 4. Одна из задач в сетевом графике идет не по плану

…и мы видим влияние на весь проект абсолютно всех изменений плана, которые возникают в любом месте и в любой момент.

Принцип материального измерения результата

Из теории управления проектами мы знаем, что все метрики проекта можно разделить на «абсолютные» и «относительные». Например:

4 фактически забитые сваи – это абсолютная метрика;

5 свай по плану – это абсолютная метрика;

80% выполненной работы по задаче – это относительная метрика;

4 забитые сваи из 5 – это снова относительная метрика.

Как правило, программные продукты для управления проектами позволяют управлять обеими группами метрик. Но каждый знает, что нет ничего быстрее, чем просто вручную поставить «46%» на задачу.

Однако, легкость и быстрота имеет один очень серьезный недостаток: отсутствие точности оценки. И возникает очень важный вопрос:

На каком основании исполнитель задачи оценивает ее прогресс?

Почему именно 46%? Почему не 45%, 47%, 146%?

Если в ответ на такой вопрос исполнитель отвечает, что он «сделал сорок шесть квадратных метров из ста», то здесь есть объективность. Если же у исполнителя таких объективных данных нет, то мы должны просто поверить на слово, довериться компетенции. И так по каждому исполнителю, который отчитывается по задачам.

А если задач тысяча, а исполнителей пятьдесят? Какова в этом случае будет погрешность оценки результата?

Опытный читатель скажет: «есть задачи, где невозможно объективно измерить промежуточный результат». Например, задачи «разработать чертеж» и «принять стройплощадку» с большим трудом поддаются промежуточной оценке (промежуточная оценка чертежа – это натягивание совы на глобус, промежуточная оценка приемки площадки – это обычный чек-лист).

В этом случае, на помощь приходит бинарность: задача либо сделана (100%), либо нет (0%). Совершенно точно, что бинарная задача, отмеченная как невыполненная, не может навредить проекту в целом: лучше прогресс проекта в плане будет чуть меньше, чем в реальности, чем чуть больше.

Обеспечить выполнение принципа материального измерения результата на практике можно так:

обязательно формировать ресурсный план: прикреплять ресурс к каждой задаче, которая может быть измерена (если разные задачи измеряются в разных единицах измерения – это абсолютно нормально);

фактические данные по задаче принимать только в единицах ресурсов, назначенных на задачу;

минимизировать использование относительных единиц (%) при вводе прогресса по задаче (в идеале процент везде должен быть только вычисляемым);

если задача сложна для измерения, либо состоит из некоего набора простых действий (например, чек-лист, о пунктах которого важно не забыть), то использовать «бинарный» подход.

Соблюдая эти рекомендации, вы не только получите высокую точность оценки прогресса задач, но также программа сама будет рассчитывать этот прогресс.

Принцип опорных точек

Опорные точки – это всем известные «вехи». В терминологии PMI веха – это задача с нулевой длительностью. Вехами обычно отделяют блоки задач, чтобы была наглядна логическая структура проекта. Смысл вех несколько пересекается с суммарными задачами. Однако обычно не рекомендуется в суммарные задачи добавлять связи (хотя технически это возможно), а вехи для того и предназначены, чтобы быть узлами, в которую сначала входят, а затем и выходят одна или целые группы связей. В этом смысле очень логично использовать именно вехи как стартовую и конечную точки проекта:

Рисунок 5. Крайние вехи проекта

Между блоками задач вехи тоже смотрятся органично. Например, для проекта строительства здания можно сделать такие вехи:

фундамент готов;

несущие конструкции готовы;

кровля готова;

мехготовность достинута.

И так далее.

Есть еще одна побочная выгода от использования вех: обзор прогресса проекта «по-крупному» для «крупного» руководства. Как правило, такое руководство интересует портфель проектов, и в отдельные задачи проекта они не заглядывают. И здесь очень поможет «План по вехам» – фильтр, показывающий план проекта «по-крупному»: как раз так, как обычно необходимо в таких ситуациях.

Рисунок 6. Как добраться до встроенного «Плана по вехам»

Выводы

Все, что я описал выше – это не что иное, как смена парадигмы восприятия плана-графика производства работ по проекту: необходимо перестать относиться к плану как к ДОКУМЕНТУ, и начать относиться к нему как к МОДЕЛИ проекта.

Я утверждаю, что, относясь к плану проекта только как к документу (который вы, напечатав на бумаге, вложите в договор или повесите на стену) вы потеряете в:

адекватности оценки реалий;

оперативности реакции на изменения;

общей оценке прогресса и рисков проекта.

Относясь же к плану проекта как к модели (соблюдая три принципа, применяя адекватную детализацию задач, вводя факт оперативно и точно), вы приобретете:

мгновенную и адекватную реакцию плана на любые изменения;

возможность выполнить адекватный план-фактный анализ;

возможность автоматически сформировать ПРОГНОЗ по тем разрезам, которые вы заложите в план (например, сроки или бюджет).

И ваша модель проекта будет адекватна и актуальна. И вам не надо будет вручную «перепланировать» проект.

Сдвиг восприятия плана-графика от документа к модели – это необходимое условие для возникновения возможности:

тушения пожара на проекте здесь и сейчас (вы будете видеть, где и что горит);

автоматизации контроля и прогнозирования в MS Project (да и в любом другом софте класса EPM).

Каждая неправильная связь в графике – это потенциальная дыра в марже. Если задача не тянет за собой следующую, вы не увидите, как опоздание на одном участке убивает прибыль на всем проекте. Модель – это не про красоту. Это про то, чтобы маржа не умерла незаметно.

Глава 2. Планирование и перепланирование

«Корабли лавировали, лавировали, да не вылавировали.»

(скороговорка)

Предыдущая глава была о создании модели проекта: плана, который отражает полную технологическую последовательность работ, а также включает ресурсы разных типов, назначенные на максимум задач.

Но в ней не было сказано ни слова об экономии времени и энергии. Однако, цель наша – не только сделать модель корректной, но и сэкономить время, нервы и энергию PM для других задач.

За счет чего?

А все очень просто: при соблюдении трех принципов, описанных в предыдущей главе, PM больше не нужно перепланировать задачи. MS Project все сроки смещает сам. Автоматически.

Понятно, что в каких-то ситуациях все же придется заниматься корректировкой сроков окончания задач (да и начала тоже). Но объем этих действий будет несопоставимо меньше, чем ранее.

Давайте разбираться как это работает.

Итак, у нас есть ресурс, который мы назначаем на задачу: один или несколько. Ресурс характеризуется неким количеством в некоторых единицах измерения (50 штук свай, 100 квадратных метров окрашиваемой стены, 5 кубов бетонного основания, 80 часов трудозатрат сотрудника и так далее). В момент назначения ресурса MS Project автоматически и равномерно распределяет количество единиц по длительности задачи.

Далее необходимо направить логику MS Project в нужное нам русло: определить тип задачи. Тип задачи – это правила, по которым MS Project обрабатывает задачу при вводе фактических данных.

Всего типов задачи три:

фиксированная длительность;

фиксированный объем ресурсов;

фиксированные трудозатраты.

Рисунок 7. Типы задач в MS Project

Тип «Фиксированная длительность» оставляет неизменной дату окончания задачи при вводе любых фактических данных. Мы можем вместо 10 единиц ресурсов в день вводить по 5, и все остатки будут равномерно распределяться на последующие дни задачи. Данный вариант имеет право на существование, но все же он достаточно экзотичен для повседневных реалий.

Рисунок 8. Плановые данные в представлении "Использование задач"

Рисунок 9. Поведение задачи типа "Фиксированная длительность" при вводе факта

Тип «Фиксированный объем ресурсов» работает так:

Если мы вводим факт за день, который равен плану, то сроки по задаче остаются неизменными.

Рисунок 10. Посуточный факт равен плану, дата окончания остается неизменной

Если мы вводим факт за день, который меньше плана, то остаток (план минус факт) переносится на день, следующий за датой окончания задачи, а дата окончания задачи смещается вправо