Показаны сообщения с ярлыком Управление проектами. Показать все сообщения
Показаны сообщения с ярлыком Управление проектами. Показать все сообщения

среда, 2 сентября 2009 г.

Управление проектами. Отработка навыка коммуникабельности. Слежение

Следующим методом отработки навыка коммуникации, является слежение за вашим кругом общения. Под слежением я понимаю, постоянное наблюдение, за вашими собеседниками, с целью понять, что они думают, чувствуют, когда говорите вы, когда говорят они. В любой компании, где вы присутствуете, вы должны не забывать отслеживать поведение, эта информация является иногда даже более важной, чем собственно то, что говорил человек.
К примеру, у вас была дискуссия, и вы смогли убедить вашего собеседника, в том, что необходимо сделать так, как вы сказали, а не как он. Но упустили или не посчитали нужным обратить внимание, что при этом, ваш собеседник, сильно напрягся. Вы уходите в полной уверенности, что все будет сделано так, как вы договорились, и позже узнаете, что ничего сделано не было. А все потому, что вынудив собеседника вербально согласиться с вами, вы все-таки не смогли убедить его внутренне, и получили саботаж, возможно даже, не осознаваемый вашим оппонентом.
Приведенный выше пример, это типичная ошибка, начинающего менеджера – убедить только внешне, а не внутренне, и не заметить этого, которая, в некоторых случаях, например при общении со спонсором проекта, может быть фатальна, как для вас, так и для проекта.
Как раз таки, для устранения такого рода ошибок, существует слежение. Вы отслеживаете, реакции вашего собеседника, составляете коллекцию его привычных реакций с расшифровками, и все время учитываете данные полученные слежением в разговоре, и дальнейшем поведении.
Хочу обратить ваше внимание на расшифровки, это важнейший компонент слежения. Без расшифровки определенной реакции определенного человека, да еще при определенных условиях, вы постоянно будете ошибаться. И в этот случае, можно сказать что вы не используете навык слежения.
Опять-таки пример, в ходе обсуждения вопроса о проведении небольшого дополнительного анализа какого-то бизнес-процесса, который раньше не был запланирован, ваш собеседник, в конце концов, согласился выделить специалиста из своего подразделения, и покинул встречу, с достаточно кислым лицом, не попрощавшись с вами. И здесь в зависимости от человека, последующие действия могут быть абсолютно разными, кто-то сдержит обещание, с кем-то вы знаете, что придется еще побеседовать, с кем-то вы точно знаете, придется серьезно конфликтовать, чтобы эту работу сделали. А в случае, что речь идет не о небольшой работе, а о средней, реакции могут серьезно поменяться. Поэтому очень важно привязать расшифровки слежения к конкретным людям, да еще с определенными условиями.
Из-за этого, расшифровка, является очень сложной в отработке и использовании. Поэтому метод слежения, зачастую не используется или используется очень незначительно. Но если, вы затратите усилия на освоения данного навыка, вы получите, грандиозные результаты. Вы сможете превратиться из технического менеджера в лидера, который чувствует, понимает команду и окружение проекта, тем самым ведя проект к успеху, с максимальной эффективностью.
Итак, слежение делиться на несколько блоков:
1. Составление списка персон и их классификация.
2. Слежение за выбранными персонами.
3. Расшифровка отслеженных реакций.
4. Занесение в каталог расшифровок.
5. Проверка правильно ли вы расшифровали реакция и при необходимости правка расшифровок.
Существует несколько практических приемов опирающихся на представленную структуру слежения, которые позволяет облегчить отработку и использование данного навыка, но об этом в следующей заметке.

четверг, 14 мая 2009 г.

