Поэтому если нет нужной динамики продаж, то никакое ISO тут качество не обеспечит!

Вот откуда начинает расти качество проекта!

Мда…

И дым от пророка в своем отечестве нам сладок и приятен…

– Друзья!

Сегодня настало время поговорить о том, что уже сейчас нам дала система качества!

Основной тезис построенной нами системы, как я уже многократно говорил, гласит: «Нет процессов без сбора данных, нет сбора данных без их анализа, нет анализа без принятия решений и нет решений без планирования корректирующих и предупреждающих действий!»

И стандартный набор инструментов и процедур только помогает эффективному прогрессу. Однако почему-то еще не все менеджеры проектов хотят следовать стандартным процессам и методикам!

– Они боятся, что это будет ограничивать их креативность?

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

Еще раз и еще раз повторяю, что стандарты – это регламенты действий только «по умолчанию». И если у вас появляется разумная им альтернатива, то это только приветствуется ISO, поскольку требует постоянного совершенствования! Поэтому не устану повторять, что наперекор устоявшемуся ошибочному мнению стандартные процедуры только способствуют креативности, а не затрудняют ее. Еще раз аргументирую. Стандартные процедуры дают четкое понимание задач данного проекта, а также конкретные инструменты и техники работы для завершения задач. Такой подход снижает количество информации, которое надо переварить, чтобы справиться с задачей. Стандартизация способствует, во-первых, эффективному логически последовательному выполнению проекта. Во-вторых, лучшей интеграции активности в связи с тем, что участники проекта видят взаимозависимость их работы с работой других участников проекта. Менеджеры смогут работать более автономно, понимая стандарты, которым надо следовать во время принятия решений. И наоборот, когда стандарты отсутствуют, сотрудники будут наталкиваться на разные препятствия, находя их просто на ровном месте. В-третьих, снижается коэффициент переделок в связи с тем, что стандартизация существенно облегчает возможность использования наработок предыдущих проектов, улучшает коммуникации, потому что все члены команды играют по общим правилам. И здесь мы плавно переходим к реальной возможности снижения рисков проекта при помощи хорошо известного способа – создания базы знаний по ранее выполненным проектам.

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

Здесь еще раз напомню вам об основных наших показателях – это как раз отклонения от плана в себестоимости и длительности проекта!

Повторное использование наработок других проектов дает возможность сконцентрироваться именно на специфике проекта. Для управления проектами могут быть повторно использованы определенные расписания из похожих проектов, форматы отчетов и формы. Более того, c технической стороны могут быть повторно использованы коды, спецификации, шаблоны и так далее. Практику повторного использования необходимо сделать элементом культуры выполнения проектов. Руководителю проектов надо научиться определять, что может быть использовано повторно. Как правило, такое понимание приходит в результате изучения истории выполнения проектов и документации предыдущих проектов.

Вот почему мы в обязательном порядке требуем наличие отчета о выполненном проекте!

Многие ИТ-проекты, уверяю вас, так похожи, что создается впечатление, что вообще ничего не меняется.

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

Это все много раз уже обсуждалось с вами на семинарах, но здесь специально повторил, чтобы подвести вас к абсолютной необходимости документирования всех проектных проблем и решений именно с целью создания такой практической базы знаний!

Да, чаще всего документирование связывают именно с понятием «бюрократии». Однако в управлении проектами достаточно разумная «бюрократия» просто необходима. В большинстве проектов члены команды выполняют колоссальное количество работы, к сожалению, часто усилия не успевают документироваться, и тогда и знания, и экспертные оценки могут постепенно растеряться.

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

Качество работы над проектом возрастает, если есть четкие записи, что было сделано, как и почему именно так.

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

Как показывают внутренние аудиты проектов-решения, на некоторых еще не полностью документируются, видимо, следуя довольно рисковой логике: раз решение дает немедленный результат, то и нет причин дополнительной административной нагрузки в виде его документирования. Но мало документировать процесс выполнения проекта, эта информация должна быть правильно структурирована, чтобы ее можно было быстро находить и извлекать!

Вот именно для этого мы и требуем теперь все проектные документы раскладывать по папкам в одной конфигурации. Но внутренние проверки показывают, что некоторые из вас опять «идут своим путем»!

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

– Да, вы правильно поняли, необходима просто исполнительская дисциплина, которой пока еще нет.

Ведь система качества – это только инструмент, а создают качество именно исполнители.

Вы все, конечно, много слышали про японские кружки качества. Этот процесс у них начался еще в 70-х годах, то есть уже более тридцати лет он в действии, и их же статистика упрямо говорит, что в среднем еще в 80-е годы каждый японский рабочий или служащий ежегодно вносил пять-шесть предложений по совершенствованию производственного процесса, из которых шестьдесят-восемьдесят процентов реализовывались на практике.

Вот откуда и выросло японское качество!

– Да, вы правы, в этом смысле Япония действительно «странная» страна. Но именно там кружки качества сделались тем средством, с помощью которого на каждом уровне производства снизу доверху коллективно прорабатываются и вносятся предложения по повышению качества продукции, процессов и ресурсов, что и требует система качества. А хотите – я вас снова приятно удивлю? Чем? А тем, что это все наш хорошо забытый опыт – правда, это помнит только старшее поколение – у нас, когда еще работали заводы, то на них помимо обязательных касс взаимопомощи всегда обязательно были и Бюро рационализаторских предложений и изобретательства (БРИЗ). Вот этот опыт они у нас и переняли, и теперь, по оценке экспертов, на восемьдесят процентов успехи японских фирм связаны именно с необычайно высокой активностью самих рабочих.