21 совет для успешного управления проектами

Управление проектами по разработке ПО дается не так легко даже в самых выгодных условиях. Руководитель проектов должен уметь взвешенно учитывать противоречивые интересы участников и согласовывать их с ограничениями, диктуемыми ресурсами и временем, вечно изменяющимися технологиями, и недостижимыми требованиями со стороны не слишком компетентных людей. Управление проектом – это управление людьми, технологиями, бизнесом, рисками и ожиданиями. Это процесс жонглирования немалым количеством шаров.

1. Закладка фундамента успеха.
2. Планирование проекта.
3. Оценка работы.
4. Наблюдение за прогрессом.
5. Уроки на будущее.

Данные советы в пяти категориях определяют систему контроля над управлением проекта, которая поможет вам в предоставлении ожидаемых результатов. Запомните их все, так как по отдельности они неэффективны.

Закладка фундамента успеха

Совет #1: Определение критериев успешности проекта

В начале проекта убедитесь, что заинтересованные стороны достаточно хорошо понимают, как определить, является ли проект успешным. Слишком часто заранее установленный график – это единственный очевидный фактор успеха, но существуют и другие. Определите участников проекта, их интересы и ожидания. Затем установите несколько четких и измеримых целей. Вот несколько примеров:

- Увеличение доли рынка на определенное значение к указанной дате.
- Достижение определенного объема продаж или дохода.
- Достижение определенной степени удовлетворения клиента.
- Сохранение денег путем устранения устаревшей системы, требующей слишком много затрат.
- Достижение определенного объема обработки транзакций и точности.

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

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

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

Совет #2: Определение движущей силы проекта, его ограничений и степень свободы

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

«Диаграмма гибкости» визуально демонстрирует ограничения, движущую силу и степень свободы. Ограничения не дают руководителю проекта быть гибким в этом аспекте, таким образом, они наносятся на график как нулевое значение на оси. Движущая сила подразумевает небольшую степень гибкости, таким образом, эта точка наносится на график немного выше нуля. Степень свободы обеспечивает различные градусы широты. Они представляют параметры, которые руководитель проекта может регулировать, чтобы достичь движущей силы успеха проекта внутри пределов, наложенных ограничениями. Соединив пять точек, отмеченных на графике, получаем неправильный пятиугольник. Чем меньше площадь внутри пятиугольника, тем больше ограничений в проекте.

Вместо того чтобы в спешке согласовывать время выполнения работы, стоит обсудить реалистичные сроки достижения результатов посредством серии вопросов, таких как:

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

Рисунок 1. Диаграмма гибкости одного проекта, ограниченного по сотрудникам и расписанию, где двигателем является бюджет, а качество и функциональность являются свободными переменными.

Совет #3: определение критериев завершенности продукта

На ранней стадии в проекте вам стоит определить, какие критерии укажут на то, что продукт готов к выпуску. Возможными критериями к выпуску могут быть:

• Отсутствуют какие-либо дефекты высокого уровня.
• Число открытых дефектов на протяжении X недель снизилось, и число важных дефектов не превышает допустимый уровень.
• Уровни производительности достигнуты на всех целевых платформах.
• Конкретная требуемая функциональность полноценно оперирует.
• Удовлетворены измеримые уровни надежности.
• X% тестов системы были успешно пройдены.
• Конкретные юридические, договорные и регулятивные цели были достигнуты.
• Оптимальное время выпуска товара на рынок подошло.
• Удовлетворены критерии приемки (продукта) заказчиком.

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

Четко изучите ваш сегмент рынка при выборе критериев выпуска. Большинство прагматичных и консервативных клиентов не будут столь терпимы к дефектам. А вот для инновационных идей и технологических прорывов лучшим считается ранний выпуск продукта.

Совет #4: Обговорите достижимые обязательства

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

• Отделите людей от проблемы.
• Сфокусируйтесь на интересах, а не на позициях.
• Изобретайте варианты для всеобщей прибыли.
• Настаивайте на использовании объективных критериев.

Любые данные, которыми вы обладаете с прошлых проектов, помогут вам в составлении убедительных аргументов, хотя не существует настоящей защиты против по-настоящему  неразумных людей.

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

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

Совет #5: Напишите план

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

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

• Прогнозы и планы насчет кадров, бюджета и других ресурсов.
• Роли и ответственности команды.
• То, как вы наймете и обучите необходимых сотрудников.
• Предположения, зависимости и риски.
• Описания и целевые даты основных результатов.
• Определение циклов жизни проекта по разработке ПО.
• То, как вы будете наблюдать и отслеживать проект.
• Собранные метрики.
• То, как вы будете выстраивать отношения с подрядчиками.

Ваша организация должна принять стандартный шаблон плана проекта по разработке ПО, который может быть специализирован под различные типы проектов. Хорошей стартовой точкой является стандарт IEEE Std 1058-1998. Данный стандарт описывает детальный шаблон, подходящий для большого числа проектов. Изучите данный шаблон, чтобы выделить самое полезное для различных типов ваших проектов.

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

Совет #6: Анализ задач ради их последующего разделения на подзадачи

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

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

Совет #7: Ведение журнала планирования работ для крупных задач

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

Совет #8: Спланируйте переработку после этапа проверки качества

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

Совет #9: Управляйте рисками проекта