Отработка навыка коммуникабельности. Обратная связь

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

  1. Получать обратную связь имеет смысл только с тем, кто имеет к вам отношения и с которым вы взаимодействуете не слишком редко. Здесь можно выделить два типа оценщиков:
    a. Оценщик с сильной вовлеченностью: это может быть ваш друг, близкий родственник, ваш непосредственный начальник или коллега с кем вы тесно сотрудничаете. Данный тип оценщика позволяет получить глубокую оценку, но она также может быть сильно искажена из-за тесных связей.
    b. Оценщик со слабой связью: это может быть коллега, с кем вы иногда взаимодействуете или приятель с кем вы иногда встречаетесь. Данный тип оценщика позволяет получить оценку, может быть и не такую обширную или глубокую, но с высокой вероятностью очищенную от личных взаимоотношений, что часто бывает полезно.Очень важно получать обратную связь с тем человеком, с кем установлен определенный уровень доверительных отношений, даже если вы не так хорошо знаете его. В противном случае вашу просьбу или не поймут, или дадут неверную оценку, которая помещает вам правильно провести анализ.
  2. Обратная связь должна быть построена в форме диалога, в котором ведущая роль принадлежит вашему собеседнику. Если это будет монолог вашего собеседника, то вы не сможете уточнить, прояснить, углубить ту оценку, которую вы получаете. Если же это будет равный диалог, то вы забьете своего собеседника, и не сможете услышать то, что он вам говорит.
  3. Для качественной обратной связи должно быть подготовлено место и время. У вас и вашего собеседника должно быть свободное время, чтобы не отвлекаться. Место должно быть таким, чтобы позволить вам без помех общаться один на один. Если там будут другие люди, то ничего не получиться.
  4. После получения обратной связи, обязательно проанализируйте то, что вы услышали. Не стоит воспринимать это как истину в последней инстанции, но и полностью критичное отношение не позволить вам извлечь урок. Нужен баланс и чем вы больше доверяете этому человеку, чем больше вы его знаете, тем больше доверия оказывайте его словам.
  5. После анализа, обсудите то что вы услышали с вашими родными, друзьями или теми кому вы безусловно доверяете. Это очень важный пункт, который позволит вам, проверить слова оценщика, проверить свой аналитический аппарат (что очень важно для другого метода) и правильно скорректировать вашу стратегию и тактику поведения.
  6. После этого, вполне возможно, вам потребуется провести еще одну беседу с оценщиком, чтобы попытаться уточнить или расширить оценку, а главное попытаться лучше понять, то, что вам говорили.
  7. Заключительным пунктом является корректировка ваших действий, на основе оценки и её анализа. Здесь у вас простор действий, вполне возможно, что вы после анализа проигнорируете оценку или коренным образом попытаетесь что-то изменить. Главное в этом, чтобы это было осознанное решение, которого вы будете придерживаться.

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

Продолжение следует…

вторник, 28 апреля 2009 г.

Построение взаимоотношений

По окончанию 6 года управления проектами, сформировал для себя очень неожиданную мысль. 80% процентов успеха 80% проектов – это ваше умение таким образом выстроить отношения с людьми которые участвуют в проекте, влияют на него, связаны с ним так или иначе, чтобы они как минимум не препятствовали проекту или как максимум активно помогали ему.
Вроде бы об этом постоянно говориться на всех тренингах, постоянно упоминается важность выстраивания взаимоотношений. Наверное, до меня долго доходит :) Но как много я видел проектных менеджеров, начальников разного уровня, которые не прикладывают каких-либо существенных усилий построения правильных взаимоотношений. Как часто я сам совершал и совершаю ошибку пренебрежения наладки коммуникаций.
Мысли о важности психологии в управлении проектами, появились у меня уже достаточно давно, но в существенное изменение стратегии вылились, только в прошлом году. Способствовало этому жесткая среда новой работы. Каждый день, множество взаимодействий с десятками людей от специалиста helpdesk до руководства. Жесткие сроки исполнения проектов и постоянная нехватка людских ресурсов. Широкое использование такого инструмента как эскалация. Все это привело к тому, что мне постоянно приходилось договариваться, и результат неудачи тут же был виден. Не смог договориться, чтобы специалист от бизнеса посмотрел данный документ в течение часа, а не двух дней, получил сдвиг по проекту, не смог убедить руководство, что тебе требуется 4 дня, а не 2, получил аврал для всей проектной команды и т.д.

