Недооцененные проекты (ограниченный бюджет) - каковы характеристики?
Я пытаюсь определить некоторые маркеры, которые указывают на проект с ограниченными ресурсами.
По моему опыту, проект становится проектом "ограниченных ресурсов", потому что кто-то отчаянно пытался продать решение клиенту. В результате бюджет ограничен, функции отбракованы, а процессы SDLC сведены к минимуму. Эти короткие пути используются для того, чтобы у компании был шанс получить прибыль или даже достичь безубыточности.
Вот список вещей, которые я видел, идут рука об руку с проектом ограниченных ресурсов:
- Минимальное количество времени, выделенное для QA
- Строгий бюрократический процесс для нестандартной работы
- Бюджет запроса на изменение может быть небольшим или отсутствовать
- Формализованные процессы отбрасываются в пользу использования времени на разработку
- Нет времени для проверки качества с добавленной стоимостью, такой как проверка содержимого (например, грамматические или орфографические ошибки в тексте).
- Не может управлять контентом или вводить данные для клиента
- Должны пойти на "достаточно хорошие" решения для кодирования
- Нет времени на проверку удобства использования в коридоре.
- нет бюджета на написание пользовательской документации или руководств.
- Как правило, нет времени для технологических исследований до кодирования
- Нет времени на подготовку документа анализа рисков
- Производственный контрольный список может использоваться вместо графика проекта.
- У программиста нет времени заполнять свои "фактические" времена в сравнении с расчетным временем в расписании проекта.
- Обновления прогресса, предоставляемые клиентам, могут быть менее частыми или очень простыми
- Меньше времени можно потратить на понимание сферы деятельности клиентов
- Программистам, возможно, придется работать без оплаты сверхурочно.
- Нет времени, отведенного для проекта после смерти
Какие еще верные признаки существуют для проекта с ограниченными ресурсами?
===
РЕДАКТИРОВАТЬ
Я постараюсь прояснить некоторые проблемы с примером. это то, что я имею в виду: клиенту дается предложение / цитата о том, что его проект будет стоить 20 тысяч долларов. Затем клиент возвращается и говорит: "Извините, мой бюджет составляет максимум 16 тысяч долларов". босс говорит: "сделайте предложение 16 тысяч долларов - мы хотим эту работу".
так что, по сути, вы должны сделать проект с меньшим бюджетом, чем он должен иметь. есть границы, где это становится нелепым - если клиент скажет "мой бюджет составляет 4 тыс. долларов", вы не сможете этого сделать.
и да, иногда жесткий бюджет может стать настолько глупым, что было плохим деловым решением принять проект в первую очередь (то есть обреченный проект).
я понимаю, что нет такой вещи как проект с неограниченным бюджетом. часто деловые люди принимают решение о том, следует ли осуществлять проект (деловой человек часто не является руководителем проекта).
7 ответов
То, о чем вы говорите, - это не проект с ограниченными ресурсами, а спешный и незапланированный проект.
Несколько пунктов в вашем списке, с которыми я не согласен:
- Строгий бюрократический процесс для нестандартной работы
- Бюджет запроса на изменение может быть небольшим или отсутствовать
На самом деле, это должно быть нормой для большинства проектов. Кто запрашивает и оплачивает изменения, вы или клиент?
- Не может управлять контентом или вводить данные для клиента
- Нет бюджета на написание пользовательской документации или руководств.
Если это не является частью контракта, почему вы это делаете?
- Должны пойти на "достаточно хорошие" решения для кодирования
В какой-то момент вы должны остановиться на "достаточно хорошо", иначе вы будете полировать с этого момента до конца времени.
Что-то, что я хотел бы добавить к вашему списку:
- Канцелярские товары становятся дефицитными или идут под замком.
- Исчезающие корпоративные продукты питания / напитки исчезают
- Время простоя исчезает. 100% вашего рабочего времени должно быть посвящено работе над проектом.
- Принтер / фотокопировальное устройство выполняет полноформатную печать резюме другого сотрудника.
- Дверь босса закрыта на 90% дня.
Откровенно говоря, я никогда не слышал о проекте, который имел неограниченные ресурсы. Даже правительство будет тормозить что-то через некоторое время.
Таким образом, с чисто логической точки зрения все проекты имеют ограниченные ресурсы.
Устаревшая или явно бета-документация, которая не связана с каким-либо выпуском продукта на сайте, или документация, которая выглядит так, как будто она была недоступна в течение нескольких поколений копий Xerox.
Нет на месте установки или поддержки. В зависимости от размера внедряемой системы, компания в хорошей форме может послать одного или нескольких своих разработчиков для наблюдения за реализацией, тогда как компания, работающая в тесном контакте, может предложить поддержку по телефону или по электронной почте только в более "подходе" забей и забудь ".
Ограниченные ресурсы? Все известные мне проекты имеют ограниченные ресурсы:
- время
- Разработчики
- бюджет
"Недорогие проекты"
Если я правильно понимаю, что вы имеете в виду, вы на самом деле говорите о проектах, в которых ресурсы, доступные для проекта, не подходят для достижения результатов, которые были обещаны клиенту.
Я могу придумать четыре способа возникновения этой ситуации:
- Неправильные оценки при подготовке плана проекта
- Требования ползучести
- Сокращение бюджета проекта без сокращения масштабов проекта
- Недостаточные ресурсы (навыки персонала, компьютерные ресурсы и т. Д.) Для объема проекта
Когда люди в проекте узнают о ситуации, у них действительно есть два варианта: сократить расходы или сократить масштабы. Сокращение объема может быть жесткой продажей и может поставить под угрозу жизнеспособность проекта, поэтому большую часть времени люди предпочитают сокращать куски, особенно потому, что затраты могут быть сокращены разными способами, не привлекая внимания высших эшелонов:
- Неоплачиваемая сверхурочная работа
- Снижение качества
- Исключение документации
и так далее.
На самом деле, вы можете даже хорошо выглядеть как менеджер проекта, когда начнете сокращать расходы, так как сдерживание затрат является одной из обязанностей менеджера проекта! Я предполагаю, что вы хотите найти способы диагностики недостаточно финансируемого проекта. Я думаю, что вместо разработки обширного списка симптомов, я бы попытался определить общее состояние.
На мой взгляд, есть общее условие, которое позволяет точно определить недофинансированный проект. Для большинства проектов персонал - это самая большая стоимость или, по крайней мере, вторая по величине стоимость, которой может управлять менеджер проекта. Когда вы обнаружите, что опытный менеджер принимает меры по сокращению расходов на персонал, и эти меры не были частью первоначального плана, вы можете быть уверены, что у вас недостаточно финансируемый проект.
С Уважением,
- Непрерывные появления новых, забытых функций, предполагаемых пользователем как "очевидные" и "неявные", никогда не указывались в требованиях, что приводило к обсуждению "Ошибка против запроса на изменение".
- Модель водопада принята вместо итеративного подхода.
- Клиент протестует против затрат на исправление, говоря что-то вроде: "Если у вас есть ошибки, это потому, что вы не выполнили свою работу правильно", не принимая тройное влияние ограничения на качество при сокращении времени / бюджета.
- Давление на более низкие цены на техническое обслуживание и поддержку после развертывания проекта в производстве.
- Давление для принятия проекта с фиксированной ценой (аутсорсинг) для передачи финансового риска вместе с временным риском.
Используя информацию, которую вы, ребята, любезно предоставили, я смог собрать все вместе и написать статью
Я поставлю здесь ссылку на случай, если кто-то в будущем ищет помощи по теме:
Выживание проекта с ограниченными ресурсами
--LM