Версия для печатиОтправить другу

Ситуация:
Вы - руководитель проекта внедрения CRM системы в небольшой компании. Это ваш первый проект в качестве руководителя проекта. Генеральный директор является инициатором и спонсором данного внедрения и надеется обойтись "малой" кровью, т.е. внедрить систему быстро и недорого. Вы утвердили устав у генерального директора и приступили к работе. Для начала, вы решили собрать требования к системе от подразделений, которые планируют использовать эту систему, а затем выбрать систему, соответствующую этим требованиям. Надо сказать, что часть подразделений восприняли идею внедрения CRM с энтузиазмом, однако другая часть отнеслась к проекту достаточно холодно. После месяца работ по сбору требований, вы получили огромный список требований к системе, как функциональных, так и технических. Часть из этих требований, по вашему мнению, были слабо применимы к вашей компании. Однако, инициаторы этих требований наотрез отказались удалять их из списка. Проанализировав рынок, оказалось, что вашему списку требований соответствуют только несколько крупных и очень известных CRM, внедрения которых славятся своей дороговизной.

Вывод:

В процессе управления требованиями старайтесь избегать избыточных требований. Многие сотрудники, зачастую, закладывают неоправданно высокие дополнительные требования к продукту проекта, действуя по принципу "в будущем понадобится" или "а вдруг пригодится". Другие же могут постараться включить как можно больше требований от недостатка экспертных знаний, опасаясь недостаточной функциональности продукта при использовании. Если во втором случае может помочь тщательно спланированное обучение, то в первом - только переговоры. Необходимо помнить, что ничего не дается даром и, возможно, вам придется заплатить за возможности системы, которые никогда не будут использованы. Кроме того, дополнительные требования часто являются синонимом дополнительным работам. А чем больше работ на проекте – тем больше сроки и тем выше вероятность проблем. Постарайтесь убедить сотрудников включать только те требования, которые реально необходимы иначе – эскалируйте проблему на спонсора проекта.