Аннотация: Цель данной статьи - определить направление развития проектного управления вашей фирмы в зависимости от её проектной среды. И обозначить какие параметры необходимо контролировать и почему.
Цель данной статьи - определить направление развития проектного управления фирмы в зависимости от её проектной среды. И обозначить какие параметры необходимо контролировать и почему. (В более сжатой форме суть статьи изложена в презентации Основные принципы управления проектами на базе Теории Ограничений (ТОС) - 30 слайдов)
Суть проекта - риски. Следовательно, управление должно позволять этими рисками управлять. Как это можно сделать?
Первое что приходит в голову - разделить проект на задачи и иметь в запасе ресурс исполнителей. Это механистический подход, который, по ряду причин, дает сбои. Дело не в программах, или методах управления. Существует фундаментальная ошибка подхода, которая выливается в итоге в проблемы и не позволяет систематически снижать риски.
Тестовое отличие, по которому можно отличить проект от "деятельности" - необходимость сделать его быстрее. Такая потребность важна для строительства, где инвесторам важно приблизить момент, с которого они могут начать возвращать свои инвестиции. Или это внутренний проект, от которого зависит, будет ли компания успешно адаптирована для условий рынка.
Классика говорит, что для успеха проекта должны быть четко определены приоритеты, заинтересованность руководства, хорошие люди... Это все следствие того, что в общей системе кому-то нужно сделать вот эту часть работы быстрее, чем все остальные. Например, в 2 раза.
В чем ошибка механистического подхода? Чтобы увидеть её необходимо понять природу неопределенности. Для любого проекта нет целых блоков знания, технологий, документации, которые позволят все заранее спланировать, как это возможно, например, в производственной среде.
Неопределенность тормозит работу и в конечном итоге создает очень большие перепады в нагрузке на исполнителей. Эти ограничения - информационные. Потери, которые они создают несопоставимо большие, чем стоимость ресурсов.
Обычный же подход фокусирует нас на перепланировании графиков и типизации ресурсов. Там где отсутствует информационный шаблон - это тупиковый подход. Что толку планировать время работы программистов, если системный архитектор не успевает спроектировать систему? Что толку оценивать время работы строителей, если проект будет согласован к концу строительства?
Т.е. мы строим свою систему под людей исполнителей, которые ожидают инструкций. Соответственно и относимся к ним как к исполнителям: платим зарплату и наделяем полномочиями. А исполнителям по факту приходится держать в голове все детали проекта. Быть готовым угадать, какое решение верное исходя из условий проекта. И взять на себя ответственность за это решение.
Другими словами управление в условиях неопределенности это работа с менеджерами, а не с исполнителями. Этот промежуточный уровень невозможно перепрыгнуть, даже если информационная система позволяет "следить" за всеми исполнителями.
Если неопределенности (рисков) немного, то проблемы можно проигнорировать. Однако, для реальных проектов, которые нужно делать всегда быстрее, только вопрос времени, когда рынок подтолкнет к такой скорости исполнения, что без проблем не обойдется.
Здесь возможны 2 подхода. И чем дальше развивается фирма, тем больше их несовместимость. Однажды сделав выбор, изменить его не удастся.
Либо мы каким-то образом умудряемся, все заранее выстроить и тогда строим "военную? механистическую систему. Наши проектные институты чудесным выдают нам вовремя всю документацию, заказчики четко знают чего они хотят, наши руководители проектов умеют сглаживать все недовольство постоянным изменением графиков и т.д.
Либо мы во главу угла ставим управление неопределенностью. И тогда для нас более важным становится устойчивость графиков, а не их точность. Умение учиться и договариваться, а не профессионализм и опыт работы. Разделение знаний и функций и дальнейший обмен. Структурность планирования вместо детальности и много других изменений.
Во втором случае есть возможность систематически увеличивать скорость выполнения отдельных проектов и обеспечивать рост фирмы. В первом случае мы упираемся в информационные ограничения.
Сутевое отличие подходов в том, что ускорение проектов делается по-разному. На что делается ставка? В первом случае на увеличение ресурсов. Во втором на изменение организационных политик, коммуникации, фокусирование и др.
В зависимости от того, на чем будет сконцентрирована система управления, какие параметры она будет выделять главными, подлежащими контролю - выстраивается деятельность всех участников проекта. Также важны основные направления развития такой системы - приоритеты, которые поощряются.
Имеется ввиду следующие приоритеты: ускорять проекты, в максимальном диапазоне изменять интенсивность работы по отдельным задачам (гибкость), фокусировать типовые задачи, обеспечивать обмен знаниями среди всех участников проекта.
Строится эта система на основании приблизительных оценок, которые уточняются в ходе проекта. Большинство её параметров закрывается использованием существующих инструментов (графики, отчеты) с небольшими изменениями.
Второй тип проектов обычно характерен для "творческой? среды: программисты, дизайнеры, маркетологи, проектировщики. Начинается деятельность таких фирм беспрецедентной работоспособностью, укороченными сроками и надежностью исполнения. Что же происходит потом?
При недостаточном внимании, через некоторое время проекты становятся неуправляемыми - никто не может уверенно ответить, когда же будет сдан очередной релиз или написана очередная версия. Тогда очень сильно желание вернуться к механистическим методам. Вариант: просто смириться, что такими проектами управлять невозможно, чтобы "художники? не разбежались.
Дело в том, что неопределенность подталкивает делать работу "от начала до конца?. У проектировщиков это называется "сквозное проектирование? - один человек выполняет все задачи сам, чтобы быть в курсе всего проекта. Кажется, что разделять функции "некогда?, объяснять и состыковывать работу нет необходимости - горят сроки.
В дальнейшем давление по срокам заставляет выполнять параллельно несколько проектов "одновременно?. Появляются последствия многозадачности: сроки пухнут, надежность оценок падает в разы, проекты требуют "специалиста, который может все?. Порочный круг замыкается. Как его разорвать?
Чтобы делать проекты быстрее нужно делать параллельно меньше проектов и более тщательно фокусироваться на выполнении текущих задач. Лучше сделать два проекта последовательно за месяц каждый, чем параллельно выполнять 2 проекта и сделать их за 2 месяца.
Управление должно позволять поставить максимальное количество людей, на текущую задачу, чтобы сделать её быстрее. Для этого необходимо выделять отдельные задачи, а не сваливать их в кучу. Тогда необходимо делиться знаниями и текущим состоянием проекта. Это сложно. Но выбора-то нет!
Кроме того, при последовательном выполнении проектов гораздо быстрее приобретается опыт не только в выполнении отдельных задач ("набивается рука"), но тренируются навыки в коммуникации и интеграции.
Подобно стремлению уйти от фокусирования и последующей интеграции, существуют иллюзии, что можно обойтись без управления. Главные специалисты, ГИПы, ведущие программисты, сами справятся с этим. Практика показывает, что они справляются с большой натяжкой. Придание им администраторов, которые ведут графики и всем "мешают?, только увеличивает напряженность.
В производственной среде задача руководителей - подготовить и обеспечить работу. В проектной среде - устранить неопределенность и предложить решение. ГИПы и специалисты работают "внутри? решения. Руководители же должны смотреть "сверху? всех решений. Это разный режим восприятия. Можно ли их совмещать?
Как правило, человек, который находится "внутри? решения не видит, как оно создается. А тот, кто умеет его создавать (руководитель) не испытывает восторга от исполнения. Разная скорость мысли.
Функция руководителя также нуждается в фокусировании. Если её недостаточно упираемся в информационные ограничения. От неё зависит деятельность не только отдельного проекта, а всей фирмы. А также потенциал её дальнейшего роста.
Чтобы выращивать руководителей необходимо фокусировать (явно отделять) эту деятельность в системе управления.
Основная задача руководителя проекта - искать возможность делать проекты быстрее. Обычно следуют возражения, что, кроме сроков важны еще объем и бюджет. Да это контрольные показатели. Но мы не можем улучшать их, рынок нас за это не похвалит. Объем проекта определяется потребностями заказчика. Стоимость - текущими ценами на рынке.
А вот сроки исполнения очень ценятся в среде, где неопределенность основная характеристика. Кроме того, сроки являются интегральным показателем способности фирмы организовывать, т.е. устранять информационные ограничения. В конечном итоге для фирмы - это пропускная способность денежного потока, текущего через неё.