среда, 2 сентября 2009 г.
Управление проектами. Отработка навыка коммуникабельности. Слежение
четверг, 14 мая 2009 г.
Отработка навыка коммуникабельности. Обратная связь
В этой заметке мне захотелось изложить свои мысли по методам отработки навыка коммуникабельности. Сразу же оговорюсь, что то, что я пишу, это написанное практиком для практика, методы простые и понятные. Существует масса литературы на эту тему, а в этой заметке на одну страницу, я просто кратко перечислю несколько методов, которые дают быстрый эффект и несложны в освоении. Возможно, это вам немного поможет систематизировать ваши знания, или просто обратит ваше внимание на некоторые методы.
Очень важным методом является обратная связь. В моей практике это один из трех основных методов. Как пользоваться методом:
- Получать обратную связь имеет смысл только с тем, кто имеет к вам отношения и с которым вы взаимодействуете не слишком редко. Здесь можно выделить два типа оценщиков:
a. Оценщик с сильной вовлеченностью: это может быть ваш друг, близкий родственник, ваш непосредственный начальник или коллега с кем вы тесно сотрудничаете. Данный тип оценщика позволяет получить глубокую оценку, но она также может быть сильно искажена из-за тесных связей.
b. Оценщик со слабой связью: это может быть коллега, с кем вы иногда взаимодействуете или приятель с кем вы иногда встречаетесь. Данный тип оценщика позволяет получить оценку, может быть и не такую обширную или глубокую, но с высокой вероятностью очищенную от личных взаимоотношений, что часто бывает полезно.Очень важно получать обратную связь с тем человеком, с кем установлен определенный уровень доверительных отношений, даже если вы не так хорошо знаете его. В противном случае вашу просьбу или не поймут, или дадут неверную оценку, которая помещает вам правильно провести анализ. - Обратная связь должна быть построена в форме диалога, в котором ведущая роль принадлежит вашему собеседнику. Если это будет монолог вашего собеседника, то вы не сможете уточнить, прояснить, углубить ту оценку, которую вы получаете. Если же это будет равный диалог, то вы забьете своего собеседника, и не сможете услышать то, что он вам говорит.
- Для качественной обратной связи должно быть подготовлено место и время. У вас и вашего собеседника должно быть свободное время, чтобы не отвлекаться. Место должно быть таким, чтобы позволить вам без помех общаться один на один. Если там будут другие люди, то ничего не получиться.
- После получения обратной связи, обязательно проанализируйте то, что вы услышали. Не стоит воспринимать это как истину в последней инстанции, но и полностью критичное отношение не позволить вам извлечь урок. Нужен баланс и чем вы больше доверяете этому человеку, чем больше вы его знаете, тем больше доверия оказывайте его словам.
- После анализа, обсудите то что вы услышали с вашими родными, друзьями или теми кому вы безусловно доверяете. Это очень важный пункт, который позволит вам, проверить слова оценщика, проверить свой аналитический аппарат (что очень важно для другого метода) и правильно скорректировать вашу стратегию и тактику поведения.
- После этого, вполне возможно, вам потребуется провести еще одну беседу с оценщиком, чтобы попытаться уточнить или расширить оценку, а главное попытаться лучше понять, то, что вам говорили.
- Заключительным пунктом является корректировка ваших действий, на основе оценки и её анализа. Здесь у вас простор действий, вполне возможно, что вы после анализа проигнорируете оценку или коренным образом попытаетесь что-то изменить. Главное в этом, чтобы это было осознанное решение, которого вы будете придерживаться.
Возможно, у вас возник вопрос, почему обратная связь это отработка навыка коммуникации, ведь обратную связь, можно получить о какой угодно области вашей деятельности и бездеятельности :) Да, это универсальный инструмент, позволяющий получить мощные результаты, в том числе и в отработке навыка коммуникабельности.
Продолжение следует…
вторник, 28 апреля 2009 г.
Построение взаимоотношений
По окончанию 6 года управления проектами, сформировал для себя очень неожиданную мысль. 80% процентов успеха 80% проектов – это ваше умение таким образом выстроить отношения с людьми которые участвуют в проекте, влияют на него, связаны с ним так или иначе, чтобы они как минимум не препятствовали проекту или как максимум активно помогали ему.
Вроде бы об этом постоянно говориться на всех тренингах, постоянно упоминается важность выстраивания взаимоотношений. Наверное, до меня долго доходит :) Но как много я видел проектных менеджеров, начальников разного уровня, которые не прикладывают каких-либо существенных усилий построения правильных взаимоотношений. Как часто я сам совершал и совершаю ошибку пренебрежения наладки коммуникаций.
Мысли о важности психологии в управлении проектами, появились у меня уже достаточно давно, но в существенное изменение стратегии вылились, только в прошлом году. Способствовало этому жесткая среда новой работы. Каждый день, множество взаимодействий с десятками людей от специалиста helpdesk до руководства. Жесткие сроки исполнения проектов и постоянная нехватка людских ресурсов. Широкое использование такого инструмента как эскалация. Все это привело к тому, что мне постоянно приходилось договариваться, и результат неудачи тут же был виден. Не смог договориться, чтобы специалист от бизнеса посмотрел данный документ в течение часа, а не двух дней, получил сдвиг по проекту, не смог убедить руководство, что тебе требуется 4 дня, а не 2, получил аврал для всей проектной команды и т.д.
Основные правила, которыми я руководствуюсь на сегодня:
- Стараться поддерживать хорошие отношения со всеми. С ключевыми персонами, сделать отношения очень хорошими, дружескими. Как способ достижения этого: быть доброжелательным, веселым, предлагать помощь т.е. все то, что вы хотите увидеть в других.
- Конфликты будут всегда, тут важно, после конфликта сохранить нормальные отношения. Как это сделать? Читать соответствующую литературу :) так как приемов масса. Один из них, которыми я часто злоупотребляю :) это после конфликта на следующий день, лично подойти к человеку и попросить его сделать какую-нибудь мелочь для проекта (которую он точно может сделать) или посоветоваться о чем-либо, как он считает нужным. Обычно помогает.
- Если вы четко видите, что что-то очень важно для проекта, то сделать это несмотря на сопротивление. Вы не должны быть мямлей, вы должны показать, что вы можете быть решительным и жестким, когда надо. Использовать надо очень осторожно! Поясню почему это важно. Люди начинают часто злоупотреблять вашим хорошим отношением, считая, что вы не сможете жестко прореагировать в этих случаях. Когда же они знают, что при необходимости, вы можете их заставить, это подвигает их не забивать на ваши просьбы.
- Очень важно быть внимательным и обращать внимание на поведение людей, их слова и пытаться анализировать их, для того, чтобы для каждого выработать свою технологию поведения. Для меня например данный пункт наиболее труден, так как требуется серьезных временных и энергетических затрат. Результат также сказывается незамедлительно, как только вы выработали к каждому свой подход. Как говорит мой шеф, к каждому человеку внутри вас, должен быть свой ящичек :)
Что вам может помочь в отработке навыка коммуникабельности? Об этом я напишу в следующий раз.
вторник, 21 апреля 2009 г.
Базовый курс по PMBoK
Когда записывался на курс, было большое желание упорядочить и согласовать мои практические навыки управления проектами и ту спецификацию, что изложена в PMBoK. Со сводом знаний от PMI я был знаком до этого курса, но было много вопросов, которые хотелось задать специалисту с хорошим практическим опытом и знаниями стандартов.
Свою задачу решил процентов на 70, появилось больше понимания по WBS, методу освоенного объема, управлению коммуникациями. Также стал лучше понимать взаимосвязи между процессами. По каждой области знания были хорошие практические примеры из опыта преподавателя, плюс было несколько задач, которые мы решали объединившись в несколько групп. Далее мы сравнивали решения и видели как много может быть подходов к одной и той же проблеме.
Те 30%, которые остались еще не решенными, это более подробное описание входов и выходов каждого процесса, интегральное взаимодействие всех процессов именно по передаваемым потокам информации между ними. Но немного подумав, понял, что первая задача решается подготовкой к сертификации, вторая, же проблема посерьезнее. Требуется самостоятельная проработка материала с уже полученными знаниями. Думаю заняться этим через месяц, когда все более-менее уляжется в голове.
Конечно те выгоды от курса которые я получил, и то что не получил, это сугубо индивидуально для каждого. Но если вы только собираетесь пойти на данные курсы, возможно, это станет подсказкой способной помочь вам определиться.
Хочу также высказать благодарность нашему преподавателю Рябоконь Сергею из компании PM-Expert, за профессиональный подход и желание делиться знаниями.
Если у кого есть вопросы, задавайте, с удовольствием на них отвечу.
PMBoK
В этой заметке хочу вкратце описать практическое применение PMBoK к ведению проектов. Начну с области знания – «управление коммуникациями проекта». Как и в предыдущей заметке, эта рассчитана на начинающих РП или тех, кому эта тема интересна и они могут дать профессиональные комментарии и замечания.
Особенности проекта обследования
В этой заметке хочу описать определенные особенности присущие проектам обследования. Возможно, кому-то они покажутся давно известными вещами, а кому-то будет полезно. На последнюю аудиторию и рассчитана данная заметка.
Главной особенностью проекта является сложность проверки качества результата. В проектах внедрения все достаточно просто система или запущена или не запущена, конечно, с учетом ограничений проекта. В проектах обследования результатом является документ «Результаты обследования» (РО, в других компания может называться по-другому) утвержденный банком. Это предполагает в свою очередь, что банк прочел документ, понял, что в нем изложено и согласен с этим. Здесь кроется риск того, что один и тот же текст по-разному могут пониматься исполнителем и заказчиком, поэтому РП должен обеспечить максимальную четкость изложения информации. Давайте посмотрим, за счет чего достигается:
1. Иметь шаблон, в котором, проработана структура разделов, максимально подробно описываются данные разделы. Состав и количество разделов должно быть достаточным для полного изложения необходимой информации накопленной во время обследования.
2. Согласовать шаблон с банком, перед началом работ или параллельно началу сбора информации.ы
3. Привлечь к внутреннему согласованию, специалиста не участвующего в проекте, но имеющего большой опыт в данной предметной области (бизнес-эксперт). Его экспертиза может существенно снизить риски белых пятен и способствовать повышению качества РО.
4. Если в компании имеется список бизнес-процессов по каждому направлению (зависит от зрелости компании), то РП обязан контролировать вхождение каждого бизнес-процесса в РО в соответствии с данным списком.
Следующей задачей РП должен быть процесс, результатом которого будет ясное понимание списка доработок (настроек и т.д.) возникших в процессе адаптации дистрибутива к бизнесу заказчика. Список доработок это полный перечень необходимых работ по модификации дистрибутива, для его приведения в состояние годное для внедрения у заказчика. Список обязательно должен включать трудоемкость задачи, и описание результата получаемого на выходе.
Задача РП проконтролировать, что все доработки, обозначенные по тексту РО, нашли свое отражение в списке и наоборот. Обязательным считаю привлечение специалистов внедрения для экспертной оценки трудоемкости работ обозначенных в списке. Желательно также данный список проработать с производственными подразделениями, вполне вероятно, что часть доработок снимутся с внедренцев и войдут в состав дистрибутива (последнее верно для тех компаний, где есть разделение дистрибутива и клиентских доработок).
Еще один вопрос, возникающий в ходе проекта обследование это различие точек зрения между различными подразделениями, а зачастую между прошлой точкой и сегодняшней одного и того же специалиста. Данная ситуация приводит к ряду проблем:
1. Затягивание сроков обследование и появление дополнительных трудозатрат исполнителя.
2. Выявление такого рода несоответствий на этапе согласование приводят к затягиванию согласования, а в худшем случае и отказе заказчика от результата работы.
3. Выявление же несоответствий на этапе внедрения приводят к увеличению сроков внедрения и опять таки в худшем случае остановки внедрения.
Для решения данной задачи, я использую следующие способы:
1. Обязательное фиксирование результата встреч на бумаге с подписью всех участников.
2. При обсуждении процессов затрагивающих несколько подразделений, на встрече должны присутствовать ответственные лица всех данных подразделений.
3. Все неоднозначные моменты выявление в ходе интервью, и нерешенные сразу, должны фиксироваться в отдельном списке и по каждой из них добиваться от заказчика определенности. Если же проблема не решается, то выносить её за рамки проекта, зачастую заказчик идет на изменение рамок проекта, чтобы не тормозить процесс.
4. На листе согласований РО должны присутствовать подписи всех участников со стороны заказчика. Обычно это серьезно повышает качество работы специалиста. Главное довести эту информацию в самом начале проекта :(
Ну и напоследок, РП должен приложить все усилия, чтобы те, кто проводил обследование, в дальнейшем проводили и внедрение. Зачастую это основной мотивирующий фактор для специалиста сделать свою работу качественно.
Устав проекта
Дополнительные работы
Как избежать данной ситуации, спросил я у себя, нашлось несколько способов:
1. Не принимать доп.требования в работу, пока не будет заключена допа к договору.
2. Принимать в работу, но сразу же начинать процесс подписания, и пока не подпишут, последующие требования не принимать в работу.
3. Принимать все в работу, но незадолго перед запуском системы, потребовать допу к договору, иначе остановить работы (естественно дав клиенту, определенный лаг по времени).
У каждого варианта есть свои минусы и плюсы:
1. Задержка работ, так как подписание допы это обычно долгий процесс. Плюс раздражение клиента. Зато юридически оформлено поступление денег.
2. Удачный вариант, но получается очень большой объем доп, что затрудняет подписание. Как вариант накапливать какой-то объем потом пускать в работу.
3. Не мешает работе, но под конец приходиться проявить определенную жесткость, что конечно может несколько раздражать клиента.
Сейчас в своем текущем проекте я склоняюсь к третьему варианту. Но на всякий случай, решил спросить не только у себя, но и уважаемых профессионалов данного ресурса, может, есть идеи и поудачнее.
Закрытие проекта
До конца недели собираюсь описать в блоге еще один интересный кейс, связанный с финансовым аспектом ведения проектов.
Если, в общем, то работой доволен. Все подводные камни изучены, дальше будет легче. Сейчас как раз веду проект, связанный с ценными бумагами, та область, что мне наиболее интересна, как инвестору. :)
Управление рисками. Опрос
Под формализованным процессом я понимаю:
1. Существует документированная процедура, описывающая управление рисками и предписывающая это делать.
2. В процесс выявления, описания, контроля рисков включены все заинтересованные лица, от исполнителей до директоров проектов, а также заказчики.
3. Существует не только качественное описание рисков, но их количественное выражение в виде трудозатрат и бюджета, как на предотвращение риска, так и его последствий.
4. Это реально работает в компании, а главное помогает управлению проектами.
Буду рад, если кто-то откликнется. Буду знать к кому обращаться за кусочком опыта :)
Ведение плана работ
Встала передо мною следующая задача. Есть запланированный блок работ, известно, что он не будет выполнен в сроки, из-за определенных проблем с системой. Сдвиг будет где-то на 30%, точнее оценить нельзя. Для правильного отражения сроков окончания есть несколько путей:
1. Увеличить каждую задачу на 30%.
2. В конце блока, поставить одну задачу длительностью 30% от блока. В течение выполнения ставить фактическое время выполнения каждой задачи, потихоньку отъедая от задачи дельты.
Я выбрал второй путь, по следующим соображениям:
1. Задачи, составляющие этот блок, могут, выполняется неравномерно, где-то 30%, где-то 5%, где-то 80% сверху будет.
2. Если увеличивать каждую задачу на 30%, то получаются очень некруглые цифры, типа 1,76 дня :) что не совсем реально. Суммарно же это вполне нормально получается.
3. Ну и, наконец, третий аргумент, ранее я работал по первому сценарию, как-то мне было не очень удобно. Решил попробовать для разнообразия второй вариант.
Возможно, кто-то знает третий путь, или у кого-то есть аргументы за первый или второй вариант. Жду ваших комментариев.
Мотивация
Когда же контрольные точки размыты, то у людей резко пропадает мотивация работать, возникает, мыль – «работаешь, работаешь, а результат хрен знает, когда будет». В связи с эти возникает вопрос о мотивировании людей. Один из способов который я предложил, является разбиение проекта на прогнозируемые этапы, по окончанию которых выплачиваются премии. Правда здесь возникает большая проблема, что результат этапа зачастую слабо проверяем, так как он промежуточный и не понятно насколько качественно сделана работа. Как пример, это настройка системы, нельзя понять, как она сделана, если не было проведено тестирование. Закладывать же тестирование, это дополнительные трудозатраты, которые клиентом не будут оплачиваться. Решение данной проблемы я, к сожалению еще не нашел.
Возможно, у кого-то есть какие-либо рецепты, как можно мотивировать людей в таких условиях. Или сделать этапы более проверяемыми без увеличения трудозатрат.
Ответы типа: ясно обозначить контрольные точки по срокам и т.т. не принимаются.
Бюджетирование проектов
Многие сталкивались с тем, что в ходе проекта появляются дополнительные работы, которые не были заложены в первоначальном плане, а также меняется трудоемкость по работам изначально запланированным.
По итогам промежуточным или окончательным требуется предоставить фактический бюджет и здесь возникает засада :) в виде вот этих самых изменений.
Предлагаю для обсуждения следующий механизм:
1. Все доп работы выносятся в отдельный раздел плана «Работы не вошедшие в договор» и делятся на три блока:
a. Работы, оплачиваемые клиентом
b. Работы, оплачиваемые из других фондов
c. Не оплачиваемые работы
2. По всем работам за исключением не оплачиваемых работ, должен быть сохранен базовый план. Соответственно по работам, которые присутствовали в плане, но по ним изменена трудоемкость, также сохраняется изменения базового плана, если они оплачиваются клиентом или из других фондов. Если же они не оплачиваются, то базовый план не сохраняется.
Следуя двум этим правилам, легко контролировать расходование средств относительно первоначального бюджета, считать премии участников и т.д.
Весь контроль бюджета осуществляется по базовым затратам, всю дополнительную работу которая не оплачивается также сразу видно. Подсчет отдельно бюджета по новым задачам, так же легко осуществлять, беря затраты только по выделенному блоку, причем так как они сосредоточены в одном разделе не надо бегать по всему плану, что очень актуально для планов начиная с 200 строк :)
Программа для ведения реестра рисков
Описываю я сейчас риски текущего проекта. Ворд конечно хороший инструмент, но все таки не совсем удобен. Задался целью найти клиент для ведения реестра рисков, и ничего не нашел :(
Желательная функциональность примерно следующая:
1. Настраиваемый шаблон описания риска.
2. Сохранения истории изменения полей.
3. Маршрутизация как отдельных рисков, так в общем.
4. Получения отчетности.
5. Сетовой доступ.
Может, кто подскажет инструмент. Хотелось бы именно специализированный продукт.