Модели приоритетов проекта реферат

Обновлено: 08.07.2024

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

Участников типового проекта разработки ПО можно условно разделить на пять групп ролей:

1. Анализ. Извлечение, документирование и сопровождение требований к продукту.

2. Управление. Определение и управление производственными процессами.

3. Производство. Проектирование и разработка ПО.

4. Тестирование. Тестирование ПО.

5. Обеспечение. Производство дополнительных продуктов и услуг.

У программного проекта имеется четыре фактора, которые определяют его успешность:

1. Выполнен в соответствие со спецификациями.

2. Выполнен в срок.

3. Выполнен в пределах бюджета.

4. Каждый участник команды уходил с работы в 18:00 с чувством успеха

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

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

Устав проекта [1] — документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта.

В российской практике данный документ чаще называется Концепция проекта. Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.

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

Приоритет любого проекта должен определяться на основе оценки трех его характеристик:

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

· Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны.

· Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.

· Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

· Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.

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

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

Шкала оценки стратегической ценности проекта может иметь следующий вид:

· Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет.

· Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года.

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

· Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.

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

Примерная шкала оценки уровня рисков проекта может иметь следующий вид:

· Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

· Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе.

· Выше среднего. Цели проекта недостаточно четки. Задачи системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы.

· Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе, в отношении которой крайне мало ясности. Технологии имеют неподтвержденную стабильность.

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

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

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

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

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

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

1. О характере задачи

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

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

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

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

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

Если мы к примеру знаем, что у Ивана Ивановича есть уроки математики в 10 классе, то это не даёт нам никакой информации о уроках русского в этом ж классе.

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

2. Можно ли её решить полным перебором

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

Для начала сформулируем задачу более точно.

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

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

Понедельник Вторник Среда
Первый урок 1 2 3
Второй урок 4 5 6

И пусть занятий только шесть. Пустые клетки это вакансии. Мы их пронумеровали, чтобы увидеть простой факт: хотя сетка вакансий и прямоугольная вакансии можно выстроить в простой ряд. Пронумеруем также и занятия А1, А2, А3, А4, А5, А6. Тогда задача поиска необходимого варианта расписания заключается в получении всех перестановок из 6 элементов. Известно же, что из N элементов можно получить N! = 1*2*3*4…. *N перестановок, то есть в нашей задаче 6! =1*2*3*4*5*6 = 720. А для реального набора данных, например в 50 занятий число перестановок вообще получается астрономическим. Кроме того, необходимо помнить, что количество вакансий в реальных задачах больше количества занятий, а стало быть даже не очень объёмная задача теории расписания требует ресурсов суперкомпьютера.

Небольшое, но важное дополнение.

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

Что же делать?

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

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

А - Множество занятий

а - Занятие

В - множество вакансий

в - Вакансия

(а, в) - допустимая пара расписания, то есть пара не противоречащая требованиям налагаемым на расписание.

Вполне возможно, что для элемента а существует несколько допустимых пар расписания. А если это возможно для элемента а, то следовательно возможно и для элемента в. Таким образом можно ввести ещё два важных понятия:

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

Ав - множество все элементов а которые могут участвовать в допустимых парах расписания с элементом в.

Тогда расписанием назовём такое множество допустимых пар расписания в котором каждый элемента множества А присутствует ровно один раз.

Таким образом, расписание это элемент множества всех множеств допустимых пар. А составление расписания тогда математически сводится к поиску нужного элемента среди уже упомянутого множества всех множеств допустимых пар (обозначим его как D).

3. Множество D

На первый взгляд оно устроено беспорядочно. Однако это не так: возьмём какой-либо элемент этого множества d. Он представляет собой множество допустимых пар. Совершенно очевидно, что для данного элемента существует (и быть может не один) элемент d' отличающийся от d на одну пару и при этом d> d'. скажем тогда, что элементы d и d' связаны между собой отношением следования d ® d'. Очевидно, что каждый элемент множества D связан отношением хотя бы с одним элементом. Если теперь, мы расположим элементы множества D на плоскости и те элементы которые находятся между собой в отношении следования соединим стрелками, то получим связный ориентированный граф. Это для тех кто знает, что такое связный ориентированный граф. Если кто не знает, то пусть не расстраивается, для нашей задачи не важно как это называется, важно представить себе эту картинку. А выглядит она примерно так.


