Session 1.2 – Why Projects Fail
Chapter 2: The Logic of the Team Software Process | Duration: 1 hr
Learning Objectives
By the end of this session, students will be able to:
- Understand why software projects fail and identify the primary causes
- Recognize the difference between technical issues and teamwork problems
- Explain the nature and sources of pressure in software projects
- Describe effective strategies for handling project pressure
- Understand how TSPi helps teams manage pressure and avoid failure
Introduction
This chapter discusses the introductory Team Software Process and explains how and why it works. It also defines teams, explains how they work, and discusses some common teamwork problems.
Chapter Overview
Much has been written about teamwork, and there are many examples of good and bad teams. This chapter cannot possibly cover all this material, but it hits the highlights.
Note: As you use the TSPi, you should read each of the book chapters as you encounter the topics it covers.
Why Software Projects Fail
Key Insight
When software projects fail, it is generally because of teamwork problems and not technical issues.
The Non-Technical Nature of Failure
The success or failure of a project is seldom due to technical issues. You almost never find yourself asking 'has the state of the art advanced far enough so that this program can be written?' Of course it has. If the project does go down the tubes, it will be non-technical, human interaction problems that do it in. The team will fail to bind, or the developers will fail to gain rapport with the users, or people will fight interminably over meaningless methodological issues.
— Tom DeMarco
The Primary Cause: Inability to Handle Pressure
One significant "people" problem is the inability of software teams to handle pressure, especially the pressure to meet an aggressive development schedule.
Taking Shortcuts
Teams skip important steps in the development process to save time, leading to quality problems later.
Using Poor Methods
Under pressure, teams abandon proven practices and resort to ad-hoc, ineffective approaches.
Gambling on New Tools
Teams gamble on untested languages, tools, or techniques hoping for quick solutions.
Understanding Pressure
The Destructive Nature of Excessive Pressure
Excessive pressure can be destructive. It causes people to:
- Worry excessively: Imagine problems and difficulties that may not be real
- Focus on unknowns: Rather than help cope constructively, pressure causes worry about phantom issues
- Act irrationally: Sometimes pressure causes people to act as if phantom issues were real
- Damage self-esteem: This behavior can have untold consequences for your project, organization, and even your self-esteem
The Relief of Having a Plan
The Power of Planning
When your team knows how to handle the pressure of a tight schedule, you can feel the difference. Before starting a job, you generally don't know precisely what is involved. But after you make a plan and get started, you feel relieved.
Why? Because you are now dealing with a known problem rather than an unknown worry. This is true even if the job is larger than you thought.
Handling Pressure Effectively
What is Pressure?
Pressure is something that you feel. For example, you may need to do a task whether or not you think you can do it.
The greater the need and the more doubt you have about your ability to do the task, the greater the pressure.
The Source of Pressure
Apparent Source
The apparent source of pressure in software projects is the need to meet a tight schedule. This schedule could come from:
- Management
- Your instructor
- Your peers
Real Source
The real source of pressure, however, is ourselves. It comes from:
- Our natural desire to accomplish what managers, instructors, or peers want
- Normal self-doubts about our ability to perform
- Lack of experience in handling project challenges
Critical Understanding
Because pressure is internally generated, you have the power to manage it yourself.
But first you must find the source of the pressure and then figure out how to deal with it.
How TSPi Helps Teams Handle Pressure
By guiding teams through a strategy and planning process, the TSPi shows teams how to handle pressure effectively.
TSPi Pressure Management Process
Understand what needs to be done
Determine approach for doing the work
Quantify the products to be built
Create detailed development plan
Turn unknown worry into known problem
Why TSPi Works
Addresses Root Cause
Because unrealistic schedules are the principal cause of software project problems, the TSPi helps teams manage their projects more effectively.
Enables Quality Work
When teams are able to manage their work, they are much more likely to do a quality job.
Key Takeaway
Teams need to know how to work efficiently and to produce quality products, especially when they are under intense schedule pressure. TSPi provides the structured approach to accomplish this.
Session Summary
Key Points
Why Projects Fail:
- Software project failures are generally due to teamwork problems, not technical issues
- The primary people problem is the inability to handle pressure
- Teams respond to pressure by taking shortcuts, using poor methods, or gambling on new tools
Understanding Pressure:
- Pressure is something you feel based on task requirements and self-doubt
- The apparent source is tight schedules from management/instructors
- The real source is internal: our desire to succeed coupled with self-doubts
- Because pressure is internally generated, we have the power to manage it
Handling Pressure:
- Making a plan transforms unknown worries into known problems
- This provides relief even if the job is larger than expected
- Teams need structured processes to work efficiently under pressure
TSPi Solution:
- TSPi guides teams through: Analysis → Strategy → Size Estimation → Planning
- This structured approach helps teams manage their projects effectively
- When teams can manage their work, they're more likely to produce quality results
Next Session Preview
In the next session, we will explore common team problems that students face, including issues with leadership, cooperation, participation, procrastination, quality, function creep, and evaluation.