Предпосылки

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

1. технология;
2. администрирование;
3. политика.

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

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

Методология: техника анализа case study

Технику анализа case study (ТАКС) принято считать наиболее адекватной, когда требуется целостное и глубокое исследование. Эта техника позволяет исследователю изучить каждый case study как единое целое. Для этого осуществляется сбор фактов, и на основе этих собранных фактов основываются сделанные выводы. ТАКС позволяет наилучшим образом раскрыть точки зрения участников исследования, используя при этом различные источники данных. Процесс сбора и сравнения многочисленных источников данных иногда называется "стратегия трехстороннего исследования". Эта стратегия разработана с целью увеличения надежности выводов исследования. ТАКС также обычно применяется в случаях, когда необходимо подтвердить или опровергнуть какую-либо теорию, представить уникальный или чрезвычайный случай, а также найти подход к явлению, которое ранее было недоступно для объяснения.

И все же ныне существующая практика ТАКС в сфере информационных систем организаций оставляет желать много лучшего. Sahay и Walsham (1995) изучили 199 статей, посвященных развитию информационных систем и пришли к выводу, что исследователи в процессе работы над индивидуальными case studies или сознательно не прибегали к ТАКС, или использовали смешанную методику при исследовании. Помимо всего прочего, было обнаружено, что исследователи постоянно оставляли без внимания существующую сейчас литературу по корпоративным информационным системам, а также они не ставили в известность своих читателей о том, какой подход они используют при рассмотрении критических проблем исследования case study. Также исследователи не сообщают подробностей о своих результатах case studies. Более того, Sahay и Walsham утверждали, что ученые даже и не пытаются объяснять, почему они выбирают тот или иной метод исследования, как они собирают данные и даже как они проводят само исследование (Sahay and Walsham, 1995).

Подобное исследование было предпринято с целью найти ответ на эти вопросы. При этом также эта работа осуществляется в рамках единого ТАКС, который включает в себя проблемы выбора, годности, обобщения и сообщения. Case studies осуществляются, в основном, выборочно и концентрируются на каком-то одном вопросе, являющемся центральным для понимания более общей проблемы. Отсюда следует, что от исследователя требуется выбирать такие примеры (cases), которые могли бы в отведенное для исследования время принести максимальные результаты. В соответствии с этим, основной исследователь выбрал два case studies из 30 ИТ-проектов из-за того, что руководители этих проектов продемонстрировали абсолютно разные стили руководства (технический против политического). Целью исследования было изучить эту разницу для того, чтобы иметь представление, как каждый из стилей влияет на исходный результат технологических проектов. Проблемы состава и внутренней валидности были решены командой исследователей путем сбора и сопоставления данных из разных многочисленных источников. Исследователи использовали шесть источников case study:

1. документация;
2. архивные записи;
3. интервью;
4. непосредственное наблюдение;
5. наблюдения за участниками;
6. физические артефакты.

Однако, для исследования какого-либо одного case study исследователи редко использовали все шесть источников. Наша команда исследователей использовала четыре из шести способов. Мы собрали и проанализировали такие документы, как демонстрационные слайды проектов, а также провели непосредственные наблюдения. Например, мы посетили одну важную презентацию проекта, которую проводил руководитель-"технолог" из Министерства транспорта. Мы также "вживую" наблюдали, как другой руководитель проекта проводил переговоры с одним из своих клиентов в Министерстве юстиции. Эти наблюдения помогли нам глубже понять разницу между техническим и политическим стилями руководства проектами. Также нами были проведены обстоятельные собеседования с участниками исследования. Часто для выяснения некоторых вопросов нам приходилось устраивать другое интервью. Мы тщательно и терпеливо собирали все ответы и пояснения наших участников исследования и даже вынуждены были отложить публикацию окончательного отчета с целью дать возможность руководителю проекта из Министерства транспорта прокомментировать полученные нами результаты, касающиеся последствий его "технического" стиля руководства проектом. Наконец, мы тщательно исследовали физические артефакты, которые были предложены в наших case study проектах (электронная доска объявлений в случае с Министерством транспорта и компьютеризированная информационная система в случае с Министерством юстиции). Например, изучив размещение электронных досок объявления и их физические характеристики, мы пришли к выводу, что руководитель проекта из Министерства транспорта не смог выполнить свою задачу в соответствии с запланированным проектом.

