Pages

Thursday, April 25, 2013

10. DCP / DRP / BRP / BCP

All of the acronyms around Disaster Planning are TLAs (Three Letter Acronyms)!  Some of them are:
  • DCP - Disaster Contingency Planning
  • DRP - Disaster Recovery Planning
  • BRP - Business Recovery Planning
  • BCP - Business Continuity Planning
Regardless of what you call it, at most companies it does not get enough attention - especially from the business.  In most companies IT has been doing some version of this for years.  If they weren't before SOX, they probably had to then.  

From a technology perspective, the approach has often gone through the following phases:
  • Back up systems to tape nightly and store the tapes off-site.
  • Have a contract with a recovery location provider and test at least annually.
  • Have a back-up data center - either at another of your own locations or at a service provider.
  • Early back-up sites were updated on a regular but not real time basis.
  • Newer sites were mirrored using one or more of a variety of hardware and software tools and some sites were kept synchronized real time.
Obviously business requirements need to drive the solution.  A brokerage company or bank probably has a need for higher uptime than a smaller manufacturing company.  The real question is - how long can the business afford to be down.

While there are many other technical issues such as:
  • Obtaining emergency SW License keys.
  • Having all your recovery information accessible when your data center is down and building access is impossible.
  • Telecommunication connections - to other facilities, to employees, and to customers and vendors.
They are all solvable.  More difficult at many companies is getting the business to step up to the plate to address all of the business issues such as:
  • Where will people sit?
  • What computers will they use (unless everyone has laptops they always take home and no one has a desk top)
  • How to communicate with everyone.
  • Are all forms and printers available?
  • Are there manual files you need access to that should be electronic?
  • Is a Corporate seal available?  Critical for certain types of businesses with many government contracts and bonds.
I think one of the reasons it is difficult to get the business actively involved is that often there is no clear business owner other than IT.  

While cloud solutions may help IT from the technology perspective, the business risks remain.  Moreover you need to have confidence that your provider's possible down time in case they have a disaster is acceptable to you.

Basically all of this is insurance.  Just like you have auto insurance that you hope to never need, you need a viable and tested BCP that you hope to never need.

Thursday, April 18, 2013

9. Contract Terms to Look for


As promised last week, I’ll share some contract terms that I think need attention.  That said, I always worked with an attorney on contracts.  In my experience only attorneys will debate the difference between a permanent license and a perpetual license.  I used to tell attorneys I always skipped the sections THAT WERE IN ALL CAPS because I knew it was legalese for them!  Several years ago a smart attorney convinced me to read those sections as well.   It’s funny, but I have had multiple vendors be very surprised by the fact that I read contracts before signing them.  My belief is that someone from the business needs to read them in addition to legal and procurement.  Since I sign, I read first.

As I said in an earlier blog, I am not an attorney and this is not legal advice.  These are some of the items I look for in a software contract.

Free test copy – My rationale is that I should pay for what I productively use.  Having a test copy helps ensure I am successful with the software and therefore I am a good reference.

Permanent license – Unless, of course, I am acquiring SAAS (Software As A Service)

Cap on Future Maintenance Increases – This one is not easy, but it is almost always possible to get a cap for a certain period of time.

Changed Functionality – This one clause saved hundreds of thousands of dollars several years after the software was in production.  The vendor removed some functionality from our product, combined it with new functionality, and wanted us to license it to use it.  We were protected by a clause that said that if something we had is removed or changed and then offered for a fee – we retain the right to continue to use it free.

Basis of contract price – You need to think carefully about this – for the present and the future – of both the company – and technology.  Some examples are:
Concurrent user
Named user
Processor-based
Business unit based
Company sales volume
Transaction count
Etc.
There is no single right answer.

DRP / DCP / BCP – license key for testing and real use in case of a disaster should be free and obtainable 7x24.

Indemnification – helps cover you if some part of the software is found to infringe on another companies intellectual property.

Time to cure breach – needs to be mutual and sufficient.

Does the software work for your purpose – hard to pin down companies but worth the effort.

How long to upgrade or stay on previous OS versions – This  is a maintenance issue and you want as long as possible – at least 18 months and preferably longer.

Reference calls can have value – especially of they would like to use your company name in their marketing literature.

Audit rights – It is better to have controls built into the software than to have to deal with an audit.  It makes it simple to be in compliance and avoids the disruption an audit can cause.

Service Levels – This is a key for maintenance.  You need to think carefully about how you will deal with bugs or downtime.  The criticality of the software to your business should be your guide.  EDI software is probably going to be more key to your business than Data Warehouse software.   You need a clear escalation process for being down.

