Управление проектами

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

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

2. Что такое управление проектами?

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

Причины неудачных проектов из-за управления проектами.

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

• неудовлетворенные или неопознанные потребности

• Неконтролируемое изменение масштаба проекта

• Лишняя стоимость

• задержки в доставке

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

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

Ответ на этот вопрос можно найти в двух основных источниках: недостатки в инструментах анализа и методах проектирования систем или плохое управление проектами.

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

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

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

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

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

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

Основные функции менеджера проекта

Менеджер проекта - это не просто опытный аналитик, который берет на себя управление проектом, а скорее должен применять другой набор методов и знаний, чем аналитик; Эти методы и знания, которые будут применены, следующие:

Основные функции менеджера проекта

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

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

Планирование задач проекта и выбор команды проекта

У хорошего режиссера всегда есть план. Директор оценивает потребности в ресурсах и формулирует план для достижения целевой системы. Это основано на знаниях директора о требованиях целевой системы на каждом этапе разработки. Базовым планом развития информационной системы является план жизненного цикла разработки системы. Многие компании имеют свой собственный стандартный жизненный цикл, а некоторые из них также имеют стандарты для методов и инструментов, которые будут использоваться.

Вот как должна быть спланирована каждая из задач, необходимых для завершения проекта:

• Сколько времени это займет? Сколько человек это займет? Сколько будет стоить задача? Какие задачи должны быть выполнены, прежде чем другие начнут? Могут ли некоторые из них перекрываться?

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

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

Организация и определение календарей для проекта

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

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

Управление проектом и контроль

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

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

3. Инструменты и методы управления проектами

PERT графика:

PERT, обозначающий Proyect - Program-Evaluation and Rewiev Technique (метод оценки и пересмотра проектов - или программ -), был разработан в конце десятилетия 1950 - 1959 годов для планирования и управления великими проектами развития вооружений армии. НАС. Он был разработан для демонстрации взаимозависимости задач проекта при их планировании. По сути, PERT - это техника взаимосвязанных графических моделей.

4. PERT определения и символы

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

«Событие (также называемое вехой) - это момент времени, который представляет начало или конец задачи или набора задач»

Чтобы проиллюстрировать события в диаграммах PERT, были использованы различные символы: круги, квадраты и тому подобное. В диаграммах PERT эти события часто называют узлами. Каждый узел делится на три раздела. Левая часть узла содержит идентификационный номер события. Это число обычно относится к легенде, которая явно определяет событие. Верхняя правая и нижняя правая части узла используются для записи максимального и минимального времени завершения события. Вместо того, чтобы быть датами, эти времена отсчитываются от TIME = 0, где 0 соответствует дате начала проекта. Все диаграммы PERT имеют начальный узел и конечный узел, который отмечает конец проекта.

На диаграмме PERT задачи (также называемые действиями) представлены стрелкой между узлами.

«Задача - это деятельность проекта (или набор действий)»

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

Пунктирная стрелка имеет особое значение. Это пустое задание.

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

Оценка требований времени проекта и разработка PERT

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

Требования времени проекта должны быть рассчитаны по смете. С оценкой это относится к тому, как это делается. Хороший системный аналитик менеджер проектов опирается на свои данные и опыт предыдущих проектов. Существуют продукты CASE, такие как SPQR / 20, которые могут помочь руководителям проектов лучше оценить время.

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

Факторы, влияющие на оценки:

• Размер команды проекта Опыт членов команды Количество конечных пользователей и менеджеров Отношение конечных пользователей Обязательства руководства Доступность конечных пользователей и менеджеров Текущие проекты

Чтобы рассчитать требования ко времени и нарисовать диаграмму PERT, необходимо выполнить пять шагов:

1. Составьте список всех задач и событий проекта

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

3. Оцените продолжительность каждого задания. Эта оценка сделана следующим образом:

a) Рассчитайте минимальное количество времени, которое потребуется для выполнения задачи, которое называется оптимальным временем (TO). Расчет TO предполагает, что даже самые вероятные прерывания или задержки не произойдут

б) Рассчитайте максимальное количество времени, которое потребуется для выполнения задачи, которое называется паршивым временем (TP). Расчет TP предполагает, что все, что может пойти не так, пойдет не так

в) Рассчитать наиболее вероятное время (TMP), которое будет необходимо для выполнения задачи

г) Рассчитайте ожидаемую продолжительность (SD) следующим образом:

4. Рассчитайте минимальное время завершения и максимальное время завершения (TmF и TMF) для каждой задачи.

5. Нарисуйте график PERT

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

Критический путь на диаграмме PERT

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

Использование PERT для планирования и контроля

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

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

Анализ Pert

