Friday, November 27, 2009

How Bad Can It Be?

From the Milwaukee Journal/Sentinel, Nov. 26, 2009:

A digital radio system that has cost the Milwaukee Police Department about $17.5 million since 2003 still is not fully operational, and the system's dispatch consoles - which cost a total of $1.9 million and were installed in 2004 - are becoming obsolete and must be replaced by 2012, according to department and city officials.



http://www.jsonline.com/news/milwaukee/74212577.html

Wednesday, November 18, 2009

I Paid For It, Don't I Own It?

My expert on Internet telecom is unavailable until later this week.  As a result, the promised article on VOIP systems will be delayed by a couple of days.  In the mean time, let's discuss ownership of intellectual property.


In the last fifteen years or so, "intellectual property" has become one of the favorite buzz words in industry.  Everyone wants to have it, protect it and, most of all, exploit it.  Which begs the question, what IS intellectual property?

As the name suggests, intellectual property ("IP") is ideas, in particular ideas that are both new and useful.  A car engine that would remove greenhouse gases from the atmosphere would be an example of particularly valuable IP asset.

IP is covered by different sets of laws:

Utility patents protect tangible inventions or discoveries, things you can hold in your hand or which perform a useful function.  The light bulb is the classic example.

Design patents protect the look or styling of a product.  Think of the distinctive shape of a Coca Cola bottle, or the racy lines of your favorite motorcycle.  A design patent can help prevent a competitor from copying these "looks" too closely.

Copyrights protect "works of authorship," such as books, music and computer software.  (Just to add to the confusion, software can also be patented.)

Trade secrets protect information that is valuable, but not publicly known.  Col. Sander's fabled "eleven herbs and spices," is a famous example.  Reportedly only a handful of senior executives know the recipe.

Trademarks and service marks protect company logos, such as the Nike "swoop," the yellow Kodak film box, and even the name "Kodak."  If I tried to exploit Kodak's good name by bringing out a film product named "Coldack," the good people in Rochester would probably be able to shut me down, claiming that my name is too similar to the name they have used for years. 

For today, however, I'd like to focus on patents and copyrights, as they seem to generate the bulk of confusion regarding ownership and use rights.

The default rule in American law is that the person who creates or discovers an IP asset owns it.  Or, to put it another way, the law automatically sees the discoverer or creator as the owner, unless he or she has made an agreement that gives ownership to someone else.  The legal term for such an agreement is an "assignment" and the new owner is generally referred to as the "assignee."

There is an exception to the default rule, called the "works for hire" rule.  It provides that, in certain conditions, assets created by employees in the course of their employment belong to the employer, not the employee.  The rule is not as clear as it might be, and employers are encouraged to include assignment language in their personnel handbooks.  In addition, if an employee is being hired to do research and development, she or he should be asked to sign an individual agreement, assigning rights to any assets created in the course of employment.  "Better safe than sorry."

The default rule can be particularly troublesome when work is outsourced to a contractor.  It would seem logical to assume that "I paid for it; I own it."  Logical, but contrary to the default rule.  You may recall that ten or fifteen years ago, when the Web began to boom, companies discovered that they did not own their Web sites, because they had not secured proper assignment of the page design from the Web developer.  The same, or worse, can happen if the "developer" is a third party programmer who  happens to create the key part of the new application that will help you dominate your industry.  Without proper assignments, you may not have this vital new asset under lock and key.  Rather, the third party might be in a position to charge you outrageous support fees, prevent you from modifying "her" product or even market it to  your competitors.  Any of those would be difficult to explain to the boss.

For all that, one does not always need, or perhaps want, to own all rights to every bit of software one pays to develop.  One may front the cost of vendor's development of THEIR new killer application, in return for a great deal on maintenance and upgrades.  Or one may pay for the development, and allow re-sale of the new product, provided, it is not sold to your direct competitors and provided you get a cut of the profits.  I once effectively owned a major software vendor for several days because no one told me my client was funding vendor's new flagship product.  I therefore provided that my client would own all rights to the new product.  Their attorneys did not see the problem until after the contract had been signed and delivered. 

The lesson is that American law protects the person who creates the IP asset, not necessarily the person who pays for the creation.  Care, and often good legal counsel, are needed to ensure that  your company secures the rights it wants and needs product it is paying for.  But do not stop your analysis with "We paid for it, we want to own it."  Ask, rather "What rights do we need to secure the competitive advantage this product offers?" and then "After we've secured our competitive advantage, can we make additional money off the new product?"

