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


09.08.19. В YouGile появилась ролевая модель прав: Администратор, Сотрудник, Наблюдатель.


Во всех тарифах сервиса для управления проектами YouGile появилась простая возможность добавлять сотрудников сразу с уровнем доступа:Администратор проекта — полный доступ. Сотрудник — доступ к задачам. Наблюдатель — доступ только к чату. Все прошлые возможности тонко настраивать права по большому количеству параметров у сформированных групп сохранены в полном объеме.


2007. Время изменений

Компания Serena Software является, по оценке экспертов IDC, ведущим мировым поставщиком решений для управления изменениями на предприятии, поддержки цикла разработки и программного обеспечения, а также управления портфелем проектов. Предлагаемое ею продукты используются более чем у 15 тыс. клиентов, в том числе в большинстве компаний из списка Fortune 100. Ее наиболее популярный программный продукт Serena TeamTrack (начиная с версии 7 он носит название Serena Mashup Business Server) внедрен в ряде крупных отечественных организаций, среди которых ММВБ, "Внешэкономбанк" ("Банк Развития"), "Компьютерные системы для бизнеса", "Лаборатория Касперского". В этом году к списку ее клиентов добавилась компания "Петер-Сервис", специализирующаяся на разработке, внедрении и обслуживании биллинговых систем и сопутствующих программных продуктов для крупных операторов связи. Serena TeamTrack - платформа создания Web-приложений для управления процессами, происходящими в ИТ-подразделениях - и не только, что показывают реальные примеры внедрения. Популярность решения, как полагает Алексей Ионин, генеральный директор компании Softmart, авторизованного партнера Serena, объясняется, во-первых, тем, что основой продукта являются именно процессы, а не формы, а во-вторых, простотой работы с ним: "Впервые люди получили возможность создавать программы, отталкиваясь не от абстрактных форм пользовательского интерфейса, а от реальных процессов, протекающих в организации и требующих автоматизации". Serena Business Mashup Server вышел в декабре 2007 года. "Новое имя было необходимо, чтобы сместить фокус в сторону бизнес-приложений, так как предыдущее ассоциировалось у клиентов с приложениями исключительно для программистов", - пояснил Ионин. Новая версия предоставляет больше возможностей для построения приложений-"коллажей" (mashup) на платформе Web 2.0, включая интеграцию с внешними системами на основе современных стандартов SOAP и XML. Два других продукта Serena - Dimensions и Mariner - в России пока не внедрялись. Программное обеспечение Serena Dimensions 10 предназначено для поддержки разработки и развития информационных систем в масштабах всего предприятия, созданных для глобально распределенных команд разработчиков и интегрирующих в себе системы контроля версий и управления изменениями и конфигурациями. Serena Mariner – это решение для автоматизации управления проектами и портфелями проектов, управления бизнес запросами и приоритетами, расчета финансовых и управленческих показателей. По мнению Ионина, спрос на подобные сложные системы управления разработкой и поддержкой в ИТ-подразделениях крупных организаций появился только сейчас - ИТ-инфраструктура в компаниях стала крайне сложной, соответственно возросли и риски по поддержке программного обеспечения. Естественно, на решение компании об инвестициях в дорогое программное обеспечение, необходимое для решения внутренних задач, может повлиять кризис. Тем не менее в кризисе есть и положительные моменты. До недавнего времени просто не хватало времени на внутренние изменения в компании. Именно сейчас настало время для инвестиций в собственное развитие и повышение внутренней эффективности", - уверен Ионин. Кроме того, ни для кого не секрет, что из-за нехватки квалифицированных кадров до недавнего времени ИТ-специалисты постоянно находились в поиске более высокооплачиваемого места работы, и руководителям, решившим внедрить в организации что-то новое, оказывалось жесткое противодействие вплоть до угроз уволиться. И наконец, во времена кризиса руководители начинают считать деньги, анализировать, на что они уходят.


2006. "Форс" поможет управлять изменениями

Компания "Форс" заключила дистрибьюторское соглашение с американской компанией Serena, разработчиком программного обеспечения по управлению изменениями в организации (Change Governance), и будет продвигать в России систему по управлению процессами и ИТ-инфраструктурой предприятия TeamTrack. Это решение позволяет отслеживать процесс управления изменениями с момента их регистрации до момента выполнения задачи, оповещая об этом членов команды. Благодаря визуальному редактору процессов, идентифицировать и настраивать их достаточно легко - независимо от класса сложности. При этом настройка процессов происходит в соответствии с выбранной и оптимальной для конкретного бизнеса моделью. "Мы будем не просто продавать TeamTrack как коробочный продукт, а использовать его с целью создания недорогих и удобных в эксплуатации систем, позволяющих заказчику четко отладить деловые процессы, независимо от размеров бизнеса или уровня его автоматизации", - говорит директор по развитию бизнеса "Форс" Николай Зезюлинский.


