управляющий проектом

1. управляющий проектом Что такое проект? Согласно DIN 69901, проект - это проект, который соответствует...
2. планирование проекта
3. Контроллинг проектов и МСФО / МСФО
4. источник
5. Первые авторы

управляющий проектом

Что такое проект? Согласно DIN 69901, проект - это проект, который соответствует следующим критериям:

1. Это уникальный, поэтому не постоянно повторяющийся процесс, никакой рутинной деятельности.
2. Это включает в себя определенную сложность (например, высокие накладные расходы, перекрестные, рискованные).
3. У него есть четкие цели.

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

Уникальные определения целей важны!

Покажите мне, как ваш проект начинается, и я расскажу, как он заканчивается. В отличие от постоянных задач, проект в какой-то момент закончен. Это делает еще более важным описать точку в начале проекта, где задача выполнена. Чистое завершение проекта может быть выполнено только при условии правильно определенной цели проекта . (Будущий) руководитель проекта должен сначала согласовать цели, связанные с контентом, с клиентом. Параметры даты и стоимости зависят от содержания контента. Определение цели является отправной точкой для всего планирования проекта и создает безопасность для всех участников: клиент знает, что он получает, а менеджер проекта знает основу его действий. Это позволяет избежать недоразумений при закрытии проекта.

Вы должны представить это как пари. Клиент говорит: Вы не можете сделать это! Руководитель проекта останавливается и позже должен доказать, что он это сделал. Поэтому он должен сосредоточиться на завершении проекта и описать ситуацию так, как должно быть. Особенно здесь: цели не должны быть интерпретируемыми, они должны быть измеримыми! Так что нет: на 1.1. это программное обеспечение XY введено. Потому что это значит ввести? Она записана на сервере? Работает ли без ошибок? Обучены ли пользователи?

Рисунок 1: Взаимозависимости в объективном треугольнике проекта

планирование проекта

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

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

Рисунок 2: План структуры проекта - объектно-ориентированный

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

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

Пакеты работ из плана структуры проекта формируют основу для оценки усилий. Здесь требуется абсолютное время (т. Е. Сколько времени занимает обработка пакета) и интенсивность в%, с которой сотрудник может обеспечить эти усилия (праздники, обучение, другие виды деятельности?).

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

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

Особенно в крупных проектах важен анализ денежных потоков . Исходя из плана сети, сроки платежей запланированы . Это, в свою очередь, является основой для переговоров с клиентом по авансовым платежам, связанным с проектом . Цель состоит в том, чтобы распознать и свести к минимуму любое «предварительное финансирование».

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

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

Рисунок 3: Отчет о состоянии проекта в виде «4 окна»

Левая часть показывает анализ фактического состояния. Самая сложная часть - это, конечно, статус обработки или степень готовности . Конечно, вы также возьмете на себя часы в качестве руководства. Но было бы неправильно просто сказать, что наш проект на 30,6. быть готовым на 40% из-за 5000 предварительно рассчитанных часов между тем 2000 год понесены. Статус обработки должен быть оценен после завершения строительства. Только менеджеры / специалисты, ответственные за рабочие пакеты, могут сделать это сами. Контроллинг проекта - типичный случай, который может быть решен только с точки зрения самоконтроля. Контролер - и часто руководитель проекта - не может проверить правильность предоставленной информации. Степень завершенности приводит к расчету технического обслуживания проекта , в котором указывается, сколько еще часов потребуется ( необходимо завершить ).

Контроллинг проектов и МСФО / МСФО

Контроллинг проектов в последнее время стал более важным благодаря интернационализации бухгалтерского учета. С одной стороны, это касается учета договоров на строительство в соответствии с МСФО 11 . Незавершенные проекты - физические товары, а также услуги - должны рассчитываться по методу PoC «процент выполнения». Это означает, что прибыль (или, точнее, маржинальная прибыль) от проекта не будет реализована до конца, но частичная реализация прибыли в соответствии с этапом завершения должна быть выполнена на отчетную дату. Это требует надежной оценки результатов проекта. Процент выполнения обычно определяется с использованием метода « затраты-затраты» (= фактические затраты / предполагаемые общие затраты). В итоге это приводит к более ранней, но менее волатильной карточке заработка.

Вторая точка соприкосновения контролера проекта с внешним бухгалтерским учетом касается учета затрат на разработку. Хотя затраты на разработку признаются немедленно в соответствии с HGB, обязательство по признанию признается в соответствии с МСФО (IAS) 38 при условии соблюдения определенных условий. Это включает в себя предоставление доказательств того, как актив достигнет ожидаемых будущих экономических выгод . Поэтому контролер должен создать бизнес- план. С другой стороны, он должен обеспечить, чтобы в рамках его системы управления проектами затраты на разработку были отделены от некапитализируемых затрат на исследования (веха!) И, конечно, были надежно определены. Поэтому элемент контировки, который контролер устанавливает и управляет, больше не является просто внутренним коллектором затрат, который заканчивается анализом рентабельности, а является основой для балансовой оценки затрат на разработку и подлежит контролю аудитора.

источник

Руководство для контроллеров, 6-е издание, переписано, издательство ControllingWissen AG, Оффенбург, 2008

Первые авторы

Альбрехт Дейхле, Академия контролеров

Герхард Радингер, Академия контролеров

Похожие

Комментарии