Содержание

Трёхфазный ток, фаза и ноль – что это такое

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

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

Под завершение 2010-х годов у нас произошло важное событие, к которому мы довольно долго шли. Мы с женой купили старый полузаброшенный дом неподалёку от Москвы и стали его ремонтировать; работы там очень много, но по цене вариант был заметно интереснее и готового загородного коттеджа, и приличной городской квартиры.

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

Самые азы. Переменное напряжение. Сколько вольт в розетках.

Вообще фазой – вне электротехники – называют то, что описывает всякие колебания. Вот такие:

Это называют синусоидой. По горизонтали время, а по вертикали почти всё, что угодно. Угол отклонения маятника, уровень воды при прохождении волны, напряжение в сети…

В случае с электропроводкой колеблется напряжение в сети – поэтому возникающий при подключении чего-либо ток и называют переменным. Когда говорят, что в розетке 220 вольт – это не означает, что там постоянно 220 вольт. Нет, напряжение на самом деле непрерывно меняется с +310 до -310 вольт! А в какой-то момент оно вообще равно нулю; отрицательные значения соответствуют случаю, когда ток течёт “в обратную сторону”, то есть не туда, куда он тёк при положительном напряжении.

Вот уже не просто синусоида – какие угодно колебания – а синусоида переменного тока. По вертикали отмечено напряжение в вольтах:

Рисунок: Pieter Kuiper / Wikimedia

Если вы в США, то у вас напряжение такое, как показано красной линией. А в Беларуси, России, Украине и в большинстве стран мира – синяя линия.

Пресловутые 220 (на самом деле уже давно 230, если смотреть на картинку и на новый стандарт*) вольт – это так называемое

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

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

*) ГОСТ 29322-2014 в Беларуси и в России, CENELEC EN 50160:2010 в Украине; всё это по сути европейские стандарты.

Самые азы. Ремарка про напряжение.

Выше я писала про напряжение. Напряжение – это такая физическая величина, которая выражает – если цитировать Википедию – “работу по переносу заряда между теми точками, между которыми мы измеряем напряжение”. Слова про “перенос заряда” не случайны, так как электрический ток это поток заряженных частиц – как правило, электронов*. Чем больше переносится по проводу электронов, тем больше сила тока; а вот напряжение показывает то, какую работу может совершить ток. При малом напряжении точно такой же ток совершит меньшую работу, чем при напряжении побольше; сила тока измеряется в амперах.

*) если говорить о металлических проводах, а не о погружённых в банку с солёной водой электродах. В воде будут не только электроны, но и ионы. Ток внутри наших нервных клеток, кстати, тоже ионный.

Что такое “фаза” и где она в проводах. Для тока нужно два провода.

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

Скриншот из магазина “Петрович”. 2х4 означает “две жилы по 4 мм² каждая”, а ВВГ – это марка кабеля, расшифровывать которую я сейчас не буду.

По одной жиле ток пришёл, по второй ушёл. Затем напряжение поменялось и стало наоборот – в одну жилу ток “всосало”, из второй “высосало”. А потом снова поменялось – и так 50 раз в секунду, так как напряжение переменное и частота его 50 герц, 50 колебаний туда-сюда за секунду.

Самое важное место во всём тексте. Провод под напряжением относительно земли – это и есть фаза.

Напряжение, как я уже сказала, измеряется между двумя точками. Но ещё его можно измерять относительно земли – что, кстати, чаще всего и делают. 220 вольт* – это напряжение на

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

*) далее я буду говорить про действующее напряжение и не упоминать больше то, что оно меняется от -310 до +310 вольт.

Всё, что находится относительно земли под напряжением – называют “фазой”. Фазный провод – тот, где напряжение относительно земли не равно нулю. А где относительно земли ноль – это “ноль” и есть. Соединяем “фазу” с “нулём” какой-нибудь лампочкой – цепь замыкается и течёт ток, лампочка зажигается.

Ноль очень важно отделять от фазы на практике так, чтоб их нельзя было спутать. Синяя жила кабеля на фотографии предполагает, что там будет ноль. “Нулевые” провода можно, в принципе, брать за неизолированные участки руками – напряжение между ними и землёй должно в норме быть равным нулю и никакого удара током вы не получите. А вот “фаза” – однозначно ударит током, если вы ещё как-то будете прикасаться к земле, нулевому проводу или всему, что связано с землей проводящими ток частями.

Занимательная пауза: что будет при замыкании фазы с нулём.

Если замкнуть фазу на ноль (с этого места я перестаю заключать эти термины в кавычки), соединив провода напрямую – будет короткое замыкание. Через провода потечёт очень большой ток и сработают защитные устройства в щитке… после того, как у вас в руках как следует пыхнет и хлопнет.

Вот что бывает, если высоковольтная линия с очень высоким напряжением оказывается соединена с землёй неудачно выросшим деревом. Это вариант короткого замыкания. “Короткое” оно в силу того, что ток вместо “длинного” пути через какое-либо устройство идёт к земле (или к нулевому проводу – где такое же напряжение, как на земле) через что-то с гораздо меньшим сопротивлением, по “короткому” пути. И раз сопротивление меньше, то и ток много больше, причём в неподобающем месте.

Почему она “фаза” и что такое “трёхфазная система”.

Но почему провод под напряжением называется именно “фазой”? Откуда такое название? В самом начале я сказала, что фаза это такая физическая величина, которая описывает колебания, причём тут провода?

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

θ на графике ниже – называют сдвигом фаз.

Иллюстрация: Peppergrower / Wikimedia

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

Поэтому и говорят о трёхфазной системе электроснабжения. Снова рисунок:

Источник – кликабельно. Вместо времени по горизонтали показан так называемый фазовый угол. Когда он равен 0 или 360 градусов, колебания совпадают. А при 180 градусах – напротив, полностью противоположны, то есть находятся в противофазе.

Зачем нужны три фазы вместо одной.

