Существует несколько самых распространённых практик управления проектами:
- Waterfall – итеративная методология разработки. Этот подход характеризуется жёсткой последовательностью решения задач. Привязка идёт от задачи к задаче. Пропускать или выкидывать задачи из процесса нельзя. Проблема решается по факту наступления срока задачи.
- Плановое управление проектом – задачи могут решаться параллельно. Какие-то подзадачи, вполне, можно менять местами и на сроки проекта это не повлияет. Сильно помогает контролировать весь процесс Диаграмма Ганта. Подход является наиболее распространённым при работе с внешним подрядчиком.
- От конечной даты – ситуация, когда точно известна конечная дата сдачи проекта и ввода его в эксплуатацию. Самый яркий пример – строительство на олимпиаде в Сочи. Дата проведения точно известна и сдвинуть её вообще никак нельзя, сославшись на плохое самочувствие.
- Методология Agile – Российский рынок только недавно стал осваивать этот подход. Прецеденты есть в больших компаниях: банки, сотовые операторы, иностранные компании.
В основном это всё. Остальное является либо ответвлениями, либо составляющими частями методологий проектного управления.
Проблема: Все работают, как хотят
Если каждый бизнес единица работает по своим правилам, то ничего не получится. Необходимо единообразие
Мы команда? – ДА. Бежим? – КОНЕЧНО. Куда бежим? – тихое молчание…
Начальник или TOP-менеджмент всегда хотят понимать, что происходит с проектом, на какой стадии сейчас задача, когда запустимся. Логично вести проект на Плановой основе. Менеджер проекта составляет ТЗ, ДТБ, согласовывает все с бизнесом, делает красивую картинку на диаграмме Ганта. Отчитывается начальнику и вроде бы все хорошо.
Допустим ситуацию, что задачки делаются, нет никаких внешних факторов, но видно, что сроки плывут вниз. Возникает вопрос ПОЧЕМУ? Проблема как всегда простая – не договорились на старте. Выясняется, что внутри отдела может быть вы и работаете по Плану, а когда речь идёт о взаимодействии отделов, все работают по своему. У каждого отдела в компании, есть своя операционная деятельность. А тут руководство подкидывает ещё какие-то непонятные задачи. Нужно куда-то ходить, что-то согласовывать. В этой ситуации нормально, что люди решают в первую очередь свои прямые задачи, а потом что осталось.
! Подумайте, как у вас налажено взаимоотношение между подразделениями? Все ли участники проекта понимают, что вы работаете по плану, а не по задачам. Или все знают конечный срок сдачи проекта и свою ответственность в нем?
Решение: Общение на одном языке. Работа в одной парадигме.
Любой проект варьирует тремя параметрами: T-сроки проекта; $-инвестиции по проекту; K-качество. Но для успешной его реализации может быть важнее даже не это. Внутреннее взаимодействие, единообразное понимание задачи, единый подход к процессу решения задач по проекту. Это может стать краеугольным камнем.
Вывод
Договаривайтесь на старте о том, как ведется работа по проекту: — по задачам – по плану – к известной дате… Добейтесь того чтобы все понимали разницу. Руководителю проекта это нужно сделать в первую очередь. Ну и самое важное – ваше руководство само должно это понимать, чтобы в ситуации срыва сроков или увеличения сметы было понятно к кому идти. В иной ситуации крайним является человек, который ведет это проект. Третьего не дано 🙂
В своё время, я понял это только в процессе работы над проектом, когда были сорваны сроки. Противодействующий сил для того, чтобы со всеми договориться о том, как будет вестись совместная работа много. Это и нежелание сотрудников менять привычных порядок дел, недоверие, корпоративная культура компании, опыт.
В любом случае, от этих вопросов не убежать. Рано или поздно решать придётся.