Проектите в ИТ се провалят по-често от всеки друг тип — обикновено защото обхватът е неясен, пропуснати са зависимости или комуникацията е слаба. С Trupeer можете да спестите часове за планиране, като започнете с безплатен шаблон за план на ИТ проект, персонализирате го с вашата брандинг идентичност и превърнете плана в видео актуализации, които поддържат синхрон между техническите и бизнес заинтересованите страни.

Какво представлява планът за ИТ проект и защо общите шаблони се провалят

Планът на проекта е документът, който казва какво ще бъде доставено, до кога, от кого и какво трябва да е вярно, за да се случи това. Всеки шаблон, който се класира за това търсене, ще ви даде това — обикновено като списък със задачи със стартови дати, крайни дати, отговорници и Gantt лента.

Списъкът със задачи не е проблемът. Проблемът е редът, по който го попълвате.

Общите шаблони започват с вашата работа. Избройте задачите, оценете продължителностите, подредете ги, добавете отговорници и крайната дата „изпада“ накрая. Зависимостите се добавят след това, в отделна колона, като бележка.

ИТ проектите рядко се „изплъзват“, защото тези оценки са били грешни. Те се изплъзват, защото нещо пристига, което никога не е било в плана и не може да бъде оспорено: замразяване на промените, което покрива седмицата на пускане, преглед по сигурността с опашка от шест седмици, доставчик, чиито консултанти по внедряване са записани до края на тримесечието, лиценз, който се подновява преди замяната да е готова, одит, който заключва средата за месец.

Нито едно от тези не са рискове. Риск е нещо, което може да се случи. Това вече е факт в деня, в който започвате да планирате, и всяко от тези неща е предвидимо още през първата седмица, ако някой попита.

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

Как да персонализирате този шаблон в Trupeer

Стъпка 1: Отворете секцията Templates

Отидете до секцията Templates от главната навигация.

Стъпка 2: Изберете и отворете шаблон

Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.

Стъпка 3: Разгънете изгледа на шаблона

Ако е нужно, разгънете изгледа на шаблона, за да виждате пълната структура и детайлите ясно.

Стъпка 4: Редактирайте шаблона

Кликнете върху Edit, за да започнете да променяте избрания шаблон.

В редактора можете да:

• Добавяте нови секции

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

• Добавяте лого и настройвате позицията му и свързаните настройки

Стъпка 5: Запазете персонализирания си шаблон

След като направите всички необходими промени, кликнете върху Save, за да запазите актуализирания шаблон като свой.

Стъпка 6: Прегледайте и фино настройте шаблона

Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.

От екрана за преглед можете да продължите да правите корекции директно, ако е нужно, като гарантирате, че шаблонът изглежда точно както искате.

С шаблон за план на ИТ проект можете да:

• Спестите часове за планиране: Пропуснете празната страница със структура, създадена за ИТ инициативи.

• Управлявате техническата сложност: Вградени секции за архитектура, зависимости и рискове.

• Останете в бранда: Приложете логото, шрифтовете и цветовете си с brand kit-а на Trupeer.

• Синхронизирате бизнес и ИТ: Превърнете техническите планове в видео актуализации, които бизнес заинтересованите страни могат да разбират.

• Стандартизирайте между проектите: Използвайте един и същ шаблон за всяка ИТ инициатива.

• Достигнете глобални екипи: Превеждайте планове и актуализации на 65+ езика с едно кликване.

Неподвижните елементи и къде да ги намерите

Неподвижен елемент е всяка дата или продължителност, зададена от някой, който не отчита към проекта. Не можете да го договаряте в рамките на проекта и ако го откриете късно, той се превръща от ограничение в криза.

Ето инвентара, с който да работите през първата седмица. Питайте всеки отговорник два въпроса: каква е вашата дата и какво е вашето време за изпълнение.

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

Начертайте тези елементи в един-единствен календар, преди да оценявате каквото и да било. Това, което търсите, е формата на празнината. Много често празнината е значително по-тясна от продължителността на проекта и честният разговор за обхвата се случва през втората седмица, а не в седмия месец.

Какво влиза в плана

След като неподвижните елементи са начертани, самият план има дванадесет секции. Копирайте заглавията, попълнете ги в този ред.