2006. ФОРС стал дистрибьютором Serena Software

Компания “ФОРС — Центр разработки”, входящая в состав холдинга ФОРС и специализирующаяся на создании больших информационных систем, заключила дистрибьюторское соглашение с американской фирмой Serena Software — разработчиком ПО по управлению проектами и изменениями в организации (Change Governance). Из обширной продуктовой линейки этого вендора ФОРС будет продвигать TeamTrack — систему по управлению процессами и ИТ-инфраструктурой предприятий самых различных отраслей: бизнес-консалтинг, страхование, аудит, медицина, транспорт, розничная торговля и т. д. (одним словом, везде, где в основе деятельности лежат процессы по управлению жизненным циклом продукта или услуги, и при этом требуется обеспечение мгновенного доступа ко всей информации, связанной с обработкой заявок клиентов). Директор по развитию бизнеса ФОРС Николай Зезюлинский отмечает: “Мы будем не просто продвигать TeamTrack как “коробочный” продукт, а использовать его с целью создания недорогих и удобных в эксплуатации систем, позволяющих заказчику четко отладить деловые процессы, максимально используя свои конкурентные преимущества, независимо от размеров бизнеса или уровня его автоматизации”.Система TeamTrack позволяет отслеживать процесс управления изменениями с момента их регистрации до момента выполнения задачи, оповещая об этом членов команды. Утверждается, что благодаря визуальному редактору процессов, идентифицировать и настраивать их достаточно легко. При этом настройка процессов происходит в соответствии с выбранной для конкретного бизнеса моделью. Более того — каждый пользователь может настроить интерфейс системы самостоятельно и по своему вкусу. В TeamTrack используются несколько предустановленных обобщенных шаблонов процессов для:организации работы службы технической поддержки;управления персоналом;управления разработкой программного обеспечения (управления жизненным циклом продукта);управления активами предприятия.По словам разработчиков, для функционирования этой системы, на рабочих местах пользователей не требуется установка никакого дополнительного клиентского ПО, кроме Web-браузера, а инсталляцию системы на сервере можно выполнить за несколько минут.Дополнительным достоинством данного продукта является то, что TeamTrack сертифицирован на соответствие рекомендациям, изложенным в “Библиотеке передового ИТ-опыта” (ITIL), где обобщён огромный опыт развития ИТ-инфраструктуры как государственных, так и коммерческих компаний. Как утверждается, с его помощью можно в достаточно короткие сроки выработать ИТ-стратегию предприятия, наилучшим образом отвечающую специфике компании и её бизнес-задачам. Проще говоря, TeamTrack может служить основой для создания самых различных процессно-ориентированных разработок, предназначенных не только для оптимизации ИТ-инфраструктуры предприятия, но и для выстраивания всей системы процессов по наиболее подходящей для данной компании модели.По оценке IDC, ПО, поставляемое компанией Serena Software, используется в более чем 15 000 организаций по всему миру, включая 96 компаний из списка Fortune 100 и 90 компаний из списка Global 100.


2004. Новый стандарт управления проектами

Институт управления проектами (PMI) выпускает третье издание руководства управления проектами (PMBOK). На протяжении многих лет оно является основным стандартом в этой области и служит эффективным инструментом в организации управления проектами.На сегодняшний день около 16,5 млн. специалистов пользуются данным руководством. Новый стандарт содержит изменения по согласованности общих процессов в проекте, а также затрагивает вопросы проектной стоимости и эффективности. Дополнительные изменения коснулись уточнения терминов и фраз, расширился глоссарий определений.PMBOK будет выпущено в бумажном и электронном (на CD-ROM) вариантах на одиннадцати языках: русском, арабском, китайском, английском, французском, немецком, итальянском, японском, корейском, португальском и испанском.Данное издание позволит удовлетворить потребности многих профессионалов по управлению проектами, оно уже стало одним из главных бизнес-справочников в мире.


2003. Управление проектами и стандарты в XXI веке