Если вы не будете определять риски проекта и управлять ими, то они будут управлять вами. Риск – это потенциальная проблема, которая может повлиять на успех вашего проекта. Это проблема, которая еще не произошла, но вам стоит избегать ее любым способом. Управление рисками было определено как одна из наиболее значимых частей разработки ПО. Простого определения потенциального риска мало – вам стоит оценивать связанную с каждым риском опасность, тем самым вы сможете сфокусировать вашу тактику управления рисками там, где это будет наиболее выгодно.

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

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

Совет #10: Планирование времени для улучшения процесса.

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

Совет #11: Не забывайте про кривую приобретения знаний

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

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

Совет #12: Оценка, основанная на работе, а не на календарных сроках

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

Совет #13: Не планируйте для членов команды задания, занимающие более 80 процентов времени

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

Совет #14: Внесите учебный период в график

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

Совет #15: Записывайте прогнозы и то, как вы их достигаете

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

Эффективным метод групповой оценки является метод Wideband Delphi. Wideband Delphi основан на том принципе, что несколько голов лучше, чем одна. Прогноз при помощи метода Delphi просит небольшую группу экспертов анонимно создавать индивидуальные оценки из описания проблемы и достичь консенсуса по финальному набору прогнозов при помощи итераций. Рисунок 2 демонстрирует процесс прогнозирования при помощи Wideband Delphi.

Рисунок 2. Течение процесса метода WidebandDelphi.
Планирование; Стартующее собрание; Индивидуальная подготовка; Собрание по обсуждению прогнозов; Задачи по сборке всего воедино; Обзор результатов

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

Совет #16: Используйте инструменты прогнозирования

Многие коммерческие инструменты доступны и могут помочь в прогнозировании всего проекта. На основании больших баз данных выполненных проектов, данные инструменты могут дать вам набор возможных расписаний и вариантов распределения сотрудников. Они также помогут вам избежать синдрома "бермудского треугольника" – комбинации усилий, материалов и графика, при котором не существует ни одного известного варианта завершения проекта. Инструменты содержат в себе множество "двигателей", которые вы можете настроить для того, чтобы инструмент точно моделировал ваш проект, на основании используемых технологий, опыта команды и других факторов. Со временем, вы сможете откалибровать инструмент своими данными о проекте, и сделать его еще более надежным. Вам стоит испробовать инструмент Estimate Pro от Software Productivity Center (www.spc.ca). Также многие рекомендуют KnowledgePlan (www.spr.com), SLIM (www.qsm.com), и Cost Xpert (www.costxpert.com). Вы можете сравнить их оценки с прогнозом, основанным на структуре декомпозиции работ. Учтите все несоответствия, чтобы впоследствии вы смогли составить общие реалистичные прогнозы.

Совет #17: Готовьтесь к непредвиденным ситуациям

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

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

Наблюдениезапрогрессом

Совет #18: Записывайте фактические данные и их прогнозы

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

Совет #19: Засчитывайте завершение задачи только тогда, когда она завершена на 100%

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

Совет #20: Отслеживайте статус проекта в открытую и честно

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

Уроки на будущее

Cовет #21: Проводите обзор завершенного проекта

Ретроспективы, которые также называют «послепроектный обзор», предоставляют команде возможность задуматься о том, как прошел последний проект или предыдущий этап, чтобы извлечь уроки, которые будут способствовать укреплению вашей будущей деятельности. Во время такого обзора определите, что прошло удачно, - таким образом, вы сможете создать такую среду, которая позволит вам повторить факторы успеха. Также обратите внимание на то, что прошло не так удачно, так вы сможете изменить свои подходы и избежать этих проблем в будущем. Кроме того, подумайте о событиях, которые вас удивили. Это могут быть факторы риска, к которым вы должны быть готовы в следующем проекте.

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

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

Библиография

1. Brown, Norm. "Industrial-Strength Management Strategies," IEEE Software, vol. 13, no. 4 (July 1996), pp. 94-103.
2. Fisher, Roger, William Ury, and Bruce Patton. Getting to Yes: Negotiating Agreement Without Giving In, 2nd Edition. New York: Penguin Books, 1991.
3. IEEE. "IEEE Standard for Software Project Management Plans, Std 1058-1998." IEEE Standards Software Engineering, 1999 Edition. Volume 2: Process Standards. New York: The Institute of Electrical and Electronics Engineers, Inc., 1999.
4. Kerth, Norman L. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.
5. Lewis, James P. The Project Manager's Desk Reference, 2nd Edition. Boston, Mass.: McGraw-Hill, 2000.
6. Rothman, Johanna. "Determining Your Project's Quality Priorities," Software Development, vol. 7, no. 2 (February 1999), pp. 22-25.
7. Wiegers, Karl E. Creating a Software Engineering Culture. New York: Dorset House Publishing, 1996.
8. Wiegers, Karl. "Know Your Enemy: Software Risk Management," Software Development, vol. 6, no. 10 (October 1998), pp. 38-42.
9. Wiegers, Karl. "Process Improvement that Works," Software Development, vol. 7, no. 10 (October 1999), pp. 24-30.
10. Wiegers, Karl. "Stop Promising Miracles," Software Development, vol. 8, no. 2 (February 2000), pp. 49-54.
11. Zultner, Richard. "Project Estimation with Critical Chain: Third-Generation Risk Management," Cutter IT Journal, vol. 12, no. 7 (July 1999), pp. 4-12.