While recovering from a recent failure on a software development project, I sat down and began channel flipping to relieve some tension. I happened across the latest installment in the Fox series “When Good [insert broad categorization; e.g., kids, animals, police stops] Go Bad.” As I temporarily ceased my channel-flipping for a few minutes (which, as a man, took an incredible amount of willpower and stamina) to watch the bad drama unfold, I started reflecting on what made this particular project, and software development projects in general, ”go bad.” As I ruminated, the top three reasons became painfully clear.

1. Who owns the project?
During the inevitable post-project failure meeting, the intensity of the finger pointing between the project designers (who “own” the vision) and the project developers (who “own” the code) is in direct proportion to the level of dysfunction that existed on the overall project. Once you distill the accusations, expectations, and frustrations of both groups, what you generally find is that everyone “owns” a piece of the project, but no one is actually willing to stand up and take ownership of the problems. Of course, no one wants to have blame placed on them. Nonownership is most often the cause of project failure—not just a symptom.

In projects that succeed, all of the participants share a common vision of the result and interact regularly to make sure they’re meeting it. If you ask a product manager, developer, or tester the question, “What does your product do and for whom does it do it?” you should get the same clear, concise, focused answer from all three project participants. I would suggest to you that you not allow a line of code to be written or a flowchart to be drawn on a whiteboard until you can get your team to agree on the answers to these questions. Until they’re in sync on this, no one really owns the project and no one will take ownership when the hard times come.

2. Don’t expect what you don’t inspect
Even if everyone agrees in the beginning, breaks the huddle, and goes to the line ready to execute, external and internal factors will inevitably require some adjustments in strategy and execution. The number one failure of most CIOs and high-level managers is their blind faith in the people they hire to deliver these projects. While it’s impossible for a CIO to be effective if he or she questions every decision made by a manager or project leader, it’s also impossible to be successful if he or she accepts every report without the proper level of inspection.

I prefer to perform my inspections in two ways: Management By Walking Around (MBWA) and Spot Demos. MBWA is the now timeless methodology espoused by Tom Peters in the business classic In Search of Excellence. Peters contended that MBWA keeps workers engaged and managers involved in the most pressing projects. I’ve found that regular (but unscheduled), one-on-one visits with team members to discuss their progress and their frustrations (as well as giving them the ability to brag about recent accomplishments) is a very effective way to chart the potential success of the project. In fact, in my organization, there’s a direct correlation between the success of the project and the amount of MBWA that’s been applied during the life of the project.

Some would say that it’s unfair to ask a development team to be prepared at all times for a demonstration of the product in its current state, but I believe that “spot demos” force the whole team to constantly think about the project as a whole instead of their individual piece. If I want to see a demonstration of the product in its current state, I’ll ask one of the developers or project leads to meet me in a conference room with their laptop and show me how the software works. Since everyone has to be ready to demonstrate the project in its current state, everyone stays up to date with how the project is doing as a whole.

3. Never forget the customer
Even if everyone on the team can recite verbatim the project mission and can show a demonstration of the current state of the product at any time, that doesn’t ensure that, when completed, the end result will be something that the anticipated customer will find useful. This is why it’s very important—in fact, it’s critical—to frame your questions about product features, performance, usability, etc., from the perspective of the potential customer. For example, if factory workers are the main users of your product, then don’t ask to see the features in the current build of the product. Instead, ask, “Show me how a factory worker will use the features in the current build of the product.” Or you can ask, “Suppose you’re presenting this project to the management team of the factory. Show me how you would demonstrate to them, using the current build, that this product will increase the efficiency of the factory or lower their operating costs.”

If you think this is an unfair question to ask developers, then your software project is doomed to failure anyway. It’s impossible for someone writing code to produce a product that’s usable by the end customer unless either a) they understand the customer intimately or b) your specification is so tight that you could have outsourced the actual development to India, Russia, or China to begin with. Following these in-process methods for helping software projects succeed doesn’t guarantee success. But not using these or similar in-process methods does guarantee failure.

Why do projects fail?

Can you add to Landgrave’s list of red flags? What about remedies and precautions? Is it true that we learn more from failure than from success? Share your experiences by e-mailing us or posting a comment below.