Тогда процесс поиска элемента d являющегося расписанием есть ничто иное как путь вдоль стрелок ведущий к искомому элементу.

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

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

Расписание уже составлено.

Расписание не составлено, но для некоторых элементов а нет ни одного элемента в. Будем называть дальше эту ситуацию тупиком.

Мы сможем ускорить процесс поиска расписания, если мы научимся определять тупиковый путь или нет не проходя его, иначе говоря мы должны научится делать

4. Прогноз тупика

В начале пути по графу каждый элемент а имеет непустую область определения Ва иначе процесс поиска расписания можно было бы и не начинать. Построение очередной пары расписания (переход в следующий узел графа) означает уменьшение множества В на одну вакансию и уменьшение областей определения некоторых элементов множества А . Предположим на некотором шаге у а1 область определения состоит из 10 элементов в, а у а2 область определения состоит из одного элемента в.

Если на следующем шаге область определения а2 уменьшится на 1 то весь процесс зайдёт в тупик. То есть можно сформулировать очевидное утверждение: Наибольшую угрозу завести процесс в тупик представляют те элементы а у которых область определения наименьшая. А отсюда возникает хорошая и совершенно очевидная идея.

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

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

Предположим, что в области Ва содержится два элемента в1 и в2 при этом Ав1 ( область определения в1 ) содержит два элемента а и Ав2 содержит пять элементов а. Это означает, что если мы возьмём для очередной пары расписания элемент в1 то мы уменьшим на 1 область определения у двух элементов а, если же мы возьмём в2 то мы уменьшим область определения у 5 элементов а. Думаю, критерий выбора в уже понятен и осталось записать общий алгоритм разработки расписания.

Рассчитать все области определения Ав

Рассчитать все области определения Ва

Пока А не пусто делать

Определить очередной а ( элемент множества А с наименьшей областью определения)

В области определения а определить очередной в ( элемент множества В с наименьшей областью определения)

Составить очередную пару расписания (очередной а, очередной в )

Вычеркнуть "очередной а " из областей определения всех в которые входят в область определения "очередного а"

Вычеркнуть "очередной в " из областей определения всех а которые входят в область определения "очередного в"

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

Заключение

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

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

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

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

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

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

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

Третья проблема. Все рассуждения приведённые выше исходят из того, чтоб области определения элементов а могут только уменьшаться на 1. Но это не так. Приведём пример.

Пусть к расписанию предъявлено следующее требование "У десятого А класса в расписании не должно быть дыр". И пусть на некотором шаге для этого класса был поставлен урок "Понедельник 2 урок каб.11". Это означает, что все вакансии "Понедельник 4 урок" будут запрещены так как это создаст дырку.

Однако, если окажется заполненной вакансия "понедельник 3 урок" то вакансия "понедельник 4 урок" опять станет доступной. Из этого следует, что область определения может изменяться скачкообразно, как в сторону уменьшения так и в сторону увеличения.

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

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

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

Литература

1. Вострикова З.П. и др. "Программирование на языке "БЕЙСИК" для персональных ЭВМ". Машиностроение, 1993г.

2. Гохман А.В. и др. "Сборник задач по математической логике и алгебры множеств", издательство Саратовского Университета, 1969г.

3. Гусев В.В. Основы импульсной техники.М. Советское радио, 1975

4. Касаткин В.Н. "Информация, алгоритмы, ЭВМ", М. Просвещение, 1991г.

5. Машовцев В.А. Вступительные экзамены по информатике // Информатика. 1997, №13

6. Орлов В.А. О вступительных экзаменах по информатике // Информатика, 1997, №15

7. Яснева Г.Г. Логические основы ЭВМ // Информатика и образование, 1998, №2

8. Лыскова В.Ю., Ракитина Е.А. Логика в информатике, М. Информатика и образование 1999

9. Шауцкова Л.З. “Решение логических задач средствами алгебры логики”, газета Информатика 1999, №5.


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