If you can transform Project X from an expensive sunk cost into a competitive advantage AND a revenue stream, that would be something to tell the boss.

Monday, November 16, 2009

Some Shameless Self Promotion

DID YOU KNOW THAT:

The State of Wisconsin has written off $100 million in IT contracts?

Barnes and Noble is being sued for allegedly breaching a confidentiality agreement relating to its new electronic text reading device (the “Nook”)?

Novell and SCO have been involved in litigation regarding ownership of the Unix operating system since January of 2004?

Each of these is an example of a no-win situation. Reputations will be damaged, time and business opportunity will be lost. No one will be significantly better off when the dust settles (except perhaps for the lawyers handling the cases).

Yet such disputes and losses are not inevitable. We can train your personnel to negotiate and draft IT, IP and nondisclosure agreements that are clear, effective and which help ensure the success of the underlying projects. We call them “Contracts That Work.”

Topics include:

  • Protection of trade secrets
  • Proper identification and use of confidential information
  • Ownership of intellectual property
  • Payment schedules that help ensure performance
  • Avoiding “project creep”
  • Securing the rights that you need
  • Getting the “best price”
  • Avoiding unexpected delays and unforeseen charges

Sessions are limited to fifteen participants and can be tailored to address the specific needs of individual companies or units.

Contact us at thomasj.hall@gmail.com

About Tom Hall:

Tom Hall is formerly Of Counsel in the Nashville office of Baker, Donelson, Bearman, Caldwell & Berkowitz, PC. He was a member of the firm's business and technology practice group. He has over twenty years experience, both with law firms and as in-house legal counsel. He therefore possesses a unique understanding of the legal and business issues involved in IP and IT transactions.

Tom is co-author of three books on IT and IP matters:

Application Service Provider and Software as a Service Agreements Line By Line
Patent License Agreements Line By Line
Joint Development Agreements Line By Line

(All written with Kelly L. Frey, Sr. and published by Aspatore.)

Thursday, November 12, 2009

When 99.9% Availability Isn't Good Enough

One of the characteristics of Application Service Provider and Software as a Service agreements that give users pause is the question of down time and availability.  If the system crashes, will the vendor commit sufficient resources to bring it back on-line in a commercially reasonable time? (By the way, what is a "commercially reasonable time"?)  Alternatively, will someone in the vendor's operation take the system down at noon on a Friday, so he or she can perform routine maintenance and still leave early for the beach?  If a system is hosted and run in-house, most users feel they have far more control over these exposures.


To address these situations, certain language is found in standard ASP and SaaS contracts, such as:

The System shall be operational, and the Services shall be Available 99.9% of the time each month, with the sole exception of scheduled maintenance periods, which shall last no longer than one (1) hour per day and which shall take place each morning between the hours of 3 a.m. and 4 a.m.


(I have omitted the three pages of technical specs spelling out how availability is measured.)  


At first reading, this language appears more than adequate.  The system is to be operational virtually around the clock, except for scheduled maintenance, which is to take place well outside normal business hours.  Yet at least two exposures remain:
  • What if the 0.1% permitted downtime occurs when user is struggling to complete its response to a large RFP?
  • What if user specifically wants to use the service between 3 and 4 a.m.?  What if, for example, user is a large investment bank that needs to do complex number crunching, and needs the processing power, and reduced pricing available with "off peak processing"?  
The first exposure is a technical one - it arises from possible hardware failures or errors by vendor or software glitches.  The proper response is due diligence - verify, before signing the contract - that vendor runs a quality operation AND has appropriate, and redundant, backup systems in place.  If Server A fails, Server B should take over automatically and user should never notice the transition.  The more critical the service is to user, the more important it is for user to select a user whose practices make it unlikely that unscheduled downtime will ever occur.
As for when scheduled maintenance will occur, that is a risk user can and must control.  A user who does not read the contract and does not realize that Vendor X performs maintenance during user's peak demand time really has no grounds to complain.  Neither should users expect vendors to readily agree to altering their schedule.  The business models of ASP and SaaS vendors call for volume and standardization.  Fast food burger joints make money by selling the same burger, millions of time each day.  Customization disrupts the system.  Rather than attempt to force Vendor X to bend, a prospective user may be better served by thanking X for her time and continue looking for a vendor whose services meet user's needs.


