1. Начало работы над проектом. Сбор информации о проекте. Нужно понимать четкое предназначение проекта. Для начала проекта нужно точно знать о признаках, свидетельствующих о завершении проекта. Проект начнется тогда, когда точно известно, к чему он приведет. Далее необходимо назначить срок начала и завершения проекта. Нужно ясно представлять цель проекта, разработку его этапов реализации и руководство командой к завершению проекта. На начальном этапе основной задачей является извлечение нужных сведений из того, что скажут люди. Все члены команды должны знать и понимать конечный результат проекта. Кроме точных требований к тому, что должен содержать проект, необходимо ясное представление о требованиях, не выполняемых в данном проекте. Нужно учитывать возможные промышленные и государственные ограничения, которые могут возникнуть во время реализации проекта. Необходимо согласовывать сроки выполнения работ. Убедиться в том, что спонсор проекта, человек на самом деле сможет выделять нужные ресурсы. Нужно утверждать бюджет до начала работы, иначе это будет не проект, а просто список требований. Узнать не разрабатывает ли кто-то в компании такой же или похожий проект. 2. Начало работы над проектом. Управление людьми. Опрос руководства. Опрос пользователей. Менеджер проекта должен ставить под сомнение концепции, технологии и время на каждом этапе разработки. Если новая технология изменит жизнь, то нужно узнать мнение людей об этих изменениях. Также следует протестировать работу технологии в существующей системе. Если компания применяет несколько ОС, то необходимо проверить совместимость с каждой из них. Если технология покупается, то необходимо знать применялась ли она где-то раньше, а также детали по использованию, тестированию и развертыванию продукта. Также нужно учитывать репутацию поставщика. Является ли он надежным Специалистам необходимо убедительно доказать, что технология оправдает надежды. Для реализации проекта необходима согласованность со взглядами руководства на то, какую пользу принесет компании результат проекта. В опросе руководства придется заняться выуживанием фактов, но если само руководство обращается с предложением решить проблему, то тогда проект становится более открытым. Начиная проект, нужно принять точку зрения руководства и оценить как их инвестиции будут способствовать увеличению прибыли. Любой проект нужно обсуждать с его пользователями. Можно обсудить его с помощью целевой группы, но нужно сохранить контроль над дискуссией и нацелить участников на поиск проблемы. Другим методом является создание сайта, где пользователи смогут обмениваться мнением и выражать свои точки зрения. Тесный контакт с пользователем поможет выяснить, как они применяют существующую технологию, как будет воздействовать на них новая, и в чем состоит конечная цель изменений. Наконец необходимо изучить, как выполняют свою работу пользователи. Это можно сделать в тестовой лаборатории, где будет запущена технология до внедрения 3. Начало работы над проектом. Определение цели проекта. Формирование обоснованных предположений. Определение даты завершения. Формирование документа проекта. Элементы документа проекта. Многие проекты разваливаются в самом начале. Основная проблема состоит в неправильном видении проекта, которое с точки зрения менеджера, означает ясный взгляд на проблемы и выявление действий по их устранению Цель суммирует план проекта в виде позитивного руководящего посыла. Дата завершения проекта базируется на фактах, результатах исследования и планировании. Проект состоит из последовательных этапов, по дате завершения всех этапов можно предсказать срок окончания проекта. На срок могут влиять следующие факторы: бизнес-циклы, финансовая ситуация, а также время года. Документ подобен цели, но является ее подробным и официальным изложением. Цели создания документа проекта: Описание проекта в целом Идентификация спонсора проекта Идентификация менеджера проекта Назначение спонсора и менеджера ответственности за проект Введение формального описания видения проекта Документ проекта состоит из официального названия проекта Контактной информации спонсора проекта Контактной информации менеджера проекта Целей проекта Бизнес условий проекта Обобщенных результатов проекта Общего описания методов работы членов проекта Базового граничного срока завершения работ Ресурсов проекта, его бюджета, сотрудников и изготовителей. 4. Исследование проекта. Как провести исследование. Целью исследования является получение точных данных, в общем случае не лежащих на поверхности, которые создают почву для принятия решений, планирования и реализации. Алгоритм планирования исследования 1. В письменной форме определить цели исследования. Это позволит точно сконцентрироваться на определенном диапазоне исследуемой области. 2. Определите ресурсы, привлекаемые на время исследования. Ведите список просмотренных публикаций. Он нужен не для отслеживания информационных источников. Он позволит упорядочить использование данных согласно приоритетности. К информационным источникам относится - предыдущий опыт; -опыт других людей; - проверенные и качественные сайт интернета; - специализированные журналы - книги по соответствующей тематике - рекламные публикации изготовителей 3. Делегирование. Если в проекте уже участвуют другие люди, привлеките их к исследованию. Разделите исследуемую область на секторы и присвойте их каждому члену команды. 4. Проведите работу по исследованию. Начните чтение. Анализ и обсуждение, сопроводив это согласованными заметками. 5. Организация и документирование. Соберите вместе всю информацию, накопленную лично и членами команды. Она станет основой для плана осуществимости. 6. Оцените полученный результат и проведите дополнительные исследования. Проверьте, дают ли объединенные данные ответ цели исследования. Если да, то исследование можно считать законченным, иначе продолжите исследования, придерживаясь данного алгоритма из шести шагов. 5. Исследование проекта. Установка приоритета проекта. Получение бюджетных средств. Менеджер проекта может одновременно заниматься несколькими проектами. В этом случае весьма полезна способность предоставить надежные бизнес-факты о приоритетности проекта. Другой подход состоит в создании специального подразделения по менеджменту проекта. Оно предоставляет традиционные услуги по менеджменту проектов и является руководящей структурой для всех проектов в этой организации. Одной из задач менеджера проекта станет согласование действий спонсора с командой проекта. Поддержание информативности спонсора текущем состоянии проекта позволит заинтересовать его самим проектом, что и должно быть сделано. Обычно спонсор проекта передает управление менеджеру проекта, который в свою очередь, передает все или некоторые задачи управления исследованием и реализацией проекта членам команды разработки. Установка приоритета между проектами может производиться: 1. Встреча менеджеров обоих проектов 2. Если они не могут прийти к соглашению, то к совещанию должны подключиться спонсоры. 3. Если спонсоры тоже не приходят к соглашению, то обсуждение должно продолжиться на следующем уровне иерархии компании 4. Менеджеры должны оценить и взвесить, какой из проектов более выгоден для компании. После этого можно принять решение, продолжить работу над обоими проектами, отменить один из них или перенести. Получение бюджетных средств. Решившись на внедрение новой технологии, следует тщательно подсчитывать необходимые затраты. Принять решение о новой технологии помогут вопросы; Как эта технология поможет повысить производительность в компании, будет ли высокий уровень возврата инвестиций ROI, почему технология станет правильным выбором через год, в чем состоит точка технологического прорыва для данных инвестиций, когда технология станет приносить большие доходы. Нужно приобретать правильную по своим масштабам технологию. Другим бюджетным аспектом является время. Оцените не лучше ли будет реализовать проект силами сторонних специалистов. Сторонние компании оценивают свои услуги 2 способами; во времени и материалам и по прибыли. В любом случае нужно оценить заявленную стоимость и подсчитать норму возврата инвестиций. 6. Исследование проекта. Формирование плана действий. Создание списка ключевых действий. Управление исследованием. План для непредвиденных ситуаций. Формирование плана действий Перед началом исследований необходимо иметь план проведения работ. Сколько времени выделить на каждый этап? Кто или что станет ресурсами проекта? Какова конечная цель проекта? Сможет ли кто-нибудь помочь в их проведении? Создание списка ключевых действий В списке исследований в сжатой форме отражаются основные этапы, необходимые для проведения проекта от начала до конца. Список задач формируется после выбора технологии и перед созданием плана реализации Есть несколько способов создания списка задач; просто перечисление, в виде диаграммы рабочих потоков, использование программ, подобных Microsoft project. Полезно сформировать последовательность или диаграмму рабочих потоков, а затем перенести ее в программное обеспечение управления проектами. Управление исследованием Если большая часть исследования проводится самостоятельно обратите внимание на потраченное время. Выделение слишком большого времени может привести к запутанным результатам. Нужно нацеливаться на задачи и придерживаться графика для каждого этапа. Если для исследования нужно привлечь сотрудников, тоне впадайте в микроменеджмент. Необязательно отслеживать действия каждого сотрудника. Когда все завершат работу нужно найти способ быстрого и простого объединения результатов и выбора на их основе окончательного варианта. Нужно провести совещание, на котором члены команды отчитаются о своей работе. После него организуйте распространение среди членов обобщающего документа. На основе высказанных мнений, готового отчета и интуиции можно принять правильное мнение. План для непредвиденных ситуаций. Отдельный план для непредвиденных ситуаций позволит заранее проанализировать решения, которые придется принимать при неуспешном продвижении проекта. Проект, не имеющий плана действий в таких ситуациях, скорее всего нельзя будет завершить вовремя или не выйти за рамки бюджета. Частью исследования должна стать запись обнаруженных опасностей, документирование любых конфликтов с существующей технологией и перечисление статей и публикаций, рассказывающих о проблемах, возникающих во время внедрения технологии. Одна из основных причин создания такого плана состоит в подготовке перехода к общению с руководством компании. Имея данный план можно получить доверительную и действенную поддержку проекта. 7.Работа с руководством компании. Представление проекта руководству компании. Презентация должна быть доходчивой, впечатляющей и информативной. Основой успешной презентации будет доскональное знание предмета выступления. Чем лучше известна тематика, тем убедительнее будут доводы выступающего. Причем знать нужно не только предметную область, но и особенности предполагаемого проекта. В начале нужно завоевать внимание аудитории. Лучше начать с конца, рассказать о том, что дает компании проект. Принцип. Что это дает мне (Whats in it for me) позволяет установит с аудиторией контакт таким образом, что все слушатели увидели преимущества от предполагаемого решения. Чтобы иметь реалистичную оценку, нужно применить этот принцип и проверить, насколько важен предполагаемый проект его менеджеру лично: Доходность. Проект должен приносить доходность Продуктивность. Проверьте, что проект повышает производительность труда в компании Личное удостоверение. Самое важное в принципе “Что это дает мне” - это возможность персонификации проекта. Найдите свойства, показывающие увеличение доходности, достоинства новой технологии, новые каналы сбыта или иные преимущества. Реклама – подумайте, как проект может улучшить продвижение продуктов компании на рынке. Во время доклада группе руководителей, нужно быстро обратить их внимание на те аспекты проекта, которые они смогут сразу понять. Если предстоит выступать перед руководителем, обладающим профессиональными знаниями, то расскажите ему о технических характеристиках технологии. Содержание презентации зависит от того, кому она предназначена, т.е. людей, которые будут принимать решения. Помочь в настройке целевой аудитории помогут вопросы: Кто будет утверждать проект Хочет ли аудитория слушать презентацию Действительно ли аудитория слушает презентацию Какую роль выберет себе менеджер проекта Чем поможет проект компании При продаже идеи говорите четко и ясно. Рассказ о причинах перехода на новую технологию не должен длиться не более 5 минут. Для любой презентации необходимы наглядные материалы - графики, диаграммы, слайды и т.д. 8.Работа с руководством компании. Определение роли менеджмента. Первые шаги нового проекта. Вопрос о взаимоотношениях менеджера проекта с руководителем предполагает, что менеджер сам становиться руководителем. Одной из первых и наиболее важных обязанностей станет делегирование обязанностей и полномочий. Менеджер проекта не сможет сам выполнить всю работу, поэтому после формирования команды потребуется не только доверие спонсора проекта и руководства, но и доверие членов команды. В начале проекта менеджеру стоит руководствоваться простыми советами - Следовать приказам руководства - Необходимо делегирование обязанностей - Все меняется, во время распределения обязанностей нужно предвидеть дальнейшее, но не следует забывать об изменениях проекта во время его реализации. - Помните о пользователях, которым придется пользоваться данной технологией. - Делегирование. Менеджеру предстоит большая работа, поэтому необходимо делегировать обязанности членам команды и позволить им делегировать задачи на следующие уровни управления. Менеджер проекта отвечает за его успешное завершение, побуждение членов команды к эффективному труду и общение с руководством. Менеджер проекта, помня о его конечной цели должен иметь: - Возможность заинтересовать проектом всех членов команды разработчиков - Возможность влияния на побудительные причины участия в проекте членов команды разработки - Возможность стимулирования как руководителей, так и членов команды разработки - Поддерживающего проект спонсора - Желание достичь цели проекта. Обычно первые шаги тесно связаны с совещаниями или конференциями, когда проект будет предоставлен руководству, которое утвердит проект, назначит его менеджера и челнов команды разработки. На первых шагах нужно точно определить дату начала работ над проектом, состав участвующих в нем сотрудников и тех, кто будет контролировать проведение работы. На первой встрече команды разработки можно заложить основы отношений на весь период работ . Рекомендации для достижения компромисса на первой встрече: Выберите легкую тему для разговора и обсуждение несложных задач Воодушевите людей. Все должны уйти со встречи довольными 9.Работа с руководством компании. Как найти контакт с руководством. Определение целей проекта. Формирование альянса с руководством. Совместная работа. Работа с «плохим боссом». Работа с «хорошим боссом». Спонсором должен стать один из руководителей, наиболее тесно связанный с проектом. Проект не является демократичным по своей сути, поэтому каждый член команды должен знать свою роль и свое место в иерархии. Для успешного проекта члена команды должны не только согласиться с подчинением менеджеру проекта, но и признать его руководящую должность. Во вступительной речи менеджера должны быть подчеркнуты следующие аспекты: - Определить свою роль в качестве менеджера проект - Точно описать цели проекта - Установить тональность своего поведения в роли менеджера проекта - Выразить влияние, оказываемое проектом на деятельность компании. - Определив цели проекта, покажите команде разработки обобщенный план реализации и распределения обязанностей. - В заключении расскажите об участии в проекте руководства компании. Покажите финансовые подтверждения, свидетельствующие об успешности проекта. Покажите, что от членов команды зависит успех проекта, и по возможности оцените то, как скажется на компании неудачное выполнение проекта. Менеджер и руководство входят в одну команду. Так же как менеджер хочет воодушевить и сформировать доверие у членов команды разработки, руководство хочет добиться того же от менеджера. Достигнув согласия с руководством, вне зависимости от совпадения мнений нужно будет совместно работать над реализацией проекта, поэтому необходимы командные отношения. В процессе реализации проекта должны возникнуть двухсторонние взаимосвязи – менеджер заинтересован в участии руководства, а руководство в успешности проекта. Основу совместной работы составляет формирование коммуникационного канала. Менеджер должен сообщать как хорошие, так и плохие новости, не следует скрывать неудачи. Если по некоторым причинам руководство действует в обход менеджера проекта и напрямую взаимодействует с членами команды, это может печально сказаться на реализации проекта, поэтому вопрос о коммуникационных потоках общения нужно решить на самых ранних стадиях проекта. Менеджер проекта должен найти пути общения с любым типом руководителя. Наиболее характерные типы плохих боссов: - Руководитель, не желающий слушать своих подчиненных - Агрессивный руководитель - Руководитель, не принимающий никаких решений - Руководитель, занимающийся микроменеджментом - Руководители, не оправдывающие доверия - Руководители меняющие порядки Хотя существует множество плохих, еще большее число руководителей являются хорошими боссами. Менеджеры часто путают хорошего и пассивного босса. С одной стороны Доверие к подчиненным не должно заменять требовательного отношения, а с другой - доверие к менеджменту проекта побуждает его к серьезной работе по достижению поставленной цели. Учитесь у хорошего босса, причем многому можно научиться и у плохого. В первом случае демонстрируется хороший пример общения с командой, а во втором как не следует себя вести. 10.Формирование бюджета. Основы бюджета. Восходящая оценка стоимости. Допустимые вариации бюджета. Проекту необходим бюджет, чтобы планировать расходы по его реализации и достижению поставленных проектом целей. Бюджет необходим для контроля и документирования расходов на проект. В план осуществимости нужно обязательно включить сведения о стоимости проекта и данные о возврате инвестиций. Бюджет помогает определить границы проекта и предписывает то, что будет реализовано. Бюджет служит финансовым руководством, ведущим проект к поставленной цели. Менеджер проекта обязан заранее обдумать, какие поставляемые части будет иметь завершенный проект. Существуют разные способы формирования бюджета. Один из них предполагает составление менеджером ИТ-проекта списка всех продуктов, которые придется приобрести компании для завершения проекта, причем с указание стоимости каждого из них. Одной из составных частей работы менеджера проекта станет точная оценка предполагаемых расходов. Наиболее непредсказуемыми в области ИТ остаются затраты рабочего времени. В основном это связано с тем, что менеджер проекта или члены команды разработки не подготовились должным образом к внедрению новой технологии, поэтому неверно оценили время на установку и развертывание новой системы. При формировании бюджета придется обратить внимание на следующие вопросы: Деление проекта на этапы -Учет интеграционного этапа -Оценка рабочей нагрузки, необходимой для завершения каждого этапа проекта -Учет стоимости специализированных услуг -Учет стоимости услуг -Оцените стоимость продуктов На первом этапе потребуется учесть затраты на приобретаемое оборудование, приобретаемое программное обеспечение, затраты на лицензии, гонорары консультантов, используемое время внутреннего разработчика, время, потраченное каждым членом команды разработки, на данном этапе разработки, иные разработки, связанные с проектом. Факторы, имеющие значение при оценке бюджета: -Предыдущий опыт -Опыт других людей -Фиксированные квоты -Стандартная стоимость Поскольку изменяется стоимость оборудования, программного обеспечения и услуг, менеджер проекта и руководство компании должны быть готовы к некоторым вариациям бюджета в сторону увеличения или сокращения (исчисляется в процентах от планируемой стоимости). 11.Формирование бюджета. Окончательный бюджет. Отсчет бюджета от нуля. Окончательный бюджет (Budget at completion ВАС) — это сумма затрат по всем этапам проекта, общая оценка расходов на проект. Если менеджер проекта разделил проект на этапы и оценил поэтапные затраты в денежном эквиваленте, то компании уже не нужно будет финансировать проект целиком, сразу выделяя запрошенные бюджетные средства. Достаточно последовательно предоставлять финансовые средства согласно календарному плану выполнения этапов. Основным преимуществом такой оценки проекта является то, что выплаты по проекту происходят только по завершении работ на каждом этапе. Кроме того, окончательный бюджет становится более понятным, чем предоставление только итоговой суммы затрат. Такой способ оценки бюджета позволяет точно показать, в чем состоит и сколько стоит каждый этап работ (причем согласованно с датами проведения работ). Менеджер проекта должен показать и этапы, не требующие финансирования. Иногда таблица затрат дополняется сведениями о рабочем времени, необходимом для каждого этапа проекта, чтобы оценить затраты на собственных сотрудников и сторонних консультантов. В показанном примере отражены только затраты на оборудование. Еще одна концепция, которую необходимо знать менеджеру проекта, называется отсчетом бюджета от нуля (zero-based budgeting). Это означает, что вычисление бюджета всегда начинается от нулевой отметки, а не от определенной величины затрат по аналогичному проекту. Отсчет бюджета от нуля требует сведения к нулю баланса, т. е. нельзя взять старый бюджет обновления сервера печати и увеличить на 20%, чтобы получить бюджет нового обновления. Такой способ помогает менеджеру проекта исходить из реальной стоимости каждого этапа. Менеджеру IT-проекта может показаться, что отсчет бюджета от нуля приводит к двойной работе, но на практике такой способ стимулирует фиксированные оценки товаров и услуг, изменения которых сразу отражаются на итоговом бюджете. Придется более точно оценить стоимость услуг и оборудования, планируемых для проекта. Однако некоторые менеджеры полагаются на аналогичные бюджеты, на основе которых они формируют бюджет нового проекта. Не следует повторять эту ошибку! 10 почему бы не использовать прошлогодние сведения, проанализировать изменения в стоимости и учесть это в новом бюджете? Чтобы разобраться в этом, нужно помнить о затратах на проект финансовых средств компании и рабочего времени ее сотрудников. Предположим, за основу взят прошлогодний бюджет обновления сервера, который увеличен на 20% для учета современных условий. Когда придет время для оплаты заказанного оборудования, может оказаться, что новые модели устройств стоят гораздо дороже устаревших либо из-за колебаний цен на рынке, изменилась стоимость даже прошлогоднего оборудования. Существуют и другие причины для изменения стоимости. Если предписано использовать метод подсчета бюджета от нуля, то так и нужно поступить. Даже если новый проект кажется идентичным старому, проведите исследование текущего состояния цен и более точно оцените затраты. Может быть, это и не очень интересное занятие, но оно входит в обязанности менеджера проекта. 12.Формирование бюджета. Определение затрат на проект. На первый взгляд кажется, что легко предсказать примерную стоимость проекта. Достаточно просуммировать расходы на оборудование и получит надежную оценку затрат. Однако на практике это сделать не так просто. При планировании расходов на проект менеджер обязан учитывать за траты рабочего времени сотрудников, стоимость оборудования, масштаб проекта и состав необходимой аппаратуры. Придется исследовать много факторов, влияющих на сравнительные оценки разных вариантов сборки и приобретения оборудования: - Сколько времени уйдет на сборку собственными силами? - Какие еще задачи стоят перед техническим персоналом? Оцените затраты рабочего времени специалистов, стоимость этого времени и иные затраты, связанные с проектом. - Присутствуют ли гарантии изготовителя? Если сборку осуществляет изготовитель, он обязан гарантировать работу оборудования. - Нужны ли лишние проблемы? Возможные трудности часто перевешивают затраты, особенно для сборки оборудования собственными силами. Иногда, особенно при незначительном выигрыше от использования собственных специалистов, лучше поручить сборку сторонней компании. Не все затраты проекта связаны с оборудованием — иногда таких затрат нет! На программное обеспечение тратится не меньше средств, что приводит к внушительным счетам еще до установки и настройки приложений. Затраты на программное обеспечение зависят от выбранной модели лицензирования: ” На станцию (рег station). Учет приложений на рабочих станциях. „ На подключение (рег connection) Учет подключений к серверу каждой рабочей станции.. На станцию с серверной стороны (рег station server based) Разрешает неограниченное число подключений к серверу с такой моделью лицензирования. На применение (per usage) Разрешает пользователю запуск приложения в определенные часы или дни недели либо предлолагает оплату каждой запущенной копии программного обеспечения. Одной из популярных тенденций в мире современных информационных технологий стал аутсорсинг. Обычно это не только выгодно, но и очень эффективно. Организации, не имеющей своего менеджера по ИТ, выгодно воспользоваться аутсорсингом, т.е. пригласить стороннего специалиста или компанию для решения своих проблем в области ИТ. Перед решением об аутсорсинге нужно обдумать следующие вопросы: „ Достигается ли финансовая эффективность? Оцените затраты времени, интервал обучения, процесс реализации и финансовые затраты, затем сопоставьте их со стоимостью работ сторонней компании. „ Достигается ли повышение производительности? „ Имеет ли сторонняя компания надежную репутацию? Аутсорсинг не всегда является наилучшим решением и часто не нравится руководству. Дело в том, что приблизительные оценки внутренних время на обучение и выполнение других проектов может приводить конфликтным ситуациям со сторонней компанией. Время менеджера ИТ-проекта слишком ценное, поэтому нужно защищаться от натиска пользователей. Достаточно всем им говорить “Да, конечно” и попробовать больше времени уделить перспективному проекту. Хотя менеджер проекта не всегда должен самостоятельно выполнять каждый этап реализации, в его обязанности всегда входит открытость к коллективной работе, устранение проблем, отслеживание исполнения проекта по времени и отчет о состоянии работ. 13.Формирование бюджета. Контроль над расходованием бюджета. Расходы часто выходят-под контроля. Это очень опасная позиция при покупке. Нетрудно соблазниться и потратить больше денег, чем планировалось. Любое увеличение цены приводит к сокращению бюджету, а значит потребует дополнительного финансирования проекта или изъятия средств из других позиций бюджетной капитуляции. Нужно не только сформировать детальный бюджет еще до начала покупок, но и точно отслеживать расходы на проект. В этом состоит контроль над окончательным бюджетом, причем документальное оформление затрат на каждую сделанную покупку позволит сравнить запланированную и реальную цену, чтобы гарантировать реализацию проекта в рамках бюджета. Отклонение проекта, как и отмечено в названии, состоит в том, что успешно начатый проект также успешно выполняется, но выходит за запланированные границы по бюджету, рабочему времени или своей репутации. В таких проектах бюджет можно считать потерянным. Менеджер проекта часто просто расходует деньги на проблему вместо того, чтобы найти ее решение. Нередко менеджмент проектов связан с расходованием дополнительных средств на каждое возникающее препятствие. Отклонение проекта происходит по нескольким причинам: „ Недостаточное планирование Некорректность плана сказывается на всех аспектах проекта. . Недостаточное видение Нарушение границ Руководство и соседние подразделения все еще продолжают что-то добавлять в уже запущенный проект. Потеря лидерства Без явного лидера проект теряет целеустремленность и требует дополнительных затрат. Предотвратить отклонение проекта можно за счет определения четкого и неизменяемого плана реализации проекта, бюджета и границ реализации. Любое дополнение проекта не способствует его успешности, хотя в любом проекте нужно заранее планировать определенные изменения. Даже если развитие проекта проходит гладко, возникает мало или не возникает совсем никаких осложнений, способных изменить видение или масштабы, необходим метод отслеживания и учета текущих расходов на проект. Для такой задачи подойдет Мicrosoft Ехсе|, но лучше использовать пакет Microsoft project. В любом программном обеспечении, выбранном для отслеживания затрат, должны учитываться следующие базовые характеристики: « Рабочее время. Это наиболее важный параметр любого проекта, поэтому нужно планировать деятельность членов команды разработки и учитывать затраченное ими рабочее время. Если приглашены сторонние специалисты или консультанты с почасовой оплатой, следует учесть и это время. „ Приобретаемые изделия. Необходимо учесть затраты на любое оборудование, программное обеспечение, инструменты, кабели и иные изделия, которые приобретаются для проекта. Лист электронной таблицы должен позволять ввод таких затрат. Лицензии программного обеспечения. Если проект предполагает оплату лицензий, необходимо документировать такие затраты. „= Рабочие станции и серверы Если план проекта предписывает покупку рабочих станций и серверов, необходимо отразить цену на момент оплаты и дату установки. 14.Создание схемы деления работы. Определение схемы деления работы. Работа со схемой WBS. Согласование между собой компонентов схемы WBS. Существуют разные критерии определения последовательности выполнения задач проекта, причем отдельные задачи могут выполняться параллельно. Схема деления работы WBS (work breakdown structure) позволяет ответить на поставленные вопросы, взять проект в свои руки и назначить задачи членам команды разработки. Схема WBS рассматривает проект на самом низком уровне — уровне элементов работы. Это перспективный план и календарная схема для каждого этапа проекта, ведь WBS позволяет менеджеру проекта разделить его на небольшие, легко анализируемые компоненты. Существуют программные средства для ведения схемы WBS, например, Microsoft project, visio, excel или PowerPoint. Проект подразделяется на этапы, Этап —это часть проекта, обычно завершаемая до перехода на следующий этап. Для каждого этапа назначено граничное время выполнения. На каждом этапе выделяются элементы работы (work init), т. е. составные части проекта, которые необходимо выполнить, чтобы перейти к реализации следующего этапа. Элементы работы можно разделить на более мелкие части, хотя это требуется не всегда. Если предполагается переход на более низкие уровни, то рабочие элементы подразделяются на задачи, т. е, отдельные части процесса реализации проекта, совместно определяющие некоторый элемент работы. Некоторые менеджеры проектов рекомендуют делить каждую задачу на более мелкие части до тех пор, пока не будут получены элементарные и неделимые действия. Однако здравый смысл подсказывает, что последовательная декомпозиция любого действия обязательно приводит к слишком мелким частям. Как правило, лучше найти приемлемый по времени уровень деления. Например, в небольшом проекте достаточно деления по рабочим дням, но в больших проектах вполне допустимо деления заданий по неделям. Любой этап в схеме WBS заключен между датами своего начала и завершения. Эти даты позволяют менеджеру проекта планировать его окончательное завершение, а затем отсчитать в обратном порядке даты завершения отдельных этапов. Схема поможет менеджеру проекта точно предсказать несколько важных аспектов: - Схема WBS определяет работы, необходимые для завершения всего проекта. Как часто проекты начинаются при выделении только ключевых этапов, однако в процессе реализации забываются мелкие, но весьма необходимые детали? Более того, иногда обнаруживается, что необходимый компонент еще не реализован, а без него невозможно продолжение других работ в рамках проекта. Схема WBS гарантирует, что менеджер проекта будет знать обо всех работах, выполнение которых позволит успешно завершить проект. - Схема WBS определяет понятие “срочности”. В ней менеджер проекта и члены команды разработки точно обозначают сроки получения поставляемых проектом частей. - Схема WBS устанавливает граничные сроки. Если руководство или соседние подразделения захотят добавить в существующий проект дополнительные возможности, это может быть отражено через изменения в WBS. - Схема WBS помогает контролировать проект. Один менеджер может одновременно руководить несколькими проектами, а схема WBS позволит в графическом виде показать текущее состояние каждого из них. 15.Создание схемы деления работы. Создание схемы WBS. Процесс создания схемы WBS. Формирование реалистичной временной диаграммы. Схема WBS определяет данные шаги, способствующие успешному завершению проекта. Схема WBS обеспечивает отслеживание назначений задач членам команды разработки и оценку времени выполнения этих задач. Некоторые задачи должны выполняться в определенной последовательности, но другие — в любое время, что позволяет вставить небольшие перерывы между завершением одной задачи и началом другой. Существуют два способа создания схем WBS: сверху вниз и снизу вверх. В первом случае применяется дедуктивный подход, поскольку мы начинаем от общего и движемся к частному. Второй способ диктует движение от частного к общему. Оба способа имеют определенные достоинства. Метод снизу вверх прекрасно подходит для “мозгового штурма” во время решения проблемы. Способ сверху вниз требует больше логических размышлений и упорядочивания, но он лучше всего подходит для создания схемы WBS. Процесс создания схемы WBS — обычно схема создается менеджером проекта вместе с членами команды разработки. Иногда требуется участие спонсора проекта или представителя руководства компании, как правило, для объединения мнений разных людей, хотя такое руководящее действие не всегда необходимо. Если бюджет еще не утвержден или не распределен по этапам проекта, выявить отдельные этапы помогут следующие вопросы: Каково логическое деление проекта на части? Существуют ли очевидные сроки, определяющие этапы проекта? Нужно ли учитывать в проекте бизнес-циклы компании? Существуют ли финансовые ограничения или рекомендации для деления проекта на этапы? Как правила компании для жизненного цикла проектов действуют в данном проекте Как работы по созданию систем уже начаты компанией? После выявления этапов проекта отметьте их на отдельных листочках и пришпильте эти заметки на доске в порядке следования этапов. Проложите декомпозицию остальных этапов проекта, при необходимости выделяя не только задачи, но и элементы работы. После анализа первого этапа переходим к декомпозиции второго этапа проекта, затем к следующему этапу. На каждом этапе нужно выделить задачи и элементы работы, если это необходимо. Затем нужно еще раз проанализировать этапы проекта и определить порядок их выполнения. При создании схемы в Microsoft project (нужно различать четыре типа отношений: Завершение-старт. Задача является преемником и не может начаться до завершения задачипредшественника. Старт-старт. Такие задачи обычно связаны друг с другом и должны начинаться одновременно, хотя могут завершаться в разное время. ] - Завершение-завершение Эти задачи соотносятся так, что предшественник и преемник должны завершиться одновременно. Старт-завершение. Предполагает, что задача-предшественник не начнется до завершения задачи-преемника. После формирования и утверждения границ проекта скорее всего будь, определен граничный срок его реализации спонсором, руководством илу менеджером проекта. Очень часто сроки устанавливаются не по количеству рабочих часов, необходимых для выполнения задач, а исходя из того “что так нужно компании”. Границы проекта, определяющие и утверждающие поставляемые проектом завершенные части, позволят защититься от ненужных дополнений, способны изменить масштаб проекта и нарушить его баланс и график. После установи границ проекта и фиксации их в официальном документе не существует особых причин для их изменения. Менеджеру проекта нужно защищать границы проекта и отказываться от их изменения. Любое изменение масштаба проекта, даже незначительное на первый взгляд, станет ахиллесовой пятой. 16.Создание схемы деления работы. Утверждение руководством. Формирование коммуникационных каналов. После создания исходного варианта схемы WBS необходимо утвердить ее руководством компании, чтобы получить окончательно утвержденный документ. Спонсор проекта, как его адвокат и защитник, должен первым познакомиться с предлагаемой схемой WBS Менеджер проекта обязан объяснить ему все этапы проекта, отмеченные в схеме WBS. Если менеджер проекта тщательно согласовал схему WBS с бизнес-циклом компании и рабочим расписанием членов команды разработки, то изменений почти не будет. На каждом этапе можно показать несколько характерных событий в сроки выполнения наиболее важных операций. В схеме WBS следует отметить возможные отключения (если они планируются), чтобы руководство заранее знало о влиянии проекта на деятельность компания. Если руководство не утвердит график работ, менеджеру проекта нужно будет срочно разобраться е возникшими вопросами. Иногда схема утверждается руководством е небольшими изменениями или окончательное решение откладывается, чтобы руководство могло подробнее познакомиться с схемой WBS. Члены команды разработки могут подчиняться другим менеджерам. менеджеру проекта вместе с членами команды нужно обсудить проект с такими руководителями и определиться с участием в проекте сотрудников данного подразделения. В процессе обсуждения должны быть решены несколько вопросов: Подтвердить у начальника участие его подчиненного в проекте и согласовать количество рабочих часов. Подтвердить менеджеру проекта участие в команде разработки сотрудников данного подразделения. Подтвердить члену команды разработки, что его непосредственный начальник и менеджер проекта согласовали участие этого человека в проекте. Определить уровень ответственности менеджера проекта за рабочее время членов команды проекта. Важнейшим элементом успешного проекта являются надежные коммуникационные связи. Менеджер проекта и команда разработки должны периодически обсуждать развитие проекта, возникшие проблемы и изменения, поэтому менеджеру проекта при формировании схемы WBS нужно предусмотреть методы общения с членами команды разработки, чтобы точно знать о завершении, задержке или начале работ над определенной задачей. Менеджер проекта обязан информировать коллектив о завершении задач, новостях проекта и вопросах, поставленных членами команды разработки. Для этого есть несколько причин: - Поддержка движущей силы проекта - Повышение морального климата в коллективе - Поддержание уровня информированности и заинтересованности - Побуждение к напряженной работе членов команды - Направление команды к успешному завершению проекта Существуют разные способы отслеживания развития проекта, успешности его продвижения и достижения характеристических точек. Среди них: Web-формы Недорогой метод коммуникации с командой разработки, позволяющий отчитаться о текущем состоянии. Идеален для совместной работы географически разрозненного коллектива. Шаблоны форм из прикладных программ Если невозможно использование web-форм, примените шаблоны документов Word или Ехсеl. Пакет Microsoft project central Дополнение к Microsoft project обеспечивающее отслеживание действий рабочей группы проекта на основе web-технологий. Электронная почта. Это прекрасный метод поддержания контактов менеджера с членами команды и членов команды друг. 17.Формирование команды разработки. Оценка опыта других людей. Формирование коллектива. Вне зависимости от того, подбиралась ли команда лично или была выбрана руководством компании, необходимо оценить уровень квалификации каждого ее члена Начав поиск фактов о сотрудниках, нужно использовать разные методы оценки профессиональных навыков: -Предыдущие проекты -Персональные заслуги Возможно, ранее не приходилось встречаться с сотрудником во время работы над проектом, но он известен своим участием в других предыдущих проектах, где отмечены выполненные им задачи. - Рекомендации руководства Нечасто удается собрать команду разработки по своему желанию — некоторых сотрудников можно выбрать самостоятельно, но остальные будут назначены руководством компании. - Рекомендации членов команд Скорее всего уже известны ИТ-профессионалы в компании, которым можно доверять и поручить определенную работу. Еще одним источником, если есть доступ к документам, станут результаты членов команды. Резюме в сжатом виде суммирует набор профессиональных качеств сотрудника. Во время опроса кандидатов можно оформить краткие резюме, чтобы оценить уровень подготовки сотрудников. Люди получают сертификаты после прохождения учебных курсов и практических занятий. Сертификация показывает, может ли человек работать с определенной технологией, понимает ли он основные научные концепции и смог ли он выдержать сертификационный экзамен. При оценке компании, занимающейся обучением, оцените следующие характеристики: - Каков практический опыт этой компании? - Сможет ли компания согласовать учебный курс с особенностями проекта? - Нужно ли пригласить инструктора, чтобы дополнить учебный курс практическими занятиями? - Какие темы предполагается изучать на занятиях? - Какова стоимость учебного курса? - Не лучше ли провести обучение в самой организации? Перед формированием самой команды нужно заранее определить тип и структуру. В частности, команда разработки может иметь одну двух структур: - Матрица частичной занятости Это весьма распространенная структура, позволяющая сотрудникам продолжить исполнение своих обязанностей и выделить некоторое время на разработку проекта. - Матрица полной занятости Эта структура распространена для сотрудников, работающих по контракту. Все свое рабочее время сотрудник должен уделять работе над проектом. Создать сплоченную команду поможет демонстрация того, как ее члены связаны вместе единой целью. Но как реализовать на практике эти красивые слова? Как побудить команду перенести своим устремления с личных задач на общие цели проекта? Приведем несколько рекомендаций: -Покажите членам команды то, что даст им проект -Покажите членам команды то, что значит проект для компании. -Покажите членам команды захватывающие перспективы осуществления проекта. - Покажите членам команды команды важность в проекте каждого из них. Объединение отдельных личностей в коллектив предполагает формирование взаимоотношений между менеджером проекта и членами команды разработки. Перед этим члены команды должны знать свою роль в проекте и ее соотношение с ролью менеджера проекта. В любом проекте команда очень быстро начинает работать вместе. Этому неплохо будет собрать людей для проведения какого-нибудь мероприятия. Примеры способов формирования взаимоотношений: -Экскурсия в боулинг - Путешествие на природу - Встреча в выходной для знакомства друг с другом и обсуждения Проект - Совместное посещение бассейна для проведения командой игры на воде 18.Формирование команды разработки. Интервью с кандидатами в члены команды разработки. Управление коллективом. Специфика предстоящей работы станет надежным ориентиром при подборе специалистов для проекта. Рекомендуется рассмотреть такие качества кандидата, как его способности, участие в прошлых проектах и текущие должностные обязанности. Целью собеседования с кандидатом в члены команды разработки (или человеком, назначенным в команду руководством компании) является определение предполагаемой роли специалиста в проекте. Любой проект хорош только тогда, когда люди завершили свою работу. Команда проекта четко отражает собственные устремления менеджера, поэтому подбор коллектива становится важнейшей задачей, влияющей на успех всего проекта. Потребуется придерживаться определенных критериев при оценке того, подходит ли кандидат для определенной должности в проекте. Критерии выбора основываются на описании должности, причем должны представлять собой список требований, определяющих полное соответствие кандидата планируемым для него задачам проекта. Критериями выбора могут быть: - Уровень образования - Знание поставленных задач - Опыт выполнения аналогичных работ - Способности, пригодные для решения поставленной задачи - Предыдущие достижения кандидата - Иные важные показатели, например сообразительность, умение вести за собой других людей, способность работать в коллективе и тд, Во время подготовки к интервью продумайте свои вопросы к кандидатам. Обычно собеседование предполагает (или запрещает) вопросы разного типа: - Однозначный вопрос Ответом будет “да” или “нет. - Развернутый вопрос В ответе кандидат должен предоставить нужную информацию, а менеджменту проекта остается только слушать и запоминать. - Вопрос о предыдущей работе Связан с поведением кандидата в предыдущих ситуациях, что позволяет предвидеть его действия в будущем, когда возникнут похожие обстоятельства. - Дополнительный вопрос Вытекает из ответов кандидата. Если обнаруживается пропуск или несогласованность в ответах, используйте дополнительные вопросы, но не пытайтесь уличить человека во лжи. - Запрещенный вопрос. Не следует интересоваться детьми, семейным положением, религиозными убеждениями, национальностью и физическими ограничениями. Положитесь на здравый смысл, и с вопросами такого типа не возникнет проблем. В коллективных дискуссиях обязательно должен участвовать менеджер проекта. Если члены команды не могут или не хотят прийти к общему решению, решение принимает менеджер проекта. В таких ситуациях менеджеру проекта нужно выработать собственное отношение к проблеме. Для устранения конфликтной ситуации подойдет такая последовательность действий: 1. Обратить внимание Нужно встретиться с обеими конфликтующими сторонами и объяснить цель совещания: поиск решения проблемы. 2. Выслушать Рассмотрите возникшую проблему и позвольте людям выговориться. 3. Решить Часто на встрече с конфликтующими членами команды достаточно просто “выпустить пар”, и решение придет незамедлительно. 4. Подождать Если на встрече не удалось найти общего решения, уступающего обе стороны конфликта, не следует немедленно принимать собственное решение. 5. Действовать Если члены команды не желают изменить свою позицию в конфликтной ситуации, решение принимает менеджер проекта. В любой компании выработаны правила наложения дисциплинарных взысканий, но ими нужно пользоваться осторожно, ведь речь идет о чужой карьере, Но, с другой стороны, отсутствие дисциплины в команде разработки отрицательно скажется на карьере самого менеджера проекта. 19.Формирование команды разработки. Использование внешних ресурсов. Иногда проект кажется компании настолько сложным, большим и неподъемным, что лучшим решением становится реализация проекта силами сторонних специалистов. В этом случае вне зависимости от причин для аутсорсинга нужно найти команду, которая наилучшим образом выполнит поставленную задачу. Нетрудно найти хорошего изготовителя в ИТ-области, но сложно выбрать наилучшую компанию. Чем отличается прекрасная компания-изготовитель от рядовой? Существует несколько признаков: -Возможность завершения проекта в полном объеме и согласно графику работ -Богатый опыт внедрения данной технологии -Забота о клиентах и своей репутации -Высокая квалификация команды разработки проекта (опыт и сертификация) -Достаточное время для работы над проектом -Неподдельная заинтересованность в успехе компании-заказчика -Истинный интерес к успешному завершению проекта - Справедливые цены на проведение работ Для поиска компании-интегратора существует несколько разных методов: -Рекомендации. Хорошие отзывы других заказчиков из вашей компании, контракты в конкретной области промышленности или даже мнение родных и знакомых. - Интернет Если известна предполагаемая к реализации технология, ищите в сети Интернет рекомендации от компании-разработчика этой технологии. - Справочник “Желтые страницы” Если не помогли другие советы, откройте телефонный справочник и поговорите с представителям, указанных там компаний, Подготовьте опросный лист, чтобы далек сравнить полученные ответы. - Промышленные выставки Если проект начнется спустя нескольку месяцев, имеет смысл посетить одну из специализированных выставок и познакомиться с потенциальными исполнителями проекта. - Предыдущий опыт Не пренебрегайте проверенными в деле сторонними компаниями. Прежняя хорошая работа свидетельствует об успешной работе над будущим проектом. Сократив область поиска потенциальных исполнителей проекта до двух или трех компаний, проведите опрос каждой из них для выбора наиболее подходящей в конкретном проекте. Во время встречи обратите особое внимание на представителей сторонней компании: - Обращали ли они внимание на детали? Прибыли ли они вовремя? Хорошо ли были одеты и согласован ли внешний вид с их профессиональной деятельностью? Были ли начищены ботинки? - Как организованы рекламные материалы? Как быстро торговый представитель нашел нужную брошюру после открытия своего портфеля? - Каков язык жестов торгового представителя? Обратите внимание на то, как он садится, где держит руки и какими жестами пользуется при ответах на вопросы. -Каково общее впечатление? Обычных человеческих чувств недостаточно. После встречи с торговым представителем у заказчика должно сложиться хорошее впечатление. Одним из наилучших методов проведения опроса, особенно для изучения потенциальных исполнителей работ, является метод STAR (ситуация, задача, действие, результат). Метод STAR предписывает ситуационные вопросы, например: “Расскажите о действиях в ситуации при внедрении новой технологии у клиента, когда принятие решения выходит за рамки оговоренных обязанностей?”. Получив материалы, пересмотрите результаты ранее выполнен следований и ограничьте область своего поиска хотя бы двумя сторон компаниями, чтобы запросить у них к определенному сроку документ RFP (Request for proposal, запрос предложений). Это общепринятая форма привлечения клиентов потенциальным исполнителем работ, определяющая примерный cрок завершения проекта и его стоимость. Оцените контрактный договор с точки зрения защиты прав своей компании и компании-интегратора. В контракте должны быть оговорены гарантии сторонней компании на производство работ в установленные сроки. 20.Формирование плана проекта. Определение графика проекта. Проекты с жестко установленной датой завершения. Создание сетевой диаграммы проекта. Проект имеет осязаемый набор поставляемых частей, определяющий завершение работ. Кроме того, для проекта нужно установит срок завершения. Бесконечные проекты (без установленной жесткой даты завершении работ) возникают при неправильном определении границ проекта, некорректном планировании или недостаточном исследовании. График проекта должен отражать схему WBS аккумулирующую в себе все задачи проекта и показывающую присвоенные каждой задаче ресурсы. Многие начинающие менеджеры проектов предпочитают использовать конкретные даты в качестве граничных сроков, этапов и общего срока завершения работ. Менеджер проекта не обязан строго привязывать план проекта к календарю, но должен точно определить промежутки времени, например, один день, две недели, три месяца и т.д. Работа с промежутками времени помогает сдвинуть весь график проекта или определить дату начала работ исходя из установленного жесткого срока завершения проекта. Диаграмма Гента (Gantt) прекрасно подходит для небольшого и короткого проекта. Она описывает временную последовательность событий, определяющих параллельность выполнения задач во время работы над проектом. Традиционные диаграммы Гентта имеют несколько недостатков: - Не показывают подробных сведений о каждом элементе работы ( Microsoft project позволяет менеджеру проекта добавить примечания и информацию о задаче на диаграмме Гентта) - показывают только последовательность выполнения задач - Не могут точно отразить последовательность задач разных этапов проекта - Не показывают кратчайшего пути для завершения проекта - Не показывают наилучшего способа использования ресурсов. Чтобы устранить эти недостатки, менеджер проекта может использовать диаграмму PND (Project network diagram, сетевая диаграмма проекта). Диаграмма PND отображает карту потока работ, подлежащих выполнению согласно плану проекта. Cетевые диаграммы прекрасно подходят в следующих случаях: - Подробное планирование проекта - Отслеживание реализации. - Вероятностные сценарии Сетевая диаграмма позволяет менеджеру проекта анализировать сценарии развития событий типа “что будет, если?”. - Контроль ресурсов. Есть много общего между схемой WBS и диаграммой PND. В обоих случаях отношения между задачами. От менеджера проекта требуется точное указание названий задач, что поможет анализировать и перестраивать задачи сетевой диаграммы. - FS (Finish to start, завершение к старту) Это задачи-преемники, которые не могут начаться до завершения задачи-предшественника. - SS (Start to start, старт к старту) Это тесно связанные по своей природе задачи, которые должны начаться одновременно, но не обязаны одновременно завершиться. FF (Finish to finish, завершение к завершению) Такие задачи требуют завершения в одно время задачи-преемника и задачи-предшественника. SF (Start to finish, старт к завершению) Это редкие задачи, у которых задача-предшественник не может начаться до завершения задачи преемника. Этот способ создания сетевых диаграмм имеет еще одно название — метод диаграммирования предшествования (PDM, Precendence Diagramming Method). Метод PDM требует от менеджера проекта оценить каждый элемент работы и определить для задачи ее предшественников и преемников. Любой элемент работы на сетевой диаграмме PDM представлен прямоугольником, именуемым узлом действия (activity node). Предшественники соединяются с преемниками стрелками, всегда направленными к преемникам. 21.Формирование плана проекта. Учет ограничений в проекте. Построение сетевой диаграммы. Анализ сетевой диаграммы проекта. Использование Microsoft Project. Ограничения формируют границы или пределы на основе отношениям между задачами. При формировании отношений между задачами нужно учитывать типы ограничений между ними. Не все ограничения являются естественными. Менеджер проекта может наложить искусственные ограничений на основе обстоятельств, находящихся вне проекта. На сетевой диаграмме менеджер проекта может указать четыре типа дополнительных, ограничений: - по дате Существуют три типа ограничений по дате: No earlier than (Не ранее чем). Это ограничение определяет, что задача будет завершена после определенной даты, но не ранее этой даты. No later than (Не позднее чем). Это ограничение определяет граничный срок. Задача должна быть завершена к установленной дате. On this date (К дате). Это ограничение определяет временной промежуток. Не существует границ изменения срока выполнения задачи, она не может быть завершена раньше или позже. - по управлению Ограничение по управлению — это отношение зависимости, основанное на решении руководства, включая самого менеджера проекта. - Техническое Техническое ограничение возникает из отношения FS. Очень часто в ИТ-проектах задачи должны выполняться в определенной логической последовательности на протяжении всех работ. Ограничения трех типов: - Дискреционное ограничение Позволяет менеджеру проекта изменить отношение между задачами на основе обоснованного предположения - Ограничение из опыта Основано не только на логической последовательности задач, но скорее на предыдущем опыте менеджера проекта или членов команды разработки. - Ограничение по ресурсам Менеджер проекта может установить для двух задач отношение FS вместо SS на основе данных о доступных ресурсах. - организационное В компании могут параллельно выполняться несколько не связанных друг с другом проектов. Но иногда завершение одного из них определяет некоторый граничный срок для другого проекта. Задержка в реализации такого проекта скажется на связанных с ним. Менеджер проекта должен начать разработку элементов работы с их описания на карточках, причем поставляемые проектом законченные части следует отразить на карточках другого цвета. получив первый, предварительный вариант диаграммы, начните присваивание задачам промежутков времени. Менеджер проекта должен учесть бизнес-циклы компании, выходные дни и допустимое время задержки в каждом отношении между задачами. При пересмотре сетевой диаграммы для формирования ее окончательного варианта нужно найти ответы на такие вопросы: - Достаточно ли ресурсов для завершения проекта? - Точны ли оценки времени? - Не слишком ли много параллельных задач? - Эффективно ли распределены ресурсы по задачам? Выполним ли план проекта? - Реалистичен ли этот план? После формирования диаграммы РМО следует определить критические пути развития проекта, Такой путь является последовательностью событий, определяющих дату завершения проекта. За счет изменения даты начала задачи или добавления задаче дополнительных ресурсов можно выполнить работу за меньший срок. Для оценки возможного сжатия графика следует учесть: - Критические пути на диаграмме для перенесения задачи ближе к началу потока работ - Изменение отношений между задачами с FS на SS - Задачи, требующие задержек по времени, и задачи-предшественники, которые допустимо сместить к началу потока работ - Все задачи и приемлемый для них уровень рисков, согласно изменению типа отношений - Возможное добавление дополнительных ресурсов задачам для сокращения сроков их выполнения Пакет Мicrosoft project обеспечивает создание сетевых диаграмм проекта. Поддерживаются три вида ограничений: Гибкие Полугибкие Негибкие Обеспечены восемь типов ограничений: как можно быстрее, как можно позднее, начать не ранее, начать не позднее, завершить не ранее, завершить не позднее, начать в, завершить в. 22.Реализация плана проекта. Обсуждение распределения работы с командой проекта. Нацеленность на работу. Проведение совещания с членами команды. Отслеживание продвижения проекта. Одной из обязанностей менеджера проекта станет формирование надежного и ответственного коллектива, члены которого доверяют друг другу и своему руководителю. Благодаря регулярным общим совещаниям, неформальным встречам и беседам с глазу на глаз можно обеспечить нормальные рабочие отношения с каждым членом команды и узнать о его заинтересованности, готовности и возможностях для участия в проекте. Любой менеджер обязан довести до сведения членов команды разработки, что нужно нацелиться на свою работу, свои обязанности и задачи в проекте. После утверждение плана проекта команда должна взяться за работу и не обращать внимание на прошлые расхождения во мнениях и уровень своего участия в планировании, ведь теперь поставлена только одна задача – вовремя завершить назначенные членам команды задачи. Распределение ресурсов по задачам поможет членам команды узнать, когда и что нужно делать. Менеджер должен побудить людей выполнять собственные обязанности и внести необходимый вклад в проект согласно распределению работ, а также не обращать внимания на то, что и как делают коллеги. Команда должна коллективно двигаться к цели проекта, причем важно движение каждого ее члена. Если члену команды требуется помощь, то команда должна быстро перестроиться, чтобы помочь ему в отдельной задаче, но сохранить скорость продвижения проекта. Менеджер проекта должен тесно общаться с членами команды разработки. Только личные контакты с командой, а также неформальные встречи и разговоры помогут участвовать в работе и реально руководить проектом. Регулярное общение еженедельно, раз в 2 недели или по графику поможет: - Отчитаться членам команды о своих действиях - Подчеркнуть видение проекта - Решать команде возникающие проблемы - Менеджеру проекта эффективно руководить командой без ненужного возвышения - Сформировать мнение об общем владении проектом - Сформировать ответственное отношение членов команды к своим обязанностям Чтобы провести совещание, нужно предварительно подготовиться. Сформируйте повестку дня. Она должна состоять из следующих пунктов - выполнение задач, поставленных на предыдущем совещании - обсуждение любой ситуации, касающейся всех членов команды разработки - подтверждение выполнения наиболее важных задач проекта - обзор общего состояния работ – хорошо или плохо идут дела - общее обсуждение диаграммы PND - задачи, остающиеся нерешенными до следующего совещания. Существует несколько причин для отслеживания продвижения проекта. Наиболее важная связана с наблюдением за ходом выполнения работ позволит вносить необходимые оперативные изменения в план проекта. Команде нужен механизм для отчетности перед менеджером. Некоторые менеджеры предпочитают отчеты о пройденных точках проекта, а другие еженедельный отчет. Если на этапе реализации возникает проблема, увеличивая число рабочих часов, запланированных для задачи. Выделяя дополнительное рабочее время, нужно учесть следующее: Зависимости задач на диаграмме PND Другие задачи, не связанные с данной задачей на PND, но которое должен выполнить сотрудник в будущем Критический путь Бюджет Дату заполнения проекта Административный резерв Менеджер не всегда имеет время поговорить с каждым членом команды каждую неделю, что лично получить информацию. Есть несколько способов сбора такой информации - электронная почта - электронные таблицы - web форма - Microsoft project - Microsoft project central 23.Реализация плана проекта. Отслеживание финансовых ограничений. В дополнение к сбору отчетов от членов команды о состоянии назначенных им задач необходимо собирать данные о финансовых аспектах проекта. Менеджер проекта обязан встречаться со спонсором проекта и отчитываться о текущих затратах. Регулярно нужно предоставлять следующую финансовую информацию: - Освоенное на данный момент финансирование проекта в целом - Все вариации цен - Реальная стоимость работ в сравнении с бюджетной стоимостью - Объем выполненных работ - Вариации стоимости и компенсации - Предложения (при необходимости) о снижении затрат на ресурсы проекта В компании обычно уже установлены правила учета финансовых документов: запросов на оплату, заявок на покупку, платежей по счетам и т. д. Если внутренний порядок обработки документов непонятен, нужно выяснить его у спонсора проекта или у сотрудника финансового отдела. Для отслеживания и учета финансов нужно использовать несколько показателей: ^ Общая бюджетная стоимость " Накопительная реальная стоимость ' Вариация стоимости ” Затраты на заработную плату " Уровень качества Отслеживание реальной стоимости Отслеживание реальной стоимости проекта проводится путем сбора сведений об оплате счетов поставщиков и консультантов, а также рабочего времени членов команды в денежном исчислении, потраченного на уже выполненные задачи. Текущая сумма этих показателей является реальной стоимостью проекта на данный момент. Полученные от поставщиков счета определяют полученные товары или услуги. Они согласованы с контрактами, которые являются основными финансовыми документами, которым сопутствуют счета, заказы и договоры о намерениях. Все они определяют фиксированные издержки (committed cost), т. е. денежные затраты — утвержденные м выделенные на часть или весь проект. Регулярно нужно сопоставлять фиксированные издержки с реальными затратами. Для нахождения возможностей по снижению затрат нужно; = Использование более дешевых ресурсов =" Присваивание задаче дополнительных ресурсов * Изменение на диаграмме РМО отношения SS у задачи на отношение FS Снижение денежных средств, выделенных в административный резерв Затраты на заработную плату служат отличным критерием постоянной проверки завершения работ проекта с бюджетной стоимостью проекта. Индекс производительности по стоимости СРI (cost performance index) отражает реально затраченные на проект денежные средства и величину сближения этих затрат с бюджетом проекта. Для подсчета индекса СРI накапливаемые затраты на зарплату делятся на накапливаемые реальные затраты , что дает %, показывающий насколько он сближен с бюджетом проекта. Например 90% покажет что проект отошел на 10% от заданного значения Менеджер проекта может на основе этой оценки перераспределить ресурсы, изменить график, переназначить задачи, и если ничего не поможет, то обратиться за дополнительным финансированием.Планируемый индекс производительности SPI (scheduled performance index) определяет отношение реально выполненной работы к запланированной. Индекс SPI показывает соотношение выполненной работы к затратам времени. Индекс является относительной величиной, а не денежным эквивалентом. Он указывает в процентах, насколько близко относятся объемы выполненной и запланированной работы. Если индекс 1 то проект строго следует графику. Он равен общим затратам на заработную плату деленное общую стоимость работ, выполненных на текущий момент. 24.Пересмотр плана проекта. Необходимость пересмотра проекта. Формирование контроля над изменениями. В менеджменте ИТ-проектов изменения внести трудно, если вообще возможно. Когда проект переходит на этап реализации, трудно убедить руководство, команду разработки и менеджера проекта в том, что изменение поставляемых проектом частей является удачной идеей. Часто изменения связаны с границами проекта, но приводят к полному пересмотру поставляемых частей, поэтому менеджеру проекта приходится втискивать план проекта в новые и улучшенные требования. Контроль изменений — это внутренний процесс, который менеджер проекта применяет для блокирования любых изменений в поставляемых проектом частях (даже изменений, предписанных руководством компании), если эти изменения не проверены на выполнимость. Контроль изменений требует от запросившего лица веских доводов в пользу пересмотра проекта, причем далее выполняется оценка влияния изменений на все аспекты проекта. Предотвратить неприятности, связанные с изменением проекта, можно разными способами: - Провести подробный опрос клиентов (или конечных пользователей) о продукте на этапе исследования - Провести повторное исследование и тестирование технологии до начала этапа реализации проекта - Проверить необходимые для проекта ресурсы до начала реализации Если изменение неизбежно, должен быть формализованный процесс внесения изменений в план проекта. Обычно этот процесс пред полагает заполнение формуляра запроса на изменение проекта (project change request). Наконец, если утверждено внесение изменений в проект, менеджер должен составить план изменения проекта и его графика. Изменения должны обсудить менеджер проекта, спонсор и члены команды разработки, Изучение диаграммы PND и пересмотр ресурсов вместе с бюджетом позволят определить, когда, где и как будут реализованы изменения текущего проекта. Документ о влиянии изменений (change impact statement) — это формальный ответ менеджера проекта автору формуляра запроса об изменении проекта. В документе обобщается план, предлагаемый менеджером проекта для внесения изменений. В документе о влиянии изменений необходимо отразить одно из семи возможных решений об изменениях, принятое менеджером проекта: - Предлагаемые изменения отвергнуты. -Предлагаемые изменения могут быть реализованы: -без нарушения сроков и без дополнительных ресурсов. - без привлечения дополнительных ресурсов, но при смещении сроков проекта. -без смещения сроков проекта, но при выделении дополнительных ресурсов. - но необходимо смещение сроков проекта и выделение дополнительных ресурсов. - но это отразится на порядке поставки завершенных частей проекта. - не могут быть реализован без существенного пересмотра проекта Наиболее неприятные изменения проистекают из самого проекта. Эти изменения не всегда связаны с обнаружившейся новой технологией, некорректностью плана проекта или конфликтом при его реализации. Чаще всего такие изменения связаны с человеческим фактором. Причиной всегда является неправильное руководство командой. Менеджер проекта должен (если, конечно, хочет играть активную роль во время реализации) немедленно реагировать на такую проблему. Еще одна проблема менеджера ИТ-проекта связана с перестановками сотрудников. Если член команды покидает коллектив в связи с увольнением или переходом на другую должность, необходимо как можно быстрее найти замену. Даже если на вакантное место в команде разработки удастся быстро найти достойного кандидата, может потребоваться пересмотр выделения ресурсов и графика проекта из-за разных квалификационных уровней старого и нового сотрудников. Еще один вариант решения проблемы связан с привлечением независимого консультанта или специалиста. Заплатить ему придется больше, чем члену команды, уволившемуся из компании. 25.Пересмотр плана проекта. Внесение изменений в проект. Совещания по возникшим в проекте проблемам. Отложенный проект. Проект периодически изменяется. Этого требует руководство компании, либо происходит изменение состава команды разработки или обнаруживается более привлекательная технология. Необходимо сопротивляться изменениям. Любое из них, даже незначительное, все равно меняет проект и его план! Постарайтесь, чтобы руководство, заказчики и команда разработки сохранили первоначальное видение проекта. Если изменение неизбежно необходим план для реакции и реализации затребованного изменения. Если задержка реализации обусловлена внутренними причинами у менеджера проекта есть несколько способов разрешения проблемы без изменения графика работ: - Привлечь дополнительные ресурсы для завершения проекта по графику -на диаграмме PND изменить для задачи отношение FS (завершение к началу) на SS (начало к началу) -Выделить критическому пути проекта наиболее квалифицированных сотрудников - Перераспределить задачи среди остальных членов команды - Применить административный резерв в задерживающихся задачах -Устранить промежутки задержек между задачами Если изменение проекта обусловлено внешними причинами руководством либо проистекает из бизнес-цикла компании, менеджер проекта должен сделать все, чтобы сохранить выполнение проекта по трафику и в пределах бюджета. Если возникают доп затраты случае менеджеру проекта потребуется опыт проведения переговоров, чтобы обосновать и получить дополнительные время и финансы. Многозвенная структура (tired structure) позволяет менеджеру ИТ-проекта согласиться с новыми требованиями к границам работ, но при условии поставки законченных частей в разные сроки. Решение такого рода позволит менеджеру проекта выиграть время. Чтобы увеличить сроки поставки реализуемых проектом частей. Выиграет и компания, поскольку для нововведений будет достаточно разумных требований к ресурсам проекта. Совещания по возникшим в проекте проблемам призваны устранять эти проблемы по мере их возникновения. Любой проект вне зависимости от тщательности его планирования может столкнуться с проблемами. Совещания по возникшим в проекте проблемам позволит обсудить ситуацию е членами команды, представителем компании-изготовителя или специалистами в области, связанной с обнаруженной проблемой. Цель совещания — в выработке наиболее эффективного решения для устранения проблемы. Можно провести “мозговой штурм”, чтобы рассмотреть различные предложения и проследить их реализацию по диаграмме РМО. Такие совещания являются важным мероприятием для быстрого и точного возращения проекта на исходный путь к цели. Результатом совещания по возникшим в проекте должен стать новый план по внесению изменений в проект, Этот план позволить определить выбранное для проблемы решение и проследить его влияние на оставшиеся задачи в критическом пути проекта. Иногда начатый в компании проект предлагается отменить. Однако нужно попробовать сохранить проект от полного удаления из перспективных планов компании и убедить руководство отложить проект, но не отказываться от него окончательно. Отложенный проект — это не отвергнутый проект, Отсрочка выполнения проекта означает сохранение его плана и возможное возвращение к реализации плана в будущем. Необходимо продолжать работу над проектом, пока явно не будет заявлено о его закрытии. Нет ничего зазорного в вопросе к спонсору проекта о возможности его закрытия в будущем, если менеджер наладил со спонсором хорошие рабочие отношения. Когда появятся сведения о закрытии проекта, выделите в них причины остановки работ. Если закрытие связано с финансовыми причинами (как это обычно бывает), подготовьте предложение о “замораживании” проекта вместо его полного прекращения. 26. Обеспечение качества. Понятие качества. Качество поставляемых проектом частей. Качество процесса реализации проекта. Необходимо управлять процессом производства, чтобы получить качественный продукт, и организовать этот процесс так, чтобы он приводил к конечному результату. Не так часто хаотичный, неорганизованный и сопровождающийся скандалами процесс производства способен привести к прекрасным поставляемым проектом частям. Ценность услуг определяется несколькими показателями: -Значимость реализации -Значимость услуги -Значимость применения -Значимость долговечности -Значимость надежности Проект, производящий услугу, должен быть спланирован и реализован исходя из конечного результата. Поставляемые проектом части (т. е. предоставляемые услуги) должны соответствовать обещаниям менеджера проекта, а команда разработки должна иметь необходимую квалификацию для установки и запуска надежной, доступной и долговечной службы. Ценность продукта зависит от его свойств. Однако для любого товара существуют общие оценки качества: -Значимость товара. Стоит ли продукт своей цены? -Значимость полезности Пригоден ли товар для использования? -Значимость надежности. Надежно ли работает товар? -Значимость долговечности Каков жизненный цикл продукта Вне зависимости от производства товаров или услуг существует процесс для достижения проектом поставляемых частей. Во время движения проекта от начала до завершения выполняется набор процессов, определяемых логическим и дискретным порядком. К процессам относятся начало работы над проектом, руководство командой разработки, общение с коллегами, работа с руководством компании, причем все эти процессы влияют на качество поставляемых проектом частей. Качество менеджмента проекта определяется несколькими факторами: - Результаты Создание поставляемых частей отражает способность менеджера проекта управлять и завершить проект. - Опытность Умение провести исследование, планирование и реализацию проекта - Команда разработки Члены команды разработки будут оценивать действия менеджера проекта по его способности привести коллектив к конечному результату, Менеджер ИТ-проекта обязан сохранить в своих руках управление как надеждами на поставляемые части, так и управление процессом получения этих поставляемых частей, причем качество процесса напрямую связано с качеством поставляемых проектом частей. У менеджера проекта могут быть разные стратегии обеспечения того, что процесс менеджмента эффективен н позволяет достичь целей проекта без задержек и превышения стоимости. На это надеется и компания, привлекшая менеджера к управлению проектом. Неорганизованному менеджеру необходимо научиться упорядочивать свою деятельность. При этом не только улучшится способность управления процессом, но и качество проведения работ. Еше одним способом, особенно в длительных проектах и при географически распределенной команде разработки, станет создание сайту 8 сети интранет для всех заинтересованных в проекте лиц. Web-решение для проекта может использоваться всей компанией. В не. которых организациях есть центральные подразделения менеджмента проектов (project management office), которые координируют все действия в рамках разных проектов через единое web-решение. Одним из наиболее полезных в менеджменте проектов программным средством является пакет Microsoft project. Вместе с ним можно применять дополнительный программный пакет Microsoft project Central позволяющий менеджеру проекта упорядочивать, отслеживать, оценивать, планировать события, связанные с проектом. 27.Обеспечение качества. Процесс управления качеством. Этапы обеспечения качества в менеджменте проектов. Тотальное управление качеством. Создание стратегии обеспечения качества. Качество менеджмента проекта достигается за счет обеспечения качественной разработки поставляемых проектом частей и качественного выполнения всех задач проекта. Этот процесс предполагает, что менеджер проекта обеспечивает качественное выполнения работ от начала и до завершения проекта, а также распространение требований к качеству на всю команду разработки и на весь жизненный цикл проекта. Пять основных этапов реализации проекта, на каждом из которых менеджер проекта обязан обеспечить качество работы и придерживаться следующих правил: - Начало проекта Причиной проекта является реакция на потребности или идеи об улучшении деятельности компании. -Планирование проекта Основой успешного проекта является этап планирования. - Реализация проекта После утверждения плана проекта менеджер создает диаграммы PND (карту планируемых задач), распределяет ресурсы ин организует команду разработки проекта. Менеджер проекта - Управление проектом На этом этапе менеджер проекта занимается контролем всех циклов реализации проекта. - Завершение проекта На этом этапе менеджмента проекта оцениваются проведенные в его рамках работы. Total Quality management (ТQМ). Это — процесс, предписывающий всем участвующим в некоторой операции сотрудникам компании заботиться о полном удовлетворений требований клиентов, причем без снижения производительности труда. Понятие тотального управления качеством ТQМ ввел д-р У. Эдвард Деминг. Основным базовым принципом ТQМ является теория постоянного повышения качества -Continuous Quality Improvement. Согласно этой теории, все правила и операции, используемые в деятельности компании, должны постоянно совершенствоваться, что приведет к увеличению производительности и повышению рентабельности. Управление качеством проекта как процессом не определяется какой-нибудь одной магической формулой, этот процесс связан с преданностью своей работе менеджера проекта и команды разработки, а также нацеленностью на высокую оценку работы на любом этапе проекта, чтобы в конце получить качественный поставляемые части. Все остальное можно считать неприемлемым. Управление качеством требует плана действий, описания процессов и стратегии для реализации запланированных операций. Нужно одновременно с командой разработки сфокусироваться на обеспечении качества. Хорошим методом обеспечения качества некоторых проектов является поддержание баланса времени, стоимости и ресурсов. Качество проекта зависит от выделенного времени, бюджета и способности менеджера руководить командой разработки. Перекос в любом из этих показателей скажется на качестве проекта. Первая сторона — это строгое управление временем. Отдельные проекты имеют большую свободу по времени, но все же на этапе планирования проекта нужно точно предсказать затраты времени для реализации плана и достижения целей проекта. Бюджет проекта после утверждения руководством становится одним из управляемых менеджером факторов — одним из наиболее важных параметром слежения за проектом. План проекта и его реализации помогут определить бюджет, но если планирование проведено некорректно, необоснованно или не полностью, то в дальнейшем можно ожидать проблем с бюджетом проекта. Третьей стороной треугольника качества является управление ресурсами. Это наиболее сложная в управлении часть любого проекта. Любой член команды оказывает существенное влияние на своих коллег, а также на стороны времени и бюджета в треугольнике качества. Менеджер проекта может использовать отчеты 4 типов: - Отчет о текущем состоянии - Накапливаемый отчет - Итоговый отчет для руководства - Подробный отчет о вариациях - 28.Обеспечение качества. Обеспечение качества на этапах реализации проекта. При переходе проекта между этапами, устранении проблем и преодолении барьеров необходима четкая система проверки качества процесса реализации. Можно привлечь одну или несколько теорий из области менеджмента проектов, но все они имеют общий корень: выполненная работа оценивается по готовности поставляемых проектом частей. В смысле обеспечения качества менеджер должен проверять проект по готовности поставляемых им частей. После того как приложение создано, проводится оценка результатов работы приложения. Обычно графический интерфейс программы свидетельствует о ее качестве, но не менее важно удобство работы. Менеджер проекта вместе с конечными пользователями должен численно оценить производительность нового приложения, чтобы точно определить его рентабельность. Возврат инвестиций в ИТ-проект — вполне точный показатель, определяемый поставляемыми проектом частями. Доход от реализации ИТ-проекта в области производительности труда напрямую связан с поставляемыми частями. Не отходите от фактов. Полезность проекта линейно зависит от доходности, достигнутой за счет поставляемых проектом частей. Итак, качество оценивается по конечному результату проекта. Необязательно ждать полного завершения работ, чтобы провести оценку качества. Можно использовать оценку качества QA (Quality assurance) по мнению команды разработки, полученную еще на этапе реализации проекта. В ИТ-проекте число явных показателей качества ограничено. Нельзя провести замер производительности ненаписанной программы. Оценка качества в ИТ-проекте основывается на подробном плане реализации технологии. Наилучшим способом исключения неожиданных ошибок в процессе реализации станет тестирование технологии в лабораторной среде. Предварительное тестирование позволит избежать или сократить время незапланированных отключений в производственной среде компании. Один из способов оценки качества ИТ-проекта состоит в оценке коллег по работе. Анализ такого рода предполагает оценку членами команды результатов работы своих коллег. Этим достигается гарантированное завершение работы членами команды и выполнение ее с должным уровнем качества. Оценка коллег обеспечивает разные цели, в том числе: - Гарантирует оценку качества каждой задачи проекта - Позволяет членам команды показать другим результаты своей работы - Позволяет членам команды узнать о других областях работ над проектом, - Позволяет менеджеру проекта быть уверенным в завершении поставленных задач - Повышает ответственность команды за качество работ Одним из наиболее эффективных способов управления качеством является наблюдение. Пойдите на рабочие места членов команды. Необязательно надзирать за работой каждого сотрудника, но люди должны знать, что менеджер проекта доступен, открыт и интересуется работой. Еще один пример оценки качества выполняемой работы связан с приглашением для анализа качества стороннего специалиста. Это позволит менеджеру проекта, который, возможно, обладает меньшей квалификацией в данной технологии по сравнению с членами команды, точно и правильно оценить выполнение работ в рамках проекта. Кроме оценки качества консультант поможет и в других областях, способствующих успеху проекта: - Проверит качество и точность выполнения работы - Предоставит непредвзятое мнение со стороны - Сформирует отчетность о работе команды проекта - Поддержит на должном уровне ответственность за порученную работу - Позволит менеджеру проекта узнать реальное положение дел -Позволит менеджеру выполнить необходимые для проекта изменения 29.Управление коллективом. Руководство командой. Формирование духа авторства в проекте. Способы управления командой разработки. Совещания команды проекта. Чтобы руководить командой, менеджер проекта должен стать ее лидером. Все лидеры имеют общее: способность мотивировать людей для устремления и достижения цели. Наиболее простой путь к формированию увлеченности проектом у других людей состоит увлеченности этим проектом. Нужно заразить остальных своим желанием получить поставляемые проектом части, энтузиазмом и рвением к успеху. Менеджер проекта, желающий стать лидером команды, должен заботиться не только об успешном завершении проекта, но и об успехах каждого члена команды. Выделите время на общение с членами команды, передайте им свою увлеченность. Менеджер обязан сформировать дух авторства проекта. Авторство менеджера отличается от авторства члена команды. Менеджер проекта отвечает за успех всего проекта, поэтому должен участвовать во всех действиях по его реализации. В менеджменте проектов неразрывно связаны авторство и ответственность. Обязанность менеджера проекта состоят в продвижении и признании возможностей членов команды завершить проект и сформировать поставляемые им части. Члены команды должен согласиться с лидерством менеджера проекта и поддерживать решения менеджера. Для успеха проекта необходимы следующие черты лидера: - Опыт управления - Заинтересованность в успехе команды - Заинтересованность в успехе проекта - Способность к работе с людьми - Способность слушать чужое мнение - Быть воспитанным и порядочным - Способность работать профессионально - Нацеленность на качество к Ориентация на успешное завершение проекта Менеджер проекта руководит процессом принятия решения командой разработки, использует мнение специалистов и их профессиональный опыт. Для подтверждения правильности решения менеджер проекта может использовать три разных способа получения этого решения: - Директивный Менеджер проекта принимает решения без учета мнения команды разработки. - Совместный в этом случае в выработке решения участвуют все члены команды разработки. - Консультативный объединяет наилучшие черты двух предыдущих методов принятия решений. С точки зрения менеджера проекта, можно обнаружить четыре типа поведения людей в конфликтных ситуациях: - Уклоняющийся Такие люди предпочитают избегать любых конфликтов. - Агрессивные Люди этого типа обожают споры. ИХ мнение почти всегда противоположно общепринятому - Мыслители Люди, умудренные большим жизненным опытом. - Идеалисты Эти члены команды имеют прекрасные устремления, но часто видят проект слишком простым и прямолинейным. Менеджер проекта, желающий эффективно руководить коллективом, должен быть организованным, подготовленным и открытым для общения. Во время встреч с членами команды они будут ожидать от менеджера обоснованного и эффективного проведения совещаний. Нужно решить, как часто нужно общаться всем коллективом для обсуждения проекта в целом н проведения работ согласно графику. Обычно на регулярных совещаниях команды разработки обсуждаются состояние работ проекта и текущие вопросы. Среди них: - Обзор завершенных задач - Обзор предстоящих задач - Рассказ о достижениях членов команды - Обзор текущих вопросов проекта - Новости о проекте в целом Если решено передать подготовку и проведение совещаний специально назначенному координатору, то такой человек должен обладать определенными качествами: - Согласием с позицией менеджера на реализацию проекта - Желанием обучаться и общаться - Навыками руководителя - Способностью управлять временем - Обязательностью при подготовке совещания Итоговый документ совещания регистрирует обсуждавшиеся проблемы и предложенные решения, а также текущее состояние дел в проекте. 30.Управление коллективом. Обеспечение лидерства в команде разработки. Работа на конечный результат. Мотивация команды разработки. Проект сам по себе не достигнет цели — необходимо участие менеджера проекта. Постоянное и непрекращающееся влияние проблем, непредвиденных ситуаций, задерживающихся задач и недостатков технологии всплывает на поверхность вне зависимости от того, какие причины нарушают поступательное продвижение проекта. Менеджер проекта должен провести команду через все ловушки, тупики и ошибки, препятствующие достижению цели проекта. Это требует от менеджера проекта опыта, квалификации н способностей. С точки зрения информационных технологий опыт означает практически любой навык. Менеджер ИТ-проекта может считать процесс управления проектом логическим переходом на руководящие должности в компании. Личная уверенность в предложенной технологии должна основываться не только на знаниях привлеченных специалистов, но и на собственных знаниях менеджера проекта Опыт работы в ИТ-области поможет менеджеру успешно руководит коллективом, чтобы сохранить движение к целям проекта. Можно стать профессионалом вне зависимости от предыдущего опыта. Секрет в том, что нужно выявить свои недостатки и искать способы и методы для получения необходимого опыта применения технологии или достижения нужного уровня административных навыков. Для проекта нужно многое: финансы, оборудование, время и другие ресурсы. Главным из этого является доступность в проекте всех необходимых частей. К ресурсам проекта относятся сам менеджер проекта, руководство, спонсор проекта и команда разработки. Необходимо сформировать и поддерживать отношения между всеми участниками проекта для его непрерывности и достижения поставленных целей, иначе менеджер вряд ли сможет успешно реализовать проект и обеспечить собственный карьерный рост. Руководство, спонсор проекта и заинтересованные в нем подразделения компании регулярно должны получать информацию от менеджера проекта. Все они хотят и обязаны быть информированы о текущем положении дел. Команда разработки ждет от менеджера проекта не только руководящих указаний, распределения задач и обновления проекта при необходимости. Команда ждет подтверждения мотивации собственных усилий, Мотивация— это способность передачи своей заинтересованности проектом членам команды разработки. Мотивация и уровень заинтересованности в первую очередь определяются порядками в компании, рабочей атмосферой и преданности общему делу любого члена команды. Суть Теория мотивации-гигиены в том, что на работника влияют нематериальные факторы, называемые мотиваторами, и гигиенический эффект, называемый демотиватором. Мотивированные работники комфортно чувствуют себя на работе и находят возможности для карьерного роста Поборники гигиены находят удобным безопасное и “теплое” место к компании. Факторами демотивации становятся преимущества компании для работника — страхование, свободное время и пр. Гигиена компании отражает атмосферу и политику внутри компании. Факторы гигиены, с которыми себя чувствуют комфортно работники, относящиеся к категории поборников гигиены: - Политика и методы - управления в компании - Надзор - Жалованье - Отношения между сотрудниками - Условия труда Мотивированные работники считать комфортными пять иных факторов: - Достижения - Официальное признание - Сама работа -Ответственность -Продвижение по службе 31. Завершение проекта. Завершение последних задач. Документы о завершении проекта. Когда видно, что окончание проекта уже на горизонте, это не сигнал для успокоения участников проекта. Проблема расслабления менеджера к концу работы над проектом приведет к тому, что команда разработки последует примеру своего руководителя. На завершающем этапе проекта его менеджер должен приложить еще больше усилий для мотивации и общения с командой разработки. Менеджеру проекта следует обсуждать с командой, заказчиком и руководством последние возникающие проблемы. Заключительная задача этого проекта имеет особую важность. К ней вели вся ранее проделанная подготовительная работа, исследования и разработки. Когда обнаружится, что за несколько часов нужно выполнить огромный объем работы, можно предложить следующие рекомендации: Оставайтесь спокойным и собранным. Покажите пример команде. Организуйте и рассматривайте заключительные задачи как мини-проект Общайтесь с членами команды даже при недостатке рабочего времени Если приходится осматривать множество рабочих станций, установите для себя метод визуальной оценки завершения работы Проверяйте качество работы Работайте по сменам При приближении к концу проекта еще раз внимательно изучите критический путь проекта, чтобы выявить порядок выполнения задач и проверить мотивацию членов команды, которым эти задачи поручены. Когда на этапе реализации проекта привлекаются сторонние участники, нужно точно следовать принципу “98% не означает полного завершения работы”. Сторонним компаниям стоит напомнить о необходимости полного выполнения работы и использовать для этого следующие побудительные факторы: Окончательный платеж блокируется до полного завершения работы, Завышение объема поставляемых проектом частей до 105%, чтобы гарантированно получить 100% выполнения плана. Настоять на четком согласовании даты и времени выполнения окончательного этапа реализации проекта. Присвоить критическому пути специальную задачу, предполагающую анализ и исследование выполненных ранее задач. Последняя задача проекта выполнена, и собраны все подписи под актом сдачи в эксплуатацию. Но это не все, в рамках проекта нужно выполнить еще много работы. После завершения всех задач реализации по критическому пути менеджер проекта и команда разработки получают возможность оценить свою работу. К этому этапу относят: Оценку качества Оценка поставляемых частей Определение ценности проекта Сторонняя оценка 32. Завершение проекта. Акт сдачи в эксплуатацию. Аудит после проекта. Формирование окончательного отчета о проекте. Объявление победы. Объявление неудачи. После проверки поставляемых проектом частей менеджер сдает проект в эксплуатацию. Заказчик может одобрить проект двумя разными способами: Неформальное одобрение – не требует документального подтверждения получения поставляемых проектом частей. Формальное одобрение предполагает подпись установленных документов.. После завершения проекта, но до утверждения окончательного отчета менеджер должен провести аудит успешности проекта. Целью станет анализ завершенного проекта. Аудит должен дать ответы на следующие вопросы; Достигнуто ли видение проекта? Выполнялся ли проект по графику от начала и до завершения? Сформировал ли проект значимые бизнес-ценности? Какие уроки следует извлечь? Аудитом после завершения проекта пренебрегают многие менеджеры. Но это важный компонент повышения собственной квалификации. Кроме того, аудит создает основу для отчета о проведенной работе и созданной технологии. На любом этапе проекта, в том числе и на завершающем, необходимо документировать результаты выполненной работы. Окончательный отчет о проекте не должен быть слишком подробным. В нем нужно отразить: Видение проекта Предложения по проекту Исходный и пересмотренный планы проекта Схему WBS и PND Итоговые отчеты о совещаниях команды разработки Все формуляры запросов на изменение проекта, которые были приняты. Все письменные заметки о поставляемых проектом частях. Общую стоимость проекта и затраты на реализацию Документ об одобрении заказчиком Отчет об аудите после проекта В конце проекта совершенно очевидным станет результат проекта — успех или неудача. Проект считается успешным, когда он был завершен в срок, выполнен в установленных границах и в пределах выделенного бюджета. Некоторые проекты будут неудачными из-за некачественного менеджмента. Для успешных проектов характерны следующе признаки: Видение поставляемых проектом частей Адекватная квалификация менеджера проекта Адекватная квалификация команды разработки Достаточное финансирование Время для завершения работы над поставляемыми проектом частями Усилия руководства по защите границ проекта Приверженность проекту всех заинтересованных в нем лиц Иногда проект прекращается не от отсутствия лидерства, финансов или времени, а по другим причинам (появление новой технологии, смена руководства и др.). Вне зависимости от успеха или неудачи проекта его менеджер должен оформить окончательный отчет о проекте для знакомства руководства с проведенными работами.
