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

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

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

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

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

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

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

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

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

Новые люди "безболезненно" подключаются к проекту на любой стадии разработки.

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

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

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

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

Четкая формулировка цели должна отвечать на вопросы: "Что система должна делать?"; "Была ли четко сформулирована цель создания системы?"; "Знает ли конечный пользователь, что система действительно должна делать?" Конечно, очень важно найти истинную цель приложения, чтобы иметь возможность определить границы проекта. Это необходимо сделать настолько быстро, насколько возможно.

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