Computerworld, США

Руководители, финансирующие разработку информационных систем, нуждаются в методах оценки таких проектов по мере продвижения от замысла к реализации. Предлагаемый контрольный список вопросов можно использовать для оценки хода выполнения любого ИТ-проекта.

Качество проекта

В первые две—шесть недель задайте себе и руководителю проекта следующие вопросы.

Какова бизнес-цель проекта? Не более чем в двух предложениях опишите действия, которые компания собирается предпринять, и желаемые результаты этих действий. Это цель, предполагаемый конечный результат проекта. Уясните его во всей полноте или остановите проект.

Каковы требования к системе? Сформулируйте их по четырем направлениям.

  • Бизнес-операции.
  • Ожидания клиентов.
  • Экономическая эффективность.
  • Повышение квалификации сотрудников и совершенствование работы компании.

Это основные критерии, помогающие определить, будет ли информационная система иметь успех. Убедитесь в том, что вы с разработчиками одинаково их понимаете.

Уверены ли вы в том, что информационная система, удовлетворяющая перечисленным требованиям, достигнет бизнес-цели, к которой вы стремитесь? Если, на ваш взгляд, какие-то важные требования не были учтены, добавьте их прежде, чем ИТ-проект сколько-нибудь продвинется вперед, но удостоверьтесь, что добавлены лишь требования, абсолютно необходимые для достижения бизнес-цели. Слишком широкие требования повысят сложность системы и снизят вероятность ее успешной реализации.

Опирается ли новый проект на ИТ-инфраструктуру компании? Новая информационная система должна использовать преимущества уже работающих систем и процедур. Она должна быть сфокусирована на предоставлении новых возможностей вместо простой замены существующих. Если вы решаете заменить все и строить на пустом месте, вы должны быть готовы к значительным дополнительным расходам времени и средств, убедитесь в их оправданности.

Распадается ли общий проект на отдельные подсистемы, каждая из которых имеет самостоятельную ценность? Большие информационные системы на самом деле состоят из нескольких подсистем, каждая должна разрабатываться независимо от остальных. Таким образом, если одна из подсистем столкнется с проблемами, вы сможете продолжить работу над другими. По мере готовности подсистем они должны как можно скорее вводиться в эксплуатацию, чтобы оправдать расходы на свое создание. Если все подсистемы должны быть закончены прежде, чем какая-либо из них может быть запущена в работу, это очень рискованный проект, построенный по принципу «все или ничего». Пересмотрите проект.

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

Доказал ли лидер проекта, что его менеджерские и технические навыки соответствуют требованиям проекта? Если у вас нет квалифицированного руководителя, проект потерпит неудачу из-за плохого менеджмента. Коллективное руководство успеха иметь не будет. Если лидер проекта не обладает необходимыми навыками руководства и проектирования, его следует заменить, независимо от его квалификации в других областях.

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

Прогресс в разработке информационной системы

По мере того как ИТ-проект проходит свои стадии, задайте себе, руководителю и участникам проекта несколько вопросов.

Соблюдаются ли план и бюджет проекта? Обращают ли сотрудники внимание на план? Есть ли в проекте административная группа, которая обеспечивает постоянные и точные обновления плана и бюджета? Многомиллионные проекты вовлекают множество специалистов и занимают значительный отрезок времени. План проекта — это основной инструмент координации, который точно говорит каждому человеку, что он предположительно должен делать в каждый момент времени.

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

Ведется ли разработка подсистем в соответствии с четко определенными стадиями проектирования и реализации? Завершаются ли эти стадии вовремя и в рамках бюджета? Проектная группа, работающая над отдельной подсистемой, может потратить от одного до трех месяцев на создание детального проекта и прототипа системы (стадия проектирования). Детальный проект должен затем в течение двух-шести месяцев превратиться в рабочую систему (стадия реализации). Если времени тратится больше, значит, проект движется слишком вяло и скоро окончательно потеряет импульс и ляжет в дрейф. За организацию и своевременное выполнение работ отвечает руководитель проекта. Удостоверьтесь, что этот человек обладает необходимыми способностями.

Как применяются тактические принципы выполнения проектов? Верите ли вы ответам, которые вы слышите? Может ли руководитель ИТ-проекта дать четкие объяснения, не прибегая к техническому жаргону? Квалифицированный человек способен дать вам прямые ответы. Руководитель проекта в действительности является подрядчиком, выполняющим работу. От него зависит успех или провал проекта. Если нужно, подыщите ему замену.

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

Компетентность и убежденность исполнителей

Задайте следующие вопросы себе, руководителю и участникам проекта.

Каковы спецификации проекта? По мере того как каждая проектная группа заканчивает свою стадию проекта, попросите их показать вам спецификации проекта, диаграммы потоков работ, логическую модель данных для своей подсистемы, пользовательский интерфейс, технические архитектурные диаграммы и прототип системы. Могут ли они объяснить вам, какие выгоды принесет эта система с позиций анализа затрат и выгод? Имеют ли смысл спецификации проекта? Знают ли члены группы то, о чем говорят?

Разделяют ли члены проектной группы уверенность своих руководителей? Разделяют ли руководители групп уверенность руководителя проекта? Если разработчики имеют необходимые навыки и хороший проект, они будут уверены в том, что смогут построить информационную систему. Если кто-то не разделяет и не демонстрирует такую уверенность, значит, где-то есть проблема. Если сотрудники стараются присоединиться к проекту, это может служить признаком уверенности. Если они уходят из проекта или покидают компанию, это указывает на недостаток уверенности. Ждите провала проекта.

Фрагмент из книги Майкла Хьюгоса Building the Real-Time Enterprise: An Executive Briefing (John Wiley and Sons Inc., 2005). Публикуется с сокращениями с разрешения владельца авторских прав

Тактические принципы

  • Назначьте выделенного лидера проекта, возложите на него всю полноту ответственности и предоставьте соответствующие полномочия, освободив его от иных обязанностей.
  • Определите совокупность измеримых непересекающихся целей, необходимых и достаточных для достижения цели проекта.
  • Сформируйте проектные группы в составе от двух до семи человек, обладающих соответствующим набором деловых и технических навыков, поставьте им задачи и назначьте практичных руководителей.
  • Объясняйте, что делать, а не как.
  • Разбейте работу над проектом на задачи, на выполнение которых нужна неделя или чуть меньше, и добивайтесь получения полезных для бизнеса результатов с периодичностью 30-90 дней.
  • Убедитесь в том, что менеджеры бизнес-подразделений в тесном сотрудничестве с руководителем проекта и руководителями групп постоянно обновляют планы и бюджеты.

Стратегические принципы

  • Тщательно увязывайте ИТ-проекты с бизнес-целями.
  • Используйте сильные стороны имеющихся информационных систем.
  • Применяйте простейшую комбинацию технологий и бизнес-процедур для достижения возможно большего числа целей.
  • Структурируйте проект таким образом, чтобы обеспечить гибкость цикла разработки информационной системы.
  • Не старайтесь построить информационную систему, сложность которой превышает возможности организации.
  • После провала проекта не возобновляйте работы, используя тот же самый организационный подход или дизайн информационной системы.