Управление проектами в сфере информатизации и реорганизации предприятий вызывает все больший интерес. Особенностями момента являются также изменение подходов к стандартизации в России и растущая открытость нашего рынка. Эти факторы требуют вернуться к основам и перспективам управления проектами. В рамках развития данного направления руководители Фонда ФОСТАС - Фонда поддержки системного проектирования, стандартизации и управления проектами - и сотрудничающие с ним компании провели обсуждение ряда стратегических вопросов с участием Вильяма Дункана, основного разработчика свода знаний по управлению проектами PMI PMBoK (в версии 1996 г.) и автора процессной модели управления проектами. Полагая, что читателям будет интересно познакомиться с обсуждением проблем, непосредственным образом затрагивающих российских руководителей проектов, а также со взглядами человека, чье имя фигурирует на титульном листе стандарта PMI, мы предлагаем вашему вниманию некоторые фрагменты этой беседы. О распространении идей проектного управленияВильям Дункан (руководитель консультационной компании Project Management Partners, США): В развитии идей проектного управления имеет место встречное движение. Если раньше основные идеи исходили из англоговорящего мира, прежде всего из США, то сегодня они появляются и в других странах. Например, в Японии разработана теория проектного и программного менеджмента (P2M). Что касается России, то у нее никогда не было недостатка в мыслителях. Здесь также будут критически осмысливать общепринятые посылы, и от этого выиграют все. Вильям ДунканМарина Грашина (вице-председатель правления Фонда ФОСТАС, генеральный директор компании PSM Consulting, Россия): Управление проектами (УП) как область знаний, разумеется, не новость для нашей страны. Другое дело, что сейчас мы говорим о “вхождении” России в систему мировых стандартов УП. И будь то стандарты PMI или IPMA - в любом случае мы не только осваиваем международный опыт, но и по-новому осмысливаем собственный. О стандартах и тенденциях в управлении инновационными проектамиЕвгений Зиндер (президент Фонда ФОСТАС, директор аналитического бюро “Группа 24”): Кроме общих тенденций важны частности, относящиеся к коренным вопросам организации проектов. PMI PMBoK и ряд других известных руководств определяют управление проектами как самостоятельную дисциплину, но в них явно или неявно предлагается гораздо более сильное решение: они позиционируют руководителя проекта как “универсального менеджера”. Имеется в виду, что, владея этой дисциплиной, такой менеджер сможет руководить любым проектом - будь то строительство здания, создание информационной системы или что-либо другое.В России существует и другой подход. Во многих областях техники, особенно там, где дело касается высоких технологий, руководителем проекта традиционно считается генеральный (главный) конструктор - идеолог основных научно-технических решений, часто - главный архитектор системы, а не только координатор. То есть на практике (да и в некоторых фирменных методиках) роли в проекте персонифицируются не так, как это трактуется многими пользователями стандартов - от PMBoK до ISO 10006. При этом в каждом проекте надо уметь выбирать, на какой стандарт и на какую традицию опираться.Вильям Дункан: По мере того как сфера применения методов управления проектами расширяется, возникают все новые вопросы по поводу того, в чьей компетенции она находится. Менеджеры проектов, будучи специалистами в этой области, пытаются отделить ее от технических специализаций. Вместе с тем инженеры и представители других профессий, на разных этапах внесшие свой вклад в развитие управления проектами, тянут одеяло на себя, претендуя на то, что именно они владеют этой областью. В любой профессии - и в ИТ, разумеется, тоже - технические специалисты не желают независимого развития управления проектами, поскольку опасаются, что в этом случае им придется перед кем-то отчитываться.Цель, которую я ставил перед собой, разрабатывая PMBoK, - выделить управление проектами как специальность, независимую от других важных для данного проекта специализаций. Вместе с тем велика вероятность пострадать от фанатиков, которые верят в то, что PMBoK - истина в последней инстанции, и тем самым ведут его к разрушению. Правильный ответ на большинство вопросов проектного управления должен начинаться словами: “Это зависит от...”. Увы, многие полагают, что существует единственно верное решение, пытаются его найти и насильственно внедрить, а в результате оно оказывается неправильным.Евгений Зиндер: Очевидно, что хорошо информационно и функционально вооруженный руководитель в принципе вполне в состоянии выполнять роль и технического лидера, и проектного менеджера. Конечно, жизнь многообразна, и руководители разные. Есть люди, которые могут успешно справляться в проекте и с творческими и, к примеру, с политическими задачами, а есть те, которым лучше поделиться частью задач, чтобы не угробить все. И тем не менее стоит учитывать, что налицо тенденция роста универсализма личности.Марина Грашина: В развитие темы стоит сказать, что проекты могут быть типологически очень разными. Например, в проектно-ориентированной ИТ-фирме, куда каждый заказчик приходит с собственными требованиями, руководители проектов могут “выезжать” за счет умения работать с людьми или за счет владения технической стороной дела.В организации, созданной для реализации одного большого проекта, его менеджер является и высшим руководителем этой организации, над ним есть только заказчик. Если это проект создания “стандартного” продукта (скажем, атомной электростанции), то руководитель проекта может быть “чистым” проектным менеджером. А если продукт инновационен (как, например, космическая станция), то руководитель должен быть и “идеологом” как технарь, и харизматическим лидером как проектный менеджер. Мы знаем немало людей, сочетавших в себе качества гениальных инженеров и гениальных менеджеров: Сергей Павлович Королев (советская космическая программа), Акио Морита (корпорация Sony) и др.Наконец, третий тип проекта - проект внедрения изменений или преобразования организации. Здесь, на мой взгляд, руководитель проекта должен быть прежде всего хорошим проектным менеджером, а уже потом - все остальное.Однако подходы и законы управления проектами будут “работать” во всех случаях.Григорий Ципес (ведущий консультант IBS, один из участников деятельности ФОСТАС, член правления СОВНЕТ): Учитывая все эти особенности и различия проектов, поставим вопрос: каким должен быть стандарт управления проектами на уровне компании? Те стандарты, которые мы предлагаем нашим клиентам, мало чем напоминают PMBoK или ISO 10006. Ведь под стандартами в России традиционно понимают нечто более или менее напоминающее армейский устав - кто, что и в какой последовательности должен делать. И такой продукт очень востребован.PMBoK к подобного рода стандартам отнести никак нельзя. Он выглядит и воспринимается скорее как методология. Мы называем его “рамочным стандартом” в отличие от стандарта “операционного”. Может быть, пора задуматься об обобщении этого опыта и о создании PMBoK операционного уровня?Вильям Дункан: Высшие руководители компании часто сами вносят путаницу. С одной стороны, они хотят дать своим менеджерам максимум свободы для работы с клиентами. Но тут же говорят, что хотят разработать стандарты на все случаи жизни, чтобы они были максимально эффективными. Однажды мы записали в стандарте для одного из наших клиентов: “Управление проектами всегда соответствует политикам и процедурам компании, кроме тех случаев, когда это будет приносить ей вред”. Может быть, это звучит смешно, но тем не менее имеет смысл. Менеджер нарушает правила не по своей прихоти, а тогда, когда видит, что это необходимо в сложившихся обстоятельствах и правила мешают достижению результата.Можно выделить три типа стандартов: предписывающий (prescriptive) регламентирует действия, которые необходимо выполнить для достижения конкретного результата; нормативный (normative) указывает, в каких случаях и каким правилам нужно следовать, чтобы проект развивался в позитивном направлении; описательный (descriptive) представляет собой перечень рецептов, а вы уж сами выбирайте, чем пользоваться.Обратимся к аналогии из медицины. Если у вас насморк, кашель, болит горло, то скорее всего вы простудились (описание). При простуде обычно нужно принимать такие-то лекарства и неделю сидеть дома (нормативы). Предписывающий стандарт для этого случая должен быть выпущен компетентным медицинским учреждением и содержать перечень симптомов, название нужных лекарств и дозировки, описание порядка и объема процедур и т. д.А вот что произошло с PMBoK. Когда мы создавали его, то надеялись, что глоссарий будет носить предписывающий характер. То есть если два разных человека употребляют термин “управленческий резерв”, оба они понимают его одинаково. Главы 1-2 должны были носить характер описаний, а именно описывать процессы, которые необходимо реализовывать при управлении проектами. Главы же 3-12 должны были стать нормативными.Теперь о том, как PMBoK, на мой взгляд, на самом деле используется. Глоссарий игнорируется. Главы 1-2 просто не читаются. Глава 3 не понимается. А главы 4-12 используются в качестве предписаний.Люди инженерного склада склонны воспринимать стандарт как нечто предписывающее. Поэтому, если вы хотите дать им описательный стандарт, сохраняющий значительную степень свободы, лучше назовите его как-нибудь иначе - руководство или общие принципы.Я считаю, что нужно переходить от “рамочных” к созданию стандартов специфических - руководство по проектному офису, руководство по составлению расписания. Если есть проблемы в таком развитии сверху вниз, то нужно начинать снизу, и в конце концов будет построена единая система стандартов. Об истории развития PMBoK PMI и о других стандартахВильям Дункан: Когда в 1987 г. началась разработка стандарта PMI, предполагалось, что это будет дерево стандартов, но в действительности связей между отдельными составными частями не просматривалось. Тогда я вызвался провести работу по упорядочиванию и связыванию этих частей.Спустя три года, в 1990-м, мы собрались в одной из гостиниц в Огайо с целью категоризировать различные знания о проектах. И о какой бы области проектного управления мы ни говорили, все сводилось к входам, выходам, методам и процедурам. Я понял, как все это можно представить в виде серии взаимосвязанных процессов, и за восемь часов организовал весь материал в этой логике. Конечно, были и пробелы, которые заполнялись позднее, но 90% PMBoK сложилось за эти восемь часов.В 1994 г. я связался с комитетом ISO и договорился о взаимном учете разработанных материалов. Но когда появился стандарт ISO 10006, в нем не оказалось ссылки на PMBoK. Причина - документы ISO могут ссылаться только на документы ISO. Впрочем, так как люди, делавшие этот стандарт, не являлись специалистами в области управления проектами, он получился настолько нелепым, что я рад отсутствию такой ссылки. Я считаю ISO 10006 очень опасным стандартом, поскольку можно сделать работу, полностью ему соответствующую, но ужасную с точки зрения управления проектами.Евгений Зиндер: Эта история подтверждает: стандарт в одних условиях может быть перспективным, а в других - тормозящим, закрепляющим устаревшие нормы. Важно сказать об этом в связи с известным посланием ИСО, МЭК и МСЭ и проводимой в России реформой стандартизации. Приведу название послания: “Единый стандарт, одно испытание, признаваемые повсюду”. Понятно, что интеграционные процессы в Европе, глобализация делают этот лозунг оправданным. Но все же перебор в “единстве” есть, уже встречалась трактовка слов “единый стандарт” как “единственный стандарт”.В середине 2003 г. вводится в действие Федеральный закон “О техническом регулировании”, но не все рационально в законопроекте. Так, разработку новых стандартов предлагается вести на базе именно международных стандартов - за исключением случаев их полной неприменимости, например из-за “климатических или географических особенностей”. В сочетании со склонностью многих к трактовке стандартов как армейских уставов такая ситуация опасна. Учтем длительность подготовки стандартов в ИСО и тот факт, что многие из них готовятся на основе стандартов некоммерческих профессиональных объединений, которые развиваются самостоятельно. В результате не исключено, что к моменту ввода в действие стандарта ИСО он вполне может играть тормозящую роль. А если стандарт ИСО окажется еще и неудачным по сути? Учтем также, что наши зарубежные конкуренты существенно менее стеснены в действиях. Они вполне могут опираться на модель процессов PMI PMBoK, а не ISO 10006 или сертифицировать свою систему работы не по ИСО 9000, а по CMM. Так что и нам нельзя терять темпа и свободы действий. Особенно это важно в связи с планируемым вхождением России в ВТО. * * *Читатели, заинтересовавшиеся мнением наших сегодняшних собеседников, смогут встретиться с ними в апреле на 3-й Всероссийской практической конференции “Стандарты в проектах современных ИС”, а в июне - на 17-м Международном конгрессе по управлению проектами в Москве.


