Доброго времени суток!

У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

Спасибо!

Здравствуйте, karbon76, Вы писали:

K>Доброго времени суток!

K>У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

K>Спасибо!

аналитики должны подчиняться своим проджектлидам

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, karbon76, Вы писали:

K>>Доброго времени суток!

K>>У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

K>>Спасибо!

А>аналитики должны подчиняться своим проджектлидам

Вот и я так чувствую. И точно так же я (проджектлид) говорю своему IT-директору. Но почему так будет лучше? Лично я не могу ему достаточно внятно обьяснить.

Его аргумент — сис.аналитик должен подчиняться мне, потому что это важная стратегическая роль, и если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет. Если он будет подчиняться IT-директору, то будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал, а не будет использован проджект-лидом.

Что в нашей компании имеется в виду под сис.аналитиком? Это человек, который собирает у заказчика бизнес-требования, и преобразует их в технические требования разработчикам (задание на уровне интерфейса пользователей и интерфейса компонент)

Вобщем, обьясните, пожалуйста, почему сис. аналитик должен подчиняться проджектлиду непосредственно?

Здравствуйте, karbon76, Вы писали:

K>Его аргумент — сис.аналитик должен подчиняться мне, потому что это важная стратегическая роль, и если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет. Если он будет подчиняться IT-директору, то будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал, а не будет использован проджект-лидом.

На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, karbon76, Вы писали:

K>>Его аргумент — сис.аналитик должен подчиняться мне, потому что это важная стратегическая роль, и если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет. Если он будет подчиняться IT-директору, то будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал, а не будет использован проджект-лидом.

G>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

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

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

Здравствуйте, zz-di, Вы писали:

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

Не размыванию, а распределению. При данной схеме аналитики ставят ТЗ, исследуя бизнес-процессы. Их роль, кстати, можно совместить с поддержкой пользователей. Они отвечают за адекватное отражение бизнес-потребностей. Их же при желании сократить команду можно совместить с тестерами и поддержкой пользователей.

Проджект лиды выполняют проект в соответствии с ТЗ — естественно, они могут спорить с аналитиками по поводу ТЗ — но прогнуть они аналитиков не могут — так же, как и аналитики их. Они должны прийти к согласию. Нормальная схема, посмотрите как сделано в Майкрософте — там в параллели находятся program manager, руководитель программеров и руководитель тестеров.

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

ZD>Опять же, с точки зрения темных исскуств , такая лазейка полезна директору, поскольку он оставляет лично себе значительную часть управления, но, в то же время, если что пойдет не так, всегда есть пиэм, на которого можно все свалить. Правильно это или нет — зависит от того, кто ты

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

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

Здравствуйте, Gaperton, Вы писали:

G>Эта схема дает больше прозрачности, что по канонам темных исскуств как раз вредно — интригу замутить меньше возмжностей. А что до того, что на кого свалить — так это вопрос желания и техники.

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

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

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

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

Здравствуйте, zz-di, Вы писали:

ZD>а по мне, как раз, неправильно. Во-первых, непонятно, почему "если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет". Пиэм не заинтересован в прогрессе проекта?

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

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

Мимо ПМ влиять они конечно не должны, от них к нему сформулированные требования приходить и должны. А его работа вставлять их в план и оценивать. ИМНО ПМ и не должен чувствовать себя ответственным единолично за весь проект.


Вячеслав Педак

Здравствуйте, karbon76, Вы писали:

K>Доброго времени суток!

K>У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

Во первых, должен выполняться принцип единоначалия. Соответсвенно, если аналитики формально находятся в IT службе, то кроме как своему непосредственному руководству никому они подчиняться не должны. Проджект менеджеры — они к каким службам относятся? к IT или к каким-то другим? Я так понимаю что они из других служб, иначе бы вопроса не было. В таком случае возможны 2 варианта — аналитики подчиняются IT директору, а проджект менеджеры взаимодействуют с IT директором. Если аналитик загружен данным менеджером полностью, то такая структура может быть неоптимальной (менеджер вынужден взаимодействовать с аналитиком через IT директора, так как аналитик будет иметь полное право не выполнять его работу до непосредственно приказа начальства. В случае конфронтации аналитика и менеджера работа встанет). Чтобы этого избежать, можно построить организационную структуру, когда аналитики на время проекта начинают подчиняться менеджерам — но это совсем другой принцип организации получается. ИМХО первый вариант все-таки лучше.

Здравствуйте, Sshur, Вы писали:

S>Во первых, должен выполняться принцип единоначалия. Соответсвенно, если аналитики формально находятся в IT службе, то кроме как своему непосредственному руководству никому они подчиняться не должны. Проджект менеджеры — они к каким службам относятся? к IT или к каким-то другим? Я так понимаю что они из других служб, иначе бы вопроса не было. В таком случае возможны 2 варианта — аналитики подчиняются IT директору, а проджект менеджеры взаимодействуют с IT директором. Если аналитик загружен данным менеджером полностью, то такая структура может быть неоптимальной (менеджер вынужден взаимодействовать с аналитиком через IT директора, так как аналитик будет иметь полное право не выполнять его работу до непосредственно приказа начальства. В случае конфронтации аналитика и менеджера работа встанет). Чтобы этого избежать, можно построить организационную структуру, когда аналитики на время проекта начинают подчиняться менеджерам — но это совсем другой принцип организации получается. ИМХО первый вариант все-таки лучше.

Нет, проджект-менеджеры тоже подчиняются ИТ-директору, как и системные аналитики...

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, karbon76, Вы писали:

K>>Его аргумент — сис.аналитик должен подчиняться мне, потому что это важная стратегическая роль, и если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет. Если он будет подчиняться IT-директору, то будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал, а не будет использован проджект-лидом.

G>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

Я не говорил, что аналитик один. Я, похоже, невнятно написал. Под каждый проект буду набираться свои системные аналитики. Три проекта — три аналитика. Кому они должны подчиняться — каждый своему проджект-менеджеру, или все три ИТ-директору? Вот в чем был вопрос!

Здравствуйте, karbon76, Вы писали:


K>Нет, проджект-менеджеры тоже подчиняются ИТ-директору, как и системные аналитики...

А в чем тогда проблема? Аналитики подчиняются менеджерам, менеджеры IT директору. Директор в таком случае все равно оставит за собой возможность контролировать результаты работы аналитиков через менеджеров. Да и зачем директору брать на себя дополнительную работу по передаче требований от аналитиков менеджерам? Уровень его задач выше.

Здравствуйте, Gaperton, Вы писали:

G>Не размыванию, а распределению. При данной схеме аналитики ставят ТЗ, исследуя бизнес-процессы. Их роль, кстати, можно совместить с поддержкой пользователей. Они отвечают за адекватное отражение бизнес-потребностей. Их же при желании сократить команду можно совместить с тестерами и поддержкой пользователей.
А если они будут подчиняться менеджеру, они не будут ставить ТЗ? Кмк, базовые функции аналитиков не меняются от того, что их кому-то переподчиняют. А конкретно в этом случае директор не доверяет (либо не уверен в возможностях) менеджеру (менеджерам), из-за чего хочет переложить чать работы менеджера на аналитика ("... будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал"). Не зная нюансов конкретной ситуации сложно сказать, кто из них прав.

G>Проджект лиды выполняют проект в соответствии с ТЗ — естественно, они могут спорить с аналитиками по поводу ТЗ — но прогнуть они аналитиков не могут — так же, как и аналитики их. Они должны прийти к согласию.
Зависит от конкретных личностей. Иногда прямого подчиненного не удается прогнуть, а иногда чужим крутят как хотят

G> Нормальная схема, посмотрите как сделано в Майкрософте — там в параллели находятся program manager, руководитель программеров и руководитель тестеров.
Куда посмотреть? Думаю, там коробочный продукт, а в рассматриваемом случае — внутренняя автоматизация.

G>Директор при данной схеме определяет приоритеты работ, контроллирует порядок реализации функциональности, рисует роадмап по внедрению технологий, инфраструктуры, и новой функциональности, управляет релизами, и разруливает конфликты. Вполне нормальная схема для маленького отдела.
Т.е. директор по сути становится менеджером на трех проектах. В принципе, тоже вариант, почему нет.
Кстати, про маленький отдел в условиях сказано не было Может, у них там по 10 программистов на проект хотят выделить.

ZD>>Опять же, с точки зрения темных исскуств , такая лазейка полезна директору, поскольку он оставляет лично себе значительную часть управления, но, в то же время, если что пойдет не так, всегда есть пиэм, на которого можно все свалить. Правильно это или нет — зависит от того, кто ты

G>Эта схема дает больше прозрачности, что по канонам темных исскуств как раз вредно — интригу замутить меньше возмжностей.
Не понял. Почему (и, главное, кому) больше прозрачности? Директору может и больше, но мы-то вроде пытаемся помочь менеджеру А ему, как раз, прозрачности будет сильно меньше.

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

Пока всё хорошо — все белые и пушистые. Мы команда, друзья, тра-ля-ля... Но когда возникают проблемы (пример: пришел срок сдачи, а ничего не готово), очень часто начинают искать виноватого. И тут виноватым окажется тот, кто хуже подготовился.
А правильно это или нет... нельзя на "темном" строить повседневную работу, но готовым менеджеру надо быть.

