Многие ответят - конечно! Другие, возможно, скажут: "Ты что, чувак! Что вообще за вопрос? И кто ты такой?"
Классический подход РМbok подразумевает наличие объекта, субъекта и методов - такой набор, по мнению PMbok, делает любой проект управляемым.
Но я думаю, слово "управлять" мало применимо к проектной работе. Да и сама работа называется проектной только потому, что ее результатом должен стать набор уникальных характеристик конечного продукта - процессный подход здесь как бы не подходит, т.к. заточен под унификацию продукта.
Я размышляю об этом потому, что последние 12 лет работаю руководителем проектов в промышленном строительстве и пытаюсь понять, правильно ли делаю свою работу. Вам может показаться, что стройка – это что-то далекое и вообще про мужчин в спецовках и касках, но на самом деле наши подходы становятся все более сходными с Ай-Ти. Прежде всего потому, что строительство стремительно цифровизуется.
Сам термин "управление проектами" с нами недавно. В английском варианте это "project management". Обратите внимание - то, что по-русски звучит как тождественное управлению, скажем, автомобилем, в первоисточнике таковым по смыслу не является.
А что общего между управлением проектом и управлением автомобилем? Мы садимся за руль, чтобы переместиться из точки А в точку В за примерно понятное нам время. Если мы движемся в пределах знакомой локации, то до выезда планируем маршрут и даже можем предположить, сколько будет на часах, когда проедем тот или иной перекресток. Начиная проект, мы тоже должны двигаться согласно утвержденному расписанию. И в точке выхода из проекта (точка В) окружающее пространство также будет отличаться от точки входа (точка А) - хотя бы потому, что завершение проекта будет означать появление нового объекта (объектов) на видимом ландшафте.
На этом сходства заканчиваются. В случае с автомобилем, чтобы повернуть, мы крутим руль, а педали помогают набрать скорость или притормозить, если почувствуем, что едем слишком быстро. А за что хвататься, чтобы изменить траекторию проекта? Можем ли мы, крутнув руль, “объехать" риск, скажем, перерасхода бюджета по одному из пакетов работ? Ответ – нет, потому что в руках руководителя проекта такого руля нет.
Но возможно ли такое? Не грешим ли мы против истины? Руководитель проекта наделён полномочиями и ответственностью, согласно классическому подходу, он анализирует, планирует и прогнозирует на "проектном" уровне. Здесь важна оговорка про этот самый проектный уровень - не погружаясь в детализацию задач. Руководителю интересны контрольные точки этапов проекта, а не операции длительностью в несколько часов. И инструментарий для принятия решений у него достаточный. Но он не может “рулить”, т.е. реагировать на события со скоростью движения, потому что не обладает качественной информацией. В его представлении проект – это партия в шахматы или на бильярде. С соответствующей скоростью реакций.
Как известно, информация считается качественной, если она своевременна и достоверна. Когда на светофоре загорается красный свет, мы тормозим перед перекрестком, избегая таким образом возможного столкновения с другими участниками движения или штрафа за проезд на запрещающий сигнал светофора. Здесь все просто - увидел сигнал, нажал педаль, остановился.
Строительное производство устроено так, что на операционном уровне за реализацию отвечает начальник участка. Именно этот человек видит стройку своими глазами каждый день. Именно он первым получает обратную связь от заказчика "в поле", он знает, что сварщик Петров халтурил полсмены, потому что поругался с женой (поверьте - да, знает), знает, что смежники не закончат в срок, т.к. им задерживают зарплату и рабочий люд готовит бунт. Он принимает материалы, раздает задачи линейному персоналу, проверяет качество работ. Разумеется, не лично - в его распоряжении соответствующие службы.
Наш участок изобилует всевозможными сигналами - одни появляются, другие исчезают. И входы те же - зрение, обоняние, осязание. Возможно, интуиция. Проблема в том, что руководитель проекта не принимает ни одного из этих сигналов лично - он имеет дело с отчётностью начальника участка или интерпретациями других участников событий. И на основании таких данных принимает решения. Возвращаясь к нашему сравнению с автомобилем, он даже не пассажир такси - он только оплачивает поездку и ежедневно просматривает записи с видеорегистратора, сидя в удобном офисном кресле.
Не секрет, что такое распределение ролей руководители проектов порой оборачивают себе на пользу - трюк в том, чтобы снять с себя ответственность. Мол, на площадке есть ответственное лицо, с него и спрос в случае чего. Хотя в "случае чего" могут пострадать или даже погибнуть люди, и лучше предотвратить, чем разбираться с последствиями. Факт остается фактом, наш руководитель проекта не может предотвращать, он может только разгребать последствия. А это означает, что большинство проектов на деле неуправляемы.
Однажды мне пришлось спасать дорогостоящее оборудование заказчика, которое могло утонуть. Так случилось, что в регионе, где мы вели работы, больше недели шли проливные дожди и власти даже объявили режим чрезвычайной ситуации. Оборудование к тому моменту уже установили на фундаменты, неподалеку от которых был вырыт котлован глубиной 6 - 7 метров. Котлован быстро наполнялся дождевой водой (по нашим подсчетам пришло 2,5 - 3 тыс. тонн), грунт был липким суглинком и довольно быстро сползал со стенок, постепенно обнажая заглубленные части фундаментов. Кульминация происходила, как назло, в субботу, когда после шестидневной рабочей недели всем особенно хотелось домой. Возможно, именно поэтому ни один из собравшихся в штабе строительства 12 промокших мужчин, не ответил утвердительно, когда я спросил, стоит ли демонтировать оборудование. Присутствовали начальник участка, производители работ, инженеры производственно-технического отдела, представители субподрядчиков – каждый из них видел ситуацию воочию и оценивал риски. В тот день на площадке был кран большой грузоподъемности, и на свой страх и риск я решил демонтировать оборудование. На следующее утро мы обнаружили, что наши фундаменты сползли в воду. Это случилось даже без нагрузки - несложно представить, как развивались бы события, не сними мы оборудование. Персонал знал о проблеме, но сам не смог принять правильного решения – это я и называю отсутствием управляемости проекта.
Давайте попробуем разобраться, почему так происходит - "поднимемся выше по течению". Прежде всего, что мы называем проектом? Наш проект выглядит как куча бумаг - чертежей, графиков, спецификаций и приложений к ним. Как этим можно управлять? Дописать в бумаги ничего нельзя, исправить чертеж невозможно без уймы согласований. Договоры порой вообще не понять без юриста. Похоже, единственное, что мы можем - двигать эту кучу с места на место. Лежащий перед нами "проект" - это сущность, которая уже "состоялась". Она создана усилиями значительного кол-ва людей, каждый из которых профессионал в своей области. Проектная документация прошла экспертизу в государственных органах, бюджет согласован заказчиком, график подписан заинтересованными сторонами. Я хочу сказать, что эти документы статичны. Они больше не изменятся никогда - именно в этом состояла цель их создания. Поэтому - да, только двигать с места на место. Никаким "проектом" мы не управляем, потому что невозможно управлять прошлым, оно уже случилось. А в контексте моей деятельности "проект" (как замысел на бумаге) - это именно прошлое.
Когда нам доверяют имплементацию, это означает, что в будущем мы должны воспроизвести замысел заказчика в оговоренный срок, потратив на это деньги в пределах согласованного бюджета. Но управлять будущим тоже невозможно - отсутствует субъект управления. Иными словами, проблема в том, что в будущем нет нас с вами.
Итак, в нашем распоряжении только настоящее. И, как мы уже поняли, чтобы не попасть в дорожные неприятности, нам нужна качественная информация. Я не имею в виду систему сбора "факта" с актуальностью день-в-день - если мы работаем с крупными проектами, такая система у нас должна быть по умолчанию. Собственные глаза и уши - вот лучшие проводники информации, безоговорочно доверяйте только им. Хотите управлять настоящим - будьте в центре событий, иначе придется иметь дело с чужими впечатлениями.
Проект является действительно управляемым только на операционном уровне, все остальные горизонты – это, по сути, сбор и анализ статистики. Но операционную деятельность контролирует начальник участка, который не может управлять проектом, т.к. руль находится в другой комнате. При этом стейкхолдеры видят главную движущую силу именно в руководителе проекта, он по умолчанию считается самым вовлеченным в проект сотрудником. Хотя он просто не может быть вовлечен, не присутствуя на площадке положенные 50-60 рабочих часов в неделю.
Большое кол-во проектов имеют похожие проблемы, но все же заканчиваются в той или иной степени успешно. Важно понимать, что часто успехом считается само завершение проекта. Но в момент, когда все счета оплачены, инициатор понимает, что недосчитался части плановой прибыли. И каждый раз, оказываясь частью таких проектов, я прокручивал в голове события и приходил к выводу, что результат был бы лучше, если бы в каждой отдельной ситуации я реагировал быстрее.
На самом деле я просто должен был “знать раньше”.
Где же рецепт успеха? Как гласит известный интернет-мем, “Нужно всего лишь…” выпихнуть руководителя проектов на площадку. Релоцировать его на время реализации проекта, разрешив кратковременные визиты в офис для решения совсем уж дистанционно нерешаемых дел.
Таким образом будут убиты сразу несколько важных зайцев – заказчик получит прямо под боком “службу одного окна”, куда может обратиться с любым вопросом по проекту; возрастет скорость принятия решений; руководитель проекта почувствует ритм площадки; площадка почувствует возможности руководитель проекта – если он действительно силен, это вызовет мультипликативный эффект для всех активностей (просто поверьте, опыт); ну и это… "пришел, увидел, победил".
Ключ к успеху – присутствие. Возьмите в руки руль, ответственность невероятно тонизирует. Пересадите начальника участка в пассажирское кресло, пусть станет вашим штурманом. Он проложит маршрут, но вести вам. Пробуйте и получайте удовольствие от езды. Если, конечно, вы хороший водитель.
P.S. Спасибо моему другу Федору за то, что рецензировал.
Комментарии (22)
overpanda1
00.00.0000 00:00+2Хорошая статья, но финал скомкан оказался. По Вашему мнению секрет - в микроменеджменте, то есть то, от чего руководителю необходимо отказываться в первую очередь. Может быть в стройке такой подход и оказался полезен (все таки результат работы на виду и сразу все видно), но есть куча отраслей, где этот подход не работает (не только IT).
Вы в статье привели всего один пример, где Ваше непосредственное присутствие спасло оборудование на проекте, но я не вижу тут системного подхода. Вы по сути как в казино, подкинули монетку поставив все на красное (что оборудование затонет), и угадали, хотя все Ваши подчиненные в один голос сказали, что все в порядке. То есть вопрос в недостаточной квалификации/вовлеченности сотрудников либо непрописанности алгоритмов в критических ситуациях. И судя по всему Вы все оставили все как есть, то есть в следующей критической ситуации опять будете гадать, не получив помощи от подчиненных.
Ключ к успешной работе: 1) подбор квалифицированного и проактивного персонала; 2) определение критических моментов, по которым вы будете контролировать их работу; 3) наделение сотрудников всеми необходимыми полномочиями.
Статья хорошая, но пока Вы находитесь на неверном пути)
Enrico_Pallazzo Автор
00.00.0000 00:00+1Спасибо за конструктивную критику????
Классно, что вы начали полемику - буду рад обменяться мнениями.
Буду признателен, если Вы приведете примеры отраслей, где не сработает описанный подход.
Секрет вовсе не в том, чтобы "передвигать ноги" своему персоналу, а именно в присутствии. Ваше присутствие в центре событий - само по себе мощный рычаг (ключевой, ИМХО). Причем работает рычаг в обе стороны - если рукпроекта откровенно слаб, площадка проявляет слабые места и проект быстрее получает замену.
Мои коллеги не сняли оборудование, потому что никто не захотел принять ответственность. Ведь это допзатраты, дополнительные риски хранения и вообще много того, что не просчитать с ходу. А если снимем, а потом назад "не поставится"?) И такие мысли приходили, уверен, в их светлые головы)
История всё-таки не про казино, т.к. любая ненулевая вероятность риска означает, что необходимо риск устранить.
Не сочтите меня занудой, мне правда оч интересна тема и хочется живого обмена опытом)
Вот Вы говорите "квалифицированных и проактивных". Но вот Вы на проекте, где бюджет не позволяет нанимать сплошь таких, или географически проект не важнец - не поедут даже за большие деньги. Или сезон высокий и спецов не найти, а пока будешь хайрить, отстанешь от расписания. Или ресурсы компании рассредоточены на 10 других важных объектах... А надо сейчас. И чего? Ну, т.е. "ключ" не так, чтобы прям универсальный.
Критические моменты - это что? Момент времени, контрольная точка в расписании, перерасход бюджета? Критические для кого? То, что критично для заказчика, может быть некритичным для меня, как руководителя проекта - бывает, работает принцип "дураку полработы не показывают". Конкретику, пожалуйста)
Полномочиями наделить можно, ответственностью нельзя. Ответственность можно только принять. А если человек ее не принимает, он своими "полномочиями" натворит дел...
Я вообще про то, что мир не статичен и изменения возможны даже в классических подходах. Или нет?)
overpanda1
00.00.0000 00:00+1я указал те моменты, к которым необходимо стремиться в идеале :)
Например, закончили Вы текущий проект, понимаете, что бригадир монтажников отличный специалист, переговорили с ним, что через пару месяцев у вас будет новый проект и было бы отлично снова с ним поработать. С начальством одновременно выбиваете для него допоплату или другие "плюшки".
Если каждый проект начинать с новыми людьми, которых первый раз видишь, то понятно, что будете наступать на одни и те же грабли.
Критические моменты - это то, от чего зависит Ваша оплата и Ваш крепкий сон) У всех людей это по-разному. Например, в IT-компании всем все равно если люди опаздывают на час и больше, а на заводе каждая минуту опоздания это катастрофа. У Вас должен быть свой список таких моментов. У меня, например, бзик на документации, потому что я понимаю, если нет документации, то в случае каких-то новых доработок новому сотруднику придется потратить огромное кол-во времени, чтобы вникнуть в суть. Соответственно, подрядчикам не подписываются акты, пока они не приведут все в порядок/
Извините, если сумбурно написал, но основная мысль, что за всеми лично не уследишь и не проконтролируешь. Ну или работать по 80 часов в неделю и оборудование топить через раз)
Enrico_Pallazzo Автор
00.00.0000 00:00Вы правы, хорошая команда, система принятия решений и делегирование необходимы любому проекту.
Но! Вот представьте: случилось чудо (прилетело НЛО?????????) и кто-то открыл Вам бюджет на строительство Вашей новой дачи. Да ещё платит Вам зарплату за строительство из этого бюджета. У вас отличные прорабы, есть техника, рабочий персонал - лапочки, не пьют и не ругаются матом, остаются на 12-часовую продленку через день. В конце каждой смены получаете полный отчёт о работе с цифрами и фактами. И специальная софтина мониторит показатели в earned value management. Одним словом, проект поехал)
Ну Вы-то поедете на площадку? Или нет?)
Вы можете остаться дома получать отчёты, оплачивать счета и подписывать договоры только в одном случае. Если скажете, что "там же профи, я-то чего там, тут вон дел гора... совещания будем с площадкой проводить по Скайпу дважды в день. Команду я собрал, софт купил, со стейкхолдерами мосты наладил". И покажете кулак - мол, вот он у меня где, проект, в кулаке, так крепко держу.
Но если профи ТАМ, то кто Вы? И какого черта Вам вообще доверили бюджет?)
Не сочтите ни в коем случае за резкость) пытаюсь развить тему на понятных примерах.
overpanda1
00.00.0000 00:00+1Так Вы сами подходите к правильному ответу на свой вопрос:) В идеале руководитель НИЧЕГО не делает! Но без него ничего не работает, потому что только у него есть ключики к каждому сотруднику/процессу. У меня лично есть опыт руководства небольшим отделом, на управление которым я тратил 1,5 дня в неделю, все остальное время занимаясь личными делами.
Enrico_Pallazzo Автор
00.00.0000 00:00Время для себя - это супер????
Но всё-таки не поедете...) меня, на самом деле, интересует, почему не едут. Почему не хотят deep dive?????????♂️
Просто знаю таких, кто едет - скорость прогресса удивляет в сравнении с "сидячими"
И похоже, вы обобщаете подходы. Если наш проект - строительство опасного производственного объекта, ни о каком 1,5-дневном управлении в неделю речи быть не может - вы просто выпустите вожжи из рук. Рукпроекта - служба единого окна для Заказчика, а запросов у него, как у 2-летнего ребенка)
Дальше было бы про разницу процессных/проектных подходов, бла-бла-бла... Не будем, в общем)
Вот какая штука: предположим, проезжую я мимо пивзавода где-нибудь в N-ской губернии. Или химкомбината. Или НПЗ. И думаю: "о, здесь мы с ребятами руки приложили". И теперь знаю, как их пиво/соль/бензин производится. И детям потом расскажу, а дети своим друзьям. Очень мотивирует, знаете ли)
overpanda1
00.00.0000 00:00Вы меня немного не поняли: я критикую не пункт "лично ездить на объект", это наоборот похвально. А пункт "Рукпроекта - служба единого окна для Заказчика, а запросов у него, как у 2-летнего ребенка". Вы занимаетесь микроменеджментом, замыкая на себе все вопросы. Неудивительно, что Ваши подчинённые не имеют своего мнения, уже привыкли, что вы сами все решаете за них
Enrico_Pallazzo Автор
00.00.0000 00:00Микроменеджмент - это менеджить расстановку рабочего персонала и техники, выдачу материалов и инструмента, контроль качества. Это не мои вопросы. Я настраиваю процессы и контролирую результат, не участвуя руками. Только делаю это на месте и на глазах у всех участников. Я не лицо на мониторе и не голос в телефонной трубке. Для них я часть команды.
Рукпроекта - камертон для участка, эту функцию невозможно делигировать. Его личный вклад - во многом и есть то, что делает разницу.
Мне доводилось собирать проектные команды и ребята, которые сейчас работают без меня самостоятельны и классно делают свою работу. Персонал копирует поведенческие паттерны и задача рукпроекта - такие паттерны создавать.
Насчёт "службы одного окна" - предлагаю Вашему вниманию небольшую статью.
KvaK
00.00.0000 00:00+1То есть вопрос в недостаточной квалификации/вовлеченности сотрудников либо непрописанности алгоритмов в критических ситуациях
Думаю вопрос в том, что это не их уровень ответственности и полномочий.
1Tiger1
00.00.0000 00:00+1а можно вопрос как к руководителю строительных проектов? что нужно делать когда на площадке много воды? вот совсем много. и в грунте и выше. вообще все затоплено. сплошная вода. и за ней не увидеть ничего, даже смысла статьи. вот что делать в такой ситуации?
Enrico_Pallazzo Автор
00.00.0000 00:00Что ж, проведем водопонижение)
Идея статьи: управлять строительным проектом получается гораздо эффективнее, если сам присутствуешь на месте событий. Многие строительные компании держат рукпроекта в офисе, что неверно, а порой вредит.
Разумеется, высокой обводненности стоит избегать, спасибо за критику????
1Tiger1
00.00.0000 00:00+1"для меня является открытием что что существуют люди для которых это является открытием" - не помню кто.
хотя наверное все же стоит учитывать что вы говорили не про IT. в реальном секторе подходы к менеджменту часто другие. возможно там иногда действительно не понимают важность качественной коммуникации. хотя кого я обманываю, в IT такая фигня тоже происходит, просто это скорее исключение.
KvaK
00.00.0000 00:00+1не согласен с выводом. "не все так однозначно....". Переместив Руководителя проекта на площадку вы превращаете его в начальника участка, он перестает решать глобальные вопросы планирования и управления рисками, бюджетом и качеством, и начинает заниматься тем, что провтыкали мастера, прорабы и начальники участков - попутно успокаивая Заказчика. В итоге Руководитель проекта будет заниматься выдачей спецодежды вместо того чтобы найти и решить заранее проблему с водоотведением еще на стадии разработки Проекта производства работ или даже Плана реализации проекта (как было в приведенном Вами примере).
Фокус - в балансе затрат времени Руководителя проекта на поле и офис, между тактикой и стратегией, между обязанностями начальника участка и стейкхолдера (спонсора проекта - да они тоже не всегда в полном мере выполняют свою роль, и их надо подстраховывать).
а второй фокус - в делегировании. У Руководителя крупного строительного проекта должен быть и Менеджер по строительству в подчинении, и Инженер проекта.
Enrico_Pallazzo Автор
00.00.0000 00:00Спасибо, что участвуете в дискуссии ????????
А с чего бы нашему рукпроекта переставать решать "глобальные вопросы"? При нем высоко(!)производительный ноутбук, принтер (плоттер), безлимитная связь, письменные принадлежности и кофемашина. Разве глобальный вопрос не состоит из множества локальных? Рукпроекта для их решения нужна информация в состоянии, так сказать, pure. И чем больше она pure, тем выше скорость решения. И добудет он ее только сам и только на площадке.
Ну, раздал он "пряников" всем провтыкавшим. Ну, понял Заказчик, что перед ним наконец тот единственный-во-всем-виноватый, с кого драть 3 шкуры. Это вопросы первой недели присутствия рукпроекта на площадке. И дальше мастера/прорабы/начучастка занимаются своим делом. Только знают, что в штабе сидит чувак, который за все это дело отвечает и если что, спросит результат здесь и сейчас, а не там и потом. Ещё лучше, если приказ о безопасном выполнении работ оформлен на рукпроекта - вот это вообще "за нами Москва, отступать некуда")
Так что нет, не убедили)
Про делегирование - да будь хоть менеджер по менеджерам и инженер по инженерам, если позволяет бюджет) Обязанность руководителя быть к ним максимально ближе.
Буду оч признателен, если уточните, какие вопросы планирования и управления рисками, бюджетом и качеством Вы считаете глобальными? Это не вопрос-провокация) Возможно, и очень надеюсь, Вы знаете то, что неизвестно мне.
KvaK
00.00.0000 00:00на глобальный вопросы у него не останется времени, так как к нему к вагончик будет непрерывный поток подчиненных, которым надо помочь (руководитель проекта с его авторитетом всяко быстрее решит проблему прораба с выписыванием перчаток со склада, у него же погоны), помирить между собой.
На собственном опыте говорю: нельзя постоянно находится на стройплощадке. Рутина поглощает, думать некогда. Там секретарши поругались, там крановщик запил, там сварщик-бракодел. В итоге никто кроме руководителя проекта и не работает. А руководитель проекта не оптимизацией
Касательно глобальных рисков и планов: сейчас - это выбор исполнителей \ поставщиков товаров и услуг. В нашей отрасли сейчас от этого зависит будет ли в принципе работа или поставка (товара или услуги, от проектирования до поставки насоса) выполнена или нет. Проблемы с санкциями, логистикой, лицензиями на ПО для расчетов и технологии переработки, возможность привлечения держателей технологий. И позднее определение смещение срока поставки \ завершения работы таким контрагентом - гарантия срыва проекта.
Enrico_Pallazzo Автор
00.00.0000 00:00Площадка - это абсолютный авторитаризм. Отправили секретарш одну к Заказчику, другую за документами. Поручили начучастка сделать заявку на новый кран (нужно прямо сейчас - пусть достает, он знает, где), сварщику-бракоделу закрыли вход на территорию завода и в кадры заявку на рассчет (тоже начуч). 20 мин на все, рутина кончилась, не начавшись.
Вот из таких каждодневных Ваших(!) решений и сложатся потом дорожки к оптимизации. Кирпичик за кирпичиком, терпеливо.
Да, случаются и "перчатки", но это совсем уж из ряда вон... Да и на склад наведываться не помешает)
Вы окажетесь в рутине только если сами туда залезете, но это вопрос опыта в первую очередь.
Насчёт рисков согласен с Вами. Меняется экономический ландшафт, приходится фокусироваться на том, что раньше не было проблемой. И надёжных исполнителей, к сожалению, больше не становится...
VedmakOff
00.00.0000 00:00+1Спасибо за статью. Я тоже не из ИТ сферы и живой опыт управления проектами в физическом мире очень интересен как взгляд со стороны на проблему.
Подскажите, а какие методики вы используете для управления проектом? Ну наверняка есть календарный план с определенными вехами, все это переложено на сетевой график с критическим путём. Что вы делаете при не соблюдении сроков на одной из стадий? Как быстро вы узнаете об этом? Вы сами это видите присутствуя на объекте или вам сообщают руководители по направлениям?
Enrico_Pallazzo Автор
00.00.0000 00:00Рад, что присоединились к обсуждению????
Мой стэк вряд ли отличается от коллег - календарный план-график, метод критического пути, метод освоенного объема, бюджетирование. Прилагаю усилия к сбору качественного "факта", стремлюсь к актуальности "на конец дня", но это не всегда получается, особенно когда работаешь с подрядчиками, а не своим персоналом. Без факта не работает система.
Составляя график, для каждого этапа закладываю буфер - этим буфером, на самом деле, и управляют. Сорвали срок - буфер. Кончился буфер - убеждаем Заказчика, что он тоже виноват и переподписываем график. Проводим дополнительную мобилизацию, если невозможно переподписаться, выбиваем оплату допработ, обосновывая перерасходы. Все как у всех)
Об отклонениях сообщают коллеги, если не увижу сам.
Срыв сроков легко прогнозировать, когда находишься на площадке (ох уж, эта площадка????????). В этом первый помощник - метод обхода. Это когда поднимаешься из кресла, одеваешь СИЗы и шагаешь на стройку)
Чтобы обезопасить себя от срывов поставок, стоит выезжать на производство-контрагент или отправлять туда инженера по качеству.
Бывает, что важный субподрядчик "останавливается" без оплат, т.к. не может своевременно "закрыть" выполнение. Помогаем бедолагам)
Отклонения вы можете увидеть и аналитически, сравнивая плановые и фактические показатели, но будет временной лаг между наступлением точки невозврата и вашей реакцией. Как минимум из-за потерь времени между сбором и анализом "факта". Ещё потратите время, чтобы разобраться в ситуации.
"Факт" - это информация о том, сколько реально было выполнено/потрачено/принято.
aimfirst
Для того чтобы управлять, кроме рычагов воздействия на объект управления нужна информационная модель на основании оценки которой можно принимать адекватные решения. С учетом не только свойств объекта и возможностей субъекта управления, но и с учетом окружающей обстановки и интересов других игроков. В стародавние времена такая модель формировалась непосредственно в голове у руководителя. С некоторых пор такая модель зачастую выстраивается на бумаге. Например, на карте боевых действий. Чтобы принимая решения можно было превентивно оценить, к чему эти решения приведут. Беда в том, что в современных учебниках по менеджменту в перечень функций управления построение такой модели вообще не входит. Управление начинается сразу с планирования. Иногда складывается впечатление, что PM BoK был написан как инструкция для роботов-исполнителей из одного хорошего фильма. Инструкция для вершителей видимо засекречена. Результаты управления, построенного на таких принципах красноречиво описаны в статье.
Enrico_Pallazzo Автор
Спасибо за комментарий, Александр!
Уведомление к 6-му изданию PM BoK гласит, что PMI (те, кто опубликовал стандарт) не занимается проверкой обоснованности мнений, высказанных в документах PM BoK, PMI лишь администрирует процесс достижения консенсуса лицами, заинтересованными в разработке стандарта. Может, ими и засекречена "инструкция для вершителей"...
А информационная модель, как мне кажется, важнее самих "рычагов". И это, возможно, тема для следующей статьи.