Основные правила, которыми я руководствуюсь на сегодня:

  1. Стараться поддерживать хорошие отношения со всеми. С ключевыми персонами, сделать отношения очень хорошими, дружескими. Как способ достижения этого: быть доброжелательным, веселым, предлагать помощь т.е. все то, что вы хотите увидеть в других.
  2. Конфликты будут всегда, тут важно, после конфликта сохранить нормальные отношения. Как это сделать? Читать соответствующую литературу :) так как приемов масса. Один из них, которыми я часто злоупотребляю :) это после конфликта на следующий день, лично подойти к человеку и попросить его сделать какую-нибудь мелочь для проекта (которую он точно может сделать) или посоветоваться о чем-либо, как он считает нужным. Обычно помогает.
  3. Если вы четко видите, что что-то очень важно для проекта, то сделать это несмотря на сопротивление. Вы не должны быть мямлей, вы должны показать, что вы можете быть решительным и жестким, когда надо. Использовать надо очень осторожно! Поясню почему это важно. Люди начинают часто злоупотреблять вашим хорошим отношением, считая, что вы не сможете жестко прореагировать в этих случаях. Когда же они знают, что при необходимости, вы можете их заставить, это подвигает их не забивать на ваши просьбы.
  4. Очень важно быть внимательным и обращать внимание на поведение людей, их слова и пытаться анализировать их, для того, чтобы для каждого выработать свою технологию поведения. Для меня например данный пункт наиболее труден, так как требуется серьезных временных и энергетических затрат. Результат также сказывается незамедлительно, как только вы выработали к каждому свой подход. Как говорит мой шеф, к каждому человеку внутри вас, должен быть свой ящичек :)

Что вам может помочь в отработке навыка коммуникабельности? Об этом я напишу в следующий раз.

вторник, 21 апреля 2009 г.

Базовый курс по PMBoK

Случилось чудо, в нашей компании наконец-то организовали курсы. Пока правда один, и есть ощущение, что дальше чудес не будет :) В данной заметке, хотел поделиться с вами ощущениями от прослушанного курса.
Когда записывался на курс, было большое желание упорядочить и согласовать мои практические навыки управления проектами и ту спецификацию, что изложена в PMBoK. Со сводом знаний от PMI я был знаком до этого курса, но было много вопросов, которые хотелось задать специалисту с хорошим практическим опытом и знаниями стандартов.
Свою задачу решил процентов на 70, появилось больше понимания по WBS, методу освоенного объема, управлению коммуникациями. Также стал лучше понимать взаимосвязи между процессами. По каждой области знания были хорошие практические примеры из опыта преподавателя, плюс было несколько задач, которые мы решали объединившись в несколько групп. Далее мы сравнивали решения и видели как много может быть подходов к одной и той же проблеме.
Те 30%, которые остались еще не решенными, это более подробное описание входов и выходов каждого процесса, интегральное взаимодействие всех процессов именно по передаваемым потокам информации между ними. Но немного подумав, понял, что первая задача решается подготовкой к сертификации, вторая, же проблема посерьезнее. Требуется самостоятельная проработка материала с уже полученными знаниями. Думаю заняться этим через месяц, когда все более-менее уляжется в голове.
Конечно те выгоды от курса которые я получил, и то что не получил, это сугубо индивидуально для каждого. Но если вы только собираетесь пойти на данные курсы, возможно, это станет подсказкой способной помочь вам определиться.
Хочу также высказать благодарность нашему преподавателю Рябоконь Сергею из компании PM-Expert, за профессиональный подход и желание делиться знаниями.
Если у кого есть вопросы, задавайте, с удовольствием на них отвечу.

PMBoK

С процессом приобретения опыта управления проектами, открываются новые грани PMBoK (свод знаний по управлению проектами от PMI). Вначале моей деятельности в качестве руководителя проектов, данная книга для меня была такой стройной теорией, которая мало применима в жизни. По пришествию определенного времени, выделил несколько центровых блоков для каждого РП, остальные блоки остались за бортом. Теперь побывав между жерновами «заказчик – руководство» стал ценить другие области знаний.  :)
В этой заметке хочу вкратце описать практическое применение PMBoK к ведению проектов. Начну с области знания – «управление коммуникациями проекта». Как и в предыдущей заметке, эта рассчитана на начинающих РП или тех, кому эта тема интересна и они могут дать профессиональные комментарии и замечания.

