Основные, необходимые, желаемые

Материалы для прочтения

 

Дерево проблем

 

Наглядно-методический инструмент «Дерево проблем» используется для визуального отображения логики процесса причинно-следственного анализа проблем на уровне республики, отрасли или региона.

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

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

Рекомендуемая организация процесса построения дерева проблем имеет следующую структуру:

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

На втором этапе участниками определяются непосредственные причины возникновения главной проблемы, которые также записываются на карточках и закрепляются на доске в горизонтальные ряды под карточкой с главной проблемой. Карточки соединяются с главной проблемой схематическими стрелками. Количество карточек, принимаемых модераторами от одной заинтересованной стороны, целесообразно не ограничивать. Когда каждая заинтересованная сторона выразит свое мнение проводится групповое обсуждение, в ходе которого исключаются повторяющиеся и близкие по смыслу карточки. Рекомендуемое максимальное количество непосредственных причин главной проблемы – 5-7. При наличии большего количества возможно возникновение технических трудностей на последующих этапах логико-структурного анализа. Как показывает практика, в результате плодотворных обсуждений и использования более емких формулировок возможно снижение количества непосредственных причин главной проблемы с 15-20 до 5 и менее. Однако следует помнить, что нельзя производить подобное сокращение в ущерб качеству самого процесса логико-структурного анализа, так как это негативно отразится на эффективности разрабатываемого проектного документа. Результатом данного этапа должны стать два заполненных уровня диаграммы «Дерево проблем» - уровень главной проблемы и уровень непосредственных причин главной проблемы.

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

· недостаточное / отсутствующее финансирование

· недостаток подготовленных кадров

· недостаток / отсутствие / устаревание оборудования, систем, проектного обеспечения или материалов

· пробелы / отсутствие законодательной базы.

Количество карточек, принимаемых модераторами от одной заинтересованной стороны (или участника проектной группы, который анализирует ее проблемы), здесь также не ограничивается. Однако, до помещения карточек в область построения диаграммы целесообразно сократить их количество путем изъятия повторяющихся или близких по смыслу формулировок. Данный процесс должен инициироваться и управляться модераторами. При этом, модераторы должны обеспечить соблюдение логической связи между всеми карточками. Необходимо четко соблюдать принцип иерархии проблем: на более высоком уровне всегда размещается следствие проблемы, на более низком – ее причина. Другими словами, из построенной диаграммы должно быть однозначно видно, какие проблемы привели к возникновению главной проблемы, каковы причины возникновения этих проблем и так далее до самого нижнего уровня. Каждая карточка должна соединяться схематической стрелкой, направленной к той карточке, причиной которой она является (стрелки идут от причин к следствиям). Результатом работы по данному этапу должно стать заполнение всех нижних уровней дерева проблем.

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

· сдерживание экономического развития;

· ухудшение социальной обстановки, снижение уровня жизни населения.

Результатом работы по описанным выше этапам построения дерева проблем должна стать законченная многоуровневая диаграмма, наглядно иллюстрирующая логические связи между главной проблемой, ее причинами и последствиями. Схематически завершенное дерево проблем изображено на рис. 1..1., 1.2. Следует заметить, что на практике количество промежуточных уровней между главной проблемой и первопричинами, а также главной проблемой и ее конечным следствием может достигать 8-10, в связи с чем ограничение участников разработки по количеству уровней диаграммы «Дерево проблем» является нецелесообразным.

 

Рис. 1. Дерево проблем.

 

 

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

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

Самая трудная часть данной работы – правильно структурировать анализ: какие проблемы ведут к появлению других и каких именно проблем, какая существует взаимосвязь между всеми проблемами и выявленными угрозами? Другими словами, что является причиной и что следствием? Будет непросто нарисовать полную картину, воссоздающую цельную социально-экономическую ситуацию в регионе с помощью одного внутренне увязанного, логичного и теоретически корректного дерева проблем. Даже глубокие экономические исследования не всегда в состоянии дать ответы на эти вопросы. Однако если объединить в одной команде нужных людей разных специальностей и разного положения, и к тому же обладающих информацией, то заключительная картина не будет отражать нереальную ситуацию. В любом случае это будет картина ситуации, которую признают все участники, которые впоследствии будут в той или иной степени отвечать за решение проблемы.

 

 

Цели по SMART

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

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

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

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

S – Specific (специфичность)	Цель нужно описать простыми словами, чтобы была понятна уникальность продукта. Необходима конкретика, чтобы можно было сравнить результат проекта с целью.
M – Measurable (измеримость)	Цель должна быть измерима количественно. Необходимо в цели задать основополагающие параметры запланированного результата, чтобы в ходе реализации проекта можно было проводить анализ при помощи графиков, статистики.
A – Appropriate (уместность)	Цель должна быть уместной, актуальной в данное время и соответствовать перспективам организации.
R – Realistic (реалистичность)	Реалистичность цели означает реальную возможность достижения цели с ресурсами, имеющимися в организации и техническим прогрессом.
T – Timebound (ограниченность во времени)	В цели указываются временные рамки проекта, т.е. дата начала и окончания проекта.

