About the Categorization

In order to categorize the different anti-patterns, we use four criteria, described in further detail below:
  • The software project management activity(ies) impacted by the anti-pattern.
  • The role(s) in the organization most impacted by the anti-pattern.
  • The root cause(s) of the anti-pattern.
  • The anti-pattern solution type.

This categorization is based on the authors' experience and has also been assessed by senior software project managers through a detailed discussion process. The full rationale can be found here. It is worth pointing out that the categorization activity does not have a single solution and many alternative results can also be justified. By no means do we attempt for completeness in our categorization analysis; the intent and scope of this work is simply to highlight the major factors related to each software project management anti-pattern.

The reader may also find useful the tool at the bottom of this page, where the different anti-patterns are summarized according to the categorization criteria.

Software Project Management Activity

We have worked with the five main software project management activities suggested by [Peters, 2008]:
  • Planning: a proactive activity, which involves creating a project plan that includes, as a minimum, a business case, a cost/benefit analysis, a risk analysis, and task delineation, including estimated resources and schedule.
  • Scheduling: the creation of the project schedule, which can be described as a list of events where each event has a calendar date for starting and finishing. The schedule includes resource and time allocation for each task.
  • Staffing: consists of recruiting the correct people while keeping teams small, reviewing and evaluating team effectiveness and productivity and removing roadblocks when needed, as well as being aware of team conduct and disruption.
  • Controlling: an activity which is both passive, monitoring using Earned Value Management, and active, re-planning to respond to some unexpected event, such as tasks running behind schedule, over budget, or changing requirements.
  • Motivating: creating and maintaining a collegial environment where teams participate in the creation of their schedules and goals and are efficiently led and managed by a "servant leader", who relies on his/her strengths, selects a complimentary team, and negotiates with teams, other leaders, and managers to achieve challenges.

While we have strived to find a single most impacted activity by these anti-patterns, or at least the most representative among the impacted activities, there are cases in which anti-patterns may have a major impact on more than one activity.

Impacted Role

We have worked with three main roles:
  • Developer: the developer role includes not only software developers, but also any member of the development team, such as analysts, architects, designers, testers, team leaders, and support personnel. This role directly or indirectly reports to the manager role.
  • Manager: the manager role is viewed here as the project manager; the person in charge of the project and responsible for managing and leading the development team to success, to whom the development team reports to. This role directly or indirectly reports to the upper management role.
  • Customer: the customer role is the person(s), team, or organization, which will ultimately use the product created by the development team. According to McConnell [1998], the customer is "the person or persons who the software ultimately must please in order to be considered a success." This role can be internal to the organization, such as teams that rely on artifacts generated by other teams, or external, such as a business client.

While we have strived to find a single most impacted role by these anti-patterns, or at least the most representative among the impacted roles, there are cases in which anti-patterns may have a major impact on more than one role.

Root Cause

We have worked with five main root causes:
  • Avarice: greed can take many forms, but it leads to inappropriate software development decisions [Brown et al., 1998]. Our interpretation of greed in this work is broader than the pure monetary aspect; we will use avarice to describe ambitious behaviors not only related to money, but also people, project schedules, and delivery dates, for example.
  • Haste: hasty decisions lead to compromises in software quality. Software projects are often subjected to severe schedule-related stress. At project inception, managers are pressured to trim budgets and schedules to make unrealistic targets. As successive project deadlines are missed, anything that appears to work is considered acceptable, regardless of quality [Brown et al., 1998].
  • Ignorance: ignorance is intellectual sloth. It's the result of failing to seek understanding. It keeps people stupid, and eventually leads to long-term software problems [Brown et al., 1998].
  • Pride: the sin of pride is the not-invented-here syndrome [Brown et al., 1998].
  • Sloth: sloth is the "healthy sign" of a lazy developer or manager, who makes poor decisions based upon an "easy answer" [Brown et al., 1998]. We also interpret sloth as the reluctance of management to make tough decisions, which could include, for example, a situation where the project manager is unwilling to allocate necessary resources to a task or project.

While we have strived to find a single most important root cause for these anti-patterns, or at least the most representative among the root causes, there are cases in which anti-patterns may have more than one major root cause.

Solution Type

