Методы определения себестоимости и способы отслеживания прогресса проекта. Курс по управлению проектами, часть 20

Продолжение моего учебного курса по управлению проектами.

Предыдущая часть курса: Методы сжатия расписания и вехи в проекте

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

 

Методы определения себестоимости

 
Какие есть способы оценки себестоимости? 

• По аналогам
• Экспертная оценка
• Параметрический расчет
• Метод оценки по трем точкам
• Техники группового принятия решений
• Анализ резервов

 В целом, для оценки себестоимости годятся те же методы, что и для оценки продолжительности (мы уже рассматривали их раньше, в публикации Управление сроками – определение продолжительности). Но есть и некоторые свои способы, которые применяют только для расчета себестоимости.

Анализ цен поставщиков 

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

 
«Цена качества» 

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

Оценка «сверху вниз» и «снизу вверх»

Вспомните иерархическую структуру работ. У нас был велосипед, он состоял из рамы, колеса, педалей, руля, седла и так далее. Колесо состояло из обода, камеры, спиц и прочего. Для оценки себестоимости оценки проекта «Сделать велосипед» есть два способа – оценка «сверху вниз» и «снизу вверх». Начнем с оценки «снизу вверх». Спускаемся на нижний уровень и оцениваем все детали. Например, рама и седло стоят по 100 долларов, обод и рама – по 10 долларов, спицы – 5 долларов, колесо – 25 долларов, педали и руль – по 50 долларов. Получается, что весь велосипед будет стоить 350 долларов. Это способ «снизу вверх». 

Какой этот метод – хороший или плохой? Конечно, хороший. Но есть и минусы. Для этого способа нужна подробная иерархическая структура. Кроме того, он дорогой, потому что очень медленный. Если у вас нормальный серьезный проект, и там большая иерархическая структура, то вы медленно-медленно ползете снизу вверх. Но иногда это неизбежно, например, в строительстве, где надо учитывать стоимость каждого гвоздя.
 
Давайте разберемся, что за метод «сверху вниз». Допустим, к вам пришло начальство и говорит, вот тебе 300 долларов, нужно сделать велосипед. Вы распределяете эти деньги и думаете, можно ли вообще уложиться в эту сумму, сколько должно быть потрачено на каждый узел. Вы спрашиваете себя, можно ли сэкономить на раме. Нельзя, иначе она быстро сломается, а это несущая конструкция, и должна быть надежной. Потом думаете, можно ли сэкономить на колесе. Допустим, можно. Оно тоже может сломаться, лопнуть, но это будет не сразу. На педалях – нельзя, на руле – можно. Так вы раскидываете деньги на уровне иерархической системы и пытаетесь методом перебора сэкономить на каких-то узлах, чтобы вложиться в ту сумму, которую дал спонсор. Это метод «сверху вниз». Он довольно быстрый, не начинается с мелочей, позволяет укрупненно прикинуть адекватность проекта.
 
Но у него есть и второе применение. Объясню на примере. Когда у вас подробная сетевая диаграмма и иерархическая структура, вы «снизу вверх» ползете, детально оценили каждую работу, сложили одну стоимость с другой, поднимаетесь все выше. Но когда вы по нижнему уровню оцениваете себестоимость, у вас может «глаз замылиться», и вы можете не заметить какие-то очевидные ошибки. И когда вы все закончили, получили какую-то цифру, неплохо бы себя перепроверить. Например, в одной из компаний, где я работал, было одно эмпирическое правило для IT-проектов. Не для всех оно, конечно, подходит, но для тяжелых бизнес-приложений, которые мы писали, оно работало. Правило было такое: разработка и тестирование софта соотносится друг к другу как 1 к 3. То есть разработка в три раза больше и дороже, чем тестирование. И наоборот: тестирование – одна треть разработки. И если хороший второй уровень, где много узлов, вы все подсчитали, то потом можете себя проверить, сколько суммарно должно уйти на проект. На разработку, например, по вашим подсчетам, должно уйти 200 долларов, а на тестирование – 100. Но есть эмпирическое правило про 1:3, значит, вы что-то неправильно посчитали, где-то ошибка. Для проверки оценка «сверху вниз» тоже годится. Когда у вас есть готовая сумма, вы можете спуститься вниз и эмпирически, используя свой опыт и свои какие-то наблюдения, определить, где неточность.
 
