This article is in response to, and supplemental to, the article on ZDNetAsia: "4 tips for buying 'big' software," by Patrick Gray - as posted in TechRepublic on 5 May, 2010.

I've observed well over a hundred negotiations where enterprises spent tens of millions of dollars for highly complex software (and/or hardware). In parallel actions I've seen thousands of small to medium-sized companies spend enormous percentages of hard-won revenue for products they didn't need, couldn't effectively use, and shouldn't have touched. In virtually every case, the enterprise or company making the purchasing has been hammered by supplier negotiating teams.

Here's a few issues to consider BEFORE dropping all your spare bucks on big money technology goods and/or services. Also, keep in mind, if you genuinely want to reduce the costs and risks of business technologies, you can take a wide range of simple, cost-effective actions. BUT, you have to commit to actually DOING asset management - merely talking about the game will not help you gain value.

Nobody is permitted to speak with ANY supplier about the project - PERIOD!

• Why do I bring this up? Because, time after time, I've seen people come back from conferences or conventions where they have "found the perfect product to solve all our problems."

• Major violators of this rule? Technical people and management. Rein them in BEFORE they damage your options.

• Result? The supplier already knows precisely what your project looks like; its schedule; its budget; who will be on the internal team; and who will be part of the decision tree.

• Since the supplier has also conveniently learned the details of ALL your requirements, their product or service is going to somehow magically fit exactly inside your needs analysis.

• When - not if - this happens, you can kiss negotiations goodbye - because you will have no leverage with this supplier.

Conduct, and follow, accurate analysis - EVERY time.

• If your company is typical, you purchase new technology goods and services for nearly ALL the wrong reasons. (Don't get all defensive on me until you read on.)

• Conduct clearly defined, honest, and complete analysis. Make sure that they are accurate and not filled with vendor hype - as well as supporting "pet" projects.

• Pick one or more: Needs Analysis, Cost-Benefit Analysis, Feasibility Study, Forcefield Analysis, Business Case Analysis, Cause & Effect Analysis, Stakeholder Analysis - ANY of these will take you further than you are already going in terms of whether or not the acquisition or project is genuinely necessary. (Incidentally, The Institute for Technology Asset Management - www.TAMinstitute.org - is the only professional organization of its kind that actually teaches you how to conduct over 16 of these critical business analysis.)

• The key is this: Fewer than 10% of enterprises actually conduct any serious level of structured analysis prior to beginning the acquisition process. Of that number, fewer than half ever follow up to ensure that the goods or services acquired actually ADHERE to the expectations. Even more critical is the tendency, in nearly ALL analysis, to insert personal perspectives in place of quantifiable documentation. Result? Decision makers are coming to conclusions that are NOT based in fact or actual business needs.

Negotiate based on what you expect to happen, not based on supplier representative assurances.

• If you do nothing that I recommend, at LEAST do this. Every agreement that I have read in the past 23 years has a clause somewhere that clearly states that ANY statement or assurance given to you is null and void - the agreement supercedes ALL verbal discussions. (You don't have to believe a word I say. Just get up out of that chair and go read a software license - any license to confirm my rantings.)

• So? If you want any specific issues made clear in the agreement you will have to negotiate them in. (Trust me, suppliers do NOT appreciate it when I give this advice. It means that they have to actually deliver the value they claim.)

• This interestingly hidden little caveat also seems to forget to mention that the functionality of the product, as delivered, does NOT have to match what you were told it would do. Again, if you expect to get the value for what you purchased, you better negotiate your specific expectations into the agreement.

The actual costs of this acquisition are NEVER what you think.

• You should already know this but nearly ALL of us tend to forget. We get excited about the new toys and slip off into Christmas morning... What to do?

• Patrick covers this but I'll expand - When you conduct the Cost-Benefit Analysis, step the process out at least three to five years. Check with anyone and everyone who has touched this product. Find out what worked out well and...well...what didn't work out. Document it ALL as part of the CBA - BEFORE you spend a single penny!

• Check out implementation costs and be sure to match them with the specific talent brought to bear on the project. If you think your internal team is going to implement better than a highly trained and experienced (think: expensive) support team, you may be in for quite a financial surprise. But, if you planned and budgeted for the difference in team talent, you may find financial relief.

• What about defects and patch management? Upgrades? Ongoing support? Check into the actual details of each and every one of these items. Look over the actual supplier contracts for the "rough" spots. Does support cost more if your own team implements the project? Is this product so full of defects that the supplier has a monthly patch day scheduled for every consumer of every product? Are there cute little items such as the "product cannot be used more than 15 miles from the server" or implementation support is billed out as "$180 per call"? (If you don't know about these interesting little revenue stream inserts, you really should spend some quality time in one of my technology asset management courses.)

Beware the Reference Fruit Punch Shuffle!

• Patrick mentions being alert to what I would call "happy people" references. You know the ones I mean: "I invented Windows 7." Keep in mind that a supplier would NEVER connect you with someone who had a nightmare failed implementation. If you rely on supplier connections, you'll only hear from the folks who consumed the entire cup of fruit punch.

• As an element of this particular common scam is the supplier advertising budget. If the product is so great, why do you have to spend so many tens of millions of dollars TELLING me about it? If implementation and ongoing support are so simple, why do I constantly hear, or read, about over budget, over time, and failed projects?
  

• You want references? Check with the people who have lost tens of millions on failed projects with this product line or supplier. THOSE folks will give you a totally different story than the ones who had plenty to spend and plenty of talented techies to contribute to implementation and ongoing support.

Manage the Project

• Patrick's observations regarding the implementation partners is right on track. Keep in mind that any enterprise that has reached the "Partner" stage of a relationship with a major software publisher has also consumed massive quantities of that ever present fruit punch. These folks make their livings via their relationship with the given software publisher. If you honestly expect them to admit the product is a dog - don't hold your breath. Instead, they'll follow the supplier pattern of letting you pay to resolve the problem so the supplier can wrap it into the next release - the one you'll pay to acquire.

• For a major software acquisition & implementation either use your own project manager or follow Patrick's advice and bring in an independent PM to monitor the project - even a spot check will be better than nothing. But, let's take this a little further...

• IT projects fail significantly more frequently than they succeed. There are plenty of reasons for this - some of them are even reason-able. But, as a PMP and a faculty member teaching project management I have found that the key to project success - or failure - all-too-often rests on the heads of project sponsors, executive management, and the initial planning team. THESE folks need to be visibly and aggressively on board or the project manager might just as well be a NATO observer.

• Remember that "negotiation" thing we discussed? It also comes into play right here. Place serious penalties in the acquisition agreement to "encourage" the implementation company to get it done right. Wrist slapping does not belong in this clause. If it is going to cost you $1M for the product, $2.5M for the implementation, and $5M to correct failure - include those costs in the failure clause. Otherwise (as clearly stated in the software license) the software publisher needs only refund the price of the software after it fails and they blithely walk away from your completely devastated IT environment.

Is there more? Oh, absolutely! In fact, there are literally hundreds of "gotchas" hidden inside every software acquisition - whether it's a simple operating system or a major overhaul. If you expect to gain value from business technologies, you absolutely must learn to identify, define, and pursue that value. Otherwise, the suppliers are in control of your money and (lack of?) results.

Thoughts? Comments? Observations?