Часто отчеты case study обвиняют в ненаучности, потому что их нельзя подтвердить и их заключения нельзя обобщить. Те, кто непосредственно работает с ТАКС, в ответ заявляют, что их выводы вполне поддаются обобщению, если они делаются в строгом соответствии с ТАКС-протоколом, который разрабатывается еще до начала сбора информации. В этом протоколе предусматриваются навыки, необходимые для конкретного исследования, методы подготовки к сбору информации, то, как должна собираться и анализироваться информация и как должны формулироваться выводы. В нашем случае руководитель исследования выбрал, обучил и проинструктировал двух студентов магистратуры. В свою очередь последние тщательно собирали данные, основываясь на вопросах интервью и на инструкциях руководителя. Кроме того, в ходе исследования руководителем были задействованы несколько подходов к изучаемой проблеме (включая психологию, социологию, политологию и деловое администрирование). Это было предпринято, чтобы заранее определить пять направлений, относящихся к проблеме руководства проектами. На основе этих пяти подходов была осуществлена подготовка вопросов для интервью, а также разработаны инструкции для проведения анализа документов и непосредственных наблюдений. Мы попытались удалить из окончательного отчета весь профессиональный жаргон для того, чтобы сделать документ доступным для как можно большей аудитории читателей.

Ужасное состояние дел в сфере ИТ-проектов

Американские компании тратят в год более 250 миллиардов долларов на техническое внедрение приблизительно 175 000 проектов. Лишь в 16% случаев это удается сделать в запланированные сроки и уложиться в отведенные средства. Количество проектов, свернутых до окончания их реализации, составило 31%. 53% доведенных до полного осуществления проектов вышли за рамки их бюджетов. Только в 1995 году государственные организации и компании США истратили 81 миллиард долларов на те ИТ-проекты, которые были свернуты до их полного осуществления. 59 миллиардов долларов было затрачено на проекты, внедрение которых происходило позже намеченных сроков. Практически невозможно измерить в этих случаях упущенную выгоду, но она вполне может составлять триллионы долларов (Agarwal, 1998; Meyer, 1998).

В учебной и специальной литературе практически невозможно найти советы по тому, как измерить степень риска новой технологической системы в государственном и частном секторах. В редких случаях проект официально признается неудавшимся. Примером этому может служить неудавшаяся модернизация компьютерных систем в Internal Revenue Service и в US Information Agency. Часто пользователи новых информационных систем считают их неэффективными, сложными в использовании и обреченными на провал. Новые ИТ-системы терпят неудачу из-за многих причин. Сюда можно отнести и несоответствие насущным требованиям, плохие интерфейсы пользователей, дизайн системы, который не соответствует корпоративной культуре. Также объяснением неудач можно считать и то, что при разработке систем большее внимание уделяется именно техническим вопросам, эти системы не столь качественно обрабатывают данные и у них велики операционные издержки.

Исследователи из Center for Research on Information Technology и Organizations at the University of California in Irvine вот уже более 25 лет занимаются проблемами ИТ-систем в государственном секторе. Изначально исследователи из Irvine занимались в основном технологическими аспектами, такими как определение эффективности и экономии, полученных в результате централизации или децентрализации компьютерных служб на муниципальном уровне.

Однако начиная с середины 80-х годов у ученых из Irvine стало формироваться глубокое подозрение в отношении взглядов на информационные технологии в государственном секторе. Изучив данные отчетов по 46 городам США (1976-1988), исследователи из Irvine обнаружили, что в большинстве местных органов преимущества компьютеризации ограничивались вопросами контроля, снижения издержек и улучшением контактов с публикой. Они также обнаружили, что совершенно остались без внимания вопросы лучшего информационного обеспечения в целях планирования и управленческого контроля. А ведь именно на них делали основной расчет, полагая, что это будет способствовать повышению эффективности работы государственных организаций. В результате полученных выводов, исследователи стали считать, что центром внимания должны стать сами программы информационных технологий. Специалисты, осуществляющие обслуживание конечных пользователей, должны максимально учитывать их специфические потребности и менталитет. К большому сожалению, выводы ученых из Irvine так и не вышли за пределы лозунга "люди - составная часть технологии" (Alic, 1990). Более того, упомянутые исследователи не показали, как нужно структурировать ИТ-проекты для того, чтобы повысить их шансы на успех.