Особенности проекта обследования

Закрыт очередной проект. Проект обследования банка по ценным бумагам, депозитарию, производным инструментам. С одной стороны проекты обследования легче, чем проекты внедрения, на выходе получаем большой талмуд и все дела. Но с другой стороны мне же потом это и внедрять  :)
В этой заметке хочу описать определенные особенности присущие проектам обследования. Возможно, кому-то они покажутся давно известными вещами, а кому-то будет полезно. На последнюю аудиторию и рассчитана данная заметка.
Главной особенностью проекта является сложность проверки качества результата. В проектах внедрения все достаточно просто система или запущена или не запущена, конечно, с учетом ограничений проекта. В проектах обследования результатом является документ «Результаты обследования» (РО, в других компания может называться по-другому) утвержденный банком. Это предполагает в свою очередь, что банк прочел документ, понял, что в нем изложено и согласен с этим. Здесь кроется риск того, что один и тот же текст по-разному могут пониматься исполнителем и заказчиком, поэтому РП должен обеспечить максимальную четкость изложения информации. Давайте посмотрим, за счет чего достигается:
1. Иметь шаблон, в котором, проработана структура разделов, максимально подробно описываются данные разделы. Состав и количество разделов должно быть достаточным для полного изложения необходимой информации накопленной во время обследования.
2. Согласовать шаблон с банком, перед началом работ или параллельно началу сбора информации.ы
3. Привлечь к внутреннему согласованию, специалиста не участвующего в проекте, но имеющего большой опыт в данной предметной области (бизнес-эксперт). Его экспертиза может существенно снизить риски белых пятен и способствовать повышению качества РО.
4. Если в компании имеется список бизнес-процессов по каждому направлению (зависит от зрелости компании), то РП обязан контролировать вхождение каждого бизнес-процесса в РО в соответствии с данным списком.

Следующей задачей РП должен быть процесс, результатом которого будет ясное понимание списка доработок (настроек и т.д.) возникших в процессе адаптации дистрибутива к бизнесу заказчика. Список доработок это полный перечень необходимых работ по модификации дистрибутива, для его приведения в состояние годное для внедрения у заказчика. Список обязательно должен включать трудоемкость задачи, и описание результата получаемого на выходе. 
Задача РП проконтролировать, что все доработки, обозначенные по тексту РО, нашли свое отражение в списке и наоборот. Обязательным считаю привлечение специалистов внедрения для экспертной оценки трудоемкости работ обозначенных в списке. Желательно также данный список проработать с производственными подразделениями, вполне вероятно, что часть доработок снимутся с внедренцев и войдут в состав дистрибутива (последнее верно для тех компаний, где есть разделение дистрибутива и клиентских доработок).

