Over a million developers have joined DZone.

Stop Keeping the Lights on, Part III: Project Anti-Patterns You Need to Eliminate Now

DZone 's Guide to

Stop Keeping the Lights on, Part III: Project Anti-Patterns You Need to Eliminate Now

Michael Dowden provides the third installment of his series about the problems related to ''just keeping the lights on.''

· Agile Zone ·
Free Resource

This is the third article in my blog series. This series is intended to be read in order, so please reference the first and second articles if you have not yet done so.

In order to thoroughly examine the causes of the Just Keeping the Lights On (JKTLO) problem, I am discussing the main causes over the course of three blog posts. It is essential to have a firm understanding of the root causes of the problem before delving into the solutions.

In this blog post, I will address the ways that project anti-patterns significantly contribute to the JKTLO problem.

Using the definition provided by the authors of the book AntiPatterns (1998), a practice or idea qualifies as an anti-pattern if:

  • It is a repeated pattern of action, process, or structure that is put into place to be beneficial, yet ultimately is more harmful than beneficial.
  • A documented, proven, and repeatable solution exists.

The Death March

Another side effect of commoditization is the death march. This is when project managers lump developers (or any workers) into a single number in order to devote excessive amounts of time to tasks that have little chance of ever adding value. The idea typically is that if one developer can complete the project in 12 months, then 12 developers can complete it in one month. However, as Fred Brooks pointed out in The Mythical Man Month, “nine women can’t make a baby in one month.” (Read more: Project Management: People, Not Numbers.)

Scope Creep

Scope creep is another common problem in IT to watch out for. Although scope change is not bad, be careful not to create a pattern of saying yes to every undocumented and unplanned change to a task or project. This is when scope creep will occur, which results in targets, dates, budgets, and other project metrics not getting adjusted accordingly. To avoid damaging scope creep, quality project management must be implemented. Whenever a new feature is added to a project, a feature of similar size must be removed. If this is not possible, the budget and timeline must be increased and communicated to all stakeholders.

Design by Committee

Similar to scope creep (and a factor that can contribute to scope creep) is “design by committee.” This is when all of the stakeholders are fully involved in the design and all have direct influence over the decision-making process. When this happens, it often leads to stakeholders saying yes to all features rather than selecting the common features and goals. The “too many chefs” scenario can easily lead to workers bouncing back and forth between tasks in an effort to please each stakeholder. This greatly reduces efficiency as progress is made slowly on each task in succession.

Stakeholder involvement is key, but in order to avoid design by committee, one single project owner or sponsor should be designated to make the final call on scope. This individual is responsible for the features and the product both during and after development.

The Impact

Project anti-patterns such as the death march, scope creep, and design by committee slash an IT department’s efficiency. This in turn severely limits the time they have to devote to innovation. You can see how easy it is to fall into these anti-patterns, but it is important to watch out for them and correct them whenever you are able. Doing so is a major step forward in addressing the JKTLO problem.

agile ,anti-patterns ,death march ,scope creep

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}