Управление проектами разработки информационных систем: этапы, требования и контроль

Управление проектами разработки информационных систем — это организация работ по созданию или внедрению ИС от определения целей и обследования бизнеса до разработки, тестирования, запуска и сопровождения. В отличие от обычного IT-проекта, такой проект должен одновременно учитывать бизнес-процессы, требования пользователей, архитектуру системы, интеграции, данные, безопасность, обучение и переход к эксплуатации.

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

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

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

Что такое управление проектами создания информационных систем

Управление проектом создания информационной системы — это планирование, организация и контроль работ, ресурсов, требований, рисков и результатов, необходимых для разработки и запуска ИС.

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

Именно поэтому проект создания ИС находится на пересечении нескольких областей:

• управления проектами;
• бизнес-анализа;
• системного анализа;
• разработки программного обеспечения;
• архитектуры;
• управления данными;
• тестирования;
• информационной безопасности;
• управления изменениями.

В образовательных программах РАНХиГС управление проектами создания информационных систем рассматривается как отдельная область проектного управления, связанная с разработкой ИС, цифровой трансформацией и применением цифровых инструментов.

Чем проект создания ИС отличается от обычного IT-проекта

Обычный IT-проект может быть направлен, например, на обновление инфраструктуры, настройку сервиса или выполнение технических работ. Проект создания информационной системы предполагает формирование целостного решения, которое должно соответствовать определенной модели работы организации.

Поэтому в проекте создания ИС особенно важны:

1. обследование текущих процессов;
2. формализация требований;
3. согласование границ системы;
4. проектирование архитектуры;
5. интеграция с существующим IT-ландшафтом;
6. приемка результата пользователями;
7. подготовка организации к переходу на новую систему.

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

Этапы управления проектом создания и внедрения информационной системы

Проект создания или внедрения ИС проходит несколько связанных этапов. Точная последовательность зависит от методологии, типа системы и особенностей организации, но логика обычно остается одинаковой: понять задачу → определить требования → спроектировать решение → реализовать → проверить → внедрить → передать в эксплуатацию.

Жизненный цикл проекта разработки и внедрения ИС

Такой подход соответствует логике, которая используется в образовательных программах по управлению внедрением ИС: от постановки целей и планирования до разработки, стабилизации и внедрения.

1. Инициирование проекта информационной системы

Инициирование определяет, зачем организации нужна информационная система и какой результат должен быть получен.

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

Обычно фиксируются:

• цель проекта;
• задачи;
• ожидаемые результаты;
• границы проекта;
• заказчик;
• руководитель проекта;
• основные участники;
• предварительные сроки;
• бюджетные ограничения;
• ключевые риски;
• критерии успеха.

Что важно определить до начала разработки

Нельзя начинать разработку только с формулировки «нужно автоматизировать процесс».

Например, вместо:

«Разработать систему управления заявками»

лучше определить:

«Сократить время обработки внутренних заявок и обеспечить контроль прохождения каждой заявки от регистрации до закрытия».

Второй вариант дает проекту измеримый результат и позволяет определить, какие функции действительно нужны.

Результат этапа

На выходе должно быть понятно:

какую проблему решаем → для кого → каким результатом → в каких границах → за какой срок и при каких ограничениях.

2. Обследование организации и текущих процессов

Обследование показывает, как организация работает сейчас и какие проблемы должна решить новая информационная система.

На этом этапе специалисты изучают бизнес-процессы, документы, роли пользователей, существующие программы, источники данных и интеграции.

Особенно важно выявить не только формальные процессы, но и фактический порядок работы.

Например, регламент может предусматривать согласование документа через корпоративную систему, а на практике сотрудники сначала отправляют файл друг другу в мессенджере. Если не учесть этот сценарий, новая система может формально соответствовать регламенту, но оказаться неудобной для пользователей.

Что исследуют на обследовании

• бизнес-процессы;
• роли и полномочия;
• используемые информационные системы;
• документы и справочники;
• источники данных;
• ручные операции;
• точки передачи информации;
• интеграции;
• узкие места;
• дублирование данных;
• требования подразделений;
• ограничения инфраструктуры.

Главный результат обследования

Результатом становится описание AS-IS, то есть текущего состояния, и понимание того, каким должно быть целевое состояние TO-BE.

Это позволяет перейти от абстрактного запроса «создать систему» к конкретному проектному решению.

3. Формирование и управление требованиями к информационной системе