Next week:  Let's talk gadgets, not law.  A look at VOIP telecomm systems.  What are they and how can they contribute to your bottom line?

 

Wednesday, November 4, 2009

Case Study – Wisconsin’s $100 Million Loss

Note: The promised piece on ASP and SaaS availability standards has been postponed for one week.


It has been said that IT projects are always late and over budget. The most commonly given reasons are:
  • Vendor errors;
  • Vendor misconduct;
  • Changed circumstances;
  • Unforeseen obstacles.
Regarding “vendor misconduct,” it is easy to find IT executives willing to believe that vendors deliberately under estimate cost and time requirements to win contracts, only to have the true cost become apparent as the project unfolds. Such “low balling” undoubtedly occurs, but more often vendor and customer must share responsibility for a troubled project. If “blame” is to be assigned, perhaps it should fall upon customers who ignore the ancient maxim: “caveat emptor.”

Remarkable examples of “how projects go wrong” are provided by the State of Wisconsin, which in late 2006 and early 2007 confronted a number of troubled projects, with an exposure of some $100 million. The figure is all the more significant when one considers that the State’s annual IT budget is roughly $400 million. A quick survey of the troubled projects will help set the stage:
  • In 2006 the University of Wisconsin discontinued a program to update its salary and benefits system, after spending five years and $26 million.
  • As of Spring, 2007, a new system to track unemployment taxes was 3.5 years late and $12.2 million over budget.
  • A new voter registration system was more than two years late (i.e. ready two years after the deadline set by Federal law).
  • New sales and use tax software required a $5.7 million fix.
  • Work on a new system to track unemployment claims was suspended in February, 2007, after an expenditure of $23.6 million.
  • A new system to handle automobile registrations was abandoned. It was at least a year late, $9.4 million over budget and had significantly increased wait times at the DMV offices.
This string of difficulties prompted members of the State legislature to request a formal audit by the Legislative Audit Bureau (Wisconsin’s equivalent to the Federal General Accounting Office). According to the Bureau, these projects had much in common:
  • Failure to appreciate the complexity of the projects;
  • Failure to define the final function of the various systems;
  • Failure to observe contracting best practices, such as standard procedures and incentive/penalty clauses.
  • Lack of leadership and oversight.
Significantly, ALL of these variables were within the control of the State.

As a case study, Wisconsin’s difficulties are rich in lessons, for it appears the State made virtually every mistake in the proverbial book. It made many of them repeatedly:
  • Failure to realistically allocate resources;
  • Failure to plan in detail;
  • Failure to plan with an end in mind.

Of these, perhaps the most damaging was the failure to plan with an end in mind. Without a clear goal in mind, it is not possible to set meaningful specifications. In turn, an absence of meaningful specifications opens the door to “mission creep” as each user tacks on items from his or her wish list. Cost and time requirements can and probably will increase dramatically. Even without mission creep, ambiguous specs are a recipe for failure. Vendor may believe that customer wants and expects “X,” while customer is expecting something quite different. Unfortunately, the misunderstanding might not be discovered until late in the project, after much time and cash has been invested. Also, without clear specs, it is not possible to develop reliable cost estimates or time tables. In a very real sense, the various Wisconsin projects were not over due or over budget, for they had never been properly planned or budgeted. Quite simply, the State did not know what it was getting into, and paid the price.

Taken as a whole, the Wisconsin projects suggest an IT unit in disarray:
  • Lack of necessary expertise;
  • Lack of leadership willing to set reasonable expectations;
  • Lack of uniform contract forms and contracting procedures to guide personnel who might not be versed contractual matters;
  • Lack of oversight.

The lack of oversight bears special consideration. The various projects discussed here fell primarily within the responsibility of the Department of Administration (aptly known as “DOA”).  That department failed in its responsibilities because it was pre-occupied with two troubled tech projects of its own. A second level of supervision is, in theory, provided by committees of the State legislature. Those committees, however, have been inactive since at least 2005.

Wisconsin’s misadventures offer a sobering example of the many ways IT projects may go wrong:
  • Failed leadership, leading to unreasonable commitments. These commitments led, in turn, to unreasonable expectations and burdens on personnel.
  • Lack of a core of personnel trained in the art and science of managing large projects (not to mention negotiating large contracts). As a result, individual units were left to fend for themselves, with unfortunate and expensive results.
  • Absence of standard forms and procedures to guide users when they were indeed forced to fend for themselves.
