Мифы, которые мешают управлению проектами

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

Миф 1 Платформой УП является программный продукт

Давайте разберемся что такое программное обеспечение в управлении проектами. Самое распостраненное мнение, что «Программное обеспечение для управления проектами (Project Management Software) [Инструмент] …».

И это верно – Программное Обеспечение (далее по тексту - ПО) было и всегда будет лишь инструментом для какой-либо деятельности, а строить деятельность вокруг инструмента крайне нецелесообразно. Фраза «построение системы УП на основе ПО» звучит так же несуразно, как и «построение процесса копания на основе лопаты».

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

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

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

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

МИф 2. Об абсолютной правильности процессов описанных в PMBOK.

В библии проектного менеджмента PMBOK (Project Management Body of Knowledge -свод знаний по управлению проектами)  описано, как все должно быть в идеале в большом проекте. Это как в Палате мер и весов, где самый длинный метр, самый тяжелый килограмм и т.д., так и PMBOK - самая долгая и дорогая методология УП. Всех описанных в PMBOK процессов не достаточно для управления комплексным проектом (программой), но этих процессов слишком много для простых и средних проектов. Поэтому компании создают свои корпоративные стандарты УП (далее по тексту - КСУП), которые являются симбиозом собственных наиболее эффективных процессов УП и рационального зерна из методологии.

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

Миф 3. О высокой эффективности внедрения УП в проектно-ориентированных отраслях.

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

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

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

Миф 4. УП – это дорогое секретное оружие для достижения небывалых результатов.

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

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

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

Миф 5. Методологию УП могут внедрить только внешние консультанты.

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

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

Миф 6. Корпоративный стандарт УП – это набор шаблонов и документов.

Хоть мы и называем это чепухой, нужно отдать должное, что она ближе всего к реальности, но все же и она требует небольшого «расшатывания своих основ». Давайте обратимся к тому же PMBOK и посмотрим определение «документа». Это «носитель и информация на нем, которые обычно имеют определенную устойчивость к воздействиям…». Да, при создании КСУП без маломальской формализации процессов УП и формирования набора шаблонов не обойтись. Но если мы формализуем процессы, впишем их в бумагу и положим пылиться на полку, тем самым обеспечив указанную «устойчивость к воздействиям», то получим мертворожденное дитя. Стандарт же должен жить и постоянно развиваться, а вместе с ним должны развиваться входящие в него документы. Даже в Конституцию вносят поправки!

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

Взгляните на технологию Microsoft Solutions Framework. Билл Г. приоткрыл коммерческую тайну и выпустил для общего обозрения одну технологию из своей богатой методологии УП. Если посмотреть на историю развития этой технологии, то видно, какой долгий путь она прошла. А теперь давайте проведем небольшой эксперимент: возьмем эту документацию, сменим логотипы и названия Microsoft на свои и издадим ее у себя в виде КСУП. Что в итоге получим? Ровным счетом ничего. Просто наша техническая библиотека пополниться еще несколькими документами.

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

Миф 7. Очень важно быть сертифицированным специалистом в области УП

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

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

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

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

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

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

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

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

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

Миф 9. Критерием успешности проекта является минимальное отклонение от запланированных сроков и бюджета.

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

Давайте снова обратимся к «библии» проектного менеджмента (PMBOK, 4-е издание, стр. 17) и прочитаем там следующую фразу: «Влияние заинтересованных сторон проекта, риск и неопределенность имеют наибольшее значение в начале проекта. Эти факторы уменьшаются по ходу проекта».

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

Итак, давайте расставлять точки над "ё". Действительно грамотный и опытный руководитель проекта для повторяющихся проектов может с точностью до 5-10% спланировать график и бюджет проекта и уложиться в эти сроки, деньги и погрешность, реализуя проект. Но если результат, подобный планируемому в новом проекте, никто из участников проекта ранее не достигал, критерии его успешности явно лежат не в минимальном отклонении от запланированных срока и бюджета. А как же тогда определить, успешен проект или нет? Давайте рассмотрим два примера:

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