Подход с использованием диаграмм PERT создает проблему применительно к разработке информационных систем, поскольку в этих диаграммах иногда предполагается, что одна задача должна быть завершена для запуска другой, но в реальном случае последняя задача Это может начаться наравне с первым или когда первый еще продолжается. Классические диаграммы PERT были разработаны для поддержки проектов, которые часто выполнялись с использованием подхода «сборочной линии». Но информационные системы не работают таким образом. Задачи разработки системы могут перекрываться; единственное, что должно произойти, это выполнение заданий. Не следует предполагать, что невозможно начать задание, пока не будет выполнено предыдущее.

Диаграммы Ганта

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

Как и диаграммы PERT, диаграммы Ганта основаны на графическом подходе. Диаграмма Ганта - это простая гистограмма. Каждый бар символизирует задачу проекта. Где горизонтальная ось представляет время. Поскольку эти диаграммы используются для объединения задач, горизонтальная ось должна включать даты. По вертикали и в левой колонке предлагается список задач.

Важным преимуществом диаграмм Ганта является то, что они четко иллюстрируют совпадение запланированных задач. В отличие от диаграмм PERT, диаграммы Ганта не очень хорошо показывают зависимость между различными задачами.

Как использовать диаграмму Ганта для планирования: чтобы создать график проекта с использованием диаграмм Ганта, сначала необходимо определить задачи, которые необходимо запланировать. Далее, продолжительность каждой задачи будет определяться с помощью методов и формул для соответствующей оценки времени. Если бы диаграмма PERT уже была подготовлена, задачи были бы определены, и, по крайней мере, должны быть определены взаимные зависимости между задачами, поскольку диаграммы Ганта не четко показывают эти зависимости, но обязательно, чтобы календарь планирования их распознавал. Тогда мы готовы планировать задачи.

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

Использование диаграмм Ганта для оценки прогресса проекта: одна из наиболее распространенных обязанностей менеджера проекта - отчитываться о ходе проекта перед его начальством. Диаграммы Ганта часто используются для отображения прогресса проекта, поскольку они могут удобно сравнивать исходное планирование с фактическим развитием. Чтобы сообщить о ходе проекта, конвекции диаграммы Ганта должны быть расширены. Если задача была выполнена, соответствующая полоса будет выглядеть темнее. Если это было только частично закончено, пропорциональная часть бара будет темнее. Процент затемненной полосы должен соответствовать проценту выполненной задачи. Более светлые столбцы символизируют задачи, которые еще не были начаты. Затем,вертикальная линия будет проведена перпендикулярно горизонтальной оси, и это обрежет ее в день дня. Затем можно оценить прогресс проекта.

Сравнение диаграмм Перт и Ганта

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

ИТ-менеджеры обычно предпочитают диаграммы Ганта за их простоту и возможность отображать график проекта. В пакетах программного обеспечения для управления проектами они объединяют лучшие функции PERT (особенно анализ критического пути), включенные в диаграммы Ганта. Когда задачи введены, их продолжительность и зависимости также включены. Бары Ганта планируются с течением времени, чтобы их зависимости учитывались. В общем, критический путь выделяется с большей интенсивностью. Кроме того, выделено количество простоев в некритических дорожных задачах.Эта презентация может доказать свою полезность при принятии решения о том, какие задачи будут отложены, чтобы компенсировать время выполнения задач, которые превышают ожидаемые сроки.

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

Примерами таких пакетов являются Project от Microsoft и Project Manager Workbench из Applied Business Technology. Эти пакеты значительно упрощают подготовку диаграмм PERT и Gantt, позволяя автоматически преобразовывать оба типа диаграмм. Программное обеспечение также позволяет менеджерам проектов выделять людские и финансовые ресурсы для выполнения задач, сообщать о ходе выполнения проекта и проводить тесты «если-то» при попытке изменить план проекта в результате отклонений графика.

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

Управление ожиданиями

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

Матрица управления ожиданиями

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

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

Приоритеты:

Максимизировать или минимизировать

-Ограничение

-Acceptance

Правила раскрываются в матрице управления:

-В любом проекте три знака х должны быть размещены в девяти доступных ячейках

-Нет строки должны содержать более одного х.

-Нет столбца должен содержать более одного х

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

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

Руководитель проекта никогда не должен устанавливать или даже предлагать эти приоритеты.

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

Применение матрицы управления ожиданиями

Предположим, у нас есть матрица управления ожиданиями в соответствии с вышеупомянутыми правилами. Как эта матрица может помочь нам управлять ожиданиями?

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

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

Когда мы сталкиваемся с изменениями в нашей матрице, есть несколько возможных направлений действий:

а) Ресурсы могут быть перераспределены (стоимость и / или график)

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

c) Можно уменьшить потребности пользователей (или качество), установив приоритеты среди этих потребностей и перенеся некоторые из них в версию 2 системы.

d) Наконец, можно изменить приоритетную меру, называемую приоритетной миграцией.

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

Управление людскими ресурсами

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

а) минутный менеджер

б) Тонкое искусство делегирования и ответственности

6. Заключение