Один из самых тонких моментов при планировании проекта - оценка времени его реализации. Есть мнение, часто приводимое в качестве шутки: "Время, необходимое для реализации проекта в случае аутсорсинга, представляет собой время, заявленное партнерами, умноженное на случайное число в диапазоне от экспоненты до пи". Надо признать, что порой и при самостоятельном выполнении проекта длительность реализации (выполнения) получаются несколько больше заявленной. (На моей памяти были "долгострои", когда время выполнения проекта как самостоятельно, так и внешним подрядчиком, отличалось от расчетного раза в 2. Конечно, два - это не совсем экспонента (e=2,7), но близко. Традиционно возникает вопрос: почему? Или, в другой интерпретации: кто виноват и что делать?

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

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

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

Оригинал и комментарии: ITBlogs.ru

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

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

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

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

Получается: "не внедряйте, да не внедряемы будете":)

Оригинал и комментарии: ITBlogs.ru

Любопытно, кто и как оценивает эффективность внедрения той или иной информационной системы?

Я, например, стараюсь подобрать KPI, которые в максимальной степени связаны с областью, в которой происходит автоматизация. Например, при внедрении Service Desk такими критериями будут являться время разрешения инцидента (оно, по идее, должно уменьшится) и количество претензий пользователей (оно, по идее, тоже должно уменьшится). В случае системы управления поручениями - количество совещаний, и т.д.

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

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

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

Оригинал и комментарии: ITBlogs.ru

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

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

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

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

Оригинал и комментарии на ITBlogs.ru

Просматривая блоги на itblogs.ru (кстати, рекомендую), наткнулся на пост Михаила Елашкина (Как правильно заканчивать мертвые проекты ), который с удовольствием цитирую:

Как правильно заканчивать мертвые проекты

Долго не кончать – достоинство мужчины, а не менеджера(С) по мотивам Довлатова

Народная индейская мудрость гласит: «Если вы обнаружили, что ваша лошадь сдохла, то слезьте с неё. Однако в мире корпоративных проектов все не так просто. Существует несколько очень популярных стратегий в этой области:

1. Купить более мощный кнут.
2. Сменить наездника.
3. Говорить: «А мы всегда так скачем – на дохлых лошадях»
4. Создать комитет по изучению лошади.
5. Посетить другие компании, чтобы узнать их опыт скачек на дохлых лошадях.
6. Начать разрабатывать стандарты езды на мертвых лошадях
7. Создать специальную команду из сильных специалистов для оживления лошади
8. Создать курсы для персонала по езде на дохлых лошадях
9. Изменить требования так чтобы лошадь выглядела живой
10. Нанять аутсорсеров – наездников дохлых лошадей
11. Запрячь в одну упряжку несколько дохлых лошадей в расчете на то, что они повезут
12. Решить усилить управление – ни одна лошадь недостаточно дохлая, чтобы перестать ее бить.
13. Выделить дополнительные средства, чтобы улучшить производительность работы дохлой лошади
14. Провести анализ эффективности и сократить расходы на наездников передав их обязанности аутсорсерам
15. Купить специальные продукты третьих фирм по ускорению дохлых лошадей
16. Объявить что лошади «лучше, быстрее и дешевле» когда они дохлые
17. Провести исследование по поиску применения дохлых лошадей
18. Пересмотреть параметры эффективности лошадей
19. Повысить в должности виновного в смерти лошади

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

Давайте задумаемся. Буквально на секунду. Что представляет собой предпроектное обследование? Это, по сути – анализ предметной области (то есть, анализ состояния исследуемого объекта - предприятия, в заданном разрезе, с учетом оговоренных рамок и ограничений) «как есть», с одновременным сбором полезной для проекта информации. Затем – проект, проектирование и реализация «как будет». Так вот, стоит ли проводить это обследование, если заказчик и так знает, что у него происходит? Не уверен.

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

Попробую пояснить на примере. Организация внедряет процесс управления инцидентами, в соответствии с ITIL. Если руководство представляет себе ожидания бизнес-пользователей от внедрения, состояние управления инцидентами в настоящий момент – то предпроектное обследование становится просто ненужным. И имеет смысл лишь сбор информации, относящейся к проекту.

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