Литература по технологическому руководству

В последнее время ученые начали непосредственно заниматься проблемами управления ИТ-проектами в государственном секторе. Их цель - выработать конкретные советы, как улучшить эти проекты. Но фактически ничего не было написано о той роли, которую играют руководители в успешном (или неудавшемся) осуществлении своих проектов. Поэтому мы были вынуждены обратиться к книгам, посвященным частному сектору. Там мы обнаружили четыре классических объяснения тому, почему некоторые руководители проектов добиваются успеха, а некоторые - нет. Первое объяснение – "сначала психология". Здесь для того, чтобы объяснить, почему некоторые руководители выходят победителями. Mintzberg (1976) выдвигал гипотезу, заключающуюся в том, что у преуспевающих руководителей хорошо развито правое полушарие головного мозга, которое отвечает за симультанные, относительные и целостные мыслительные процессы. По его мнению, эти мыслительные процессы являются более критически важными для успеха менеджера, чем линейные, последовательные и аналитические мыслительные процессы, свойственные для левого полушария человеческого головного мозга. Также Бадауи (Badawy, 1982) видел причины успеха руководителей проектов в их потребности управлять другими людьми, в их потребности во власти и в их способности сопереживания. Zaleznic (1977) развил эту мысль и предложил способ, как организации могут способствовать психологическому развитию руководителей-победителей.

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

Третье объяснение - "сначала человеческие отношения". Здесь основное внимание уделяется тому, как руководители-победители взаимодействуют с другими людьми. Peters и Waterman (1984) предполагали, что, формируя и продвигая новый набор ценностей, руководители-победители тем самым делают значимой ежедневную рутинную работу своих команд. В этом они превосходят всех остальных. McCall (1983) также утверждал, что преуспевающие руководители знают, как сделать так, чтобы их подчиненные специалисты трудились в условиях "контролируемой свободы". Такие лидеры знают, что нужно сделать для того, чтобы служить часовым механизмом команды, чтобы выдвигать перед членами команды новые горизонты, как сделать так, чтобы члены команды сами хотели бы стать лидерами.

Четвертое объяснение - "сначала организация". Здесь утверждается, что у любого менеджера есть возможность стать победителем, при условии, что в самой организации у него есть должная поддержка. Kanter (1984) говорила, что менеджеры-новаторы трудятся "в тех организациях, где сама корпоративная культура поощряет сотрудничество и командную работу и где сама структура этой организации способствует тому, чтобы люди "делали то, что надо делать и как надо делать" (1982). В своей работе она подчеркивала, что у руководителей должны быть и возможность, и заинтересованность для того, чтобы решать запутанные проблемы, выходящие за рамки их формальных обязанностей. Она поясняла, что подобные возможности создаются и существуют в тех организациях, где поощряется свободный обмен информацией, где существуют взаимопересекающиеся круги обязанностей, что позволяет руководителям вынашивать и воплощать собственные замыслы. В таких организациях менеджеры имеют достаточную (но разумную) бюджетную свободу, и там существует хорошо продуманная и эффективная система поощрений (Kanter, 1982).

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

Политический характер преуспевающих технологических руководителей

Более чем когда бы то ни было руководители проектов должны обладать самыми современными технологическими, административными и политическими знаниями. Основной задачей является объединение новых и старых технологий и воплощение их в эффективные ИТ-системы. Более того, в современных программных проектах отражаются последние технологические достижения. Поэтому от руководителя требуется постоянно быть в курсе новых концепций и методов. Например, существуют такие инструменты, как MS-Project, предназначенные для управления сложными проектами. Также существует такая специализированная программа, как Unified Methodology Language (UML), которая служит для проведения анализа требований того или иного проекта. ИТ-продукция стала неотъемлемой частью организационных систем. Поэтому у руководителей часто остается слишком мало времени для того, чтобы детально изучить новые технологии до того, как перед ними будет поставлена задача об их практическом внедрении.