Еще раз. Первое и главное – методом перебора определить стоимость узлов. Второе – если у вас есть какие-то эмпирические правила, вы можете проверить себя «сверху вниз».
 
Коллеги, подчеркиваю, здесь, как и с продолжительностью, полезно сохранять исходный расчет себестоимости. Если вы долго считали стоимость какой-то работы, потом эти расчеты потеряли, то обязательно появится вопрос, «а почему столько?». Чтобы не пересчитывать, не вспоминать, лучше сохранить исходные расчеты.
 
Еще хочу напомнить, что планы – это не клятва, это прогноз.  По поводу точностей планов, понятно, что на этапе инициации, когда вы в основном оцениваете по аналогу и экспертно, и у вас нет подробного плана, точность планирования в среднем – плюс/минус 50%. Это средний показатель по всем отраслям по проектному управлению, и в строительстве, и в IT. И это совершенно нормальная точность, хорошая. 

Но что значит «плюс/минус 50%»?. Когда вы устав пишете, вы можете оценить сроки и бюджет с точностью плюс/минус 50%. К примеру, если у вас бюджет на 1 млн. долларов, вы закладываете, что он будет не дороже, чем 1,5 млн. долларов. Если у вас проект на год, вы должны уложиться не позже, чем за 1,5 года. Это на этапе инициации. Эти оценки называют приблизительными, грубыми.
 
Когда закончилась инициация, вы пошли планировать. В какой-то  момент у вас все планы готовы, и можно начинать работать. В этой точке, когда планы готовы, и можно начинать выполнять проект, в ней у вас точность планов уже другая – плюс 25% минус 10%. Это тоже далеко не идеал, но точность уже выше, чем на этапе инициации. В данном случае оценки почему-то называют бюджетными.
 
Когда у вас проект в ходу, планы переписываются, уточняются, проект становится все понятнее и понятнее. Помните, у нас гибкие планы. Тем не менее, на этом этапе точность планирования все равно не идеальная – плюс/минус 10%. И эти оценки в проектном управлении называются окончательными. Точнее они не будут, пока вы проект не закроете. А 100% точности никогда не бывает.

 

Способы отслеживания прогресса проекта
 

 

 

 

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

Первый способ — это «спросить исполнителя в лоб» 

Сюда стоит относить все, что касается прямых способов получения информации.  И отчеты, и «глазами посмотреть», и любые планерки. Ведь именно на планерке можно и нужно обо всем расспрашивать, сотрудники должны вам рассказать.  А после того, как вы услышали, что рассказал сотрудник, можно еще и самому посмотреть на результаты. Вместо проведения планерки, вы можете запросить отчеты. Чтобы ни о чем не спрашивать специально, можно заранее договориться с исполнителями, чтобы они присылали их по почте или еще как-то доставляли. Некоторые команды пытаются сделать все сразу в Project – они отмечают статусы, кто сколько сделал за день. Я не агитирую ни за что, я просто рассказываю. Я считаю, что Project, действительно, удобен для менеджера. Но совсем не факт, что он удобен для команды проекта. У команды другая задача – им надо не в менеджерские игры играть, а работать: программировать, паять, копать, проектировать. И у них должен быть инструмент, который мозг не выносит. Единственный человек, которому можно выносить мозг с управлением, – это менеджер. Он пусть помучается, главное – чтобы команде было удобно. И пусть команда использует все, что угодно, например, доски со стикерами или пробковые доски, лишь бы им было нормально, а у вас (у менеджера) был понятный способ разобраться, что сделано. Сам по себе способ «спросить в лоб» – самый хороший, чтобы понять, как идут дела. И если вы можете спросить это у человека, пойдите и спросите, не надо ничего придумывать.
 
Есть еще два способа – rules (правила) и earned value.

 
Второй способ — rules 