Управление приоритетами проектов в настоящее время выделяется в самостоятельную тенденцию ИТ-менеджмента, обособляясь от управления проектами. Разница между этими двумя областями управления существенная: управление приоритетами происходит ДО, а управление проектами - ПОСЛЕ начала работы над проектом. Управление приоритетами проектов концентрируется на том, каким проектам отдать предпочтение, до того как запустить их. Управление проектами вступает в силу уже после того, как данный проект или серия проектов получили полномочия к выполнению. Выделение управления приоритетами проектов в отдельную область управления связано с тем, что для настоящего этапа развития ИТ характерно серьезное повышение роли планирования во всех областях управления. Компании, которые не уделяют этой дисциплине достаточного внимания, завалены десятками проектов, цели и задачи которых часто конфликтуют друг с другом. Неспособность компании толком приоритезировать проекты в ИТ-отделе является одной из наиболее распространенных причин неэффективности ИТ-отделов

Дарвинизм в управлении проектами

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

Управление приоритетами (Demand Management and Project Prioritization, DMPP) представляет собой метапроект, выполняемый ИТ-директором с целью определить последовательность выполнения ИТ-проектов. В рамках этого метапроекта ИТ директор учитывает и инвентаризирует все текущие и планируемые проекты, оценивает усилия по выполнению проектов, доходы и расходы, легкость выполнения, риски, ожидаемые результаты и соответствие требованиям существующей системы. В конце концов ИТ-директор должен прийти к соответствующим образом приоритезированному списку проектов и решить, сколько проектов может реально находиться в одновременном выполнении.

Почему хорошего управления проектами недостаточно?

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

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

Проблема № 4. Гибкость в осуществлении проектов. Увы, но нередки случаи изменения целей ИТ-проекта по мере выполнения проекта. И это не вопрос плохой организации управления проектами. Это насущная необходимость, связанная с изменениями в бизнесе компании по ходу ИТ-проекта. В течение этого времени многие факторы изменяются и начинают влиять на значимость и жизнеспособность данного проекта. Бизнес-ситуация, технологии, набор сотрудников, управление компанией - все может поменяться, изменив и значимость проекта. Проблему эту пытались решить самыми разными способами. На сегодняшний день практика показала, что можно добиться качественного выполнения проектов и в то же время сохранить определенную гибкость и чувствительность к переменам. Однако это связано с изменением приоритетов ИТ-проекта и соответственно с практикой управления приоритетами проектов.

Симптомы отсутствия управления приоритетами

Этапы управления приоритетами проектов

Рассмотрим основные этапы в процессе управления приоритетами проектов.

Этап № 1. Список всех потенциальных проектов. Первый шаг в практике управления приоритетами проектов состоит в том, чтобы описать все потенциальные проекты, которые должны поступить в работу в ИТ-отдел. Чаще всего это длинный список, который не так просто составить, ведь запросы на проекты поступают из огромного количества источников, разбросанных по компании. Хорошим началом будет создание реестра проектов ИТ-отдела. Все проекты, включая любые текущие задачи апгрейдов оборудования или ПО, должны быть собраны и добавлены в один мастер-список проектов. Как правило, ИТ-отделы имеют один или более списков проектов, находящихся в работе или в состоянии рассмотрения в настоящее время. Интервью с менеджерами отделов компании и топ-менеджментом компании помогают выяснить, какие еще проекты могут требовать выполнения.

После того как данный список создан, его надо оптимизировать, совмещая маленькие проекты с более крупными. Опыт показывает, что большинство первоначальных списков содержат более не спонсируемые или уже не соответствующие запросам компании проекты. Эти реликты тоже надо удалить из списка. Как это ни парадоксально, но для ИТ-отделов типична ситуация, когда проект держится в списке активных, даже если никто уже и не помнит, почему он туда попал. Такая оптимизация списка, как правило, уменьшает его на 60-70%.

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

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