A word should also be said about the broader consequences of these difficulties. The responsible CIO has returned to the private sector and the State has represented that all is not lost – that portions of these troubled projects can still be put to productive use. In a private company, the results might have been more dramatic. Such losses, combined with the evidence of failed oversight and leadership, might well cause a wholesale dismissal of management, not to mention the possibility of shareholder derivative suits.
Whatever the political or economic consequences, Wisconsin illustrates the importance of professional, systematic management of IT contracts (indeed, of all contracts) and the importance careful, detailed planning by trained and experienced personnel.

Tuesday, October 20, 2009

Towards a Successful ASP Agreement, Pt. 2

Where Has All My Data Gone?

Microsoft and T Mobile are currently receiving lots of bad press relating to the loss of data from users of T Mobile's Sidekick device. Because Microsoft was essentially acting as an ASP for those users – storing data for them – this event raises some interesting questions.

What happens if my ASP loses my data?

That depends on whether the data is critical to the operation of your business. If you were using thousands of Sidekicks to run a world-wide enterprise, you would probably be out of business. In a more likely scenario, if you had out-sourced complex calculations or processing of a large volume of information, you might still face a serious business interruption. Orders may not be filled correctly, or on time, trading (or reporting) deadlines might slip past or payroll checks might not issue on time.

Of course “What happens if my data is lost?” is the obvious question. A better one is “What is the appropriate response to such a loss?” While the answer is obvious – restore the data – it begs a number of questions:

Who is responsible for the restoration?
Who will pay the cost?
Where will the information for the restoration come from?

According to media reports, in the Sidekick case both the main and backup databases were lost due to a server malfunction. From that it would appear Microsoft observed one of the main commandments of computing: Back up your data. Whether the back ups were made in an appropriate manner is not clear from published reports. For example, were the main and back up files stored on the same server, meaning that one failure would interrupt access to both?

User difficulties were apparently compounded by the fact they did not have copies of their data on their PCs or their Sidekick devices. They could not simply update Sidekick from PC (or vice versa) and continue with their lives while Microsoft and T Mobile sorted things out. They had put “all their eggs in one basket,” and lost the basket.

The lessons are not new:

Back up your data
Observe appropriate back up protocols (e.g. off-site storage of back up data)
Keep your own copies, just in case

What safeguards should I observe?

The first safeguard has just been mentioned – keep your own copies. The second is to require the provider to keep its own back ups, and to observe appropriate processes and protocols. At a minimum the contract should require back ups, and specify the protocols to be observed. Failure of provider to meet these obligations should be defined as a material breach of the agreement, constituting grounds for subscriber to terminate the contract. But mere words on the page may be insufficient, particularly if the data is critical, sensitive or protected by law. After all, the ink on the page will not rise up and compel provider to perform. Even a court order enforcing the written words might come only after significant, if not irreparable, harm, has been done to your business. The more important the information is to your business, therefore, the more important it is to verify provider's data protection practices before the contract is signed, and to inspect provider's facility periodically to ensure compliance during the contract term. To avoid any doubt or dispute on the question, the right to inspect should be written into the agreement.

Yet the ASP model contains an exposure not presented by the Sidekick occurrence – loss of functionality. Users could still access the various functions of their devices, but could not retrieve their stored data. But what if the software that enabled each device to communicate with the servers had failed? What if software used by your payroll processor abruptly doubles everyone's salary?

Mitigating this exposure in the ASP context requires a bit of care. Should subscribers require their providers to have off-site back up facilities, able to begin processing in the event a disaster strikes the primary site? Absolutely, if the provider is providing services critical to subscriber's business. Again, the need for careful drafting by counsel and due diligence by business personnel rises in direct proportion to the importance of the services. If provider cannot, or will not, provide such a mirror back up site, consider creating one of your own, complete with copies of the necessary software, licensed for use in the event of catastrophic failure by provider. (Care would also be needed to define what constitutes a “catastrophic failure”.) But if subscriber is compelled to create its own emergency back up site, is the ASP investment cost effective?

What are my remedies?