Алекс

Здравствуйте, karbon76, Вы писали:

K>Доброго времени суток!

K>У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

Посмотрите здесь: http://old.e-xecutive.ru/publications/aspects/project/article_921/
Рассматриваются различные подходы к организации управления проектами на предприятии.

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

Здравствуйте, Gaperton, Вы писали:

G>Так вот, теперь у меня в голове все встало на свои места.

Шо-то тебя колбасит на эту тему в последнее время
Я в хорошем смысле

Здравствуйте, karbon76, Вы писали:

K>Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

Для начала нужно определиться какую роль будут выполнять аналитики. Как минимум есть два полярных варианта:

1. А ну-ка, милок, сгоняй к бабе Мане и спроси откуда она эту цифру взяла.
2. Аналитик как представитель заказчика (на больших проектах эту роль выполняет Product Manager, у которого в подчинении может быть несколько аналитиков).

Я видел обе схемы. Какую из них выбрать зависит от размеров проекта, удалённости разработчиков от заказчика и предпочтений руководства проекта. На больших проектах и/или удалённости разработчиков рулит второй вариант. На небольших и/или внутренних соответственно первый.

Здравствуйте, karbon76, Вы писали:

G>>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

K>Я не говорил, что аналитик один. Я, похоже, невнятно написал. Под каждый проект буду набираться свои системные аналитики. Три проекта — три аналитика. Кому они должны подчиняться — каждый своему проджект-менеджеру, или все три ИТ-директору? Вот в чем был вопрос!

Что конкретно вменяется в функции аналитику, чем он занят на разных этапах проекта? От этого зависит ответ на вопрос, стоит их выделять в отдельную группу, или нет.

ZD>контролировать сроки и функционал"). Не зная нюансов конкретной ситуации сложно сказать, кто из них прав.

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Gaperton, Вы писали:

G>>Так вот, теперь у меня в голове все встало на свои места.

IT>Шо-то тебя колбасит на эту тему в последнее время
IT>Я в хорошем смысле

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

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

Здравствуйте, karbon76, Вы писали:

А>>аналитики должны подчиняться своим проджектлидам

K>Вот и я так чувствую. И точно так же я (проджектлид) говорю своему IT-директору. Но почему так будет лучше? Лично я не могу ему достаточно внятно обьяснить.

K>Его аргумент — сис.аналитик должен подчиняться мне, потому что это важная стратегическая роль, и если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет. Если он будет подчиняться IT-директору, то будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал, а не будет использован проджект-лидом.

K>Что в нашей компании имеется в виду под сис.аналитиком? Это человек, который собирает у заказчика бизнес-требования, и преобразует их в технические требования разработчикам (задание на уровне интерфейса пользователей и интерфейса компонент)

K>Вобщем, обьясните, пожалуйста, почему сис. аналитик должен подчиняться проджектлиду непосредственно?

------------

1. Аналитик не должен конролировать функционал и сроки. Функционал и сроки контролирует проджектлид. Аналитик "пытает" заказчика и документирует его требования к фунционалу, срокам и его приоритеты. Далее команда проекта (в лице проджектлида) договаривается с заказчиком что они готовы сделать то-то и то-то в такие-то сроки. Заказчик подтверждает, что его поняли верно и это именно то, что он хочет. Эти договоренности надо документировать.

2. Не понимаю опасений по поводу зависимости аналитика от проджектлида и что первый "будет использован проджект-лидом"? Требования которые готовятся аналитиком должны проходить ревью у заказчика. Именно заказчик должен лучше всех (в том числе и ИТ-директора) знать что нужно в итоге получить. И если проджектлид и попытается выкинуть что-то из требований или как-то изменить приоритеты — то это будет обнаружено заказчиком.

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

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

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

Если речь идет именно о такой ситуации совмещения 2х ролей в лице одного ИТ-директора — с одной стороны он ваш начальник, а с другой стороны представитель заказчика — вот это не есть хорошо. У него появится большой соблазн запихать как можно больше функционала в каждый этап (как заказчик), а с другой стороны продавить вас по срокам (как ваш начальник) — т.е. навязать вам нереальные графики работ. Тут вам надо будет иметь смелость аргументировано отстаивать свои оценки трудоемкости и сроков. Либо аккуратно передвинуть ответственность на ИТ директора.

Вообще попытка все делать самому и чрезмерная концентрация контроля на себе — как мне кажется это от недостатка опыта управления. Кажется что никто кроме тебя лучше не сделает. Это надо в себе подавлять. Задача управленца заключается в том чтобы делать работу чужими руками. И делать хорошо

С уважением,
Олег З.