Project failure is a reoccurring theme on this blog, because it's an issue that seems to dog IT like no other. Up to three-quarters of IT projects can be considered failures, according to an often-cited piece of research conducted by the Standish Group -- although a group of academics using different methodologies than Standish suggested late last year that"only" about a third of IT projects fail.

Back in May, I wrote about some of the usual suspects in IT project failure -- including a lack of governance, internal politics and poor communication between business and IT -- and offered some great suggestions from a Baseline article on how to improve the odds of project success.

A recent piece on project failure that captured my attention is a list of a dozen characteristics of bad projects, adapted by ZDNet's Michael Krigsman from Project Smart. I think sometimes people tend to give short shrift to these kinds of lists, assuming, d'uh, they know a project gone bad when they see it. Yet too often, I think folks ignore some of these points until there's nothing left to do but put a project out of its misery.

In my desire to throw in a little good with the bad and the ugly, I thought I'd share some advice from my recent interview with Compass Management Consulting's Nigel Hughes, in which he stresses the importance of conducting a quantifiable, fact-based analysis of an operation prior to any major project.

Though companies generally recognize the importance of such an analysis, says Hughes, it often gets lost in a flurry of other priorities. Omitting it, however, often leads to companies focusing narrowly on project milestones and schedules rather than broader benefits. Or in some cases, companies end up simply basing projects on assumptions and opinions rather than fact.

What kind of data should be included in these analyses? While base metrics such as cost efficiency, productivity, cycle time and error rates are important, they shouldn't be the only considerations. Says Hughes:

It's critical to incorporate scenario modeling into the initial pre-project analysis, so that you can evaluate different options and extrapolate the implications of different courses of action over time, and then select the option that's most realistic and that yields the optimal benefit. In other words, you need to not only manage the project efficiently and make sure it delivers results, you need to make sure the project you've chosen in the first place is the right one for the business. Finally, the metrics need to be tied back to the business objectives so that, as the project is implemented, you're tracking and quantifying the benefits as they're delivered.

Ensuring that changes are maintained and reinforced, so folks don't slip back into old and less effective processes, is another often-neglected aspect of project management. One way of preventing this, suggests Hughes, is making specific individuals responsible and accountable for change, and empowering them with adequate executive support.