Стартъпите играят покер, големите компании играят шах.

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

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

Не е всичко черно и бяло

Едно предупреждение, преди да се потопим в тази тема, е, че има всякакви компании. Можете ли вече да наречете стартираща компания със 100 служители? Ами ако расте до 200 или 300 служители? Понякога Uber все още се нарича стартъп в медиите, но сега Uber има 12 000 служители. Друго разграничение е, че стартирането, стартирано от студенти, е много различно от това, стартирано от серийни предприемачи с над 20 години професионален опит, които преди това са работили в предприятието и са връщали най-добрите практики от там на своите стартиращи фирми.

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

Стартъпи срещу предприятия

Като се отклоним от това предупреждение, нека се опитаме да дефинираме двете крайности, за да положим основа за нашата дискусия. За целите на тази статия характеристиките на a започвам са:

• Едновременно разположен екип (~ 1-50 служители), където обикновено познавате по име всичките си колеги.
• Ролите са слабо дефинирани.
• Съоснователите са много активни при вземането на повечето решения.
• Компанията губи пари и не е останала дълга писта - оцеляването е основен проблем.

В другия край на спектъра, an предприятие ще изглежда така:

• Множество отдели и локации.
• Познавате добре само преките си колеги и си взаимодействате с шепа хора от други отдели.
• Всеки има ясни отговорности и йерархии.
• Компанията може да е публична.
• Рентабилността и краткосрочното оцеляване вероятно не са проблем.

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

Мениджър на проекти ≈ Мениджър на продукти

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

Възможности за ръководители на проекти в стартъпи

Бързи решения и голямо въздействие

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

Стартирането е добро място да изпробвате идеите си и да се развиете професионално. Можете да изпробвате нов инструмент за управление на проекти, който вашият приятел ви е казал, че използва в неговата компания. Какво ще кажеш преместване от Скрум в Канбан ? Каквото и да ви кара да доставяте по-бързо, отговаря изпълнителният директор. Какво мислите за внедряването на този нов чатбот, който позволява заявките за вашата Google Analytics на естествен език? За това не ви е необходим разработчик, обяснява вашият технически директор по време на обяд. В едно предприятие всички те биха били отделни, големи и дълги инициативи, управлявани от специален ръководител на проекти.

Нещата се правят бързо

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

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

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

Течни процеси

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

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

Отговорностите не са напълно дефинирани

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

Например, нова версия е разбила уебсайта на клиента. Всички в компанията знаеха за предстоящото издание, но никой не информира клиента. Трябва ли мениджърът на проекта или мениджърът на ключови акаунти да се свържат с екипа за разработка на клиента? Трябваше ли техническият директор да е по-проактивен? След разгорещена дискусия участващите хора се съгласяват, че следващия път конкретни служители ще носят отговорност за определени действия преди освобождаването, за да се гарантира, че това няма да се повтори.

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

Слаба сила на договаряне

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

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

Преки пътища създават стари проблеми

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

Да приемем например, че вашата компания решава да създаде страница с продуктова листа. Трябва да има множество филтри, за да стесни резултатите. Освен това трябва да има опции за сортиране въз основа на различни атрибути. Първоначалната оценка е твърде голяма и се опитвате да стесните необходимите филтри и опции за сортиране. В крайна сметка се оказва, че по-голямата част от оценката е цялата система - търсене и връщане на резултатите. Питате дали има някакъв начин да доставите по-проста версия по-бързо. Един разработчик предлага да се използва решение на трета страна с месечен абонамент. Другите разработчици говорят за проблеми със зависимостта и за наследени проблеми. За вас звучи перфектно, защото получавате MVP по-бързо и по-късно абонаментът може да бъде отменен, ако решите да премахнете проекта. Scrum master се съгласява да използва решението на трета страна, само ако получи шанс да пренапише кода, ако проектът не е бракуван.

Реалността обаче е, че това споразумение почти никога не се изпълнява, освен ако капитанът на скрам всъщност не постави задача за технически дълг в по-късен спринт и не го защити, когато му дойде времето. Ако първоначалната обратна връзка за страницата с обяви е положителна, естествената реакция за ръководителя на проекта е да разработи допълнителни функции, тъй като MVP беше само тест. 6 месеца по-късно достигате точка, при която добавянето на нови функции става много скъпо, но рефакторингът е още по-скъп и тогава има други приоритети, които стават по-важни и засенчват първоначалното намерение.

Фалшиви положителни резултати

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

Фалшивите положителни резултати са голямо предизвикателство, но има начин да ги смекчите. Стив Кон, основател на Validately, предлага да го направите потвърдете търсенето на вашето решение . Има три сигнала, които могат да ви помогнат:

1. Готови ли са вашите клиенти да харчат или да поемат пари, дори преди да предоставите пълното решение? Получаването на договор преди доставянето на решението е може би най-доброто потвърждение, което можете да получите.
2. Готови ли са клиентите ви да отделят време с вас за разработването на решението? Времето е пари и всеки има безкрайно изоставане от задачи. Колкото повече клиентът активно се ангажира с вас, за да разберете изискванията, като включите другите му колеги в дискусията, тествате щателно MVP и предоставите достатъчно обратна връзка, толкова по-вероятно сте на прав път.
3. Готови ли са клиентите ви да използват репутацията си, за да ви популяризират? Независимо дали става въпрос за социални медии, на професионално събитие или под каквато и да е друга форма, когато клиент ви популяризира, те ви предоставят своята репутация, която потвърждава истинския им интерес.

Управление на заинтересованите страни

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

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

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

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

Ръководител на проекти ≠ Мениджър на продукти

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

Служба за управление на проекти (PMO)

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