На административном фронте тенденция к реструктуризации привела к тому, что компании увольняют миллионы работников и при этом отказываются набирать новых (Hammer and Champy, 1993). Те руководители, которые остаются на своих постах, оказываются в ситуации, когда они отвечают за большее количество проектов, но при этом имеют в своем распоряжении меньшее количество людских ресурсов. Их проектные команды состоят из крошечного количества основных штатных работников и огромного количества всякого рода консультантов и подрядчиков, которые совершенно не обязаны проявлять к данной организации свою лояльность (Rufkin, 1995). Подобное "кочевое племя специалистов-космополитов" очень трудно удержать, трудно заинтересовать. Более того, они очень щепетильно относятся к попыткам их контролировать. Работая с ними, очень трудно сохранять высокий уровень сервиса, потому что большинство подобных "торговцев high-tech" продают свои услуги на почасовой основе и при условии, что время контракта не будет превышать трех-шести месяцев. Они внимательно следят за тем, как работает руководитель, и при первых же признаках угрозы провала проекта они тут же бегут с корабля. Поэтому руководителям в этом случае приходится постоянно работать над тем, чтобы держать ситуацию с людскими ресурсами под контролем.

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

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

Другие исследователи обнаружили, что те руководители, которые очень много внимания обращают на чисто технологические решения, могут пасть жертвой (вместе со своими проектами) политической борьбы в компании (Boston, 1994; Saint-Martin, 1998). Именно политика находится на первом месте у руководителей-победителей.

Ход исследования

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

Ситуация 1: Электронные доски объявлений (Министерство транспорта)

Цель Министерства транспорта Израиля - обеспечить регулярные, высококачественные и эффективные транспортные услуги. К сожалению, в стране отсутствует хорошо развитая система муниципального транспорта и многие жители пригородов вынуждены добираться на работу на автомобилях. В период с 1982 по 1997 год количество автомобилей на дорогах увеличивалось на 5% ежегодно, в то время как рост дорожной инфраструктуры составлял всего 1,5% в год (Central Bureau of Statistics, 1998). Повсюду вокруг зажиточных районов Тель-Авива в часы пик возникали огромные пробки. Газеты назвали транспортную проблему "проклятьем государства". Чтобы успокоить гневную публику, министр транспорта пытался прибегать к "пожарным" решениям. В начале 1994 года министр учредил новую комиссию, состоявшую из известных ученых, целью которой было "служить в качестве решающего органа во всех вопросах, касающихся разработки, исследований, развития и внедрения во всех областях транспорта". Новая комиссия начала с поисков компромиссных решений жуткой транспортной проблемы.

В качестве главного специалиста был назначен ученый с мировым именем, который специализировался на "умных" транспортных системах. У него были научные степени бакалавра института Israels Technion, магистра и доктора Массачусетского технологического института. За его плечами были три опубликованных книги, более сотни статей по проблемам практического применения динамичного программирования, теории сетей, по вопросам внедрения результатов исследований в планирование транспортных систем. Также он сотрудничал с международным обществом исследователей транспортных систем. Он выступал в качестве делегата от Израиля в транспортной программе Европейского Союза, был членом оргкомитетов нескольких международных конференций и являлся президентом Израильской ассоциации исследователей транспортной системы. Главный специалист предложил создать сложную систему для сбора информации в режиме реального времени. Эта информация должна поступать от автолюбителей, полицейских машин и вертолетов. Используя сложные алгоритмы, данная информация обрабатывалась системой, которая затем отражала свои рекомендации на огромных электронных досках, которые должны были ставиться на перекрестках основных дорог. Тогда водители могли бы, опираясь на эту информацию, выбирать, по какому маршруту им лучше ехать и какие условия движения их ждут впереди.