Зачем это надо? Можно взять какой-то мощный котёл, станок на фабрике, мотор лифта или электровоз – и подключать их не между фазой и нулём, а между фазами.

Посмотрите – разница между линиями разного цвета оказывается часто гораздо больше, чем высота над уровнем нуля или глубина под ним! Напряжение (действующее) в 380 вольт, которое часто фигурирует в описаниях техники помощнее, берётся именно отсюда – из подключения между двумя фазами, каждая из которых может выдать всего 220. Между любой из фаз и землёй будут те самые 220 вольт, а между фазами – 380.

По трём проводам – трём фазам – можно передать втрое больше энергии, чем по паре “фаза-ноль”, хотя расход кабеля вырастёт всего с 2 до 3: выгода очевидна. А ещё всякие моторы с генераторами на три фазы делать тоже удобнее – но это отдельная история, которую тут затрагивать не стоит. Кроме того, я не буду говорить о системах, где не три фазы, а две – если вы не в США, не на британской стройке и не на шведских железных дорогах, вам с этим вряд ли придётся сталкиваться. Хотя уже понятно, что дают две фазы со сдвигом в 180 градусов – если измерять напряжение между ними (его, кстати, называют

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

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

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

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

Скриншот “Петровича”. Обратите внимание – уже 4 жилы и потому кабель вдвое дороже. Но мощности он позволяет передать втрое больше!

Три жилы для фаз, ещё одна для нуля. Далее ноль расходится по всем розеткам – обычным, тем, что с двумя дырочками – а вот фазы (провода, которые находятся под напряжением относительно нуля и относительно земли – напомню на всякий случай) делятся между розетками поровну так, что каждая розетка получает только одну фазу. Первая фаза, например, питает холодильник на кухне и розетки в спальне, вторая – розетки в кухне и свет в комнатах, третья – ванную со стиральной машиной, прихожую и свет на кухне.

Ток, питающий электрочайник, можно заставить работать в холодильнике!

Что это даёт, если всё равно в розетки включаются однофазные потребители? А вот что: от электрощитка расходится пучок кабелей – линий – с одним общим нулём и тремя фазами. Если это нарисовать, получится сначала так (рисунок мой):

Теперь смотрите – предположим, мы включили чайник, который питается от второй фазы. Часть пути тока:

Ток пришёл с фазы (для простоты, кстати, считается что он идёт именно так – хотя мы помним, что реально ток переменный) и ушёл на ноль. Но! Ноль того кабеля, который ведёт к розетке – той линии, которая питает этого потребителя – соединён с нулями остальных линий. А на фазе 1 и фазе 3 в тот момент, когда фаза 2 находится под максимальным напряжением, напряжение отрицательное. Потому что сдвиг фаз, снова смотрите картинку:

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

В итоге ток, питающий чайник, протекает заодно через холодильник, стиральную машину и вообще всё, что при этом подключено. И если нагрузка равномерно распределена по фазам – сбалансирована – то через нулевой провод вообще тока почти и нет. Но, разумеется, нет и чудес вида “мы заставили электроэнергию работать дважды” – то, что ток проходит через несколько потребителей, обеспечивается большим напряжением – между фазами ведь не 220, а все 380 вольт. Закон сохранения энергии тут (да и во всех иных местах) не нарушается.

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

Уточнение.

Я, разумеется, многое упростила. В курсах электротехники рассказывают больше и во многом корректнее – но эти курсы и рассчитаны на большее внимание и большее время освоения. А мой текст был для того, чтобы пояснить, что же такое “фаза” в розетке – и тут ответ “это провод, напряжение на котором относительно земли равно 220 вольт” мне кажется уместнее серии лекций с вопросами вида “пример рассчёта подключения генератора треугольником” или “особенности трёхфазных устройств защитного отключения”.

Ее величестве Науке посвещается, или Как два выпускника ПО и два выпускника ПЭ мерили фазу: kormitigrov — LiveJournal

Коллега на работе подошел с вопросом, знаю ли я как проводка устроена в квартире и как подключать люстру и выключатель, если и тот и тот имеют по три выхода. Разбирались как могли, а раскрытие свое тема получила позже, когда подошел другой коллега, выпускник ПЭ и человек склонный к долгим и скурпулезным спорам, что, впрочем, нисколько не умаляет его умения разбираться во всем электрическом. За долгими объяснениями, что такое трехфазный ток (а как же без этого к.т.н может объяснить, как подключать люстру?) всплыл один очень хитрый вопрос, мнения по которому разошлись просто полярно.
Вот в розетке 220В два провода, один называется фазой, а другой нулем. Что будет если замкнуть пальцами эти два провода – знают все, и на интуитивном уровне, и на теоретическом. Но вот что будет если взяться только за ОДИН провод? И вот здесь нас переклинило. Промэлектронщики как сговорившись рассказывали ужасные истории из своей жизни, когда они трогали фазу и их било током, приводили теоретические выкладки, объясняющие это явление, – а в голове у меня происходило столкновение теоретических идей, подкрепленных авторитетом специалистов-коллег, и интуитивного представления о том, что ток не может и не будет втекать и протекать по проводу в изолированный со всех прочих сторон металлический шар, которым я представлял себя.
Такое столкновение “интуитивно понимаемого” или “визуально наблюдаемого” с тем, что предсказывает текущепринятая теория, как мне кажется, является главным двигателем настоящего, обусловленного познания, в отличие от вызывающего скептицизм идеалистического мудрствования (впрочем, это только на мой дилетантский философский взгляд человека, последний раз сдавшего философию на 4, пусть отличники меня поставят на место). Короче, нельзя долго жить так, когда рассогласуется текущее теоретическое понимание вопроса, новое возможное теоретическое понимание того же вопроса и бытовой житейский опыт. Что-то одно должно уступить.
Собирая в кучу все опять-таки дилетантские познания физики, получаем набор следующих высказываний. Ток течет там, где есть замкнутая цепь и разность потенциалов. Однако течет он по-разному, – замыкаем ли мы розетку 220В, или, нашаркавшись тапочками о ковер, тыкаем пальцем в нос домочадцам. ПЭшники утверждали, что долбало их по первому сценарию, а не по второму. Но как и где там могла быть цепь, если они брались только за один провод? Довольно быстро пришли к общему мнению, что если браться за фазу, и при этом не браться на ноль, но при этом тебя что-то с этим нулем соединяет, – земля ли, ноги ли – то это все равно что браться за оба провода розетки, только еще хуже – ток пойдет через все тело. Но что если с нулем тебя все-таки ничего не соединяет? ПЭшники утверждали, что долбанет, но объяснение этому было только предложенное мной. Если взяться за провод с постоянным потенциалом, то часть электронов сразу забежит в тело, чтобы разницу уравнять, и на том все закончится. Сколько электронов забежит, как раз определяется емкостью тела человека. Но в случае если потенциал переменный, как в случае если взяться за фазу из розетки, то электроны сначала забегут в тело, а потом, когда фаза поменяется, побегут обратно, и так далее с частотой в 50 герц. А раз они будут туда-сюда бегать, вот и получим ток через палец, который держится за провод. Все определяется, конечно, емкостью тела и проводимостью пальца, но теоретически долбануть может, увы. Но как же тогда сидят птицы на проводах? Даже если считать, что держатся одной ногой, а не двумя, чтобы не сводить задачу к школьной задачке по физике – ведь по той же логике, их должно долбануть хорошенько. Или у них совсем маленькая емкость?
В общем, интуитивное понимание говорило о том, что долбануть не должно, но теоретические выкладки говорили о том, что долбануть может. Попробовать прямо на работе разрешить этот вопрос мне мешало чувство ответственности за коллег, у которых не ноутбуки, и которые могут потерять в результате таких физических опытов содержимое оперативной памяти.
К разборкам подключили других выпускников ПЭ, ЭЛА и АСУ, в конце концов вопросы задали широко известным в городе людям, имеющим отношение к электрике, и те со всей ответственностью заявили, что если стоять на резиновом коврике и не иметь отношение к нулю, то за фазу можно браться без боязни…

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

Теперь я знаю, как оно на самом деле. Нестроение было предотвращено.

Причины КЗ электропроводки | Алатырский район Чувашской Республики

Физический износ изоляции

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

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

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

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

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

Значительный перегрев изоляции кабелей

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

 

 

Прямое соединение фазного и нулевого проводов

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

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

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

Как предупредить короткое замыкание

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

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

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

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

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

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

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

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

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

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

Правильным выбором вида электропроводки и способа ее прокладки;

Соответствием вида электропроводки и характеристик используемых проводов;

Правильным выбором электрозащиты;

Удобная прокладка кабелей, способствует быстрой локализации очага пожара;

Монтаж электропроводки должен осуществляться специалистами.

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

ПОМНИТЕ: Единый телефон службы спасения – 01, 101, 112

Первоисточник: ОНДиПР по г. Алатырь и Алатырскому району УНДиПР Главного управления МЧС России по Чувашской Республике – Чувашии

Закрытие проекта или фазы

«Завершение проекта или фазы» – это процесс завершения всех действий для проекта, фазы или контракта.

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

Этот процесс выполняется один раз или в заранее определенных точках проекта.

Входы, инструменты, методы и выходы процесса показаны на Рисунке 4-14 »(PMBoK Guide p121).

Закрытие проекта – это не выключение компьютера. Еще многое предстоит сделать, и многое может пойти не так.

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

Напомню, что упомянутый здесь тип «фазы» – это мини-проект внутри основного проекта.

Действия, необходимые для административного закрытия проекта или фазы, включают:

  • Действия и действия, необходимые для удовлетворения критериев завершения или выхода для фазы или проекта, например:

    • Убедиться, что все документы и результаты актуальны и что все проблемы решены;

    • Подтверждение доставки и формальной приемки результатов заказчиком;

    • Обеспечение отнесения всех затрат на счет проекта;

    • Закрытие счетов проекта;

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

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

    • Перераспределение проектных помещений, оборудования и других ресурсов; и

    • Составление окончательных отчетов по проекту в соответствии с политиками организации.

  • Действия, связанные с завершением контрактных соглашений, применимых к проекту или фазе проекта, например:

    Следующее действие:

    • Подтверждение официального принятия работы продавца.Если работа не соответствует согласованному стандарту, продавец должен довести ее до уровня. Это часто вызывает споры, когда продавец пытается взимать плату за переделку в качестве «улучшения». Здесь вам нужно как можно более четко указать объем и требования к качеству. Но вы не можете придумать все.

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

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

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

      Его ответ был: «Это улучшение. Вы не указали, что не хотите, чтобы система производила нулевые платежи в случае невыполнения работ »

      Итак, никогда не предполагайте, что« здравый смысл »применим к контрактам.

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

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

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

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

  • Необходимые действия для:

    • Сбор записей проекта или фазы,

    • Аудит успешности или неудачи проекта,

    • Управление обменом и передачей знаний,

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

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

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

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

  • Измерение степени удовлетворенности заинтересованных сторон.

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

ЗАКРЫТЬ ПРОЕКТ ИЛИ ФАЗА: ВХОДЫ

  1. УСТАВ ПРОЕКТА

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

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

    Избегайте хлопот, укажите «офис», а не человека.

  2. ПЛАН УПРАВЛЕНИЯ ПРОЕКТАМИ

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

  3. ДОКУМЕНТЫ ПРОЕКТА

    Документы проекта используются в проекте, но не считаются частью плана управления проектом. Они могут включать:

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

      Но… в записях указано, что вы виноваты в сбое – уничтожение записей не вариант: D

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

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

    • Журнал ошибок. Снова к последней проверке, чтобы убедиться, что все проблемы решены.

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

    • Список вех. В списке вехи указаны окончательные даты, когда были достигнуты вехи проекта.

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

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

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

    • Требования к документации. Документация по требованиям используется для демонстрации соответствия объему проекта.

    • Реестр рисков. Реестр рисков предоставляет информацию о рисках, которые произошли на протяжении всего проекта.

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

  4. ПРИНЯТОЕ ДОСТАВКА

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

  5. БИЗНЕС-ДОКУМЕНТЫ

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

    Деловые документы включают:

    • Бизнес-кейс. Экономическое обоснование документирует потребности бизнеса и анализ затрат и выгод, который оправдывает проект. А теперь этап проверки обоснованности обоснования.

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

  6. СОГЛАШЕНИЯ

    В данном случае «соглашения» означают контракты, которые были выпущены для проекта и зарегистрированы в Плане управления закупками. Фактические требования для официального закрытия закупок включены в План управления закупками и могут быть проверены на соответствие условиям контрактов.

  7. ДОКУМЕНТАЦИЯ ПО ЗАКУПКАМ

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

  8. АКТИВЫ ОРГАНИЗАЦИОННОГО ПРОЦЕССА

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

    • Руководящие принципы или требования к закрытию проекта или фазы (например, извлеченные уроки, заключительные аудиты проекта, оценки проекта, валидация продукта, критерии приемки, закрытие контракта, перераспределение ресурсов, оценка работы команды и передача знаний).

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

ЗАКРЫТИЕ ПРОЕКТА ИЛИ ФАЗА: ИНСТРУМЕНТЫ И МЕТОДЫ

  1. РЕШЕНИЕ ЭКСПЕРТА

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

    • Управленческий контроль,

    • Аудит,

    • Юридические вопросы и закупки и

    • Законодательные и нормативные акты.

  2. АНАЛИЗ ДАННЫХ

    Методы анализа данных, которые можно использовать при закрытии проекта, включают:

    • Анализ документов. Это используется для извлечения информации для записи в «Извлеченные уроки».

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

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

  3. ВСТРЕЧИ

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

ЗАКРЫТЬ ПРОЕКТ ИЛИ ФАЗА: ВЫХОДЫ

  1. ОБНОВЛЕНИЕ ДОКУМЕНТОВ ПРОЕКТА

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

  2. ПЕРЕХОД КОНЕЧНОГО ПРОДУКТА, УСЛУГИ ИЛИ РЕЗУЛЬТАТА

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

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

  3. ЗАКЛЮЧИТЕЛЬНЫЙ ОТЧЕТ

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

    • Краткое описание уровня проекта или фазы.

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

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

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

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

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

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

    • Краткое изложение любых рисков или проблем, возникших в ходе проекта, и способов их устранения ».

    (Руководство PMBOK, стр. 127)

  4. ОБНОВЛЕНИЯ АКТИВОВ ОРГАНИЗАЦИОННЫХ ПРОЦЕССОВ

    Обновленные активы организационных процессов включают:

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

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

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

    • Репозиторий извлеченных уроков. Извлеченные уроки и знания, полученные в ходе проекта, сохранялись в реестре извлеченных уроков, но окончательная отредактированная версия теперь передана в репозиторий извлеченных уроков для использования в будущих проектах.

На этом мы подошли к концу проекта или фазы закрытия.

И это также конец модуля управления инициацией проекта

Следующий модуль – «Управление содержанием проекта»

Пожалуйста, прочтите соответствующую главу в Руководстве PMBoK перед просмотром видео.

Фаза закрытия проекта

– Массачусетский университет, Бостон,

На главную ›Услуги в области информационных технологий› Офис управления проектами ›Методология› Фаза завершения проекта

Обзор

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

Описание

Целью завершающей фазы в жизненном цикле управления проектом является подтверждение завершения результатов проекта к удовлетворению спонсора проекта, а также доведение окончательной позиции и статуса проекта до всех участников и заинтересованных сторон.Закрытие проекта гарантирует, что все участники и заинтересованные стороны проекта будут проинформированы о последующих действиях (например, о новых проектах, переходах между услугами, SLA и т. Д.), А также будут иметь достаточные возможности для общения и координации со связанными проектами и / или владельцами производственных услуг. Завершающие мероприятия должны также включать выявление и сбор извлеченных уроков и передовых методов, а также архивирование этих активов организационного процесса (OPA) в ServiceNow для последующего использования, организационного обучения и повторного использования.

Директор PMO может предоставить менеджерам проектов различные уровни услуг на заключительном этапе, включая:

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

Завершающие процессы Действия

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

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

  • За завершенный проект менеджер проекта несет ответственность перед:
  • Запланировать и провести встречу по закрытию проекта / извлеченным урокам
  • Заполните отчет о завершении проекта с участием проектной группы.Отчет подтвердит в письменной форме от спонсора проекта и / или заказчиков, что проект завершен.
  • Заполните контрольный список закрытия проекта
  • Заполните отчет о переходе службы (если применимо)
  • Проведите опрос удовлетворенности проектом (Приложение F) и проанализируйте результаты.
  • Закройте и деактивируйте проект в ServiceNow (обязательно)
  • Организуйте соответствующий праздник выполненной работы. Не забывай получать удовольствие! (Необязательно, но рекомендуется)

Результаты заключительной фазы:

Совещание по закрытию проекта

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

Если работа по проекту завершена:

  • Выполнили ли мы все согласованные цели в этом проекте? Было ли это доведено до сведения всех заинтересованных сторон проекта?
  • Какие дальнейшие действия потребуются для будущих проектов?
  • Как «ввести в действие» проект, чтобы обеспечить постоянную поддержку (при необходимости)? В конце заключительного этапа какая операционная группа возьмет на себя поддержку или администрирование продукта или услуги?
  • Какие уроки мы извлекли из этого проекта?
  • Знает ли команда проекта, что их тяжелый труд был оценен по достоинству?

Если проект был отменен или приостановлен:

  • Каковы причины отмены или приостановки проекта?
  • Есть ли планы возобновить проект в будущем?

Отчет о завершении проекта

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

Цели отчета о завершении проекта:

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

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

  • Процесс управления изменениями проекта
  • Оценка проекта
  • Ресурсы проекта (объем, график, бюджет, ресурсы)

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

Допуски

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

5 способов беспрепятственно завершить этап закрытия проекта

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

Почему важно закрытие проекта?

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

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

Как узнать, что проект завершен?

Это когда в вашем списке задач отмечены все пункты? Или маленькая полоса прогресса в вашем программном обеспечении для управления проектами светится зеленым светом, который кричит «100% выполнено»? Это когда клиенты или конечные потребители начали использовать результаты вашего проекта? Или это когда руководство поручает вам другой проект?

Короткий ответ: это может быть любой из них, и как вы определяете « сделано » .

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

Когда вы считаете проект успешным?

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

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

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

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

Может быть. Может быть нет.

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

5 шагов до закрытия проекта

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

1. Перенести все результаты

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

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

2. Завершить контракты

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

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

3. Проведите ретроспективную встречу

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

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

Задайте себе и своей команде следующие вопросы в дополнение к вышеупомянутым обсуждениям:

  • Хорошо ли мы поработали над прогнозированием и снижением рисков?
  • Есть ли идеи по улучшению существующего процесса?
  • Было ли что-то, что вы сделали бы по-другому?
  • Были ли компромиссы на этом пути?

4.Распустить команду

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

Уведомить внешних поставщиков и подрядчиков о завершении проекта. Также пора проверить незавершенные платежи и завершить закрытие закупок.

5. Задокументируйте все полученные знания

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

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

Отмечайте успех вместе со своей командой

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

А теперь откройте бутылку шампанского и наслаждайтесь успехом своего проекта!

Дополнительные ресурсы


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

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

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

Вот обзор каждого этапа и задействованных действий.

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

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

Взято из

Определите реальную проблему, которую нужно решить
Прежде чем вы начнете, найдите время, чтобы точно определить, какую проблему проект должен решить на самом деле.Это не всегда очевидно. Допустим, ИТ-директор вашей компании попросил вас, ИТ-менеджера, разработать новую базу данных и систему ввода данных. Возможно, вам захочется сразу же приступить к работе над проектом, чтобы решить проблемы, с которыми вы столкнулись из первых рук. Но решит ли это проблему компании? Чтобы повысить шансы проекта на успех, вы должны выйти за рамки наблюдаемых вами симптомов: «Мы не можем получить данные достаточно быстро» и «Мне нужно просмотреть четыре разных отчета, чтобы собрать обновленную информацию о недавних отчетах моих клиентов. деятельность »- найти основные проблемы, которые пытается решить организация.Перед проектированием базы данных вы должны спросить, какой тип данных требуется, что с ними будет делать, как скоро потребуется исправление и так далее. Если вы этого не сделаете, вы рискуете потратить зря время и деньги на создание слишком упрощенного, слишком сложного или слишком запоздалого решения или решения, не выполняющего то, что нужно пользователям.

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

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

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

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

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

  • Спросите: «Что нужно сделать, чтобы достичь X?»
  • Продолжайте задавать этот вопрос, пока ваш ответ не будет разбит на задачи, которые нельзя будет разделить дальше.
  • Оцените, сколько времени потребуется для выполнения этих задач и сколько они будут стоить в долларах и человеко-часах.

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

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

Качество = Время + Стоимость

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

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

Build-Up: как запустить проект

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

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

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

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

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

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

Составьте бюджет
Первый вопрос, который нужно задать при разработке бюджета: «Что потребуется, чтобы на самом деле выполнить работу?» Чтобы определить свои затраты, разбейте проект на следующие категории: персонал, командировки, обучение, расходные материалы, помещения, исследования, капитальные затраты и накладные расходы.

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

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

Реализация: как выполнить проект

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

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

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

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

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

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

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

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

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

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

Распродажа: как решать конечные вопросы

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

Оцените эффективность проекта
Перед закрытием проекта ваша команда должна достичь поставленных целей (или вместе с ключевыми заинтересованными сторонами определить, что эти цели больше не применяются). Сравните свой прогресс с объемом, о котором все договорились в начале. Это покажет вам, насколько хорошо проект выполнен – ​​и есть ли над чем поработать. Когда вы обсуждаете свои выводы с заинтересованными сторонами, убедитесь, что вы достигли с ними консенсуса в отношении того, насколько «завершен» проект.Держите прицел спереди и по центру, чтобы все использовали один и тот же критерий для измерения успеха.

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

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

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

Адаптировано из HBR Guide to Project Management ; содержание, первоначально опубликованное в Pocket Mentor: Managing Projects , Harvard Business Review Press, 2006.

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

Структурирование вашего проекта

Для всех проектов, кроме самых маленьких, опытные менеджеры проектов используют хорошо зарекомендовавшие себя методологии управления проектами. Это часто публикуемые системы, такие как PMBOK®️ Guide. (Свод знаний по управлению проектами) или PRINCE2 – но они также могут быть внутренними методологиями, специфичными для организации.

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

Это показано на рисунке 1 ниже.

Рисунок 1 – Структура управления проектом

В этой статье более подробно рассматриваются эти этапы и процессы. Если какой-либо из терминов, используемых в этой статье, вам незнаком, обратитесь к нашей статье Слова, используемые в … Управление проектами и программами. .

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

Этапы проекта

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

Вы определяете необходимые результаты для каждого этапа из Иерархической структуры работ. (WBS) за это. WBS составляется как часть ваших подготовительных мероприятий, а затем утверждается остальной частью проектной группы. В конце каждого этапа кто-то подписывает результаты этого этапа.(На этапе подготовки подумайте, кто должен утверждать каждый результат. Утверждающие могут включать совет проекта, спонсора проекта или ключевые заинтересованные стороны.) После утверждения результатов этап завершается, и команда проекта может пройти через «ворота». “к следующему этапу. Вот почему термин «этап / ворота» так часто используется в управлении проектами.

Подпишитесь на нашу рассылку новостей

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

Прочтите нашу Политику конфиденциальности

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

  • Стратегия проекта и бизнес-кейс.
  • Подготовка.
  • Дизайн.
  • Разработка и тестирование.
  • Обучение и бизнес-готовность.
  • Поддержка и реализация преимуществ.
  • Проект закрыть.

Давайте рассмотрим каждую фазу более подробно.

Стратегия проекта и экономическое обоснование

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

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

Совет:

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

Препарат

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

  • Завершите высокоуровневую иерархическую структуру работ .
  • Определите общий план проекта на уровне этапов . (Работайте с соответствующими членами проектной группы над составлением подробных планов на каждом последующем этапе. Это гарантирует, что у них есть чувство ответственности за эти планы.)
  • Определить и нанять участников проекта.
  • Создание документа об инициировании проекта .
  • Выберите третьих лиц для использования на ранних этапах проекта (например, ИТ-субподрядчиков или партнеров).
  • Принять меры для защиты ключевых ресурсов.(Например, зарезервируйте комнаты для этапа обучения и выделите столы и ПК / принтеры для команды проекта.)

Конструкция

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

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

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

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

Совет:

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

Разработка и тестирование

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

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

Обучение и бизнес-готовность

Этот этап посвящен подготовке к запуску проекта или его запуску.”На этом этапе выполните следующие действия:

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

Поддержка и реализация преимуществ

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

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

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

Закрыть проект

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

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

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

Ключевые процессы управления проектами, которые проходят через все эти фазы:

  • Фазовое управление.
  • Планирование.
  • Контроль.
  • Управление командой.
  • Связь.
  • Закупки.
  • Интеграция.

Рассмотрим каждый процесс более подробно.

  • Управление фазами – Здесь вы убедитесь, что вы в достаточной степени удовлетворяете условиям для завершения каждой фазы и для начала следующей. Для этого убедитесь, что вы полностью понимаете «ворота» или результаты, которые должны быть завершены и утверждены соответствующими заинтересованными сторонами, прежде чем вы сможете выйти из фазы. Конечные результаты и требования к утверждению обычно указываются в Документе об инициировании проекта. , так что просмотрите это соответствующим образом во время проекта.
  • Планирование – Выполните высокоуровневое планирование для всего проекта в начале проекта, затем выполните более подробное планирование для каждой фазы в начале каждой фазы. Убедитесь, что у вас есть нужные люди, ресурсы, методологии и вспомогательные инструменты для каждого этапа планирования, чтобы вы могли выполнить проект вовремя, в рамках бюджета и в соответствии с соответствующими стандартами качества.
  • Контроль – Необходимо контролировать объем , Стоимость , и вопросы ; и управлять временем, рисками , и преимущества эффективно.Создавайте отчеты, содержащие информацию, необходимую для создания точной картины того, как идут дела. Обычный способ сделать это – использовать панель управления проектом. .
  • Управление командой – Как руководитель проекта вы несете ответственность за управление командой проекта. Работа над проектом часто отличается от большинства «обычных» действий, и работа над проектом может потребовать другого подхода и набора навыков. Таким образом, вам, вероятно, потребуется специальное обучение и поддержка по управлению проектами.И есть дополнительные сложности в управлении членами команды, у которых одновременно есть обязанности по проекту, а также другие роли (см. Нашу статью об управлении кросс-функциональными командами. подробнее об этом).
  • Коммуникация – Убедитесь, что вы четко понимаете, кто отвечает за общение с членами команды, советом проекта, различными заинтересованными сторонами. внутри компании и у соответствующих третьих лиц. Неадекватное общение – частая проблема для проектов, и для хорошего общения требуется значительное внимание.

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

  • Закупки – Это специализированная область. Многие проекты нанимают третьи стороны для управления закупками, особенно когда это связано с ИТ-системами. Управление этими третьими сторонами часто является ролью менеджера проекта. Смотрите наши статьи о документах запроса предложений. и управление закупками для получения дополнительной информации об этом.
  • Интеграция – Многие проекты не работают сами по себе в рамках организации – они часто влияют на другие области бизнеса. Обязательно продумайте, как ваш проект будет взаимодействовать с другими проектами или функциями.
Ключевые моменты

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

Для более подробного изучения управления проектами пройдите курс индивидуального обучения «Что такое… Управление проектами»?

1. Шесть этапов управления проектами – Projectmanagement-training.net

После утверждения плана проекта (который был разработан на начальной стадии) проект переходит во вторую фазу: фазу определения. На этом этапе требования, связанные с результатом проекта, указываются максимально четко.Это включает определение ожиданий всех вовлеченных сторон в отношении результата проекта. Сколько файлов нужно заархивировать? Должны ли метаданные соответствовать формату Data Documentation Initiative или достаточно формата Dublin Core (DC)? Могут ли файлы храниться в исходном формате или будут приниматься только те, которые соответствуют Предпочтительным стандартам? Должен ли хранитель набора данных гарантировать, что он был должным образом обработан в архиве, или это ответственность архивариуса? Какие гарантии будут даны по результатам проекта? Список вопросов можно продолжать и продолжать.

Рисунок 2: Ожидания от проекта (Иллюстрация: Рашель Хармсен)

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

  • Предпосылки
  • Функциональные требования
  • Эксплуатационные требования
  • Конструктивные ограничения

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

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

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

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

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

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

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

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

Объяснение 8 этапов проекта

Обзор статьи

В этой статье рассказывается о 8 этапах проекта.1-я фаза – это начало проекта, 2-я фаза – разведка, проект будет 3-й фазой -й. Узнайте, какие из 5 этапов проекта являются оставшимися.


Содержание

  1. Этап проекта 1: Начало проекта
  2. Фаза 2 проекта: разведка
  3. Проект
  4. , этап 3: проектирование
  5. Этап проекта 4: Разработка
  6. Проект
  7. , этап 5: тестирование
  8. Проект
  9. , этап 6: обучение
  10. Проект
  11. , этап 7: развертывание
  12. Проект
  13. , этап 8: после развертывания
  14. Сводка

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

Препарат

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

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

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

SOW Обсуждение

Задача здесь достаточно очевидна. Это общий обзор Технического задания, который был разработан – обычно отделом продаж – вместе с заказчиком. Здесь я еще раз отстаиваю свою позицию в отношении того, что PM-организация должна быть вовлечена заранее, чтобы SOW, вероятно, лучше соответствовал бизнес-потребностям клиента в части выполнения взаимодействия.По крайней мере, «пробелы» будут более очевидными сразу.

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

Обзор этапов / методологии проекта

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

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

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

Подробнее: 10 Характеристики успешных проектных команд

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

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

Обзор плана проекта на высоком уровне

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

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

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

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

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

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

Результаты этапа разведки:

  • Документ о бизнес-требованиях (BRD)
  • Пересмотренное расписание проекта
  • Пересмотренный список рисков / проблем
  • Отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта

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

  • Размер проекта
  • Бюджет проекта
  • Предпочтения клиентов
  • Таймфрейм
  • Наличие проектного персонала

Методология PM компании, в которой вы работаете (если применимо)

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

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

Целью этапа проектирования является успешное завершение и утверждение одного основного результата – документа функционального проектирования (FDD).Фаза проектирования по-прежнему в основном состоит из менеджера проекта и бизнес-аналитика со стороны группы доставки. Могут быть задействованы один или несколько разработчиков – в зависимости от сложности проекта. Однако более вероятно, что они будут переданы команде ближе к завершению этапа проектирования. Сторона клиента будет разной, но, вероятно, она будет состоять из спонсора проекта, возможно, менеджера проекта на стороне клиента и малых и средних предприятий из компании Exploration или подмножества малых и средних предприятий из некоторых ключевых областей компании, на которые повлияет реализация.

Ключевые моменты, которые PM и BA должны будут изучить на этапе проектирования с заказчиком при подготовке к производству твердого FDD:

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

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

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

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

Подведем итоги…

Результаты этапа проектирования:

  • Требования к функциональному дизайну
  • Требования к отчетности
  • Требования к переносу данных
  • Требования к интеграции данных
  • Безопасность (если применимо)
  • Документ функционального дизайна (BRD)
  • Пересмотренный график проекта (еженедельно при необходимости)
  • Пересмотренный список рисков / проблем
  • Еженедельные отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта
  • Назначение членов команды разработчиков и другого вспомогательного персонала

На данный момент мы доставили заказчику:

  • Стартовое собрание
  • Пересмотренный график (в процессе)
  • Документ о бизнес-требованиях (подписан)
  • Документ функционального проектирования (подписан)
  • Еженедельные статусные встречи (текущие)
  • Еженедельные отчеты о состоянии (текущие)
  • Пересмотренный список рисков / проблем (текущий)

Лично я верю в итеративный процесс разработки с постоянными демонстрациями прогресса разработки для заказчика до:

  • Обеспечить соответствие разработанного решения потребностям и ожиданиям клиентов
  • Выявление проблем с объемом по мере их возникновения
  • Своевременно предоставлять возможность изменения заказа / получения дополнительных доходов
  • Сделайте так, чтобы заказчик чувствовал себя вовлеченным в разработку и постоянно был в курсе прогресса

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

Я лично начал управлять очень большими 5-летними государственными программами / проектами стоимостью в десятки миллионов долларов еще в конце 80-х – начале 90-х годов, используя Project Workbench ABT в старую эпоху DOS. Переход на MS Project значительно улучшил ситуацию и является основным продуктом до сих пор.Я также заинтригован предложением Seavus Project Viewer и сейчас знакомлюсь с ним. Я постараюсь осветить его в следующем посте, поскольку считаю его невероятно ценным инструментом управления проектами, инструментом планирования и инструментом совместной работы не только для небольших компаний, но и для крупных компаний. И цена на тысячи и тысячи долларов превосходит MS Project / MS Project Server как инструмент для совместной работы. Уже одно это стоит того, чтобы на него взглянуть.

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

Технический проектный документ (TDD) – это документированный результат этапа разработки. Это может быть, а может и не быть фактической доставкой заказчику. Если это так, то это действительно только для их целей документации – это НЕ должно требовать формального подтверждения, поскольку это действительно документированное представление решения «как построено». Это может упростить внесение изменений в систему в будущем исходным поставщиком, заказчиком или сторонним поставщиком, или это может быть документ, который поможет заказчику во время будущих обновлений.В любом случае, это хорошо, и решать вам или кому бы то ни было, передать ли вы это клиенту.

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

Подведем итоги…

Результаты этапа разработки:

  • Технический проектный документ (TDD) – это необязательно и не требует подписи.
  • Периодические обзоры / демонстрации разработки – запланированы в соответствии с требованиями проекта
  • Пересмотренный график проекта (еженедельно при необходимости)
  • Пересмотренный список рисков / проблем
  • Еженедельные отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта

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

Подготовка к тестированию состоит из трех мероприятий:

  • Подход к тестированию – устанавливает объем системного тестирования, общую стратегию, которую необходимо принять, действия, которые необходимо выполнить, общие требуемые ресурсы, а также методы и процессы, которые будут использоваться для тестирования выпуска. В нем также подробно описаны действия, зависимости и усилия, необходимые для проведения системного теста.
  • План тестирования или обеспечения качества (результат) – подробно описывает действия, зависимости и усилия, необходимые для проведения системного тестирования и UAT.
  • Документы об условиях / случаях тестирования – тесты, которые будут применяться, данные, которые будут обрабатываться, покрытие автоматизированным тестированием и ожидаемые результаты для System Test и UAT.li>

Читать: 5 способов улучшить тестирование проекта

Тестирование системы

Под руководством разработчика приложений или разработчиков и других архитекторов, интеграторов данных и т. Д., Которые могли работать над проектом, разработанная система должна пройти тщательное тестирование для подготовки к UAT заказчиком.Все модули – по отдельности и вместе – должны быть протестированы на соответствие разработанным BRD, FDD и сценариям тестирования. Все интеграции данных также должны быть протестированы, чтобы гарантировать, что система взаимодействует с другими системами (ERP, SAP, CRM и т. Д.), Как ожидалось.

В идеале, тестирование должно проводиться на отдельной платформе с использованием инструментов управления тестированием или сервера, выделенного для разработки, поскольку эта протестированная и завершенная среда тестирования затем прошла бы от System Testing до User Acceptance Testing.

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

В случае программного / ИТ-проекта заказчик придумывает свои собственные тестовые сценарии и сценарии для тщательного тестирования системы перед развертыванием.Создание тестовыми сценариями, которые заказчик может использовать во время UAT, является серьезным конфликтом интересов.

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

Подпись

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

Подводя итоги…

Результаты этапа тестирования:

  • Развитая система (без подписи)
  • План обеспечения качества (результат – подписание необязательно)
  • Подтверждение приемочного тестирования пользователем
  • Пересмотренный график проекта (еженедельно при необходимости)
  • Пересмотренный список рисков / проблем
  • Еженедельные отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта

Ключевые вещи, которые должны произойти на этапе обучения:

  • Разработка и реализация плана обучения
  • Разработка и доставка учебных материалов
  • Настройка обучающей среды или сервера с готовой к производству копией системы
  • Данные для обучения загружены в базу данных
  • Проведение обучения или обучение инструкторов

План обучения и материалы

Разработка плана обучения и учебных материалов, вероятно, началась во время приемочного тестирования пользователей.На этом этапе команда разработчиков разрабатывает и тестирует систему, и мы надеемся, что она на 99% готова к производству. Таким образом, группа доставки – скорее всего, бизнес-аналитик – может приступить к составлению плана обучения и учебных материалов, исходя из потребностей клиента в обучении.

Учебная среда и загрузка данных

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

Обучение

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

Вперед

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

Подведем итоги…

Результаты фазы обучения:

  • План обучения (результат – подписание необязательно)
  • Учебные материалы (результат – подписание необязательно)
  • Среда обучения
  • Данные обучения в базе данных обучения
  • Пересмотренный график проекта (еженедельно при необходимости)
  • Пересмотренный список рисков / проблем
  • Еженедельные отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта

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

Производственная среда

Иногда во время обучения ИТ-проекту производственная среда была подготовлена ​​- либо на стороне группы доставки, либо на фактическом объекте клиента. В любом случае, произошла значительная настройка (и уже согласованный заказ оборудования и т. Д.), И, вероятно, имели место тестирование среды и настройка производительности.

Загрузка производственных данных

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

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

Отзыв клиента / подписка на ввод

После того, как производственная среда установлена ​​и настроена, производственные данные загружены, а готовая к производству система получает зеленый свет от группы доставки, пора получить официальное разрешение на запуск от спонсора клиента или назначенного представителя.Это очень важно … не позволяйте этому ускользнуть. В зависимости от того, как настроен ваш проект и как обрабатывается выставление счетов, это может означать разницу между получением вашей компанией следующего платежа или появлением бухгалтерского учета в вашем офисе, когда вы задаетесь вопросом, почему последний счет просрочен на 90 дней. Получите официальную подписку. Если клиент доволен и все идет хорошо, он подпишется. Если что-то нечеткое, оставайтесь с этим, убедитесь, что те же члены команды будут задействованы в Фазе 8 – Пост-развертывание в течение «x» дней, и что вы будете тут же, чтобы поддержать их в выполнении любых перерывов / исправлений. Работа.В любом случае, заставьте их официально подписать документ для начала работы.

Вверх следующий

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

Подведем итоги…

Результаты этапа развертывания:

  • Производственная среда
  • Загрузка данных в реальном времени в производственную среду
  • Развернутая система, готовая к работе (требуется подписка)
  • Пересмотренный график проекта (еженедельно при необходимости)
  • Пересмотренный список рисков / проблем
  • Еженедельные отчеты о статусе проекта
  • Еженедельные совещания по статусу проекта

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

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

В организации профессиональных услуг PM, BA, разработчики, архитекторы и специалисты по данным, вероятно, у всех есть другие активные проекты, а также новые обязательства, к которым они начинают переходить. Тем не менее, я твердо верю в то, что сделаю все возможное, чтобы сохранить существующую команду доставки, по крайней мере частично, вместе, чтобы обеспечить практическую поддержку типа «позвони мне на летучую мышь» для вашего недавно внедренного клиента в течение как минимум 30 дней. окно – 60 было бы еще лучше.Почему? Потому что это хороший бизнес. Потому что это может означать разницу между будущим взаимодействием с этим клиентом и переходом к другому поставщику в следующий раз. Потому что вы держали велосипед и бегали рядом с ним, наверное, 6-12 месяцев, и вам не следует просто выталкивать их на улицу сейчас, когда они, наконец, научились это делать.

Они упадут … всегда что-то ломается. И, по крайней мере, в течение 30-дневного периода после внедрения, люди, которые знают это лучше всего – которые только что завершили внедрение решения, – должны быть теми, кто быстро ломает / исправляет работу над ним.Поверьте, ваши клиенты согласятся. Если это не является частью обсуждения продаж вашей компании, я не удивлюсь, если заказчик поднимет этот вопрос во время Project Kickoff. Для них это важно, и во время проекта они постоянно ждут того дня, когда им придется делать свои первые шаги в одиночку… и это их пугает. Сделайте это легко … и придерживайтесь их.

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

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

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

Для ясности: этапы процесса, которые я рассмотрел, описывают различные этапы ИТ-проекта, НО это только пример.Это методология / процесс PM, которые я обычно использую для ИТ-проектов. Если у вас есть какие-либо вопросы, не стесняйтесь размещать их в разделе комментариев в конце.

.

Добавить комментарий

Ваш адрес email не будет опубликован.