Этап № 3. Утверждение проектов. Каждый проект, определенный согласно вышеизложенной схеме, должен быть представлен для предварительного одобрения менеджменту компании, которому подчинен ИТ-отдел. Данное одобрение не означает, что проект сразу же запускается в дело. Оно только показывает, что проект одобрен для детального анализа и участия в процессе управления приоритетами. Именно на этом этапе определяется количество ИТ-проектов, которые будут находиться в одновременной разработке в ИТ-отделе. В связи с тем, что процессы приоритезации достаточно затратны по объему работ, окончательно принятое количество ИТ-проектов, к которому придет ИТ-директор, должно быть очень серьезно продумано. Только действительно важные и неотложные проекты должны попасть в список одобренных. Количество и размер проектов, которые могут находиться в одновременной работе в ИТ-отделе, называется проектной мощностью ИТ-отдела. Вдумчивый анализ проектной мощности ИТ-отдела гарантирует, что число проектов, находящихся в одновременной работе, будет соответствовать как возможностям ИТ-отдела, так и способности организации адаптировать перемены.

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

Проектная мощность

Приоритезация ИТ-проектов

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

Приоритезация не является каким-то однократным актом, а представляет собой продолжающийся процесс. После того как приоритезация проектов проведена, ее изменение должно быть произведено в одном из трех случаев:
1. Когда существующий проект завершен, и высвобождается проектная мощность ИТ-отдела.
2. Когда в ИТ-отдел добавлены новые проектные мощности или сокращены существующие, то есть изменено общее количество одновременно разрабатываемых ИТ-проектов.
3. Если выявлен высокоприоритетный проект, который по важности перевешивает имеющиеся в разработке в настоящее время. Это случай исключительный и редко встречающийся, но иногда он имеет место, например, если ключевые заказчики требуют изменений в связи с правительственными регулированием.

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

Управление приоритетами проектов и последовательностью работ взаимосвязанных проектов на примере ОАО ( реферат , курсовая , диплом , контрольная )

