A solid batting average in major league baseball is about .300. That’s considered success, although it really represents a 70 percent failure rate at the plate. Software project management essentially works the same way.

Survey after survey, year after year, failure rates are about the same as a Yankees power hitter. According to The Standish Group’s latest widely recognized Chaos Report that measures failure rates in IT projects, software projects in business have about a 65 percent failure rate.

The most common reasons that cause projects to derail include: the project runs out of money before it’s completed, the goals of the software get lost in the process, it doesn’t work after the rollout and is too expensive or unwieldy to fix, or management abandons the project midstream reprioritizing money towards something else more pressing.

Sound familiar?

“You see the same problems over and over again,” says Andrew Stellman, co-author of the book Applied Software Project Management.  Stellman’s consulting partner and the book’s other co-author Jennifer Greene boils all of those problems down to a more fundamental mistake. “If there’s one major takeaway, it’s that there’s a discipline to follow. But a lot of people skip that and tend to barrel ahead,” says Greene.

It’s not what -- but who -- that goes off track

Both agree it’s a shared blame among those involved when things go wrong. “I’d say it’s about evenly split among management, coding problems and pure quality issues,” says Stellman.

Management: Very often the software team just doesn’t get enough support from the boss. Managers tend to low ball budgets, get impatient before the project is completed and either tinker with the initial goals midstream or abandon it altogether. “A lot of its classic micromanagement,” says Stellman

  • Solutions: Give your software team a wide berth to do their job and with the support they need. Make a plan, with goals and a realistic budget. Stick to it. “You don’t have to understand how the software’s built, you just have to understand and appreciate the process,” says Greene.

Programmers: IT types tend to resist planning with people outside their department. “They find it irritating,” says Stellman. Programmers often make the mistake of working in a bubble not seeing the entirety of the business, while at the same time minimizing problems and delays. “It’s amazing how often you hear programmers promise ‘just another three weeks.’ Regardless of the problem, it’s always three weeks,” says Stellman.

  • Solutions:Coders typically would rather code than make plans to code. Resist that temptation and invest the time in planning up front. Be inclusive, involving people within the business who will actually be using the application. It’s important to understand what functionality they need and don’t need. Just as important, programmers need to understand how the application fits into the functionality of the business itself.

Managers and Programmers: There’s a sort of corporate dance that goes on between management and the software team during a project. Often the two are out of step with each other. Programmers may inflate numbers in the budget to compensate for anticipated cuts from management. Management assumes that’s the case and cuts the numbers. It’s a vicious cycle that breeds resentment and distrust. And that distrust spills over into a resistance with working together period.

  • Solutions:During the planning stage, foster a good relationship between the two camps. Make sure goals, expectations and target dates for certain milestones throughout the process are clear and agreed upon by all up front. Have something to refer back to that prevents misunderstandings along the way.

Less is less

Perhaps the best strategy for minimizing failure is to minimize the size of the project itself. “I believe the failure rate of an application project is proportional to the size of the project and the time it takes to complete it,” says David Heinemeier Hansson, creator of the Ruby on Rails Web development framework.

Hansson advocates open source solutions, like his own Ruby on Rails, because projects involve far less coding than traditional solutions and therefore can be done with fewer people and in less time. 

Staying on track

Regardless of the size of the project, success isn’t a matter of good luck. It’s a matter of discipline. Greene offers the following principles that are universal to securing a good rollout.

  • “The fastest way through a project is the right way through a project,” says Greene. Remember the tortoise and hare. It’s steady methodical progress that will eventually result in a solid rollout of a new application. A disciplined approach may require more time, especially in the planning stages, but will pay off in the end.
  • Tell the truth. This applies to setting budgets, coming clean about delays and being clear about expectations throughout the process.
  • Trust your team. Managers should resist the temptation to micromanage what they don’t necessarily understand. “If you really don’t trust the team enough to do the job, then you should just fire the team and hire the right people you do trust,” says Greene.
  • Check your egos at the door.The developer with the best title is not necessarily the developer with the best ideas. Everyone on the project team should have an equal voice and an equal opportunity to contribute.