1. Обобщение. Едно изречение: какво се променя, за кого и какво престава да е вярно след това.

2. Резултат и критерии за успех. Измерими и с дата. Включете поне един критерий за това, което се заменя — например че наследената система няма трафик и няма разходи за лиценз до посочена дата. Планове, които приключват при пускане в продукция, са начинът компаниите да започнат да плащат за две системи.

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

4. Обхват. Три списъка: включено, изключено и отложено. Отложеният списък е полезният, защото там попада обхватът, когато бъде съкратен, и така се прекратява същият разговор да се случва четири пъти.

5. Фази и ключови етапи. Ключовите етапи са събития с наблюдаем отговор, например „прегледът по сигурността е преминат“ или „първият магазин е пуснат“, а не „фазата на проектиране е завършена“.

6. Разбивка на работата. Задачи, отговорници, оценки, последователност. Това е частта, с която започва всеки друг шаблон.

7. Зависимости. Разделете вътрешните от външните. Всяка външна зависимост получава конкретно име на човек в другата организация и дата, която те са се съгласили, а не дата, която вие сте предположили.

8. Среда и данни. Кои среди съществуват, какви данни има във всяка, как се защитават продукционните данни в тест и резултатът от профилирането на изходните данни.

9. Преминаване и откат. Последователността час по час за превключването, точката на решение, при която спирате, кой прави този избор и как се връщате обратно. Запишете това като изпълнима процедура, където се вписва шаблонът за метод на процедура.

10. Рискове с тригери. Не е матрица за вероятност и въздействие. Всеки риск получава наблюдаем тригер и действието, което се задейства, когато тригерът бъде видян. „Консултантът на доставчика не е потвърден до 12 май“ е тригер. „Доставчикът може да закъснее“ не е.

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

12. Управление и приключване. Кой решава, кой ескалира, как изглежда записът за решение и при какви условия проектът се обявява за завършен и предаден за експлоатация.

Работен пример и какво струва

Ashmore Retail, осемдесет и четири магазина и три дистрибуционни центъра, планират през февруари да заменят системата за управление на складовете във всичките три DC. Девет месеца работа, пускане в продукция планирано за средата на ноември, описано в kickoff deck-а като „удобно преди пика“.

В деня на този kickoff съществуваха два неподвижни елемента. И двата бяха публикувани. Нито един не беше в плана.

Първият беше замразяването на промените. Retail operations го публикуват всяка януари и то тече от 1 ноември до 15 януари, покривайки пиковото търговско време. Никакви промени в продукцията от какъвто и да е тип не се правят през тези единадесет седмици.

Вторият беше наследеният договор. Той се подновяваше на 31 декември за още дванадесет месеца на сто осемдесет и шест хиляди паунда, като се изискваше предизвестие от деветдесет дни, което постави реалния срок на 2 октомври.

Проектът вървеше по план през пролетта. Прегледът по сигурността отне четири седмици при декларирано SLA от две. Консултантите по внедряване на доставчика не бяха налични до октомври, защото бяха поискани през юли. И двата пропуска бяха „погълнати“ чрез преместване на пускането в продукция от средата на ноември към края на ноември, което никой не отбеляза, защото никой не гледаше календара за замразяване.

Замразяването излезе наяве на среща на change advisory board в началото на септември. Пускане в продукция през ноември не беше възможно и следващият работещ прозорец се отвори на 16 януари.

Това остави един избор, който трябваше да се направи до 2 октомври. Да се даде предизвестие по наследения договор и да се работи от 1 януари без поддръжка на системата, от която цялата компания зависеше, или да се остави да се поднови и да се плати за година за система, която планираха да изключат през ноември.

Те го оставиха да се поднови. Новата система влезе в продукция на 4 март. Наследеният договор беше използван девет седмици от неговия общ срок от петдесет и две седмици — това е около тридесет и две хиляди паунда стойност срещу фактура от сто осемдесет и шест хиляди паунда. Грубо сто и петдесет и четири хиляди паунда купиха нищо.

Поучителното е, че проектът никога не беше „закъснял“ по начина, по който хората имат предвид, когато казват „късно“. Работата беше свършена до разумен стандарт и с разумно темпо. Това, което се обърка, е, че прозорецът беше с шест седмици по-тесен, отколкото някой беше начертал, и двете дати, които го определяха, стояха в публикуван календар и подписан договор още преди проектът да съществува.