Содержание

  • ВВЕДЕНИЕ
  • ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ВЗАИМОСВЯЗАННЫХ ПРОЕКТОВ
    • 1. 1. Ключевые понятия и инструменты Управление проектами
    • 1. 2. Отличительные признаки проектно-зависимых и проектно-ориентированных компаний
    • 1. 3. Особенности управления при взаимосвязанности проектов
    • 2. 1. Организационно-экономическая характеристика деятельности проектно-зависимой компании
    • 2. 2. Разработка параметров формирования портфелей и программ компании
    • 2. 3. Организация работы фронт-офиса мультипроектного управления

    10 008 003,97276,321.

    210 010 000,88265,131.

    331 012 062,59062,741.

    464 111 563,37897,951.

    610 512 106,67517,3Итого35 367,419519,3Таким образом, чистый дисконтированный доход равен 19 519,3тыс.

    руб., а DPP =(20 500−7276,3−8265,1)/ 9062,7+1год = 1,5года, PI = (8003,9/1,1 + 10 000,8/1,21 +12 062,5 /1.3310+11 563,3/1.4641+12 106,6/1,6105) /20 500 =1,95%.ТАБЛИЦА9Исходные данные для расчета показателей Год

    Ден.поток (тыс. руб.)r=20%NPV1r =30%NPV2r = 40%NPV30- 205 001,000- 205 001,000−205 001,000- 2 050 018 003,90,8 336 667,250,7 696 154,990,7 145 714,78210000,80,6 946 940,560,5 925 920,470,5 105 100,41312062,50,5 796 984,190,4 555 488,40,3 644 390,75411563,30,4 825 573,510,3 504 047,160,2 603 006,46512106,60,4 024 866,850,2 693 256,680,1 862 251,8310532,364 367,7−35,77IRR = 30 + (4367,7/(4367,7+35,77))*(40−30) = 39,9%, таким образом, внутренняя норма окупаемости данного проекта составила 39,9%.Расчет предельных значений проекта, согласно прогнозному балансу и бюджету доходов и расходов. ТАБЛИЦА10Прогнозные значения доходов и расходов по проекту Показатель (в тыс. руб.)

    0-й1-йДоход от реализации проектных мероприятий -7276,3Начальные затраты -800-Трудовые издержки —5685

    Материальные издержки —3899

    Прочие издержки—3593Wtr — коэффициент дисконтирования: Wtr = [((1+r)n-1)/r (1+r)n], так С учетом среднегодовых доходов и расходов для ставки дисконтирования 18% и 5 — летнего горизонта инвестиций коэффициент дисконтирования составит Wtr (t = 1, 2 …, n; r) = Wtr (5;18%) =3,12 717. (Р +8003,9 — 5685 — 3899 — 3593) (1−0,20)] Wtr (4; 18) — 800 = 0;(0,80Р -4138,48)3,12 717 -800= 0;2,50 1736P =13 741,7;P = 5493тыс.

    руб.Представленное решение уравнения свидетельствует, что для проекта КСУП значение NPV станет нулевым в случае, когда доходы снизятся до 5493тыс.

    руб. (базовое значение Р = 7276,3 руб.). Таким образом, был выполнен расчет чувствительности проекта внедрения проекта к изменению среднегодового бюджета проектной деятельности компании, который показывает, что проект продолжает генерировать положительные денежные потоки при уменьшении среднегодового бюджета от планового уровня не более 32%.При снижении бюджета более чем на 32% для рентабельного функционирования проектного офиса должны быть снижены затраты на его содержание. Сгруппируем полученные данные коммерческой эффективности в таблице 10. Таблица 11Итоговые показателикоммерческой эффективности проектных мероприятий

    Чистый дисконтированный доход (ЧДД) или (интегральный эффект Эи), тыс. р.19 519,3Индекс рентабельностиPI, %1,95Внутренняя норма доходностиIRR, %39,9Дисконтированный срок окупаемости, годы1,5Уровень риска низкий, так как цели проекта и требования хорошо поняты и документированы, масштаб и рамки проекта заданы четко, а ресурсы требуемой квалификации доступны в полном объеме. К тому же разрабатываемые проектные мероприятия не потребуют новой технологической платформы.

    2.3. Организация работы фронт-офисамультипроектного управления

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

    Определение и утверждение вех и результатов проекта

    Утверждение устава, графика финансирования

    Общий надзор и анализ результатов проектной деятельности

    Заключение

    договоров с контрагентами;

    Утверждение лимитов финансирования проекта, прочих ограничений

    Утверждение состава команды проекта

    Распределение мотивационного фонда проекта

    Разрешение спорных вопросов (арбитражные функции) Приемка результатов проекта

    Принятие решений по стратегическим вопросам реализации проектов

    Обеспечение проекта ресурсами

    Согласование предложений по составу команды проекта

    Внесение изменений в проект (в зависимости от категории проекта) Обеспеченность проекта ресурсами (финансы, персонал, материалы и технические средства) Контроль основных вех проекта

    Разработка Устава и календарного плана проекта

    Формирование предложений по составу команды проекта

    Оперативное управление проектом;

    Мотивация команды проекта

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

    Перераспределение ресурсов проекта

    Внесение изменений в проект (в зависимости от категории проекта и уровня изменений) Вынесение предложений вышестоящим органам о внесении изменений в проект

    Достижение запланированных результатов проекта

    Соблюдение сроков выполнения работ календарного плана Контроль расходов бюджета проекта Качество выполняемых работ Контроль работы подчиненных

    Оформление и корректировка календарного плана и уставных документов проекта

    Мониторинг выполнения календарного плана

    Требовать информацию от членов команды проекта о состоянии дел по проекту

    Регулярный мониторинг проекта

    Соблюдение плана коммуникаций между членами команды проекта

    Соблюдение регламента документооборота проекта Прочие участники команды проекта (функциональные специалисты) Участие в реализации проекта в рамках прямых функциональных обязанностей;

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

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

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

    Во главе данной организационной структуры стоит Внутренний Заказчик проекта (Генеральный директор). В его прямом подчинении:

    Руководитель фронт — офиса;

    — Руководители функциональных подразделений;

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

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

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

    3.Определение частных требований к ролевым компетенциям

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

    4.Подбор кандидатов в команду проекта по каждой роли

    По каждой роли в команде проекта проводится выбор кандидатов согласно порядку назначения участников проекта 5. Собеседование с сотрудниками — кандидатами в команду проекта

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

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

    ЦелеполаганиеПланирование и контроль проекта

    Принципы работы с командой

    Основные стандарты по управлению проектами

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

    Разрешение конфликтов и проблем

    СамоконтрольОриентация на результат, а не на процесс

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

    Организация проектной отчетности

    Принципы проектного документооборота

    Решение административных задач

    Предметные функциональные знания

    Основы управления проектами

    Планирование функциональных задач

    Работа в матричных структурах

    ГибкостьКак и было упомянуто ранее, для реализации проектных мероприятий характерна матричная организация управления, поскольку матричные структуры применяются для реализации проекта в рамках однойкомпании и в том случае, если нужно управлять несколькими проектами одновременно, как и есть в нашем случае. С целью полноценной горизонтальной интеграции на вертикальную функциональную структуру компании накладывается проектно-целевая структура, при этом образуется матричная организационная структура, применимая для исследуемых проектных мероприятий, построенана рисунке 16Рисунок 16 — Матричная структура управления проектами ОАО «АК ТРАНСАРО"В нашем исследовании для проектной реализации наиболее подходит слабая матричная структура управления проектами, даннаяматричная структура характеризуется тем, что руководитель проекта имеет небольшие права и полномочия, в проекты привлекается небольшое количество организационных ресурсов компании, руководитель проекта не функционирует на постоянной основе, а также не обладает собственным штатом. Таблица 14Порядок назначения ролей в управлении проектом№Роль

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

    Срок назначения1Заказчик (внутренний)ГД——2Члены проектного комитета

    Заместители ГДГенеральный директор

    Приказ о составе

    Приказ о приеме на работу-4Куратор проекта

    Члены ПК, начальники отделов

    Приказ о запуске проекта Фаза проекта «Концепция"5Руководитель проекташтатный руководитель проекта

    Приказ о запуске проекта

    Фаза проекта «Концепция"6Администратор проекта

    Штатная должность ПОГенеральный директор

    Куратор проекта, Руководитель проекта

    Приказ о запуске проекта

    Фаза проекта «Концепция"7Главный предметный специалиструководитель проекта Генеральный директор

    Куратор проекта, Руководитель проекта

    Устав проекта (орг.

    структура);Приказ об организации работ

    8Прочие функциональные исполнители

    Куратор проекта, Руководитель проекта

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

    — Модернизировать электронные сервисы, прежде всего сервисов электронной коммерции и сервиса отношений с клиентами, предполагаемый расчет затратна проект 10млн.

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

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

    ЗАКЛЮЧЕНИЕ

    1. Описаны ключевые понятия и инструменты Управление проектами;

    2. Обозначены отличительные признаки проектно-зависимых и проектно-ориентированных компаний;

    3. Охарактеризованы особенности управления при взаимосвязанности проектов;

    4. Дана организационно-экономическая характеристика деятельности проектно-зависимой компании;

    5. Разработаны параметры формирования портфелей и программ компании;

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

    — Модернизировать электронные сервисы, прежде всего сервисов электронной коммерции и сервиса отношений с клиентами, предполагаемый расчет затратна проект 10млн.

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

    Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОГРАММОЙ Москва Стандартинформ2011 2. ГОСТ Р 54 869―2011

    Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОММосква Стандартинформ20 113. ГОСТ Р 54 870―2011

    Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПОРТФЕЛЕМ ПРОЕКТОВМосква Стандартинформ20 114

    Руководство к Своду знаний по управлению проектами (Руководство PMBOK). Четвертоеиздание, 2008.

    5.Балашов, А. И. Управление проектами: учебник для бакалавров / А. И. Балашов , Е. М.

    Рогова, М. В. Тихонова , Е. А. Ткаченко ; под ред. Е. М. Роговой .

    Богданов, В. В. Управление проектами. Корпоративная система — шаг за шагом / Вадим Богданов. — М.: Манн, Иванов и Фербер, 2012. — 248 c.

    8.Володин В.В."Повышение эффективности межотраслевой диверсификации с использованием проектного управления" — М.: ИНИОН РАН, 20 059

    Мазур И.И., Шапиро В. Д. , Управление проектамиМ.: ИНФРА-М, 201 010

    12.Мартин П., Тейт К. Управление проектами / Пер. с англ. —- СПб.: Питер, 2006.

    В. Современная команда менеджмента проекта. :

    16. ISO21500, подготовленный ПроектнымкомитетомISO/PC 236.

    17.PMI PMBOK Guide 4th EditionРуководство к своду знаний по управлению проектами (четвёртое издание), издательство: ProjectManagementInstitute, Inc., 2010. — 241с. Дополнительная литература:

    1.Арчибальд Р. Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд; Пер. с англ. Мамонтова Е. В. ; - 3-е изд., перераб. и доп. — М.: Компания АйТи; ДМК Пресс, 2006.-472 с.

    2.Структуризация проектов. Мир управления / под ред. Х. Решко, Х.Шелле.

    Богданов В. В. Управление проектами в MicrosoftProyect: Учебный курс.

    СПб.:Питер, 20 064

    5.Бухалков М. И. Внутрифирменное планирование. Учебник. М: ИНФРА-М. 2006 г.

    6.Мирзоян Н. В. Управление стоимостью проекта. Учебное пособие. М.МФПА.2007г.

    7.Управление проектами. Справочник для профессионалов. Под ред. И. И. Мазура и В. Д. Шапиро . 2001 г. Интернет -ресурс:

    ФазаУправленческий документ по проекту

    Роли по управлению проектами

    ИнициаторВнутренний заказчик (ГД)Проектный комитет

    Главный предметный специалист

    Руководители функциональных подразделений

    Зам.ГД по финансам

    Сотрудники функциональных подразделений

    КонцепцияПроектная инициатива1РУС2РУС3Предварительный бюджет1РУС2РУС3Приказ о запуске проекта (в т.ч. о назначении РП)1ИУР2ИУР3УРПредварительный календарный план1РУС2РУС3Разработка

    Устав проекта1УССРИ2УССРИ3УССРИКалендарный план проекта1УСССРИИС2УССРИИС3УССРИИССтруктура продукта проекта1ССУРИ2ССУРИ3ССУРИСДР проекта1УСРС2УСРС3УСРСМатрица ответственности по проекту1СРИ2СРИ3СРИПлан-график платежей1УСРИСС2УСРИСС3УСРИССЛимитная карта проекта1УССРИ2УССРИ3УССРИПлан-график поставок1УСИСР2УСИСР3УСИСРБюджет доходов и расходов (БДР) проекта1УСCРИРСС2УСCРИРСС3УСРИРССБюджет движения денежных средств (БДДС) проекта1УСCРИРСС2УСCРИРСС3УСРИРССПлан-график контрактов1УРИСИ2УРИСИ3УРИСИПлан по вехам проекта1УCСРИ2CУРИ3CУРИРеализация

    План работ на неделю по календарному плану1РИ2РИ3РИПлан работ на неделю по протоколам1РИ2РИ3РИПовестка совещания1РИ2РИ3РИПротокол совещания1СР2СР3СРЗапросы на изменения*1УУИРСР2УУРИСР3УУРИСРСводный отчет по протоколам1СРИИ2СРИИ3СРИИСтатус-отчет по проекту1РИ2РИ3РИФактическая справка по календарному плану1СРИ2СРИ3СРИРеестр документов проекта1Р2Р3РРеестр внесенных изменений по запросу1СР2СР3СРЗакрытие

    Реестр совещаний и рабочих встреч1СР2СР3СРПриказ о закрытии проекта1УСРИ2УСРИ3УСРИИтоговый отчёт по проекту1УССРИ2УССРИ3СУРИАрхив управленческих документов по проекту1ССР2ССР3ССРПриказ о премировании команды проекта1УССР2УССР3УССРВ таблице использованы следующие буквенные обозначения:

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

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

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

    У — утверждает, т. е. рассматривает документ в последнюю очередь и принимает решение о придаче ему статуса документа, регламентирующего процесс управления проектом. Приложение 2Приложение 3Перечень основных форм по проекту

    Приказ о запуске проекта Устав проекта

    Календарный план работ по проекту

    Структура продукта проекта

    Структурная декомпозиция работ проекта

    Матрица ответственности в проекте

    План-график платежей по проекту

    Лимитная карта проекта

    План-график поставок проекта

    Бюджет доходов и расходов по проекту

    План-график контрактов План по вехам

    План работ по календарному плану (на неделю) План работ по протоколам (на неделю) Запрос на изменение в проекте

    Читайте также: