Методология управления проектами, сложившаяся в компании «СетьПроект», имеет ряд особенностей.
1. Мы считаем, что проработка проектного решения до его внедрения (проектирование) является важнейшим фактором успеха проекта. Наш опыт выполнения множества проектов показал, что проекты, выполняемые «с наскока», удачными не бывают никогда. В каких-то случаях проектирование может быть очень глубоким и детальным (например, если на внедрение выделяется очень сжатый промежуток времени — именно так происходила модернизация телефонной станции в компании «МОРОН», или когда предполагается внедрение силами низкоквалифицированного персонала заказчика). В других случаях проектирование может быть довольно поверхностным (если, например, применяемое решение уже ранее апробировано, персонал обучен, а серьезные сложности во внедрении не просматриваются), но в любом случае, без проектирования мы стараемся не обходиться никогда (см., например, доклад о внедрении IP-телефонии в компании Baker & McKenzie).
2. Результатом выполнения каждой работы по проекту (и в фазе проектирования, и в фазе внедрения, и в фазе эксплуатации) является тот или иной документ— техническое задание, план настройки, протокол испытаний и т. п. Наличие документально оформленного результата работы позволяет существенно снизить риск разногласий между руководителем проекта и исполнителем по вопросу приемлемости качества выполненной работы — появляется сравнительно объективный критерий для оценки этого качества.
3. Все документы по проекту разрабатываются в несколько версий (обычно в три версии), причем каждая версия подвергается редактированию (научному, техническому и литературному) руководителя проекта и (или) других участников проектной группы или сторонних экспертов. Это обеспечивает приемлемый уровень качества каждого выпускаемого документа.
4. За концептуальную целостность документа отвечает только автор. Все редакторы работают только в режиме комментирования документа, им запрещено вносить правки непосредственно в текст. Ключевая задача редакторов — помочь автору грамотно сформулировать свои мысли и чётко и правильно изложить их. Все работы по проекту детализируются таким образом, чтобы длительность каждой элементарной работы не превышала двух-трёх дней. Дробные отчёты о выполнении работы (например, «настройка выполнена на 60%») не принимаются — работа считается выполненной только тогда, когда она выполнена на 100%, в противном случае она считается невыполненной вовсе. Это эффективно предотвращает ситуации «зависания» работ, когда работа, выполненная на «99%», остается незавершенной в течение дней, недель и месяцев. Кроме того, такая детализация существенно повышает эффективность планирования времени на выполнение работ по проекту и позволяет, при необходимости, гибко маневрировать качеством и сроками (например, планируется, что техническое задание будет разработано в две версии, а не в три, при этом длительность фазы проектирования сократится на неделю, а длительность приемочных испытаний увеличится на полторы недели).
5. Все документы, разрабатываемые в ходе проекта, чётко структурируются еще до начала разработки — иногда структура задаётся стандартом (например, ГОСТ 34.602-89 задаёт требования к структуре технического задания), но чаще — внутренними шаблонами «СетьПроекта» с учётом особенностей конкретного проекта. Опыт показал, что нечёткая структура документа практически всегда гарантирует невнятность и его содержания.
Только после того, как структура документа согласована, начинается наполнение этого документа содержанием.
6. Все документы, разрабатываемые в ходе проекта, тщательно проверяются на читабельность и понятность: мы добиваемся простоты и лаконичности формулировок, отсутствия грамматически сложных предложений, строгости стиля и минимизации использования жаргона. Повышению убедительности документа существенно способствует, по нашему опыту, чёткое разделение фактов, допущений и выводов и отсутствие орфографических и грамматических ошибок.
7. Все документы, разрабатываемые в ходе проекта, аккуратно увязываются между собой — выдавая задание на разработку того или иного документа, руководитель проекта указывает, на каких документах должен базироваться разрабатываемый документ, и как разрабатываемый документ будет использоваться в дальнейшем. Это позволяет придать проектным документам целенаправленность и избежать затрат ресурсов на разработку тех документов, которые далее в проекте не будут востребованы.