Требования определяют, что должна делать система и каким ограничениям она должна соответствовать.

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

Какие бывают требования к ИС

Условно их можно разделить на несколько групп.

Как правильно управлять требованиями

Требование должно быть однозначным, проверяемым и связанным с конкретным результатом проекта.

Например:

Плохо:

Система должна быть удобной.

Лучше:

Пользователь должен создавать заявку не более чем за пять последовательных действий.

Второй вариант можно проверить при приемочном тестировании.

Что делать с изменениями требований

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

Для каждого существенного изменения нужно определить:

• что именно меняется;
• почему изменение необходимо;
• какие функции затрагиваются;
• сколько дополнительных ресурсов потребуется;
• повлияет ли изменение на сроки;
• повлияет ли изменение на бюджет;
• какие требования или задачи придется изменить.

Так появляется управление изменениями, а не бесконтрольное расширение проекта.

4. Проектирование информационной системы

Проектирование отвечает на вопрос: как именно будет устроена система, чтобы реализовать согласованные требования.

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

В зависимости от проекта определяются:

• архитектура системы;
• компоненты;
• базы данных;
• интерфейсы;
• роли пользователей;
• интеграции;
• механизмы обмена данными;
• требования к инфраструктуре;
• механизмы безопасности;
• правила обработки данных.

Почему нельзя пропускать проектирование

Если сразу перейти от списка пожеланий к разработке, команда начинает самостоятельно интерпретировать требования. В результате разные специалисты могут реализовать одну и ту же бизнес-логику по-разному.

Проектирование создает общий технический контекст для аналитиков, разработчиков, тестировщиков и заказчика.

5. Разработка или настройка информационной системы

На этапе разработки создается программная часть системы или выполняется настройка готового решения.

Выбор подхода зависит от задачи.

Разработка с нуля

Подходит, когда:

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

Настройка готовой платформы

Подходит, когда:

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

Гибридный подход

На практике часто используется комбинация: базовые функции реализуются средствами готовой платформы, а специфические сценарии дополняются разработкой и интеграциями.

Главная задача управления на этом этапе — не контролировать каждую строку кода, а обеспечить выполнение согласованного объема работ, требований и критериев качества.

6. Управление интеграциями информационной системы

Интеграция определяет, как новая ИС будет обмениваться данными с другими системами организации.

Для корпоративных проектов этот этап часто становится одним из наиболее сложных, потому что новая система редко существует изолированно.

Она может взаимодействовать с:

• ERP;
• CRM;
• кадровыми системами;
• бухгалтерскими системами;
• системами электронного документооборота;
• корпоративными порталами;
• внешними API;
• базами данных;
• сервисами авторизации.

Что контролировать при интеграции

Руководителю проекта важно отслеживать не только факт наличия интеграции, но и ее работоспособность.

Нужно проверить:

1. какие данные передаются;
2. какая система является источником;
3. как часто происходит обмен;
4. в каком формате передаются данные;
5. что происходит при ошибке;
6. как контролируется повторная передача;
7. как защищается канал;
8. кто отвечает за каждую сторону интеграции.

Интеграционные задачи стоит выделять отдельно в плане проекта. Если оставить их «на потом», проблемы часто проявляются уже во время тестирования или запуска.

7. Тестирование информационной системы

Тестирование показывает, соответствует ли реализованная система требованиям и готова ли она к эксплуатации.

Тестирование нельзя сводить только к поиску программных ошибок. Для проекта создания ИС важно проверить соответствие системы бизнес-сценариям.

Что проверяют

• функциональность;
• пользовательские сценарии;
• интеграции;
• права доступа;
• обработку данных;
• ошибки и исключения;
• производительность;
• стабильность;
• соответствие требованиям;
• готовность к приемке.

Связь требований и тестов

Хорошая практика — обеспечить связь:

требование → задача → реализация → тест → результат приемки.

Такая трассируемость позволяет ответить на вопрос:

«Каким тестом подтверждено выполнение этого требования?»

И наоборот:

«Какое требование нарушает найденный дефект?»

Это особенно важно для крупных корпоративных систем, где десятки или сотни требований реализуются разными командами.

8. Внедрение информационной системы

Внедрение переводит систему из состояния готового программного решения в состояние реально работающего инструмента организации.

Именно здесь проект разработки превращается в организационное изменение.

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

