Вот мои критерии - чем их больше тем больше вероятность наличия проблем на проекте:
- В плане есть задачи длительностью более 4 дней. Оптимальным считается когда в плане задачи длительностью от 4 часов до 4 дней. Если задачи более крупные их следует разукрупнить.
- Присутствуют невыполненные задачи в прошлом.
- Слишком много задач - план настолько детальный что его невозможно охватить взглядом и осознать весь целиком.
- Много задач привязано жестко ко времени вместо того чтобы иметь зависимости друг от друга
- Очень много нестандартных зависимостей: Finish-Finish, Start-Start, Start-Finish.
- Использование ресурсов не выровнено - хотя люди на самом деле на проекте задействованы равномерно: фулл-тайм или парт-тайм
- В проектах по разработке забывают включать задачи по
- получению аппрувов от служб безопасности, бизнеса
- закупке и настройке оборудования
- настройке сред для разработки и тестирования
- тестированию (юнит-тестирование, системное тестирование, приемочное тестирование),
- code review
- баг-фиксингу
- созданию документации/справки
- обучению команд operations/support
- созданию процессов backup/rollback
- деплойменту в тестовый, предпродакшен и продакшен среды.
- Если в качестве оценки были взяты числа указанные руководством а не проэстимированные командой (это нельзя сказать глядя на план - тут нужно узнавать предысторию, но если числа слишком круглые то так скорее всего и было).
- Если команда дала оценку но в виде одного числа для каждой задачи, т.е. если не применялась оценка несколькими членами команды и не применялся PERT (тут тоже чаще всего нужно узнавать предысторию, т.к. не все пользуются полями для PERT а чаще сразу заносят финальные цифры рассчитанные где-то вовне)
- Отсутствуют резервы на известные и неизвестные риски.
- Если в плане отсутствует baseline и не делается анализ сравнения текущего плана с изначальным.
