Blogs

I was reading about a document management project fiasco and one of the bloggers introduced the concept of The Devil’s Triangle (TDT). Briefly, TDT is a relationship between three participants in a software implementation project: the customer, the vendor, and the system integrator. And yes, a TDT has a negative connotation meaning that someone of the three is to blame for a challenged project (project “failure” can be defined in many ways so I’ll use challenged).

In many reports that document and dissect challenged projects, I haven’t seen one that lists the software itself as a leading cause of failure. In one recent study by pmsolutions  research, they listed the top five causes of failed projects to be:

1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
3. Schedules: Too tight, unrealistic, overly optimistic.
4. Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
5. Risks: Unidentified or assumed, not managed.

http://www.pmsolutions.com/collateral/research/Strategies%20for%20Project%20Recovery%202011.pdf

Similarly, an often quoted report from the Standish Group called the Chaos Report cites ten key factors for a challenged project and none of the ten factors includes or blames the software product itself as the primary reason for project failures.

And one final reference from a presentation by Bob Lawhorn of CAI in March 2010 about the causes of challenged projects:

1. Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester Research)
2. 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
3. 50% are rolled back out of production (Gartner)
4. 40% of problems are found by end users (Gartner)
5. 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
6. Up to 80% of budgets are consumed fixing self-inflicted problems (Dynamic Markets Limited 2007 Study)

If we agree, for the sake of argument, that the software is not typically the problem, that leaves us with the other two corners of this triangle – the customer or the system integrator. If we then believe these reports that challenged projects are the result of poor requirements, it would appear that the system integrator is off the hook because the integrator is just implementing the project requirements as given to them by the customer. This means that for most, maybe not all, challenged projects, the failure points to the customer and the issue of poorly developed and stated requirements.

This is why requirements analysis and definition is so important today for our ever increasing array of document management solutions and products. These product choices represent very different approaches to document management both in terms of the technology itself and how/where the system is implemented. Also we know that for every dollar spent on a traditional application, at least an equal amount is spent on the implementation (which is, BTW, a big selling point for SaaS and cloud-based application vendors – they are cheaper to implement – but that is another blog to be written).

Today, in addition to finding the right application and the right vendor, we also have to make a choice as to how the system can be implemented. For example:

1. A traditional on-premise system from a traditional ECM vendor (versus some of the new systems that are only cloud-based with no on-premise options)
2. An ASP (application service provider) model (yes, they are still offered and still a valid option)
3. A SaaS system hosted by the system provider (which may be on your premises) from one of the traditional ECM vendors
4. A cloud-based application (which may be different from a  SaaS implementation) from one of the new document management startups

While the basic application requirements remain the same (versions, check-in/out, security, workflow, etc), which of the four methods for implementation is right for you? You won’t really know unless you do a rigorous analysis of your needs, develop those needs into requirements, and measure those requirements against the differing technologies and implementation methods.

If a complete requirements document cannot be completed, chances are the system will not fulfill your needs, will cost more than you budgeted for, and you may eventually replace it and start over again. In the case of the ECM project failure that started this line of thinking, the customer spent over twice their original budget for a system that still does not work properly and now, they face the cost of replacing it after a five year effort to make it right. And, these are the explicit costs that we can see….what about the costs to workers who are less productive, the cost of overtime and temps, and the cost of the ill-will created by a system that doesn’t work?

Bud Porter-Roth