Ако календарът на ограниченията беше начертан през февруари, последователността щеше да е очевидна. Пускане в продукция преди 1 ноември, връщане назад през четириседмичен преглед по сигурността, който всъщност беше шест, шестседмичен път за възлагане и консултанти, които се нуждаят от тримесечие предизвестие, означава, че договорът с доставчика трябва да бъде подписан до средата на април. Той беше подписан през юли. Проектът не е трябвало да се движи по-бързо. Трябвало е да започне своите неподвижни зависимости единадесет седмици по-рано.

Пет форми на ИТ проект и кои секции носят тежестта

Списъци с двадесет шаблона за ИТ проект са често срещани в това търсене — от внедряване на ITSM до надграждания на инфраструктура и създаване на PMO. На практика те се свеждат до пет форми и формата ви казва кои от секциите по-горе заслужават детайл.

Замяна. Смяна на работеща система с друга. Включва WMS, ERP, ITSM инструменти, платформи за help desk, HR системи. Секции 3, 9 и 2 носят тежестта, защото трудните части са прозорецът, преминаването и доказването, че старото наистина е изключено.

Внедряване. Нещо ново без предшественик. Включва управление на SLA, ИТ управление и програми за съответствие, управление на активи, управление на знания. Секции 11 и 2 носят тежестта, защото преди това нищо не е било „счупено“, така че осиновяването е единственото, което го прави реално. Нашият guide за внедряване на digital adoption навлиза по-дълбоко в това.

Миграция или надграждане на място. Същата система, нова версия, нов хост или нов регион. Включва виртуализация, консолидация, миграция към облак, надграждания на база данни. Секции 8 и 9 носят тежестта, защото откатът е цялата игра.

Изграждане. Разработка на софтуер и автоматизация на процеси. Секция 4 носи тежестта, защото обхватът е променливата, която се движи, а критериите за приемане са това, което го спира да се движи тихо.

Програма и гарантиране. Създаване на PMO, ИТ одити, управление на портфолио, управление на рискове, съответствие по сигурността. Секция 12 носи тежестта, защото доставката е доказателство и подписване, а не работеща система, и ключовите етапи са дати за преглед, зададени от някой друг.

Ако вашият проект не се вписва чисто в една от тези категории, обикновено това са два проекта, които са получили едно и също име.

Създаване на плана за един ден

Сутрин, начертайте неподвижните елементи. Изпратете двата въпроса на всеки отговорник в таблицата, преследвайте първо отговорите от доставчика и по сигурността, защото те имат най-дълги „опашки“, и поставете всяка дата, която получите обратно, в един календар. Посочете получения прозорец в едно изречение.

Следобед, напишете секции 1, 2 и 4, а след това и ключовите етапи. Оставете детайлната разбивка на работата за екипа по доставка да я попълни през седмицата. Планът е полезен в момента, в който прозорецът и обхватът са договорени, и не става по-полезен заради това, че съдържа четиристотин реда.

Преглеждайте го спрямо прозореца на всяка среща за управление. Единственият въпрос, който си струва да зададете, не е „в крак ли сме“, а „преместен ли е някой неподвижен елемент“. Замразяванията се удължават, одитите се пренасрочват, а доставчиците губят консултанти. Тези промени пренаписват плана по начин, по който задача, която е закъсняла, никога не го прави.

Какво да оставите извън документа

Gantt диаграма на всяка задача не принадлежи в документа с плана. Тя принадлежи в инструмента, с който планирате, и ако я дублирате в документ, създавате две версии, които се разминават още в рамките на две седмици.

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

Подробни процедури за това как се изпълнява работата принадлежат в IT SOP, а описанието на това, което сте изградили, принадлежи в IT documentation, а не в плана. Предаването към екипа за експлоатация си струва да се планира правилно — за това е knowledge transfer SOP.

Кога да спрете да използвате документ и да преминете към софтуер

Документът е правилният контейнер, докато планът се обсъжда — това е по-голямата част от първия месец. Той престава да е правилният контейнер, когато едновременно станат верни три неща: повече от около тридесет задачи са „на живо“, повече от четирима души актуализират статус и зависимостите между задачите започват да се променят всяка седмица.

