Главная Промышленная автоматика.

здания, документы и информация. Эксплуатационные и физические интерфейсы имеют место во всех этих видах продуктов.

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

Типы интерфейсов проекта

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

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

кий отдел завершает работу над спецификацией, затем отдел снабжения аД- начинает закупки по указанной спецификации. Ее передача из инженерно- " технического отдела в отдел снабжения является интерфейсным событи- Ш ем (исходящим для инженерно-технического отдела и входящим для отде ла снабжения). Данная ситуация может рассматриваться и как пример =" информационного интерфейса.

2. Результат действия. Результаты выполнения одной задачи требуются для на-чала другой. Пример: прежде чем поставщик оборудования начнет его монтаж, подрядчик по бетонным работам должен закончить заливку фундамента. Это также может трактоваться как интерфейс, связанный с изменением ответственности.

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

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

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

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

13.5 СВЯЗУЮЩИЕ СОБЫТИЯ ПРОЕКТА

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

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

13.6 пять ЭТАПОВ УПРАВЛЕНИЯ ВЗАИМОДЕЙСТВИЕМ ПРИ ИСПОЛНЕНИИ ПРОЕКТА

Управление интерфейсами проекта состоит из пяти этапов:

1. Выявление.

2. Документирование.

3. Календарное планирование (календарная привязка).

4. Коммуникация (информационное взаимодействие).

5. Мониторинг и контроль ключевых интерфейсных событий.



Выявление

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

Документирование интерфейсных событий

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

1. Координационный список включает новые события, еще не занесенные в другие списки.

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

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

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

® коды: кодовый номер события, согласованный с используемыми в проекте процедурами сетевого планирования, а также идентификатор, указывающий, что данное событие является интерфейсным;

® описание события;

Календарное планирование

Третий этап в управлении интерфейсами - определение календарной даты для каждого интерфейсного события, согласующейся с текущим единым главным расписанием проекта.

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

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

задействованные организации:

- породитель;

- получатель (получатели);

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



времени до завершения каждой задачи, а не вычисление процента (доли) выполнения.

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

Коммуникация (информационное взаимодействие)

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

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

Мониторинг и контроль интерфейсных событий

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

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

• контроля интерфейсных событий;

• процедур и методов утверждения и контроля работ;

• распоряжений по проекту;

• процедур оценки и пересмотра проекта.

13.7 выводы

Надежные методы управления интерфейсами проекта обеспечивают:

• прояснение ролей и обязанностей, уменьшение числа конфликтов;

• понимание того, кто и что именно должен предоставить каждому члену команды проекта. Совершенствование работы в команде и укрепление контактов;

• улучшение планирования, составления расписаний и контроля проекта;

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





0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73

0.004