The Standish Group (www.standishgroup.com) has been doing research and surveys on various types of information technology (IT) projects since 1994. Their research, published under the title CHAOS, reveals some facts that, to most, will be astonishing. The Standish Group CHAOS database shows a staggering 31.1 percent of projects being canceled before completion. Further results indicate 52.7 percent of projects cost 189 percent of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but easily exceed the more tangible costs.

For successful projects, the proportion of projects that are completed on time and on budget is approximately 16 percent. And, even when these projects are completed, many are no more than a mere shadow of their original specified requirements. Projects completed by the largest American companies have only about 42 percent of the originally proposed features and functions. Smaller companies do better, but there is still a pretty large gap. A total of 78.4 percent of their software projects will get deployed with only 74.2 percent of their original features and functions.

For purposes of the referenced research, The Standish Group classified IT projects into three resolution types:

• Succeeded:  The project is completed on time and on budget, with all features and functions as initially specified.
• Challenged:  The project is completed and operational but over budget, over the time estimate, and offers fewer features and functions than originally specified.
• Impaired:  The project is canceled at some point during the development cycle.

The industry research reveals that exceeding budget is common, delivering projects late is the norm and achieving less functionality than was originally slated is typical. For many organizations, project failure is almost considered a standard operating procedure.

Further diagnosis behind the results find that the most common root causes of project failure were incomplete requirements, lack of visible sponsorship, lack of key user involvement, lack of project management, unrealistic expectations, lack of management support, and changing requirements. These causes occurred with approximately equal frequency.

A recognized comparable research study focused on why projects fail was performed by Peerstone Research (www.peerstone.com). This study focused on projects that involve application software implementations and external professional services. This study results point to senior executives failing to lead as the number one factor contributing to implementation failure. However, the additional root causes leading to failure all stem from shortcomings on the part of the software or services vendor.

As you might expect, it has been our clear experience that project failure reasons vary based upon who you are speaking to. Only when anonymous surveys are used do unbiased and political free comments surface.

Best Practices For CRM Project Success

• Recognize that CRM is not just about software. CRM is a business strategy aimed at understanding, anticipating and responding to the needs of an enterprise's current and potential customers. CRM software applications enable the automation, execution and collaboration of CRM. If an organization doesn't have an identifiable CRM strategy, software which automates piecemeal sales components and ad-hoc labor functions will not likely not deliver a competitive business advantage.
• For salesforce automation (SFA) projects, listen to the sales people as they can generally state the four things they need to sell more effectively:
  1. Additional and improved sales information, especially accurate, advance knowledge of customer sales opportunities, competitive threats, and service problems.
  2. Better value proposition, information sharing and sales presentation knowledge and tools.
  3. Better, more straightforward ways to manage orders, agreements and contracts.
  4. Simpler ways to communicate with marketing, service, shipping, each other, alliance partners and the customer.

Salespeople generally do not tell us they need customer profiling, opportunity management, call reporting or forecasting systems.

Too many sales initiatives have failed to deliver because they focused on technology, not on effective selling. Projects that think technology first, and selling effectively second generally are not successful. Similarly, projects that seek to achieve sales management objectives first, and sales person gains second, often find an uphill battle looming.

Early Warning Signs

Most projects don't suddenly bite the dust. There are generally red flags which can serve to provide advanced warning.

• Missed deadlines: Project deadlines can slip for various reasons, such as unforeseen or uncontrollable events. However, if the project manager or project team consistently misses deadlines is it generally a clear sign of lack of knowledge or lack of discipline.
• Shifting specifications Scope creep and changing requirements will affect the project's timeframes, cost and ability to be successful. 
• Quality problems Lack of quality may be disguised or explained away by blaming vague requirements. Promises of future improvement in these scenarios are a pipe dream.
• Spotty reporting An absence of management reporting tools almost assures that issues and problems are not being detected timely, escalated or communicated to the right people.
• No milestones Key project decisions, deliverables and milestone dates are essential to ensure predicted success. Missing milestone dates is a sure sign of future trouble.

Project Intervention

When a project is in trouble, a well thought through and structured rescue plan can turn around the downward spiral. However, project turnaround must have objective analysis, disregard for sacred cows and the freedom to constructively challenge the status quo. There are key steps required for project turnaround.

First, face the problem. This is undeniably difficult. The most common incumbent response will be to suggest that the conclusion is near and to beg for more time. Common sense and historical experience clearly demonstrate that this is seldom the case.

Next, pause the project to stop burning more time and money. Taking a break gives everyone a opportunity to regroup, consider lessons learned and create a new plan. Do not consider restarting the project before you have revisited the project's original objectives, unequivocally uncovered the problem occurrences root causes and validated the project's anticipated benefits and ROI.

Once the project is restarted, place extreme emphasis on milestone dates and deliverables. Most projects are well into the implementation phase, and sometimes near the testing phase, before a strong case can be made for intervention. However, by identifying the telltale indicators early in a project's life cycle, it is often possible to salvage much of the original scope and projected benefits.