Seven Characteristics of dysfunctional software projects

“Managing a software project requires ‘courageous’ and often clairvoyant individuals…willing to confront today’s challenges to avoid tomorrow’s catastrophes.” This is a highlighted quote held within the pages of this paper written by Michael W. Evans, Alex M. Abela, and Thomas Beltz of Integrated Computer Engineering, Inc. The paper lists seven characteristics that one is likely to encounter within dysfunctional software projects, and serves as a good head start to any project leader who doesn’t wish to fall into the same difficulties identified within the paper. The characteristics are:

  1. Failure to apply essential project management practices
  2. Unwarranted optimism and unrealistic management expectations
  3. Failure to implement effective software processes
  4. Premature victory declarations
  5. Lack of program management leadership
  6. Untimely decision making
  7. Lack of proactive risk management

These seven were determined through an assessment of more than 280 software intensive programs in many different levels of government. The assessment was conducted Integrated Computer Engineering (ICE), with insights from Capers Jones and Tom DeMarco. The characteristics represent a lack of communication, top level involvement, and proper risk management practices, generally. Each of these seven characteristics are explored within the document fully, explaining the typical risks that can occur with the characteristics, an explanation of how the dysfunction came into existence, and what a project can attempt to mitigate and correct the dysfunction. Take, for example, this explanation of how to avoid premature victory declarations: A clear understanding of the customer’s quality expectations is an essential prerequisite to client satisfaction. Delivery of a faultless solution that is significantly over-budget and so late in delivery as to be obsolete will fail to satisfy a customer as much as a product delivered on time that does not meet specified requirements or that has poor reliability. The final suggestion found in the conclusion of the paper is a recommendation to review faltering projects and apply the characteristics defined in the paper. This may help you determine what is going wrong and how to fix it. The point isn’t that you will have a cheat sheet of possible errors—rather that you and your team will be readily able to admit the errors that are occurring. Denial is often the catalyst for easy to fix errors growing and becoming project-killers.

Show More

Leave a Reply


We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.