Behavioural Patterns

When failure occurs it is sometimes due to a single mistakes made in planning or executing the project. More often than not however, failure is the cumulative result of many mistakes. In such situations the mistakes are themselves often born out of a dysfunctional environment that sets the stage upon which mistakes can be made and that acts as a barrier to detecting and correcting the mistakes. The following links provide examples of the types of behavioural patterns that create these dysfunctional environments. By understanding these “patterns” the mechanisms behind project failure can be better understood.

Figure 1 - Elements in project failure (click to enlarge)

Figure 1 – Layers in project failure
(click for larger version)

Each pattern embodies a broad set of behaviours that negatively influences the way individuals, teams, groups and even whole organizations, make project related decisions and how people work together.  The resulting problems interact with individual trigger events (mistakes) and the combined effects are the drivers of project failure (figure 1).

The following page lists some of the more common patterns. If you’re new to the site, try reading our introductory article on the topic “Disaster DNA – Decoding the DNA of failed technology projects” before reading the samples below.

Pattern Library

The following entries are examples of some of the most common patterns;

  1. First option adoption
    Team fails to generate alternate ideas for how to meet the project objectives resulting in them settling for the first option they thought of rather than the best available option
  2. Silos
    Barriers between organizations and group lead to a breakdown in collaboration
  3. The pressure wave
    The build up of schedule pressure due to inaction in the face of an impending fixed deadline
  4. Disconnect failure
    Project creates its intended deliverables, but those deliverables fail to deliver the intended business value
  5. Top led failure
    Mistakes made by Senior Executives early in the project set the project on a course to disaster
  6. Focal imbalance failure
    One or more critical aspects of the project receives insufficient attention leading to failure
  7. Bottom fed failure
    Poor quality at the implementation level results in project failure
  8. Alignment failure
    Different parties are focused on different goals (often unstated goals) resulting in conflicts and misalinged efforts
  9. Schedule pressure failure
    Excessive schedule pressure results in critical mistakes that otherwise would not have been made
  10. Commitment failures
    Project team makes unachievable commitments to schedule, budget and scope
  11. Navigational failures
    Team lacks leadership and oversight in one or more dimensions
  12. Intellectual disintegration failure
    Failure to communicate results in individuals and groups having different understandings and heading off in different directions
  13. Transitional failures
    Deliverables are created, but the value the project hoped to create is lost due to an ineffective transition into the operational world and failure to track outcomes
  14. The fast-forward freeze-out
    The failure to consult stakeholders during the planning process in order to expedite progress.
  15. Green shifting
    The tendency to report project status in positive terms despite growing indications that serious problems exist
  16. Left shifting
    Key strategic, architectural and organizational decisions are down played in favour of diving into the hard core development activities
  17. Quality kaboom
    Quality and testing activities are pushed to the end of the development cycle rather than being seen as an ongoing activity
  18. Techcentric myopia
    Technology aspects of the project become primary focus while business and organizational issues are handled superficially
  19. Gravitation
    The tendency to be drawn to back to our comfort zone
  20. Poly-project blindness
    Failure to recognise that a new project has different characteristics from prior experiences and hence needs to be managed differently

To suggest a pattern that is not documented above, use the following link – Suggest a pattern