Рис. 1.3 Таблица SMART

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

Явные и неявные

Цели участников проекта

1. Основные цели – это те цели, ради достижения которых собственно и затевался проект. В свою очередь необходимые – подцели, выполнение которых необходимо для того, чтобы выполнить основные. Желаемые – это те улучшения, которых мы можем добиться попутно с выполнением основных целей, но которые не являются приоритетными. То есть, если мы их не достигнем, то (в отличие от двух других видов) это никак не скажется на успехе проекта. Бонус, другими словами. Деление целей на основные, необходимые и желаемые нужно для того, чтобы в процессе реализации проекта верно концентрировать основные усилия и ресурсы проекта. Иначе мы рискуем тем, что начнем разбрасываться на мелочи, а основную задачу проекта так и не выполним.

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

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

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

 

Дерево целей

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

· Общая цель(и) - цель проекта более высокого уровня, вклад в который данный проект предназначен внести.

· Цель(и) проекта вклад проекта в достижение общей цели путем использования результатов проекта.

· Результаты проекта - те значимые выходные продукты, которые получат пользователи проекта по его завершении.

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

 

При формулировании целей важно обеспечить их:

· Реальность - возможность достижения в рамках заданных ресурсов и ограничений (финансовых, физических, временных, др.).

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

· Измеримость - возможность количественной оценки при приемлемой затрате средств и усилий.

Важно четко разграничить цели, результаты и действия и соответственно определить области ответственности, в частности, менеджеров проекта. При их определении исходят из их управляемости со стороны менеджера (ов) проекта, что в свою очередь зависит от предположений, заложенных в проект и присущих ему рисков. Менеджер (ы) проекта несет ответственность за эффективное использование ресурсов и достижение результатов и не может нести прямую ответственность, например, за использование предоставляемых проектом услуг. Но он может осуществлять в течение определенного периода мониторинг связанных с этим рисков и допущений и тогда имеет смысл включитьнеобходимость указанного мониторинга в формулировку результатов проекта. Пример. В одном из проектов ТАСИС по оказанию содействия системе высшего образования на менеджера проекта возлагается ответственность за результат проекта в виде "приобретения слушателями организованных курсов знаний" вместо просто "организации курсов" или "обучения 200 слушателей. Аналогично следует поступать и при формулировке целей проекта. Их достижение предусматривает использование результатов проекта получателями, что находятся вне возможностей непосредственного контроля со стороны менеджмента проекта. Но он должен осуществлять мониторинг имеющихся при этом допущений и факторов риска.

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

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

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

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

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

Рис. 2. Преобразование проблем в цели

 

Рис. 3. Дерево целей.

Декомпозиция

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

Рисунок 1.8 Пример иерархической структуры работ, организованной по фазам

Рисунок 1.9 Пример иерархической структуры работ для элементов оборонного комплекса

 

Рис. 1.6 Окружение проекта

К ключевым участникам любого проекта относятся:

Менеджер проекта. Лицо, ответственное за управление проектом.

Заказчик/пользователь. Лицо или организация, которые будут использовать продукт проекта. Иногда заказчик и пользователь совпадают, в то время как в других под потребителем подразумевается юридическое лицо, получающее продукты проекта, а под пользователями – тех, кто будет непосредственно использовать продукт проекта.

Исполнитель. Исполняющая организация, чьи сотрудники непосредственно участвуют в исполнении проекта.

Члены команды проекта. Группа, которая выполняет работы по проекту.

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

Спонсор. Лицо или группа лиц, предоставляющая финансовые ресурсы – деньгами или в натуральном выражении (оборудование, помещения) – для проекта.

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

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

Следует учитывать, что каждый участник (их группа) по-своему заинтересованы в проекте, что может породить конфликт интересов.

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

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

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

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

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

 

		Влияние
		Слабое	Среднее	Сильное
Отношение	Положительное
Нейтральное
Отрицательное

Рис. 1.7 Матрица влияния

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

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

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

Планирование мероприятий

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

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

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

Таблица 7. План-график действий.

Месяцы (недели) Действия

Разработка сценария…

х

Проведение переговоров

х

х

Таблица 8. План работ.

Задача	Подзадача	Ответственный	Сроки	Результат	Риски

 

Планирование рисков

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

- Что может помешать выполнению задачи?

- С какими возможными последствиями мы можем столкнуться в результате реализации данных рисков?

Материалы для прочтения

 