Software Escrow – If the software is in a language you could support, this is a realistic option should they go bankrupt.

And to repeat an earlier point – READ BEFORE YOU SIGN!






Thursday, April 11, 2013

8. Negotiating Strategies


As promised last week, we’ll take a look at some negotiating strategies this week.  I don’t claim to be a professional negotiator but I have been involved in many successful negotiations over the past twenty years for hardware, software, and services.

While there are many principles that apply to all three types of contracts mentioned above there are some differences to keep in mind as well.   Consider a typical software negotiation:

  • It may be the only transaction for that type of software you’ll do in twenty years.  This is very different from negotiating agreements for one to three years and then opening up a new agreement with a supplier change as a viable option.  The conversion costs for software mean that this is usually not possible.

  • Pricing can be interesting because valuing intellectual property is very different from valuing a pump or a lift truck.

  • Because it is normally a one-off purchase, market intelligence about pricing is often difficult to come by.


All that said, my focus here is more about what is in common.

You almost always need to view this and treat this for the long-term not the short-term.  You are signing up for a partnership – or normally should be.  This means always looking for a win-win outcome.  Consider both sides:
  • As a vendor - if you are trusted, we will come back to you
  • As a customer - vendor will often go out of their way to make us successful because we are a partner and we treat them as one.

Create a strategy before you start negotiations.  Decide who is playing what role (usually procurement is the “bad guy” - as I mentioned last week, include Procurement and Legal early in the process).

Be fair & honest.  This means being truthful, it doesn't always mean being exhaustive of the truth (as a former VP of Legal once told me before I gave a deposition).

Be willing to walk away – this is not always easy, but if possible it puts you in a position of strength.  There may not always be a possible common agreement – but make sure to explore all options before reaching that conclusion.  Years ago I had a senior vice president of a software company come back to me after I though we had reached an impasse.  He met just with me without Sales, Legal, or Procurement and shared with me his revenue recognition formulas and costs.  In less than an hour we structured a five-year deal that we could both live with.

This last point brings me to an important one – look at the TCO – Total Cost of Ownership – of any deal you do.  It is important to have the CFO aligned with the time horizon you are looking at.

Good luck!

Next week I will mention some contractual items I always look for.  That said, I will NOT be providing legal advice!







Thursday, April 4, 2013

7. Software Selection



Selecting software is a relatively short process that has long reaching implications for a company.  As such, it should be run as well-coordinated project.  Aspects to consider include:

Team Structure
  • Have a focused and empowered Steering Committee
  •  Include Procurement on the team from the beginning
  • Keep Legal informed
  • Be sure to include representation of various types of users 

Project Charter should include
  • Scope definition – both what is in scope and what is not
  • Timeline for the project
  • Benefits case
  • Budget 

Requirements are critical:
  • Requirements need to consider both management and end users
  • Relative value ratings for the importance of each requirement need to be established before the potential solutions are evaluated
  • Some may be mandatory – but care should be taken when using this category
  • Technical requirements need to be understood, especially interfaces 


Scope of vendors to be contacted
  • Do research on-line
  • Talk to customers and vendors
  • Do any of your current software providers supply what you are looking for


Request for Proposal - RFP
  • Let Procurement be the point person
  • Be specific in requested information
  • Provide vendors a timeline that you expect them to meet – as well as your timeline – which you should commit to keeping
  • Limit response at 15 / 20 pages telling vendors that any additional information they want to provide can be in an appendix but that it may not be read
  • Solicit questions from vendors and combine into a single list, removing who asked
  • Have all participants sign a confidentiality agreement.  Many vendors will want you to sign one as well, so just make it mutual.
  • Have a Bidder meeting with all vendors attending and go over all questions (anonymously) so that all vendors will have the same information
  • Review proposals in a timely manner
  • Narrow the number of vendors as quickly as possible
  • Reference calls are critical – in as close to your line of business as possible.  Ensure that the vendor is NOT on the call to help ensure candor.
  • Have finalists (maximum of three) come in and present to the team.  Have them demo their product – ideally with your information that you will have supplied them.
  • Selection Process
    • Assign a value to each requirement and calculate a weighted average score for each vendor
    • Remember, though, it is not just a numbers game
    • Get Steering Committee buy-in


Now it is time to start negotiating with your first choice.  Unless you are sure they can meet your cost requirement, it is sometimes better to keep the number two choice, if they are viable, in the mix.

Next week I’ll discuss some negotiating strategies.