Ситуация 2: Данные земельного кадастра (Министерство юстиции)

Одна из задач министерства юстиции - управлять, регистрировать и контролировать соблюдение прав граждан на собственность и другие права. В обязанность министерства входила регистрация всех транзакций, связанных с собственностью на землю. Вплоть до конца 1970-х годов подобная регистрация осуществлялась вручную. Контроль за более чем двумя миллионами объектов собственности осуществлялся с помощью буклетов, размером 40х60 см, в каждом из которых содержался план с фотографией объекта. Эти реестры были распределены между девятью подразделениями министерства, каждое из которых представляло собой вполне самостоятельную организацию, в ответственность которой входила определенная географическая зона. Порядка 30-50% этих буклетов не имели дубликатов. Ситуация осложнилась в период между 1967 и 1997 годами, когда к существующему кадастру в Израиле добавилось более 9% новых объектов (пик роста пришелся на 1974, 1991 и 1992 годы, когда страна столкнулась с большим количеством иммиграции). Организации поняли, что не могут справиться с растущим спросом и обеспечивать быстрое и эффективное проведение транзакций.

В 1978 году опытный государственный чиновник, отработавший 10 лет в Министерстве образования, был переведен на работу в Министерство юстиции, где и был назначен руководителем отдела информационных систем управления (ИСУ). Помимо выполнения всех прочих обязанностей, его попросили компьютеризировать операции, проводимые с объектами собственности.

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

Сравнение case studies

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

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

Осуществление проектов

Руководитель проекта из Министерства транспорта занял свою должность начальника ИСУ в начале 1977 года. Он быстро осознал, что его проект имеет больше политическую, нежели технологическую подоплеку. Он сказал:

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

Для того, чтобы обойти подобные политические препятствия, руководителю пришлось искать потенциальных союзников за стенами министерства. Он нашел, что Земельный комитет Израиля (Israel Land Authority, ILA) хочет создать компьютерную систему управления государственными землями. Тогда он убедил своих коллег из этого комитета совместными усилиями создать базу данных для регистрации и управления государственной собственностью. В течение следующих шести месяцев работники отделов ИСУ из министерства и из этого комитета разработали технические условия для этого проекта. В технических условиях были задействованы лучшие компьютерные технологии того времени: центральная база данных на центральном компьютере была доступна через модемы и интерфейсы пользователей.

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

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

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

Проект получил свое начало в одном из подразделений министерства в большом городе в центре страны. Систематически на протяжении последующих семи лет он продвигал свой проект от одного подразделения к другому. В каждом подразделении содержались данные по сотням тысяч объектов, каждый документ включал 2-3 тысячи буквенных и цифровых символов. Чтобы научить сотрудников каждого центра вносить данные с "разумным количеством ошибок", у его команды уходило по шесть недель. Два отдельных клерка должны были тщательно выверять каждый заполненный файл с целью проверки его точности. Когда ввод данных был завершен, команда обучала сотрудников данного подразделения тому, как пользоваться системой, и затем переходила работать с другим подразделением. Руководителю также при этом приходилось заниматься и урегулированием рабочих споров, так как работники требовали увеличения оплаты труда и без этого не хотели начинать работать с новой компьютерной системой. В 1986 году проект был завершен, и руководитель так объяснил свой успех:

Мне удалось успешно завершить начатое дело потому, что я не "ставил из себя специалиста-технолога". Я просто шел к руководству министерства со своими идеями, рабочими планами, стратегией и политикой.

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

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

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

Он уже как-то пытался создать электронные доски объявлений, но не смог успешно осуществить проект, который проходил по заказу муниципалитета города Хайфы. Этот неудавшийся эксперимент он приписывал отсутствию опыта и был полон решимости попробовать снова. Когда министр спросил его, что делать с этим транспортным кошмаром, он вызвался лично возглавить проект-пилот по созданию электронных досок объявлений (ЭДО). Министр согласился, определил начальный бюджет в сумме 400 000 шекелей, назначил наблюдательный комитет под его руководством и дал добро на начало работы над проектом. Главный специалист, выступая уже в роли руководителя проекта, решил синтезировать все недорогие источники данных о движении транспорта (такие, как вертолет, полиция, сообщения автомобилистов). При этом он не стал прибегать к более точным, но дорогим источникам информации (спутники, видеокамеры), решив использовать их на более поздних этапах проекта. Он решил создать промышленную систему, описывая ее следующим образом:

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

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

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

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