В учебных программах по управлению внедрением ИС отдельно рассматриваются организационная структура проекта, участники, риски, качество и особенности перехода к новой системе.

Основные варианты внедрения

Пилотное внедрение. Система сначала запускается на одном подразделении, процессе или группе пользователей.

Поэтапное внедрение. Функциональность или подразделения подключаются последовательно.

Параллельная эксплуатация. Старая и новая системы некоторое время работают одновременно.

Полный переход. Организация одномоментно переводит пользователей на новую систему.

Выбор варианта зависит от критичности системы, количества пользователей, рисков и возможности остановить или ограничить старый процесс.

9. Обучение пользователей и управление изменениями

Обучение необходимо, чтобы пользователи могли выполнять рабочие операции в новой системе и понимали изменения в своих процессах.

Обучение должно соответствовать ролям.

Например:

• сотруднику нужна инструкция по созданию и обработке заявки;
• руководителю — контроль и согласование;
• администратору — настройка и управление доступами;
• проектной команде — контроль изменений и ошибок.

Кроме обучения, важно объяснить пользователям зачем меняется процесс.

Если новая ИС воспринимается только как дополнительный инструмент контроля, сотрудники могут продолжать вести собственные таблицы и дублировать данные.

Поэтому управление изменениями должно сопровождать проект не только в момент запуска, но и на предыдущих этапах.

10. Переход в эксплуатацию и сопровождение

Завершение разработки не означает автоматического завершения проекта.

После запуска необходимо обеспечить:

• поддержку пользователей;
• устранение выявленных ошибок;
• мониторинг работы;
• контроль интеграций;
• передачу документации;
• передачу системы ответственным за эксплуатацию;
• обработку запросов на изменения.

На этом этапе фиксируется, какие задачи относятся к проекту, а какие уже становятся частью регулярной эксплуатации.

Как контролировать проект разработки информационной системы

Контроль проекта должен охватывать не только сроки разработки, но и объем требований, качество, ресурсы, риски, интеграции и готовность пользователей.

Для этого руководителю проекта нужна единая картина состояния работ.

Что контролировать на каждом этапе

Какие показатели использовать

Набор метрик зависит от проекта, но полезно контролировать:

• процент выполнения работ;
• отклонение от плановых сроков;
• количество открытых критических задач;
• количество дефектов;
• количество изменений требований;
• долю выполненных требований;
• готовность интеграций;
• готовность пользовательского обучения;
• количество нерешенных рисков;
• готовность к приемке.

Главное правило: метрика должна помогать принимать решение. Не стоит собирать десятки показателей, если по ним невозможно понять, что делать дальше.

Какие документы нужны для управления проектом создания ИС

Документы проекта должны фиксировать решения, требования и результаты, а не создаваться исключительно ради отчетности.

Типовой набор может включать:

1. паспорт или устав проекта;
2. описание целей и границ;
3. план проекта;
4. результаты обследования;
5. требования к системе;
6. архитектурные и проектные решения;
7. реестр рисков;
8. реестр изменений;
9. план тестирования;
10. протоколы испытаний;
11. документы приемки;
12. инструкции пользователей;
13. эксплуатационную документацию;
14. отчет о завершении проекта.

Состав документов нужно адаптировать к масштабу и требованиям конкретной организации.

Как управлять требованиями, сроками и изменениями одновременно

Главная проблема крупных проектов ИС заключается в том, что изменения одного элемента затрагивают остальные.

Например:

изменение требования → дополнительная разработка → увеличение трудозатрат → изменение срока → изменение тестового плана → перенос внедрения.

Поэтому требования нельзя вести отдельно от проектного плана.

Практически полезно связывать:

требование → задачу → исполнителя → срок → результат → тест → приемку.

Так руководитель может быстро понять не только, что изменилось, но и какие последствия изменение вызвало для всего проекта.

Методологии управления проектами создания информационных систем

Для проектов разработки и внедрения ИС применяются разные подходы. Выбор зависит от стабильности требований, характера продукта, масштаба проекта и степени неопределенности.

Каскадный подход

Работы последовательно проходят основные стадии: требования, проектирование, разработка, тестирование и внедрение.

Подход удобен, когда:

• требования относительно стабильны;
• этапы необходимо формально согласовывать;
• проект требует большого объема документации;
• изменение требований дорого.

Agile

Agile подходит для проектов, в которых требования могут уточняться по мере разработки.