2000. Затраты на подготовку проектов окупаются сторицей

Вы, разумеется, не станете возводить дом на песке. Вот и страховая компания Chubb Group of Insurance решила: хватит строить информационные проекты на зыбкой почве предположений. Чтобы заложить под них прочный фундамент, решено было организовать проектный отдел. “Сегодня, когда технологии управления проектами развиваются со скоростью света, а в нашем бизнесе происходят постоянные изменения, необходимо работать лучше, быстрее и рентабельнее, - уверена Джоан Капуто, помощник вице-президента компании Chubb. - Только так можно удержаться на плаву и успешно конкурировать с другими страховщиками”.Говоря о скорости света, Капуто подразумевает влияние электронного бизнеса на сроки выполнения проектов. Именно этот фактор заставляет организации, активно использующие информационные технологии, создавать группы контроля проектов. В компании Chubb все без исключения проекты проходят экспертизу, на основании которой принимается решение об их реализации. Впрочем, такой практики придерживаются и другие компании. И в этом есть смысл. Как свидетельствуют данные Standish Group, в прошлом году неудачей закончилось около 74% всех начатых проектов, - не слишком ли много домов, утонувших в зыбучих песках?Проектный отдел создается подразделением информационных технологий и служит его целям. Он действует на основе формализованного набора процедур, охватывающих самые разные сферы: и контроль за всеми этапами подготовки и реализации проекта, и его коллективное обсуждение, и проверка сроков выполнения, и анализ использования ресурсов, и планирование, и документирование. Если все сделано правильно, такой отдел не просто освобождает менеджера проекта от черновой работы. Он может предложить общую методику объединения разнородных систем при слиянии компаний, помогает повысить эффективность электронного бизнеса, обеспечивает обмен знаниями между сотрудниками. И, наконец, самое главное: отдел проектирования дает менеджеру по информатизации возможность налагать вето на сомнительные начинания и своевременно выявлять те элементы проекта, которые могут выйти далеко за исходные рамки.Однако не следует думать, будто идея четкого контроля легко найдет понимание у специалистов ИТ и служащих бизнес-подразделений. Чтобы реализовать ее, руководству Chubb, к примеру, даже пришлось пойти на уловку. В течение четырех лет новая структура работала едва ли не подпольно и лишь недавно получила свое настоящее название. До этого оценка проектов велась под более скромной вывеской - служба поддержки проектов.К сожалению, сопротивление персонала - далеко не единственная преграда на пути к полному контролю за проектами. Во-первых, на развертывание отдела проектирования и разработку всех его процедур приходится затрачивать немало сил и времени. Во-вторых, у сотрудников, как правило, просто не хватает знаний и опыта, необходимых для управления проектами. Учитывая все это, высшее руководство должно заранее приготовиться к решению нелегкой задачи: убедить в необходимости проектного отдела как менеджеров по ИТ, так и рядовых служащих.Может возникнуть вопрос: а стоит ли игра свеч? Ответ прост. Организация электронного бизнеса грозит в любой момент превратиться в сущий ад. Чего стоит одна только интеграция разнообразных технологий. А ведь нельзя забывать и о политических трениях, которые неизбежно возникают, когда приходится ставить бизнес-подразделения в жесткие рамки единой организационной структуры.Эксперты, познакомившиеся с работой проектных отделов на практике, видят в таких подразделениях один из способов наведения порядка. Этого мнения, в частности, придерживается Стив Чихос, директор общенационального проектного отдела консультативной фирмы Born Information Services (Миннеаполис, шт. Миннесота). Его фирма, активно участвующая в электронном бизнесе, уже приступила к организации проектного отдела, призванного связать воедино многочисленные подразделения, рассеянные по стране, и тем самым взять все и вся под строгий контроль. “При первой же попытке наладить взаимодействие таких организаций приходится сталкиваться с недопониманием и неверной интерпретацией требований проекта”, - отмечает Чихос. А такая почва слишком зыбка для реализации серьезной инициативы.По мнению экспертов, отдел проектирования лучше всего создавать в рамках подразделения ИТ, поскольку именно его сотрудники, как правило, играют главную роль в подобных проектах. Конечно, знаниями, необходимыми для управления проектом, в идеале должны обладать все служащие организации. В этом случае выгоды от унификации процесса будут ясны и понятны всем бизнес-подразделениям. Но мы живем в реальном мире, и поэтому одной из главных задач отдела проектирования становится распространение знаний.В Американской ассоциации адвокатов (Чикаго, шт. Иллинойс), например, популяризация проектного отдела осуществляется в тесном взаимодействии с кадровыми структурами. По договоренности с информационными службами кадровики взяли на себя подготовку служащих бизнес-подразделений к совместной работе над проектами. Благодаря этому, как отмечает Пэт Мак-Махон, менеджер отдела управления проектами этой ассоциации, специалисты ИТ перестали быть единственными обладателями таких знаний.“Мы постепенно отходим от модели, при которой пользователи высказывают свои требования, а информационная служба чудесным образом превращает их в реальный продукт, - пояснила она. - Времена, когда вся работа велась в информационных структурах, канули в Лету или, по крайней мере, должны кануть”.Но порой в поддержке нуждаются и подразделения ИТ. Некоторые скептически настроенные менеджеры по информатизации, заваленные массой других дел, ссылаются на большую занятость: им, мол, просто некогда заниматься проектным отделом, вести бесконечные обсуждения и анализировать множество разнообразных отчетов. Где взять время, спрашивают они, чтобы контролировать сроки работ, соответствие реальных расходов бюджетным ассигнованиям, ход поставок, своевременность представления промежуточных отчетов?Но ведь назначение проектного отдела как раз и состоит в том, чтобы освободить менеджера от подобной черновой работы! “Такая структура призвана избавить руководителя от рутинных операций, - подчеркнул Гопал Капур, президент центра управления проектами Center for Project Management (Сан-Рамон, шт. Калифорния). - Хороший проектный отдел предоставляет руководителю проекта всю информацию, необходимую для принятия решений, освобождая его от сбора и анализа данных”.Все это достигается за счет упрощения и унификации процессов, распространения опыта, накопленного при реализации прошлых проектов. К тому же проектный отдел помогает избежать дублирования одних и тех же операций в параллельно работающих группах. Однако убедить менеджера проекта в преимуществах такого отдела - еще не все. Необходимо преодолеть следующее препятствие - на этот раз психологическое. Много ли найдется руководителей, готовых терпеливо внимать указаниям о том, как должна выполняться их работа?Чтобы преодолеть сопротивление, эксперты рекомендуют особо тщательно подойти к подбору кадров. Прежде всего, во главе проектного отдела нужно поставить человека, хорошо известного специалистам ИТ и пользующегося у них авторитетом. “Зачастую проектные отделы комплектуются администраторами, которые давно забыли, что такое проект, - заметил Капур. - Они не вызывают никакого уважения, а потому их рекомендации попросту игнорируются”. У-ва-же-ни-еРуководство подразделения ИТ компании Chubb на собственном опыте убедилось, насколько важно добиться уважения к проектному отделу среди специалистов-информатизаторов и каких трудов это стоит.Чтобы завоевать доверие, понадобилось шесть лет напряженного труда и успешного выполнения целого ряда проектов, в том числе и по созданию новых приложений. Лишь так удалось убедить инженеров, что концепция проектного отдела действительно жизнеспособна.Сегодня каждый руководитель группы видит на рабочем столе Lotus Notes пиктограмму-лицензию на ведение соответствующего проекта. Достаточно одного щелчка на ней - и концепция проектного отдела вступает в действие. Компьютер становится всезнающим помощником, готовым дать ответ на множество вопросов. Какой инструментарий нужен для создания нового ПО? Должна ли окончательная версия ПО поддерживать круглосуточное функционирование системы без выходных? Как будет финансироваться проект?Но это всего лишь первый, так сказать, индивидуальный уровень, который органично вписывается в коллективную работу. Каждые две недели руководство компании проводит совещания по лицензированию проектов, где осуществляется экспертиза проектов и анализируются их детали. На такие встречи приглашаются специалисты по ИТ, эксперты по безопасности и программной архитектуре, представители бизнес-подразделений. Чтобы проект не оказался построенным на песке, участники совещаний должны быть уверены в его соответствии стандартам и нормативам. Скажем, нужно убедиться, что никто из служащих не установил на своем компьютере версию приложения, которая пока не поддерживается системой.Однако не следует думать, будто скептицизм присущ только подразделениям информационных технологий. В крупной авиакомпании, где Чихос руководил проектом до перехода в Born, самое упорное сопротивление он встречал в бизнес-подразделениях - их сотрудники боялись оказаться заложниками новой структуры.Как вспоминает Чихос, их реакция была примерно такой: “Теперь, когда вы контролируете мельчайшие детали проекта, вам становится не до нас, грешных. Вы превращаетесь в сторонних наблюдателей”. Сотрудники были уверены, что проектный отдел помешает специалистам по ИТ оперативно реагировать на их нужды.Развеять такие опасения пытается Мак-Махон. Она считает, что хороший проектный отдел должен быстро идентифицировать новые потребности и сразу же включать их в собственный проект. С административной точки зрения внутренний проект ничем не отличается от любого другого: проводится столь же тщательный его анализ, определяются приоритеты, выделяются ресурсы. “Чем ближе пользователи знакомятся с системой, - отмечает Мак-Махон, - тем больше они хотят получить от нее. Мы собираем все пожелания, чтобы реализовать их на втором этапе проекта”.И это, возможно, одно из главных достоинств проектного отдела. Подобный подход дает руководителю проекта дополнительный рычаг управления, помогающий справиться с быстро растущими запросами пользователей. А поддержка проектного отдела со стороны высшего руководства компании предоставляет ему еще одну возможность, о которой раньше можно было только мечтать. У менеджера проекта появляется право вето.“Менеджеры получают прочную опору, необходимую для работы с пользователями, - поясняет Чихос. - Теперь на них будет не так-то просто нажать, чтобы они ускорили выполнение проекта, изменили его функциональность, сократили расходы, изменили масштабы”.Поддержка со стороны проектного отдела облегчит жизнь и специалистам по ИТ. Они смогут спать спокойно, ибо проекты теперь закладываются на надежном фундаменте. Когда нужен проектный отдел?Что заставляет корпорации приниматься за создание проектного отдела? Чаще всего можно слышать, что предприятие созрело для него. Об этом свидетельствуют безнадежное отставание от планов или огромный дефицит бюджета. Однако есть и другие причины, не столь явные. Ниже приведены лишь некоторые предупредительные симптомы.- Стоны и жалобы отдела ИТ. На очередном совещании вдруг раздается: “Мы отстаем от плана из-за нехватки нужных спецификаций”. Это значит, что предприятию пора брать на вооружение методики проектного отдела. Они гарантируют тщательный анализ и подбор всех спецификаций в самом начале работы над проектом, благодаря чему его участники получают довольно полное представление о конечных результатах.- Дублирование работы подразделений. Одинаковые обзоры, повторяющие друг друга оценки, несовместимые комплекты стандартов - все это присуще тем организациям, где различные команды работают над сходными, а то и дублирующими друг друга проектами, имея самое смутное представление о своем месте в общей системе. Проектный отдел становится своего рода штабом, который помогает избавиться от ненужной потери времени, материальных и трудовых ресурсов.- Повторение ошибок. Тот, кто не учится на ошибках прежних проектов, обречен на их повторение. Если на предприятии не налажен обмен опытом между группами разработки, если они ничего не знают об ошибках друг друга, значит, пора переходить на модель проектного отдела.- Нехватка руководителей проектов. Как это ни парадоксально, но о развертывании проектного отдела в первую очередь нужно задуматься именно тем предприятиям, где ощущается острая нехватка в руководителях проектов. Опираясь на такую структуру, маститый менеджер, даже один-единственный, получает возможность распространять свой опыт в масштабах всей организации. В его силах теперь унифицировать процесс разработки, наладить обучение и подготовку остальных менеджеров проектов, обеспечить руководство ими.Источник: материалы PC Week. Как заполучить профессионала для проектного отделаПроектный отдел сослужит хорошую службу любой корпорации, ведь унифицированный подход к созданию проектов значительно упрощает управление ими и повышает качество работы. Но вот вопрос: а достаточно ли у вас квалифицированных специалистов для новой структуры? Ведь найти их будет не так-то просто. Бурное развитие электронной коммерции привело к тому, что руководителей проектов сегодня впору заносить в Красную книгу. Выследить эту породу профессионалов вам помогут заметки, приведенные ниже.Кто они?Нарисовать общий портрет руководителя проекта довольно сложно - эти специалисты столь же многолики, как и проекты, осуществлением которых им приходится руководить. Можно только отметить, что в прошлом большинство менеджеров были инженерами или занимали руководящие посты в информационных службах.Насколько велик спрос?В октябре Gartner Institute попросил специалистов по ИТ перечислить самые дефицитные профессии. 38% опрошенных назвали специалистов по планированию проектов и руководству ими. В общем списке профессий, необходимых для развертывания электронного бизнеса, такие сотрудники оказались на пятом месте.Где искать?Поищите поблизости отделение какого-либо института, занимающегося подбором этих редких специалистов, их подготовкой и поддержкой. Хорошей почвой для взращивания руководителя проекта могут служить программы сертификации. Впрочем, многие компании предпочитают готовить менеджеров проектов своими силами или обращаться к услугам консультантов в этой области.


