Страсти по ISO 9000. Грустно-комическая повесть о получении сертификата на систему качества - [29]

– Да уж, как не понять! ISO начинается только с момента подписания контракта, а качество проекта закладывается до этого – при анализе требований возможного клиента, и если вы «голодны» и ваш портфель проектов пуст, то вы и наобещаете сделать «из мухи слона».

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

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

Мда…

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

Глава одиннадцатая Подводим итоги

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

Сун Цу

– Друзья!

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

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

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

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

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

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

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

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

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

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

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

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

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

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