“What are my remedies?” is simply a polite way of asking “What does my provider owe me?” Assuming the contract has been properly researched, drafted and enforced, the answer should be “Nothing.” A failure at provider's facilities should pass virtually unnoticed by subscriber, certainly without loss of critical information or functionality. That would be an excellent example of a contract that works. After all, even if a court eventually orders provider to hand over a sack of money equal to the value of the interrupted services, it may be too little and too late to pay for your attorneys, lost business and loss of goodwill.

COMING SOON: Part 3 - When is a warranty of 99.7% availability a bad deal?

Wednesday, October 7, 2009

Steps Towards a Successful ASP, Part 1

The Application Service Provider ("ASP") model has many attractions:

  • Someone else pays for the hardware, software, maintenance, updates, etc.
  • Subscriber pays a fraction of the total cost of implementation.
  • Competition gives each provider an incentive to continually improve their offerings.
But there are also potential down sides. Someone else controls the:
  • Hardware
  • Software
  • Personnel
  • Security
  • Back up
  • Disaster recovery
If your ASP crashes, will it take along your critical processes?

Setting aside the worst case, there are other reasons an ASP may be unsuitable.
  • A third part will be given access to subscriber's data.
  • The services offered may not precisely meet subscriber's business needs or processes. Because many ASP business models are based on standardization and volume, provider may be unwilling to offer custom solutions for individual subscribers. In that event, is it cost effective for subscriber to revise its policies and practices to accommodate the proposed application?
  • Provider, not subscriber, controls when and how changes to the application are made. If changes effect the "look and feel" of the application, subscriber may encounter unexpected costs and delays for re-training personnel. Alternatively, subscriber may not want the added features, and extra cost, of Version X +1, while provider may not want to continue to support Version X.
  • In general, neither provider nor subscriber controls the transmission lines, creating an exposure - interruption - that neither party can fully control.
  • Quitting a provider can be problematic. For example, will the provider simply block subscriber's access to the application or provide transition assistance. If assistance is provided, what will it cost?
Some of these concerns can be addressed through careful contracting, some cannot. If granting provider access to subscriber's data violates privacy laws, or if provider's business model does not allow for needed customization, no amount of brilliant lawyering will make the deal work.

What then, are the foundations of a successful ASP project? A full answer would require a book (See shamless plug below), but I can address some highlights here.

1. Due Diligence

As mentioned, if provider's offerings do not meet subscriber's needs, the relationship will be rocky, at best. But diligence must extend beyond matching needs to services.
  • Is provider financially sound?
  • Are its personnel adequately trained?
  • Does vendor have all the necessary permits and licenses?
  • Does vendor implement appropriate physical and logical security?
  • Are appropriate disaster recovery measures in place?
It is important that subscriber verify this information before signing the contract. Afterwards, one can always sue if, for example, there is a disaster and provider does not have in place the recovery safeguards required by the contract. Subscriber might well recover money damages, but those will be cold comfort if he/she has been put out of business.

2. Interim Remedies

In fiction, at least, the appropriate response to any business disagreement appears to be "So Sue Me!" A better approach might be to build in "safety valves" to permit discrete disagreements to be resolved without derailing the entire project. Examples would be meet and confer requirements, permission to withhold payment of disputed balances and a narrow list of circumstances in which provider may suspend or terminate services.

3. Objective Standards

When will the application be available?
What processing speeds will be provided?
What response times will be accepted?
In what format will subscriber's data be stored?
In what format will reports and other output be delivered to subscriber?

To protect both sides, it is important that these and other standards be stated clearly and be subject to objective measurement. Without objective standards, subjective judgments ("It's too slow!") could put the project at risk.

4. Testing

We will purchase an auto after a 20 minute test drive and a house after a walk-through and home inspection (and a little haggling). Outsourcing business functions, however, merits more detailed examination. The more critical the processes, the more important it is to thoroughly test the application in the most realistic setting possible.

5. Business Continuity

If the provider's servers fail, will subscriber's business come to halt? Thus the need to verify that provider observes proper security, back up and recovery procedures. For truly critical processes, consider requiring a source code escrow (which must be kept current) or maintenance of a mirror site that could easily be taken over by subscriber.

We will explore these and other features of a successful ASP contract in greater detail in future postings.


This article is derived from "Application Service Provider and Software As A Service Agreements Line by Line," Kelly L. Frey, Sr. and Thomas J. Hall. Published by Aspatore Press, 2007.

Note - my friend and colleague Kelly Frey had no part in drafting this post. Any errors in it are mine alone.