Работа организуется итерациями, а результат регулярно проверяется заказчиком или пользователями.

Преимущество — возможность получать обратную связь раньше.

Риск — потеря управляемости, если отсутствуют четкие цели, приоритеты и правила изменения требований.

Scrum

Scrum использует короткие итерации — спринты — и регулярную проверку результата.

Подход хорошо подходит для продуктовой разработки, когда команда постепенно уточняет функциональность.

Гибридный подход

Для корпоративных проектов создания ИС часто разумно сочетать разные подходы.

Например:

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

Выбор методологии должен следовать характеру проекта, а не наоборот.

Роли в проекте создания информационной системы

Успешное создание ИС требует взаимодействия бизнеса и технической команды.

В зависимости от масштаба проекта могут участвовать:

В небольшом проекте один специалист может совмещать несколько ролей.

Главное — заранее определить кто принимает решения, кто выполняет работу и кто отвечает за результат.

Типичные ошибки при управлении проектами информационных систем

Большинство проблем возникает не из-за отсутствия программного кода, а из-за ошибок в организации проекта.

1. Начало разработки без обследования

Команда сразу начинает реализовывать функции, не разобравшись в реальном процессе.

Последствие: переделки и рост объема проекта.

2. Размытые требования

Формулировки вроде «система должна быть удобной» невозможно нормально проверить.

Решение: переводить потребности в конкретные и проверяемые требования.

3. Отсутствие владельца требования

Если непонятно, кто утверждает бизнес-логику, решения постоянно пересматриваются.

Решение: назначать ответственных за ключевые группы требований.

4. Скрытые интеграции

Интеграции откладываются до конца проекта.

Последствие: система готова функционально, но не может полноценно работать в IT-ландшафте компании.

5. Неконтролируемое изменение объема

Каждое новое пожелание кажется небольшим, но в совокупности они существенно меняют проект.

Решение: использовать формальную процедуру управления изменениями.

6. Тестирование только перед запуском

Если ошибки обнаруживаются только в конце, времени на исправление остается мало.

Решение: проводить проверки на протяжении всего цикла разработки.

7. Игнорирование пользователей

Система технически готова, но сотрудники не понимают новый процесс.

Решение: подключать представителей пользователей к проекту заранее.

8. Разрозненная проектная информация

Задачи находятся в одном сервисе, документы — в другом, решения — в чатах, а отчеты — в таблицах.

Последствие: руководитель видит отдельные фрагменты проекта вместо целостной картины.

Какой инструмент использовать для управления проектом создания ИС

Инструмент управления проектом должен связывать задачи, сроки, документы, коммуникации, требования и результаты, а не просто показывать список задач.

Для небольшого проекта может быть достаточно таблицы и набора специализированных сервисов. По мере роста количества участников и зависимостей становится важнее единое рабочее пространство.

Современные ИСУП используют единое информационное пространство для планирования, контроля сроков, ресурсов, документов и проектных данных. Такой подход также описывается в материалах НИУ ВШЭ и российских методических материалах по проектному управлению.

Что должно быть в системе управления проектом ИС

Минимальный набор возможностей:

• управление задачами;
• иерархия проектов и задач;
• зависимости;
• контроль сроков;
• статусы и workflow;
• документы;
• комментарии и история решений;
• управление ролями;
• отчеты;
• контроль загрузки;
• интеграции;
• поиск проектной информации.

Для крупных проектов дополнительно важны:

• управление портфелем;
• API;
• интеграции с корпоративными системами;
• разграничение доступа;
• аудит изменений;
• on-premise-развертывание;
• инструменты аналитики.

Как использовать ИСУП в проекте создания информационной системы

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

Например, в одном рабочем контуре можно связать:

этап проекта → задачу → исполнителя → срок → документ → обсуждение → результат.

Это особенно полезно при разработке и внедрении ИС, где один результат зависит от нескольких команд.

В качестве примера единого рабочего пространства можно использовать Интабия Платформу: в ней доступны трекер с досками, бэклогами и workflow, документы, календарь, диск и конференции с транскрибацией и протоколами встреч. Платформа также предоставляет API для интеграции с CRM, ERP, внутренними порталами и другими сервисами.

Для IT-команд особенно полезна связка задач и проектного контекста: задачи и подзадачи, комментарии, вложения, связи и история изменений могут храниться в рабочем пространстве. На сайте Intabia также заявлен импорт из Jira с переносом задач, статусов, исполнителей, комментариев, вложений, связей и истории изменений.