В този момент преместете разбивката на работата в софтуер за планиране и запазете документа за секции 1 до 5 и 12 — това са частите, които се четат от хора, които никога няма да отворят инструмента. Документът държи договореността. Инструментът държи графика.

Превръщане на плана в нещо, което екипът по доставка реално следва

Планът се чете на kickoff и на срещата за управление. Runbook-ът за преминаването се чете в два през нощта от някой, който не е бил нито на едното, нито на другото.

Trupeer AI превръща запис на екрана в документиран процес, така че стъпките за преминаване в секция 9 и задачите за първия ден в секция 11 да станат walkthrough-и на вашите реални системи, вместо параграфи, които ги описват. Запишете последователността веднъж и получавате стъпка по стъпка ръководство, видео и документ във вашия knowledge base, с вашия собствен брандинг.

Запишете. Брандирайте. Преведете. Trupeer-нете.

За работата по осиновяване в секция 11, change management и training videos покриват страната на rollout-а, а documentation държи плана, runbook-а и материалите за предаване заедно. Инструкциите за настройка са в document template setup guide.

Често задавани въпроси

Има ли безплатен шаблон за план на ИТ проект в Excel?

Не като файл от нас, и си струва да сме директни за компромиса. Excel е наистина по-добрият контейнер за разбивката на работата в секция 6, защото датите, зависимостите и обобщенията принадлежат в клетки. Направете сами този лист с колони за задача, отговорник, старт, край, зависимост, статус и флаг за неподвижен елемент. Дръжте секции 1 до 5, 9 и 12 като документ, защото те се обсъждат в текст и никой не договаря обхват в електронна таблица.

Има ли версия за Word или безплатно сваляне на Word документ?

Структурата с дванадесет секции по-горе е написана така, че да се копира директно в Word или Google Docs. Поставете заглавията, запазете номерирането и ги попълнете в дадения ред. Няма „заключено“ сваляне, което също означава, че няма формуляр между вас и структурата.

Има ли версия за PDF?

Поставете секциите в редактора си и експортирайте в PDF, когато планът бъде договорен. Струва си да „замразите“ плана като PDF в момента, в който е подписан, и да го държите за редакция преди това, така че експортирането на собствено копие в правилния момент е по-добре, отколкото да започвате от фиксиран файл.

Има ли версия за PPT за kickoff deck-а?

Декът е различен документ с различна задача. Обикновено шест слайда са правилни: резултатът, прозорецът за доставка от вашия календар на ограниченията, обхватът включено и изключено, ключовите етапи, именуваните външни зависимости и кой решава какво. Не поставяйте разбивката на работата в дек-а. Никой не чете Gantt лента на проектор.

Мога ли да го изтегля безплатно?

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

Планът за доставка на проект същият ли е като план на проект?

Достатъчно близо, че разграничението рядко си заслужава. Когато организациите ги разделят, планът на проекта обхваща целия живот на проекта, включително бизнес кейса и приключването, а планът за доставка обхваща само частта за изграждане и пускане. Ако вашето управление изисква и двете, напишете плана по-горе и третирайте секции 5 до 9 като план за доставка.

Трябва ли ми и отделен шаблон за отчет за управление на проекта?

Да, и го дръжте много по-кратък, отколкото очаквате. Отчет за статус, който повтаря плана, се игнорира в рамките на месец. Докладвайте четири неща: преместен ли е някой неподвижен елемент, прозорецът все още ли е достатъчно широк, какво решение трябва да вземете от тази група днес и какво е задействано от списъка с рискове от последния път.

Колко детайлен трябва да е планът за ИТ проект?

Достатъчно детайлен, за да може новоназначеният да разбере какво се случва след това — и не повече. На практика документът с плана е около осем до петнадесет страници за деветмесечен проект, като повечето от тях са секции 8 и 9. Ако документът е по-дълъг от runbook-а за преминаване, балансът е грешен.

Колко често трябва да се актуализира планът?

Секции 6 и 7 се променят всяка седмица и принадлежат там, където вече работи вашият екип. Секции 1 до 5 трябва да се променят рядко и всяка промяна в тях е решение, което някой трябва да одобри. Ако секцията за обхвата се редактира тихо всяка седмица, вие нямате план — имате дневник.