Does anyone remember the article several years ago about Goodyear's ERP program difficulties? To the tune of +$100Million? Is there a pattern emerging?

According to the initial filing: “Unknown to Waste Management, this ‘United States’ version of the Waste and Recycling Software was undeveloped, untested, and defective.” See Andy Moon's Tech Republic blog materials HERE.

When it comes to software asset management or technology asset management, the pre-purchase work you perform as a responsible business technology consumer is absolutely vital to the ongoing relationship—or the lack there-of. Judging even by the minimal information supplied in the related articles, Waste Management swallowed the vendor hype, hook, line, and sinker. Who's at fault? Could there be an entire industry out there that tends to sacrifice long term customer value in favor of short term profits? (Picture the Goose and the Golden Egg Story.)

Read on for 7.65 Guaranteed Ways of Smoothing the Technology Acquisition and Utilization Waters—before the tsunami of product or implementation failure crashes over your collective corporate craniums.

According to the Project Management Institute, North American companies, alone, spent over $300 Billion on late, over budget or failed implementations from 1999 to 2001.

Define your own criteria—up front—in writing—before you pay a penny. Be sure it is clear to the provider that, if your criteria are not met—for the entire life cycle of the product, you will demand compensation.

Lesson Two: You, the customer, need to clearly define the acceptance criteria for the product as delivered & implemented. There is an entire range of issues to consider here. Suffice it to say that, if you do not define a specific process for acceptance testing and approval, you get what you paid for—only what you paid for—nothing more and certainly nothing less.

Try This! Set your own rules—in writing—for acceptance testing and approval in the initial agreement or don't buy the product.

Lesson Three: Perform serious—business methodology—due diligence before you agree to any license. Here is where I frequently irritate my techie friends. Your technical people, for the most part, have absolutely no clue how to develop a serious business needs analysis or business process map. In order to perform an effective analysis, you need to have a multi-talented approach. This means you need a vendor-neutral techie as well as an operations and business analyst. Then, you need to ensure that the entire product acquisition process is conducted along business best practices—not the current “We absolutely need this new toy!” practices.

Hello? If you perform a vendor-neutral business case or cost/benefit analysis (or, in many cases ANY formal pre-purchase analysis) that reflects your specific needs, you will be way ahead of the majority of business tech consumers.

Lesson Four: Review failed implementations. The providers of tech products are always more than happy to refer you to their favored clients for product track records. Unfortunately the majority of these referrals are folks who have willingly consumed the “Corporate Punch.” The referrals you need the most are the ones that had problems with the product, service, or supplier. THESE folks can provide significantly more information than the satisfied customers. (I'm not saying that you shouldn't check in with satisfied customers. I'm saying that you need to listen carefully to BOTH sides.)

Case in Point: How many negative reviews have you heard about the latest PC operating system (2007/2008)? How many local hardware builders are dissatisfied with this product? How many consumers are having difficulties? Despite these negative reviews, how many small- to medium-sized companies have still acquired the product? You may notice, if you read carefully, an enormous number of larger companies have stepped back and are not buying this product—yet.

Did you know? Many of the companies that beta test software products of this kind are under contractual agreement with the supplier to NOT publish any negative review of the product?

Lesson Five: Realize that the absolute majority of vendor-generated software license and implementation agreements clearly state that the product does not have to work according to any criteria other than those criteria very clearly and narrowly specified by the supportive documentation (usually the manual). In other words, unless you clarify your own expectations—and ensure that they supersede those of the license—you get whatever shows up on site.

Scary Fact: Any software license agreement that cites Maryland or Virginia as the state of governing law is partially governed by UCITA—a software supplier-supported legislative act in those states that virtually ensures the tech consumer has no recourse in dealing with software problems.

Lesson Six: Establish, up front, an Alternative Dispute Resolution (ADR) process and ensure that it is included in the license and implementation agreement—and, once again, it supersedes the vendor-centric license terms. Without the ADR, you get to settle ALL disputes through the legal system—significantly more costly and time intense. Look over our Alternative Dispute Resolution Knowledge Briefing in the subscribers' content HERE. You'll need to log in but it's free [unless you really, really want to pay for it] and your login is confidential.)

Want to Save Plenty? Establish, up front, the specific processes and procedures for resolving disputes.

Lesson Seven: Bring in your own vendor-neutral project manager to manage implementations. Ensure that this PM is fully qualified and experienced and that they closely follow standard PMI PMBOK™ practices. Ensure that the project plan is very clearly and carefully developed with meaningful milestones and stage-gates. Pause often, especially in the initial stages of the project, to ensure that everything is on track. Be ready to pause or complete shut down the project if the expected results are not matching up with the plan.

If you do not control and proactively manage the implementation project, don't be surprised if the vendor-supplied team doesn't fit into your expectations. Don't even be surprised to find that the project fails to meet criteria. (Caveat: A majority of implementation teams—including vendor-supplied project teams—is perfectly ethical and strives to produce positive results for you and your company. However, YOU are responsible for project results.)

Final Lesson (for now): There is no silver bullet! No matter how basic, complex or, sophisticated your company, technology is not the ultra-cosmic, super secret solution to your problems. Tech is only one of the many business tools that fit in a multi-functional toolbox. Those tools are of no value unless they are the right tools for the job at hand; they are being used to produce the results for which they are designed; and they are used effectively. Your people and your corporate culture will determine the actual business value of the tools you place in their hands.

Tools? An entire tool kit of top-of-the-line tools is useless unless the worker actually knows how to use them; is willing to use them; uses them correctly; and, here's a core secret: actually USES them.