1995. Time Line облегчает задачу управления проектами за счет гибкости и поддержки ODBC

Мощь и гибкость программы Time Line 6.5 позволяет менеджерам осуществлять четкое управление портфелем проектов, ресурсов и приложений. Версия 6.5 под Windows этого пакета корпорации Time Line Solutions для управления проектами (цена $699) вышла в сентябре. В ней улучшен интерфейс и расширены возможности конфигурирования пакета самим пользователем. Однако самым значительным изменением, внесенным в продукт, является поддержка совместимых со стандартом ODBC (Open Database Connectivity) SQL-баз данных, что облегчает совместное использование данных и управление проектами.Компании, которые больше заинтересованы в управлении сотрудниками, работающими над проектом, а не деталями самого проекта, могут изучить пакет ManagePro 3.0 фирмы Avantos Performance Systems. В ManagePro основное внимание уделяется мониторингу и обзору работы сотрудника, а возможности управления проектами минимальны. Однако Time Line - хороший выбор для компаний, которым нужен надежный, гибкий, ориентированный на работу с ресурсами пакет для управления проектами. Time Line можно настроить для взаимодействия с другими приложениями компании и таким образом упростить обработку большого количества проектов. Кроме того, хотя интерфейс программы Time Line может показаться сложным, пользователям, которых пугает трудность изучения инструментов управления проектами, очень помогут предлагаемые пакетом подробная документация и система оперативной помощи. Достоинства программы Time Line этим не исчерпываются: в ней существуют две дополнительные системы - Guide Line (планировщик проектов, который создает расписания, задавая пользователю подробные вопросы) и Crystal Reports Version 4 (мощный инструмент генерации отчетов).