Дерево проблем

 

Наглядно-методический инструмент «Дерево проблем» используется для визуального отображения логики процесса причинно-следственного анализа проблем на уровне республики, отрасли или региона.

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

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

Рекомендуемая организация процесса построения дерева проблем имеет следующую структуру:

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

На втором этапе участниками определяются непосредственные причины возникновения главной проблемы, которые также записываются на карточках и закрепляются на доске в горизонтальные ряды под карточкой с главной проблемой. Карточки соединяются с главной проблемой схематическими стрелками. Количество карточек, принимаемых модераторами от одной заинтересованной стороны, целесообразно не ограничивать. Когда каждая заинтересованная сторона выразит свое мнение проводится групповое обсуждение, в ходе которого исключаются повторяющиеся и близкие по смыслу карточки. Рекомендуемое максимальное количество непосредственных причин главной проблемы – 5-7. При наличии большего количества возможно возникновение технических трудностей на последующих этапах логико-структурного анализа. Как показывает практика, в результате плодотворных обсуждений и использования более емких формулировок возможно снижение количества непосредственных причин главной проблемы с 15-20 до 5 и менее. Однако следует помнить, что нельзя производить подобное сокращение в ущерб качеству самого процесса логико-структурного анализа, так как это негативно отразится на эффективности разрабатываемого проектного документа. Результатом данного этапа должны стать два заполненных уровня диаграммы «Дерево проблем» - уровень главной проблемы и уровень непосредственных причин главной проблемы.

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

· недостаточное / отсутствующее финансирование

· недостаток подготовленных кадров

· недостаток / отсутствие / устаревание оборудования, систем, проектного обеспечения или материалов

· пробелы / отсутствие законодательной базы.

Количество карточек, принимаемых модераторами от одной заинтересованной стороны (или участника проектной группы, который анализирует ее проблемы), здесь также не ограничивается. Однако, до помещения карточек в область построения диаграммы целесообразно сократить их количество путем изъятия повторяющихся или близких по смыслу формулировок. Данный процесс должен инициироваться и управляться модераторами. При этом, модераторы должны обеспечить соблюдение логической связи между всеми карточками. Необходимо четко соблюдать принцип иерархии проблем: на более высоком уровне всегда размещается следствие проблемы, на более низком – ее причина. Другими словами, из построенной диаграммы должно быть однозначно видно, какие проблемы привели к возникновению главной проблемы, каковы причины возникновения этих проблем и так далее до самого нижнего уровня. Каждая карточка должна соединяться схематической стрелкой, направленной к той карточке, причиной которой она является (стрелки идут от причин к следствиям). Результатом работы по данному этапу должно стать заполнение всех нижних уровней дерева проблем.

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

· сдерживание экономического развития;

· ухудшение социальной обстановки, снижение уровня жизни населения.

Результатом работы по описанным выше этапам построения дерева проблем должна стать законченная многоуровневая диаграмма, наглядно иллюстрирующая логические связи между главной проблемой, ее причинами и последствиями. Схематически завершенное дерево проблем изображено на рис. 1..1., 1.2. Следует заметить, что на практике количество промежуточных уровней между главной проблемой и первопричинами, а также главной проблемой и ее конечным следствием может достигать 8-10, в связи с чем ограничение участников разработки по количеству уровней диаграммы «Дерево проблем» является нецелесообразным.

 

Рис. 1. Дерево проблем.

 

 

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

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

Самая трудная часть данной работы – правильно структурировать анализ: какие проблемы ведут к появлению других и каких именно проблем, какая существует взаимосвязь между всеми проблемами и выявленными угрозами? Другими словами, что является причиной и что следствием? Будет непросто нарисовать полную картину, воссоздающую цельную социально-экономическую ситуацию в регионе с помощью одного внутренне увязанного, логичного и теоретически корректного дерева проблем. Даже глубокие экономические исследования не всегда в состоянии дать ответы на эти вопросы. Однако если объединить в одной команде нужных людей разных специальностей и разного положения, и к тому же обладающих информацией, то заключительная картина не будет отражать нереальную ситуацию. В любом случае это будет картина ситуации, которую признают все участники, которые впоследствии будут в той или иной степени отвечать за решение проблемы.

 

 

Цели по SMART

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

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

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

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

S – Specific (специфичность)	Цель нужно описать простыми словами, чтобы была понятна уникальность продукта. Необходима конкретика, чтобы можно было сравнить результат проекта с целью.
M – Measurable (измеримость)	Цель должна быть измерима количественно. Необходимо в цели задать основополагающие параметры запланированного результата, чтобы в ходе реализации проекта можно было проводить анализ при помощи графиков, статистики.
A – Appropriate (уместность)	Цель должна быть уместной, актуальной в данное в