Но сопротивление росло не только в стенах министерства, но и вне его. Министерство имеет в подчинении два полусамостоятельных учреждения, которые осуществляют проекты, касающиеся дорожной инфраструктуры и контроля движения. Это - Maatz (государственный отдел дорожного строительства) и Netivei Ayalon (отвечающий за проекты организации дорожного движения в районе Тель-Авива). Последняя из упомянутых организаций уже работала над похожим проектом контроля движения, но руководитель проекта из министерства не захотел объединять эти два проекта на том основании, что проект Netivei Ayalon слишком дорог, медленно продвигается и не соответствует его стандартам. Он даже отказался делиться с Netivei Ayalon информацией, хотя именно эта организация имела полномочия устанавливать ЭДО на тех перекрестках, которые были предусмотрены его проектом. Некоторые из членов его команды советовали своему руководителю работать в тесном контакте с упомянутыми двумя учреждениями. Но он отказывался от такого сотрудничества, объясняя это тем, что его собственный проект представляет собой большой технологический рывок в отличие от замусоленных проектов, с которыми привыкли работать эти организации.

В течение 1995 и 1996 годов главный специалист разработал технические условия своего проекта, провел тендер на его выполнение и выбрал одного подрядчика для создания ЭДО, а другого подрядчика - для написания программы для аналитической системы. Затем в 1996 году вследствие роста сопротивления в отношении своего проекта он внезапно вышел в отставку и вернулся на работу в академию. После его ухода министерство решило поставить точку на этом проекте. Такое решение министерства один из его работников объяснил так:

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

В конце концов главный специалист сам признал, что его провал имеет политические корни. Вскоре после того, как данная статья была готова, он написал автору и ответил на некоторые вопросы. В ответ на вопрос "Что бы вы изменили в своей работе, если бы снова взялись бы за этот проект?" он написал:

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

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

Выводы

Важнейшим фактором является то, как руководитель воспринимает и видит свою руководящую роль. Руководитель из Министерства транспорта видел в свой работе только лишь технологическую подоплеку и игнорировал проблемы организационной политики. Его больше интересовали технологические, а отнюдь не социальные вопросы. Например, он подробно описывал будущую пользу своего проекта, но при этом не стал принимать во внимание параллельный проект Netivei Ayalon. В полную противоположность ему руководитель проекта из Министерства юстиции подчеркивал, что его роль заключалась в том, чтобы продвигать свой проект (от начала до конца) через все политические минные поля. Много времени он уделял описанию не связанных с технологией аспектов своего проекта (обучение пользователей, решение трудовых конфликтов). В то время как руководитель из Министерства транспорта хотел создать технологию мирового класса, его коллега из Министерства юстиции пытался найти технологию, которая соответствовала бы децентрализованной природе его организации. Ключевым моментом в окончательной судьбе проекта является то, как много внимания уделяет руководитель повседневному руководству. Менеджер из Министерства транспорта был убежден, что он ничего не может поделать для того, чтобы ускорить медленный бюрократический процесс. Совершенно обратной выглядит ситуация в другом случае, где руководитель проекта обходил оппонентов, уговаривал сомневающихся и даже сотрудничал со "средневековыми чиновниками", уважения к которым сам он не испытывал. В то время, когда специалист из Министерства транспорта пытался создать оптимальную единую коммуникационную технологию, его коллега из Министерства юстиции компьютеризировал одно подразделение за другим и в процессе этого создавал новую рабочую культуру в своем министерстве. Руководитель проекта из Министерства юстиции искал влиятельных союзников для своего проекта, а его двойник из Министерства транспорта отвергал даже параллельные проекты, разрабатываемые другими учреждениями.

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

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

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