Он обычно вызывает возмущение, потому что он выглядит по-дурацки. Он действительно немного дурацкий. Но он не от хорошей жизни придуман, он придуман на случай, если вы не можете спросить и не можете самостоятельно посмотреть. Это возможно в ситуации, когда исполнитель находится далеко, и связи с ним нет. К примеру, у нас был проект, который охватывал Дальний Восток, Питер и США. У двух из трех команд физически были разные сутки. И был только 1 час, когда мы могли созвониться и что-то обсудить. Поэтому «спросить исполнителя в лоб» было крайне сложно. Кроме того, метод rules может пригодиться в госсекторе. Такое у меня было, когда мне привели подрядчика и сказали, что он очень хороший, и надо работать только с ним. Раскидали мы с этим подрядчиком план работ, он пошел работать, а когда я его через какое-то время спросил, как дела, что успел, он со мной не захотел разговаривать. Сказал, что по контракту у нас через 2 месяца этап заканчивается, поэтому отчитается через 2 месяца. А до этого не надо ему звонить. И все. Я иду к заказчику, а мне говорят, что это очень хороший подрядчик, не надо его трогать. Печальная такая ситуация — фактически, руководитель проекта теряет контроль над ходом проекта. В подобных мрачных ситуациях, когда вы не можете спросить либо можете, но не доверяете оценкам или еще что-то, используют rules — то есть правила, по которым рассчитывается объем сделанной работы. 
 
Rules бывают:
 

• 20/80
• 30/70
• 50/50

 
Видите тенденцию? В сумме с двух сторон дроби получается всегда 100. Как это понять?
 
Допустим, мы используем правило 30/70. Есть какая-то работа, которую надо сделать. И она относится именно к тем, про которые мы не можем спросить, и мы не можем сами ее посмотреть (как в примере, описанном выше). Там «черный ящик». Или мы не доверяем оценкам поставщика, исполнителя. Пришел исполнитель, ему объяснили, какую работу надо сделать. Он сказал, что все понял, пошел работать. Как только он сказал, что пошел работать, даже если он еще в дверь не вышел, мы сразу пишем, что у нас работа на 30% закончена. Потому что подтвердил, что понял, что ему надо делать. Оставшиеся 70% мы добавим, когда он все закончит. То есть он взялся за работу, и мы сразу считаем, что 30% работы сделано. Дальше он работает, рассказывает что-то или не рассказывает, не важно, но следующие 70% мы добавим, когда он все закончит и покажет результат.
 
Это rules. Такой способ вызывает раздражение, потому что многие не понимают, зачем он нужен. Повторю: он нужен в тех ситуациях, когда вы спросить не можете. И у вас выбор – либо костыль какой-то соорудить, либо использовать правило под названием 0/100 (ноль на сто). Это правило, когда исполнитель ушел работать, и до тех пор, пока он не закончит работу, вы считаете, что работа не сделана. Проблема в том, что правило 0/100 всегда показывает неправду. Почти наверняка работа будет сделана не на 0%, даже если у вас крайне некомпетентный исполнитель, он что-то все равно сделает. Самое страшное, что он потратит ваши ресурсы – деньги и время. Он все это израсходует потихонечку. И это будет уже не 0%. И чтобы не закладываться на 0%, вы эмпирически (методом комсомольского прищура) смотрите на каждого исполнителя. Этому вы больше доверяете, используете правило 50/50. Этому меньше, поэтому используете правило 30/70. Это совсем примитивный костыль, но он пытается вас приблизить к реальности. Правило 0/100 — это  точно неправда. А правда неизвестно где. Но вы пытаетесь подобраться к ней.
 
Если у вас параллельно несколько работ с такими «черными ящиками», то использование rules будет вас двигать немножко ближе к правде, чем использование правила 0/100. Но, еще раз: если у вас есть возможность спросить исполнителя в лоб, спросите его. Не надо пользоваться больше ничем. Способ rules работает только со странными исполнителями, с которыми вы никак не можете договориться.
 
Действительно интересный способ оценки – метод освоенного объема. О нем пойдет речь в следующей части. 

Статья написана на основании видео учебного курса по управлению проектами:

• Видео про методы определения себестоимости
• Видео про способы отслеживания прогресса проекта

Предыдущая часть курса: Методы сжатия расписания и вехи в проекте

Следующая часть курса: Контроль прогресса – метод освоенного объема (earned value management – EVA)

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