Планируя проект, все заинтересованные стороны договариваются, что необходимо сделать именно это, в такие сроки, за столько-то денег. Все понимают, что только в таком случае результат проекта «принесет всем счастье», поэтому наносят это, такие и столько на бумагу, ламинируют и, радуясь, вывешивают у каждого в кабинете. Руководитель проекта «гонит лошадей», отвергает любые изменения в проекте, поскольку они влекут за собой изменение бюджета и сроков (при этом все участники с ним соглашаются), и укладывается в заламинированные такие сроки и столько денег с минимальным отклонением: -1% по срокам и +1% по деньгам. Но под конец Заказчик не знает, кому и как впарить это, поскольку самому уже это давно не нужно. Руководитель проекта, уже успевший вписать в резюме заведомо успешный проект, скромно стирает его кнопочкой Backspace. Команда на премиальные уже давно не рассчитывает…

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

Миф 9. Роль Заказчика в проекте исключительна и непоколебима.

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

Рыночная экономика не устает нам доказывать, что Заказчик всегда прав! Но здравый смысл и опыт руководителей проектов заставляет их держать Заказчика в роли консультанта по проекту и формального центра принятия решений (то есть чтобы бумажечки подписывал). И такое удается не всем руководителям проектов: одни идут на поводу у Заказчика, боясь его разочаровать и, как следствие, выполняя все его прихоти; другие доводят Заказчика до белого каления своими отказами и закрытостью информации проекта, и Заказчик в итоге выгоняет их взашей. Как правило, и в том и в другом случае цели проекта не достигаются, Заказчик результатами не доволен, проект провален.

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

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

Заказчик абсолютно точно понимал текущее состояние проекта (т.е. обеспечить прозрачность проекта);

при желании или потребности Заказчика вносить какие-то изменения в ход проекта, чтобы он абсолютно точно видел, как это повлияет на сроки, бюджет и результаты проекта;

решения по проекту поступали Заказчику в готовом виде с понятным обоснованием, и ему оставалось только выбрать (если подразумевается выбор из нескольких вариантов) или просто подписать;

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

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

Миф 11. Руководителей проектов не хватает на все проекты.

Это самая распространенная чепуха 2007-2008 годов. Сегодня ее продолжают распространять, но с эпитетами, - мол, не хватает «опытных», «грамотных», «профессиональных» руководителей проектов…

Миф о нехватке проектных менеджеров придумали и распространяют HeadHunter-ы и HR ы. Хотя они это сделали не со зла, и даже не из корысти – им помогли те, кто вдруг понял, что им срочно нужны руководители проектов, причем сразу умудренные опытом, сертифицированные и за небольшие деньги. А поскольку такая потребность возникла как-то сразу, да еще и по всему миру, – вот на свет и появилась очередная чепуха. Но все-таки хорошее время – «кризис». Он почти убил эту чепуху, а мы добьем!

Вы действительно хотите себе в проект затащить сразу гуру? Тогда рассчитывайте ежемесячное вознаграждение этого человека как 0,1-0,5% от полного бюджета проекта.

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

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

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

Это особый склад характера людей – они боятся равновесного состояния. Когда все спокойно - им плохо, когда все движется - им хорошо. Вот из них-то и получаются отличные проектные менеджеры, а еще предприниматели и исследователи. Да, часто эти люди ничего не знают о существовании PMBOK и ни разу не видели Microsoft Project. Более того, они вряд ли рассматривали свои реализованные проекты с точки зрения сроков и бюджетов, и никогда не загоняли их в рамку «инициализация – планирование – исполнение – контроль – завершение». Но на каком-то подсознательном уровне они умудрялись доводить дело до победного конца. Когда же на вооружение попадает методология УП, их сразу начинают называть успешными руководителями проектов. Ищите именно таких людей! От остальных их отличает не образование и опыт работы (критерии по которым их ищут HeadHunter-ы и HR-ы), а наличие всех следующих качеств:

- нацеленность на результат и удовольствие от процесса;

- способность решать проблемы, а не желание констатировать факт их наличия;

- азарт от преодоления преград;

- умение договариваться с людьми.

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

Миф 12. Руководитель проекта может совмещать обязанности проектного менеджера и должностные обязанности сотрудника фирмы.

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

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

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

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

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

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

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

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

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

Миф 13. Кризис – это плохо.

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

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

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

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

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

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

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