We have identified four main solution roads from the ones discussed at by Brown et al. [1998]:
  • Process: indicates that the solution entails pursuing a process. Process patterns provide the definition of activities that are consistently repeatable for a given solution [Brown et al., 1998].
  • Role: indicates that the solution entails assigning responsibility to an individual or group. Role patterns solve problems by allocating clear responsibilities to organizational stakeholders [Brown et al., 1998].
  • Technology: technology indicates that the solution entails acquisition of a technology or product. Technology patterns solve software problems through adoption of a technology, as opposed to programming the capability from scratch [Brown et al., 1998].
  • Software: a process by which someone is taught the skills that are needed for an art, profession, or job [Merriam-Webster, 2014]. In this work we consider such process to include any professional development activity, such as education and on-the-job training.

While we have strived to find a single most important solution type for these anti-patterns, or at least the most representative among the solution types, there are cases in which anti-patterns may have more than one major solution type.


Categorization Tool

 

Anti-Pattern Name SPM Activity Impacted Role Root Cause Solution Type Description References
Absentee Manager Controlling,
Motivating
Developer Sloth Role Manager who engages in avoidance behavior or is invisible for long periods of time. Laplante (2005)
All You Have Is a Hammer Motivating Developer Ignorance Training One-dimensional management, where the same techniques are used on all subordinates and in all situations. Laplante (2005)
Appointed Team Staffing Developer Ignorance Training False assumption that a group of people selected by management will immediately gel and become a team. c2.com (2014)
Detailitis Plan Scheduling Manager Avarice Process Excessive planning leading to complex schedules with high level of detail, giving the false perception that the project is fully under control. Brown (1998)
Dry Waterhole Staffing Manager Avarice Process Specifying stringent requirements for a job when it is not strictly necessary, resulting in a very limited pool of available talent. c2.com (2014)
Fire Drill Controlling Customer Haste Process Months of boredom followed by demands for immediate delivery. Brown (1998)
Glass Case Plan Controlling Manager Ignorance Process Lack of tracking and updating of initial plans, assuming the plan is enough. Brown (1998)
Inflexible Plan Planning Manager Ignorance,
Sloth
Process,
Training
Lack of flexible plans and processes. Brown (2000)
Irrational Management Controlling,
Motivating
Developer Ignorance Training Irrational management decisions, habitual indecisiveness and other negative management practices. Brown (1998),
Laplante (2005)
Leader Not Manager Planning Developer Ignorance Training Manager with a vision (leader) but no plan or management methodology. Laplante (2005)
Micro-Management Motivating Developer Ignorance,
Pride
Role,
Training
Excessive management involvement in tasks beyond their responsibility. Brown (2000)
Mushroom Management Controlling Customer Ignorance Training Isolating developers from end users, under the mistaken assumption that requirements are stable and well-understood by both end users and the software team at project inception. Brown (1998),
Laplante (2005)
Myopic Delivery Controlling Customer,
Developer
Pride Process Management insisting on original delivery date even when reducing staff or funding. Brown (2000)
Process Disintegration Motivating Manager Sloth Technology Failing processes due to an underlying decline in overall cooperation and morale. Brown (2000)
Project Mismanagement Controlling Customer, Manager Ignorance,
Sloth
Training Lack of proper software project monitoring and controlling. Brown (1998)
Proletariat Hero Motivating Developer Ignorance Training False assumption that coercion is an efficient way to increase productivity. Laplante (2005)
Rising Upstart Motivating Manager Ignorance Training Superstars who cannot wait their time and want to skips learning phases. Laplante (2005)
Road to Nowhere Planning Developer Sloth Process Lack of planning. Laplante (2005)
Size Isn't Everything Scheduling Manager Ignorance Training Assuming developers are interchangeable and that the number of people working on a problem is inversely proportional to development time. Brown (1998),
Brown (2000),
Laplante (2005)
The Brawl Controlling,
Motivating
Developer,
Manager
Ignorance Training Project manager with no leadership or management experience. Brown (2000)
The Domino Effect Controlling Developer,
Manager
Ignorance Training Moving critical resources between projects, blurring project boundaries. Brown (2000)
Ultimate Weapon Motivating Manager Pride, Sloth Role Relying heavily on a superstar in the team. Laplante (2005)