Като ръководител на проекти в предприятие ще трябва да взаимодействате с PMO. Всеки PMO е различен, но от нещата, с които можете да се сблъскате, са:

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

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

• Ангажирайте PMO рано, за да разберете изискванията за докладване. След това те могат да бъдат съпоставени с материали, произведени по време на изпълнението на проекта, за да се спести време.
• Бъдете шампион в процеса. Осигурете обратна връзка на PMO за това как процесите могат да бъдат променени, за да улеснят живота на ръководителите на проекти. Една от основните цели на PMO е да помогне на продуктовия мениджър да бъде ефективен.
• Използвайте PMO за помощ, когато вашият проект има проблеми. PMO има изглед на компанията за всички проекти и има опит в справянето с различни проблеми или рискове, които възникват по време на изпълнението на проекта. Използвайте техните знания във ваша полза.

Възможности за мениджъри на проекти в предприятието

Достоверност

Стабилността и дългосрочното планиране на предприятията показват доверие към клиентите и партньорите. Хората, които искат да се ангажират с вашата компания, търсят добър опит - че можете да изпълнявате обещанията си и да имате много опит във вашата област на опит. Това е едно от най-големите предимства, които едно предприятие има пред стартиращите. Улеснява намирането на нови клиенти и партньори.

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

По-лесно да се съберат изискванията

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

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

Друга група колеги, които могат да ви помогнат с изискванията на потребителите, могат да бъдат намерени в екипите за продажби, управление на акаунти или поддръжка на клиенти. Хората, които работят там, са ежедневно изложени на клиенти и могат да ви предоставят много отзиви за потребителските нужди и разочарования. Винаги обаче имайте предвид контекста, от който идва тази обратна връзка. Например екипът за поддръжка на клиенти може да се занимава с хората, които използват продукта ви, докато продавачите и мениджърите на акаунти могат да се занимават с висши мениджъри от най-високо ниво, които вземат решения за покупка, но всъщност не използват вашия софтуер.

Изградете или купите

Възможност, която не е достъпна за стартиращи фирми, е растеж чрез сливания и придобивания (сливания и придобивания). 2018 вече видя a рекордно количество сделки за сливания и придобивания в световен мащаб . Голяма част от тази тенденция са мега сделките, като скорошни AT&T придобиване на Time Warner за 85 милиарда долара. Част от сделките обаче са малки по отношение на оценките и генерират по-добра възвръщаемост, според a проучване от Harvard Business Review. Има много малки стартъпи с решения с една точка и ръководителите на проекти в предприятията трябва да имат предвид, че понякога може да има смисъл да ги изкупуват, вместо да се опитват да копират тяхното решение. Мениджърът на проекти може да не е взимащ решение за такъв сценарий, но може да е този, който да представи тази опция на масата.

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

Одобренията отнемат повече време

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

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

Погрешна комуникация

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

Вашият екип се нуждае от няколко нови икони за новите функции, по които работи. Неочаквано се срещате с ръководителя на дизайнерския екип по време на обяд и й кажете за иконите. Тя казва, че всъщност работят върху подобни икони в момента и ще ги подготвят скоро. По време на изправянето на следващия ден вие предавате информацията на екипа и им казвате да се свържат с дизайнерския екип, когато ще се нуждаят от иконите. Въпросните функции трябва да излязат след 4 седмици, така че всички предполагат, че иконите ще бъдат готови по това време. Разработчиците поставят заместители за иконите и само по време на QA някой забелязва, че са забравили да ги заменят. Те се опитват да се свържат с дизайнерския екип, който всъщност е отложил създаването на тези икони поради други спешни задачи. Никой от вашия екип не се е свързал с тях и ръководителят на дизайнерския екип е приел, че повече няма да имате нужда от иконите. Указанията за марката не ви позволяват да отидете на производство с произволни икони и вашият екип е останал да седи там с завършени функции, които не могат да ги разгърнат.

Работата на ръководител на проекти в едно предприятие е изпълнена с такива моменти, зрели за неразбирателство. Има две стратегии, които можете да използвате тук:

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

Движете се бавно и не счупвайте нищо

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

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

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

Заключение

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

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

Мениджърът на проекти в стартираща компания също е изправен пред значителни предизвикателства. Не напълно дефинираните отговорности могат да доведат до много проблеми с нарастването на стартиране. Клиентите и съоснователите може да настояват ръководител на проекта да се ангажира с повече от това, което екипът може разумно да предостави. След това в пътната карта могат да бъдат включени различни преки пътища, което води до проблеми с наследството в бъдеще. Съоснователите на стартъп са много активни в определянето на пътната карта. Убежденията им обаче могат да доведат до фалшиви положителни резултати и ръководителят на проекта трябва да бъде управляван от данни и пъргав, за да смекчи тези предизвикателства.

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

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

Това са основните разлики между тези две среди, в които работят мениджърите на проекти. Чрез разбирането на тези предизвикателства можем по-добре да предскажем какво бихме могли да срещнем при преместване от една среда в друга.

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

Какво определя стартираща компания?

Стартираща компания в най-широкия смисъл е всяка нова компания. Когато говорим за ИТ стартиращи компании, обикновено имаме предвид малка компания, която се опитва да намери подходящ продуктов пазар и да събере пари. Тя ще има 1-50 служители и е много вероятно да има дигитален бизнес с голям потенциал за растеж.

Какво е пример за предприятие?

Предприятието е голяма, утвърдена компания с множество отдели и местоположения. Често има повече от една бизнес единица. Добре известни примери за предприятия в областта на технологиите биха били Microsoft, Google, Cisco и IBM.

Какво представляват проектите на ниво предприятие?

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