При выборе конкретной системы важно оценивать не количество функций само по себе, а то, насколько инструмент поддерживает реальный жизненный цикл проекта создания или внедрения ИС.

Практический пример управления проектом создания ИС

Представим компанию, которая хочет создать внутреннюю систему управления заявками сотрудников.

Цель

Перевести обработку заявок из электронной почты и таблиц в единую систему.

Этап 1. Инициирование

Определяются:

• подразделения-участники;
• типы заявок;
• ответственные;
• сроки обработки;
• критерии успеха.

Этап 2. Обследование

Команда изучает:

• как заявки поступают сейчас;
• кто их обрабатывает;
• где возникают задержки;
• какие данные используются;
• какие системы необходимо подключить.

Этап 3. Требования

Формируются требования:

• создание заявки;
• маршрутизация;
• согласование;
• уведомления;
• контроль сроков;
• отчетность;
• интеграция с корпоративным каталогом пользователей.

Этап 4. Проектирование

Определяются:

• роли;
• структура данных;
• архитектура;
• интеграции;
• интерфейсы;
• правила доступа.

Этап 5. Разработка

Команда реализует базовый функционал и постепенно добавляет дополнительные сценарии.

Этап 6. Тестирование

Проверяются основные пользовательские сценарии и интеграции.

Этап 7. Пилот

Систему получают несколько подразделений.

Команда собирает обратную связь, исправляет ошибки и уточняет процессы.

Этап 8. Масштабирование

После успешного пилота система распространяется на остальные подразделения.

Такой подход снижает риск ситуации, когда организация одновременно переводит всех пользователей на решение, которое еще не прошло полноценную проверку.

Как понять, что проект создания информационной системы идет успешно

Проект можно считать управляемым, если руководитель в любой момент способен ответить на несколько вопросов:

1. Что уже сделано?
2. Что должно быть сделано дальше?
3. Какие требования реализованы?
4. Какие требования изменились?
5. Что сейчас блокирует работу?
6. Есть ли отклонение от сроков?
7. Какие критические риски существуют?
8. Какие интеграции готовы?
9. Какие дефекты остаются?
10. Готовы ли пользователи к внедрению?
11. Что необходимо принять заказчику?
12. Какие решения нужно принять руководству?

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

Чек-лист управления проектом разработки и внедрения ИС

Перед запуском проекта проверьте:

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

Частые вопросы

Что такое управление проектами разработки информационных систем?

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

Какие этапы включает проект создания информационной системы?

Основные этапы — инициирование, обследование, формирование требований, проектирование, разработка или настройка, интеграция, тестирование, внедрение, обучение и переход к сопровождению.

Чем отличается создание ИС от внедрения ИС?

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

На практике эти процессы часто являются частями одного проекта.

Какие требования предъявляются к информационной системе?

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

Что такое управление проектами внедрения информационных систем?

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

Как контролировать проект разработки ИС?

Контроль должен включать сроки, объем работ, требования, изменения, ресурсы, риски, дефекты, интеграции и готовность пользователей. Оптимально связывать задачи с требованиями, ответственными, сроками и результатами приемки.

Нужна ли ИСУП для проекта создания информационной системы?

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

Что такое информационная система управления проектами для цифрового проекта?

Информационная система управления проектами — это цифровой инструмент, который объединяет данные, задачи, документы, сроки, участников и результаты управления проектом. Для цифрового проекта такая система позволяет связать разработку, аналитику, тестирование, документацию и управленческий контроль в одном рабочем контуре.

Итоги

Управление проектами создания информационных систем — это не только контроль разработки программного обеспечения. Проект охватывает весь путь от постановки бизнес-задачи и обследования процессов до формирования требований, проектирования, разработки, интеграции, тестирования, внедрения и сопровождения.

Наиболее важные принципы можно свести к пяти правилам:

1. Начинайте с бизнес-задачи, а не с разработки.
2. Формализуйте требования до реализации и контролируйте их изменения.
3. Учитывайте интеграции и пользователей как часть проекта, а не как задачи «после разработки».
4. Контролируйте не только сроки, но и объем, качество, риски и готовность к внедрению.
5. Храните задачи, решения, документы и результаты в связанном информационном пространстве.

Именно такой подход позволяет превратить разработку или внедрение ИС из набора технических работ в управляемый бизнес-проект.