Еще один вопрос, возникающий в ходе проекта обследование это различие точек зрения между различными подразделениями, а зачастую между прошлой точкой и сегодняшней одного и того же специалиста. Данная ситуация приводит к ряду проблем:
1. Затягивание сроков обследование и появление дополнительных трудозатрат исполнителя.
2. Выявление такого рода несоответствий на этапе согласование приводят к затягиванию согласования, а в худшем случае и отказе заказчика от результата работы.
3. Выявление же несоответствий на этапе внедрения приводят к увеличению сроков внедрения и опять таки в худшем случае остановки внедрения.
Для решения данной задачи, я использую следующие способы:
1. Обязательное фиксирование результата встреч на бумаге с подписью всех участников.
2. При обсуждении процессов затрагивающих несколько подразделений, на встрече должны присутствовать ответственные лица всех данных подразделений.
3. Все неоднозначные моменты выявление в ходе интервью, и нерешенные сразу, должны фиксироваться в отдельном списке и по каждой из них добиваться от заказчика определенности. Если же проблема не решается, то выносить её за рамки проекта, зачастую заказчик идет на изменение рамок проекта, чтобы не тормозить процесс.
4. На листе согласований РО должны присутствовать подписи всех участников со стороны заказчика. Обычно это серьезно повышает качество работы специалиста. Главное довести эту информацию в самом начале проекта  :(

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

Устав проекта

Если честно, то не люблю писать уставы проектов. Занятие нудное и зачастую неблагодарное. Веду в настоящий момент проект, где клиент настаивает на появлении устава проекта. Делать нечего взялся за написание. Взял шаблон, удалил лишние разделы, добавил дополнительные. Прописал все стандартные пункты и встал! Встал потому, что задумался о его ценности для данного проекта. Понял, что ценности нет, за исключением одного раздела – порядок приема системы. РП со стороны банка, вменяемый, бизнесу интересен наш продукт (RS-Securities V.6), проект двигается в целом нормально, первый этап почти закрыли. Да и регламент взаимодействия с банком выработали. 
Вот теперь сижу и думаю, как же сделать документ не для проформы, а так, чтобы он реально работал. Несколько идей есть, но пока не вполне оформившиеся.
Интересно мнение коллег по цеху, как они выходили из данной ситуации.

Дополнительные работы

Всем думаю, знакома ситуация – проект в полном разгаре, все работают, и тут заказчик выставляет дополнительные требования. Обычно я запрашиваю у РП со стороны заказчика подтверждение оплаты, вставляю в план, сообщаю новые сроки если сдвинулись контрольные точки и работаем дальше. В конце проекта приходить время платить, и тут начинается тягание кота за хвост. Не хочет заказчик платить деньги, особенно если объем доп.работ приличен по размеру.
Как избежать данной ситуации, спросил я у себя, нашлось несколько способов:
1. Не принимать доп.требования в работу, пока не будет заключена допа к договору.
2. Принимать в работу, но сразу же начинать процесс подписания, и пока не подпишут, последующие требования не принимать в работу.
3. Принимать все в работу, но незадолго перед запуском системы, потребовать допу к договору, иначе остановить работы (естественно дав клиенту, определенный лаг по времени).
У каждого варианта есть свои минусы и плюсы:
1. Задержка работ, так как подписание допы это обычно долгий процесс. Плюс раздражение клиента. Зато юридически оформлено поступление денег.
2. Удачный вариант, но получается очень большой объем доп, что затрудняет подписание. Как вариант накапливать какой-то объем потом пускать в работу.
3. Не мешает работе, но под конец приходиться проявить определенную жесткость, что конечно может несколько раздражать клиента.
Сейчас в своем текущем проекте я склоняюсь к третьему варианту. Но на всякий случай, решил спросить не только у себя, но и уважаемых профессионалов данного ресурса, может, есть идеи и поудачнее.

Закрытие проекта

Закрыл свой первый проект в SoftLab. Внедрили модуль «Вклады». Не могу сказать, что все прошло гладко, банк был тяжелым, были допущены кое-какие ошибки при планировании из-за незнания некоторых особенностей работы в компании :) В настоящий момент сижу, пишу документ – Закрытие проекта. Хотел бы более подробно описать проект здесь, но ДСП.
До конца недели собираюсь описать в блоге еще один интересный кейс, связанный с финансовым аспектом ведения проектов.
Если, в общем, то работой доволен. Все подводные камни изучены, дальше будет легче. Сейчас как раз веду проект, связанный с ценными бумагами, та область, что мне наиболее интересна, как инвестору. :)

Управление рисками. Опрос

В последнее время, в управлении проектами, мне наиболее интересна тема управления рисками. Очень сильное впечатление произвела книга «Вальсируя с медведями». Провел среди своих знакомых опрос, используются ли в их компаниях формализованный процесс управления рисками. Оказалось, что нет. В моем личном опыте, также отсутствуют такие компании. Может, вы знаете, в каких российских ИТ-компаниях или филиалах западных компаний здесь, используется управление рисками. Возможно это крупные ИТ-департаменты крупных компаний :).
Под формализованным процессом я понимаю:
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. Сетовой доступ.

Может, кто подскажет инструмент. Хотелось бы именно специализированный продукт.