Oregon sues Oracle. Time for you to learn more lessons in IT.

The state of Oregon has sued Oracle for breach of contract.

Read the complaint - at least the first 7 pages. It looks a scene taken from a suspense movie unravelling itself. Except for the fact that there is no suspense here, it runs more like a bad movie where you know the ending. But you stick with the movie nevertheless to see if anything is different this one time.

This is a formula that miraculously works each time towards assured failure of an IT project.

• Trust promises by a product vendor
• Trust the independent evaluator that certifies the viability of solution/product
• Trust one vendor to implement everything for you
• Even trust the status reports from the implementation partner, never really cross-verifying what is happening on the ground

Yeah, it is the state of Oregon at fault. One of the primary things that you learn in the industry is

Don’t trust anybody.

(or D.T.A) - Mr. Stallone in 1989.

I have never seen a product work out of the box, for anything more complex than a HTML page with nothing but a H1 title. You don’t trust me - well, read the above sentence again.

So, imagine you had a time machine and went back. How would you change it?

• Always ask for references.
  What was the time taken for the last implementation of similar nature? Vendor says you are unique enough to start a new project? Ask them the product for free, and congratulate yourself on being an alpha tester (I am talking about the maturity level of the product, not your hierarchy in your tribe)
  You have a critical project where people can die if the finished product is not delivered on time? Politely reject the suggestion to become the first scapegoat, and move on
  Do you still remember D.T.A? Ask for multiple references to mitigate risk.

• Always start small.
  You cannot achieve the end goal in 6 months. If you believe you do, you don’t know today’s IT. A million requirements implemented in whatever form is a sure recipe for disaster.

• Measure milestones, and keep measuring.
  Keep milestones small. A development period of 6 months is only small if you have a project spanning 6 years. If you have a project spanning 6 years - you have not read my second point.

• Have multiple vendors, and/or independent audits.
  Make sure you mix and match IT vendors. Keep them tied to one another, keep them on alert by the threat of audits and “no payments on non-performance” statements.
  Bring in auditors for each phase. Either have your people who understand business and IT checking in once in a while, or bring external vendors. People within the project (even if they are your own) will face the danger of being complacent, and developing an attitude of “going with the flow”.

• Get involved.
  Get business to check out what is going on - it may be the requirement document, the foundation of product that is in progress, and silly things like the way users click on a button. It may be anything - let the users comment, they really know what will work. Always be willing to negotiate your way through what is required of the product, and how much you are willing to spend.
  And, re-read D.T.A. Create milestones for yourself to check on the developments.