Аннотация
В первой статье данной серии публикаций дается расширенная трактовка термина "базовый уровень проектного управления". Это описание является основой для понимания последующих статей серии.
Введение
Начинать повествование с клише - это стандартный подход, но в данном случае это видится крайне уместным. Данная серия публикаций отражает применение далее приведенного высказывания, приписываемого Альберту Эйнштейну, к описанию проектного управления: Если вы что-то не можете объяснить шестилетнему ребенку, вы сами этого не понимаете. Не обещаю по поводу шестилетних, но минимум третьекурсникам соответствующих профильных ВУЗов должно быть понятно практически все.
Если рассмотреть существующие источники информации по данной теме, то современная литература и стандарты по проектному управлению представляются чрезмерно усложненными. Очевидно, пытаясь охватить весь возможный спектр случаев применения этого подхода, авторы объединили столь различные варианты применения проектного инструментария, что в итоге получилась "сверхвысшая математика", хотя в большинстве случаев обычной "таблицы умножения" бывает более чем достаточно. В данной серии публикаций я постараюсь, используя многолетний опыт проектного управления на предприятиях иностранных представительств, рассказать доступным языком об основах этого подхода, а также поделиться соображениями по внедрению базового уровня данного типа управления.
Уверен, что описанный подход можно будет масштабировать и адаптировать, но целевая аудитория данной серии публикаций - это небольшие и средние предприятия полного цикла, выпускающие промышленную продукцию, которые имеют ориентировочную численность административного персонала от 50-60 до 200-230 человек (если организация небольшая там более логично применить какие-либо вариации Скрам или Канбан, если предприятие достаточно крупное, тогда применение описываемого подхода видится излишне сложным). Под полным циклом понимается функционирование на предприятии в каком-либо виде минимального набора основных "стандартных" подразделений производственной организации. Примером может послужить следующий список: отдел продаж, инженерный отдел, технологический отдел, отдел закупок, отдел качества, производственный отдел, отдел логистики и экономический / управляющий блоки.
Также хотелось бы заметить, что, скорее всего, даже в большей мере, целевой аудиторией написанного будут являться предприятия, подходящие под описываемые параметры, где уже были попытки внедрения проектного управления своими силами или с помощью приглашенных специалистов, и на которых дело не пошло, или получилось не совсем то чего ожидали (или совсем не то).
Предвосхищая вопрос читателя, скажу, что мне не довелось внедрить проектное управление ни на одном предприятии, основываясь на данной методике, но я неоднократно был свидетелем того, как работает управление проектами на российских предприятиях, и видел, как оно внедряется у нас. Плюс очень показательными были интервью с работодателями и отражение функционала руководителей проектов в многочисленных описаниях вакансий. По большому счёту это меня и побудило взяться за перо: не совсем корректное понимание того, как работает механизм управления проектами и, зачастую даже того, в чем именно заключается работа руководителя проекта. Что уж тут говорить о руководителях, которые хотят, чтобы проектное управление было внедрено на их предприятиях. Одним из основных мероприятий по его внедрению они видят написание "регламента реализации проектов" и, что самое прискорбное, внедряющие его зачастую понимают это таким же образом.
Повествование постараюсь не усложнять излишне, а также буду стремиться по минимуму "лить воду" и создать что-то наподобие сжатой методической инструкции, предназначенной для самостоятельного применения, без какого бы то ни было участия ее автора. Также буду пытаться писать простыми словами для более однозначного понимания читателями изложенных идей, в случае необходимости буду приводить примеры, а также схемы или/и диаграммы, поясняющие и дополняющие текст.
Закончить столь неожиданно объемное введение хотелось бы также очень подходящим к логике данного подхода клише: сначала необходимо научиться ходить, а только потом учиться бегать.
1.1 Что такое проект?
Термин "проект" - это пока не полностью зафиксированное в профессиональном сообществе понятие. Даже если мы возьмем стандарты РФ (например, ГОСТ Р 21500-2014 "Руководство по проектному менеджменту" и ГОСТ Р ИСО 9000-2015 "Системы менеджмента качества. Основные положения и словарь") определения различаются, не говоря уж о различных трактовках в общеизвестных международных основополагающих документах (PMBoK, PRINCE2, P2M). Самым близким к достоверному и краткому описанию функционала этой деятельности считаю определение из упомянутого выше ГОСТ Р ИСО 9000-2015. Здесь будет приведена небольшая его адаптация, в рамках публикаций этого цикла будет использована данная формулировка.
Проект - это уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятый для достижения определенного результата и имеющий финансовые ограничения.
Для предприятия проектная деятельность представляется обыкновенной работой по исполнению агентского договора(ов) на поставку какой-либо продукции. При реализации проекта существуют ограничения сроками, указанными в договоре, определенной ценой, прописанной в нем и техническим описанием поставляемого продукта. Эти три ограничения составляют "Железный треугольник" проекта: Затраты - Время - Качество (Качество результата).
Охват работ в рамках проекта всецело зависит от каждого отдельного предприятия и его специфики. Если брать в общем, работу команды следует считать проектной, начиная с этапа проектирования и заканчивая подписанием закрывающих документов клиентом. В отдельных случаях к проектным можно причислить работы от подготовки коммерческого предложения клиенту до работ по гарантийным случаям - это зависит от особенностей договорных отношений.
1.2 График проекта
Главным рабочим инструментом организации работ в рамках проекта является диаграмма Ганта или просто - график работ проекта. Это документ основное поле которого занимает горизонтальная столбчатая диаграмма, вертикальную ось которой представлют собой все задачи проекта, а горизонтальную - шкала времени. В рабочем поле этой диаграммы находятся сами горизонтальные столбцы, характеризуемые датами начала и окончания выполнения задач и их принадлежностью определенным задачам. Каждая из задач в графике представляет из себя определенный объем выполняемых проектных работ. При необходимости задачи могут быть сгруппированы по различным признакам, в большинстве случаев, производят группировку по пакетам (однотипных) работ или подразделениям их выполняющих. Отображение работ таким образом удобно с точки зрения понимания последовательности проектных работ, их взаимозависимостей и временных рамок.
Специализированное программное обеспечение для составления графиков позволяет связывать задачи друг с другом. Каждая задача проекта должна быть связана с какой-либо другой задачей или с датой начала проекта (датой собрания на котором утверждается старт проекта). График может быть представлен в более подробном виде для понимания деталей взаимодействия членов проектной команды и в сокращенном для общего контроля прогресса проекта руководством.
Задачи детализированного графика в обязательном порядке содержат имя ответственного за каждую задачу и подразделения, которые они представляют. В более общих графиках допустимо указывать только подразделения. В детальном виде он "настольная книга" для руководителя проекта, к которой тот регулярно обращается и на постоянной основе использует в работе. Графики работ составляются руководителем проекта при поддержке членов проектной группы и их руководства.
1.3 Документность заданий
Очевидно, что результатом работ сотрудников любого производственного предприятия является документация. Даже если сотрудник выполняет какого-либо рода физическую работу или работу с использованием оборудования, ее результаты или свидетельства ее выполнения заносятся в документы. Проектная работа в этом понимании более формализована, потому что из нее исключена поддерживающая операционная деятельность, которая документируется менее формально, такая как, например, уборка территории предприятия от снега, замена лампочек освещения производственных помещений, ремонт душевых кабин и т.п.
Все задания, которые есть в списке работ проекта, это, по сути, работа по составлению / заполнению / созданию какого-либо документа, или результатом которой является документ. Хотелось бы особо подчеркнуть, это понятийная основа всей серии публикаций. Поэтому повторюсь - результат выполнения каждого задания в рамках проекта - это документ, будь то габаритный чертеж или технологическая карта, акт приема-передачи или договор на поставку материалов и т.п. При составлении графика работ правило соответствия каждого задания в рамках проекта документу (или набору документов) следует соблюдать неукоснительно. Естественно, не нужно и переусердствовать и слишком формализовывать описание работ проекта. Текстовое описание необходимо формулировать понятным производственным языком, например: задание "Провести испытания образца изделия" нет необходимости формулировать как "Составить протокол испытаний образца изделия", но иметь понимание, что результатом выполнения этого задания будет документ "Протокол испытаний №ХХХ от ХХ.ХХ.ХХХХ".
После выпуска документов их электронные копии хранятся у руководителя проекта и изменению не подлежат. Для данного пункта оставим это утверждение как верное, на самом деле изменения документов теоретически возможны, но этот процесс будет описан в последующих частях. Последовательность документов, отраженная в графике, представляет собой последовательность выполнения проектных работ проекта, другими словами, она отражает течение информации, характеризующее прогресс проекта. Большими штрихами это будут: конструкторская документация - технологическая документация - договоры на закупку материалов и инструментов (оборудования) - отчёт производства образца изделия - протокол испытания образца - акт приемки изделия.
1.4 Процессность проекта
Хотелось бы избежать повторения прописных истин относительно описания бизнес-процессов, но все-же при этом показать их в ракурсе представленного здесь описания проектной деятельности.
Классическое описание бизнес - процесса (ГОСТ Р ИСО 9001-2015)предусматривает, что он состоит из "Входов" -> "Деятельности" -> "Выходов". Если взять выполнение работы в рамках проекта, то горизонтальный столбец диаграммы Ганта (графика работ проекта) - это и будет обозначение "Деятельности" - работы члена проектной группы и "Выхода" - результата выполнения им этого задания. Т.е. дата окончания выполнения задания - это дата, когда член проектной группы предоставляет финальную версию документа, за подготовку которого он ответственен.
Предприятие обеспечивает члена проектной группы ресурсами для того, чтобы у него была возможность выполнить это задание, оно обеспечивает его материальными ресурсами: инструментом для его выполнения, будь то компьютер или станок с ЧПУ, и информационными ресурсами: соответствующими знаниями и документами, регламентирующими выполнение данной работы. Регламентирующий документ, в проектном понимании, представляет собой текстовое описание того, как из документа предыдущего шага проекта сделать следующий шаг, следующий документ.
Качественной характеристикой регламентирующего документа является достаточность результата его выполнения для качественного выполнения последующего шага. В рамках данной серии публикаций нет необходимости уходить достаточно глубоко в описательную часть процедурной составляющей, но необходимо заметить, что для руководителя проекта знание основных регламентирующих документов (стандартов, процедур, инструкций и т.п.), которыми руководствуются члены проектной группы является одной из основополагающих компетенций.
1.5 Ответственность за выполнение заданий
Это еще один важный момент в проектной работе.
Руководителю проекта следует позаботиться о том, чтобы задания графика работ (и все остальные задания проекта) были полноценными, в общем случае они должны иметь краткое описание начинающееся с глагола (Составить, Выполнить, Подписать, и т.п.) и заканчиваться обозначением предмета работ или документом (Технологическая документация, Испытания образцов, Договор с потребителем, и т.п.), также они должны иметь дату выполнения задания и ФИО ответственного за то, чтобы данное задание было выполнено.
Ответственность за выполнение задания подразумевает достаточную автономность в его выполнении. Если члену проектной команды необходима информация для его выполнения, то он самостоятельно получает ее посредством любых средств обмена информацией принятых на предприятии: пишет и получает эл. письма, совершает звонки, назначает / проводит совещания и т.п. По умолчанию контроль правильности заполнения / создания / составления документов лежит на непосредственном руководителе сотрудника, ответственного за документ. Обычно подпись руководителя в документе является показателем правильности выполненной сотрудником работы.
Если затронуть качественные характеристики и их достижение, то тут необходимо обратиться к Ключевым показателям эффективности (КПЭ) работы сотрудника. Для того чтобы работы проекта имели высокое качество и выполнялись в срок, эти характеристики проектных заданий должны отражаться в КПЭ членов проектной команды. В отдельных случаях (по усмотрению непосредственного руководителя) руководитель проекта может быть привлечен к оценке степени выполнения КПЭ членом проектной группы во время выполнения проектных работ.
1.6 Производственные и непроизводственные процессы
Вся работа по реализации проекта, с точки зрения процессной составляющей, делится на две части: на ту, которая выполняется в теоретической плоскости, и ту, которая лежит в практической (физической) плоскости. На начальной стадии проекта обычно выполняется работа по подготовке документации, необходимой на более поздних этапах. Это, в основном, касается конструкторской, технологической документации, планов испытаний, планов монтажа, сюда же относится заключение договоров с поставщиками материалов и инструментов. Когда основные теоретические работы завершены, проектная деятельность переходит в физическую плоскость: производятся такие работы как приемка материалов, испытания поступивших материалов и инструментов (оборудования если необходимо), производственные и сборочные работы, разрушающие и неразрушающие испытания.
Данное разделение достаточно условное, оно не определяет приоритетность или уровни важности какой-то одной из этих стадий для работы руководителя проектов. Для него этот переход обозначает то, что область его контроля и осведомленности расширяется, и теперь необходимо дополнительно быть в курсе того, что происходит с материальной составляющей проекта.
Если смотреть с точки зрения ошибок, которые могут возникать в процессе реализации проекта, то руководителю проекта необходимо значительно увеличить уровень внимания к проектным сложностям, т.к. стоимость исправления ошибок с началом "физической" стадии возрастает в значительной мере.
1.7 Качество проекта
В заключении хотелось бы вкратце резюмировать изложенное в этой части. Цель существования предприятия - это приносить доход. Доход приносят договоры на поставку продукции предприятия. Ограничения, описанные в обычном договоре на поставку какой-либо продукции, идентичны ограничениям, накладываемым на деятельность в рамках реализации проектов. Можно сказать, что проектная работа является естественным способом исполнения договорных обязанностей. Проект, в свою очередь, состоит из работы отдельных сотрудников (производственной и непроизводственной составляющей), результатом которой являются документы. Эту работу они осуществляют, руководствуясь имеющимися регламентирующими документами предприятия. Отсюда выходит, что от качества процессов зависит качество выполняемой в соответствии с ними работы, а от качества работы зависит качество каждого документа самого проекта и, соответственно, общее качество его результата.
Ссылка на "Часть 2. Описание функционала"
Ссылка на "Часть 3. Процесс внедрения"