Saturday, March 30, 2002

 
Posted by Anonymous 11:53 AM
Life imitating ... life. Mike's recent entries here and in Notes from the Field have been heavily focused on contract law. I cannot resist using the following quote as a lead-in:

A learned County Court judge in a book of memoirs recently said that the overwhelming amount of his time on the bench was taken up 'with people who are persuaded by persons whom they do not know to enter into contracts that they do not understand to purchase goods that they do not want with money that they have not got.'

Credit goes to Lord Greene, about whom I know nothing except the above is attributed to him. What Lord Green says, however, goes to the essence of contracts in general and aptly sums up software development contracts.

Opportunities Abound. What I most like about writing here and in Notes from the Field is the frequent opportunity to meld my knowledge and skills with what Mike and Linda discuss. Such an opportunity presents itself today. As a competitive intelligence specialist one of the knowledge areas that is important to my profession is law. The practice of law is left to the attorneys; however, understanding the fundamental issues is necessary when one is gathering raw intelligence and transforming it into processed intelligence and knowledge. The scope of understanding includes principles and processes.

A Matter of Principle. Intellectual property is a core area for intelligence gathering and analysis, which makes Basic Principles of Patent Law a key knowledge area. Patent and contract law have radically changed since the web's growth in popularity and the business focus on e-commerce. I've put together a Zip archive of documents and presentations about E-contracts as a basic primer on a wide-ranging subject. The field is ever changing, so do not base any decisions on knowledge or sources other than from an attorney who specializes in this practice of law. You can, however, gain sufficient understanding of the issues through selected reading. One book I recommend is CyberRegs: A Business Guide to Web Property, Privacy, and Patents by Bill Zoellick. I reviewed this book on Amazon on 8 November 2001 and Mike reviewed it on 25 September 2001. It's interesting to read our two completely different perspectives, both of which are valid, of the book.

An interesting paper that integrates contract and knowledge management factors is titled An Incomplete Contracts Theory of Information, Technology and Organization, which discusses information as an asset (which it certainly is) and contested ownership of the information. This paper cuts across a number of disciplines, including law, knowledge management, and human resources.

Processes. Mike has gathered a wealth of documents and links about contracting and/or outsourcing software development. If you want to see what happens when things go wrong (and they often do in our litigious society), read The Anatomy of a Software Lawsuit. Since litigation occurs despite the best efforts and intentions of all parties it will behoove you to gain an understanding of the underlying process.

 
Posted by Mike Tarrani 11:14 AM
New Thread? Not! The material on software development RFPs and contracts was in response to a friend's questions. The topic has taken on a life of its own. On the plus side we've all pitched in and provided information to someone who needed it, and that's what TEAM Zarate-Tarrani is all about, and why we started these weblogs in the first place. An added bonus is this material complements layers in the Tarrani-Zarate model, which I've been writing about. On the minus side, however, is I'm behind on the series about the Tarrani-Zarate Model. I'll err on the side of sharing information every time, so I'm going to wrap up the software development and contract topic and leave it to Kate and Linda to fill in any gaps.

Putting a Fine Point on it All. The final documents and resources I'm going to share are:

• An article titled Fixed Price IS Development Contracts (online), which discusses some of the basic and finer points of this contract model.
• Internal vs. External Software Maintenance: An Empirical Study of Transaction Cost Economics Propositions (online), which supports the decision of whether to outsource maintenance vs. performing this function in-house. As an aside, maintenance is a common goal for development contracts, and even if your goal is to contract out for the development of a new application, the issue of maintenance needs to be addressed.
• A series of online articles that cover the full spectrum of software development contract issues (be aware that these articles are based on UK law):
  1. Software Development Agreements
  2. Maintenance & Support Agreements
  3. Escrow
  4. Outsourcing
  5. Licenses
• A collection of MS Word and PowerPoint documents on Software Development Contracts
• A dissertation in MS Word format on Outsourcing Software Development
• Whitepaper in PDF format titled Vendor Screening in IT Contracts
• Whitepaper in PDF format titled Estimating Software Contracts, which addresses a critical aspect of development contracts from both the vendor and buyer perspectives - PDF format
• GSA Guide to Acquiring Software Development Services in PDF format (the US Government's General Services Administration is probably one of the best sources for mature acquisition and contracting practices, as is shown in this document

I'm ending this entry with one final document that is an example of a decision support tool for in-house vs. outsourcing development. It employs standard risk adjustment factors based on PERT (program evaluation and review technique), and uses one standard deviation to the normalized result to increase the safety factor to 84% probability (versus the 50% probability that the PERT formula yields). This is an example from a real life document.

Friday, March 29, 2002

 
Posted by Anonymous 8:02 AM
Saving the Best for Later. I've accumulated a large number of presentations, links and documents about knowledge management and competitive intelligence during the past two days. I'm in the process of sorting and classifying them, and will be posting them here and in Notes from the Field later today.

There are two resources that I do want to share in this entry:

1. CIO Magazine's collection of articles about knowledge measurement.
2. An article titled Is Somebody Dulling Your Competitive Edge?

I'm also reading Working Knowledge: How Organizations Manage What They Know, and will be sharing my thoughts and impressions about this wonderful book later this weekend. Stay tuned.

Wednesday, March 27, 2002

 
Posted by Mike Tarrani 5:22 AM
Software RFPs. A friend recently asked if I had an example RFP for software development. The short answer was I had a few, but like all RFPs they were poor examples. I've been on both sides of the RFP process: I've written them and managed the vendor evaluation and selection process, and I've responded to them with proposals. Rare is the RFP that does the either party justice (rarer still are proposals that completely respond to RFPs, but that issue is for another time).

If you want it done right, do it yourself, so I'm going to take this opportunity to develop an RFP template and share it with all who needs one.

The Goal. The goal of the RFP is to clearly communicate what it is that you're seeking, and to give potential bidders enough information with which to propose a solution that is matched to your needs. An RFP epitomizes capitalism at its finest because you want something someone else has, and they want your money in exchange for it.

An RFP also is an exercise in risk management because you don't want to pay more than necessary to to get what you want. In the seller's case, value is at risk. The sellers who will be responding with proposals will be competing for your money, and risk bidding too high and losing your business or bidding too low and leaving money on the table (or losing money).

There are other, more subtle risks inherent in the process that go to the stability and track record of the seller, the quality of their work, their ability to warrant their work and make good on the warranty, and ownership of the product after it has been developed and delivered. All of these will be addressed in the discussion below.

Elements of the RFP. Here are the minimum elements of a software development RFP and why they are necessary:

1. Statement of Objectives - describe what you are seeking in general terms. Example: Company is seeking the development of a software application to sort widgets.


2. Background - give the background in a paragraph or two that sets the context of your objective(s). Example: A workflow study concluded that our manufacturing facility can reduce cycle time by 30% and improve quality by 50% if newly manufactured widgets are sorted by size and color before they are sent to QA. The software application we are seeking is an initiative sponsored by our VP of Manufacturing to implement a system that results in the improvements cited in the workflow study.
3. Environment - Describe the technical environment that will determine how the respondents to the RFP approach crafting a proposed solution. Example: The system operates on a 24x7 basis, supporting geographically dispersed manufacturing locations across three time zones with two 10-hour shifts in each time zone. We use IBM AS/400 midrange systems that are located in our West Coast data center. The applications to which our widget counting solution must interface are written in RPG/400. We use IBM Client Access/400 and Rumba 5250 terminal emulation from Windows 98 and Windows 2000 PCs. Access to the midrange systems are via point-to-point circuits from each remote facility. Each circuit is sized to allow each remote user 56 kbps of bandwidth, and all terminate into a 100 mpbs switched Ethernet environment in our central data center.
4. Policies, Standards and Methods - List all mandatory policies and standards with which vendors are expected to comply, and methods that you employ to which they will need to align. Example:
   • [Company] has policies in place for change control and release management (copies to be provided under non-disclosure to bidders that make our short list) with which the success bidder must comply.
   • We use Rational ClearCase software configuration management software and will make one licensed seat available to the success bidder to be used during the life of the contract.
   • The system into which the application we are requesting will be integrated has the following service level objectives [list them]. These service level objectives cannot be degraded by any proposed solution.
   • We are in the process of standardizing on Windows 2000 with plans to migrate to Windows XP in 9 months. Any proposed solution must work with our existing and planned standards, and not conflict with the standard software suites and configurations for [Company] desktop PCs that are provided in Attachment A.
5. Statement of Work - Completely describe what you want in unambiguous language. Make sure that the following are covered:
   • Requirements and specifications. Express requirements as business rules for the best results. Example: The application will:
     1. Sort all widgets in two passes: (1) by size and (2) by color.
     2. Group all widgets of the same size and color
     3. Create a routing slip that provides a count of each group and route widgets as follows: Size less than 1" and Color = any to QA station #1, Size greater than or equal to 1" and less than 2" and Color = any to QA Station #2, Size greater than or equal to 3" and Color = any to QA Station #3.
     4. If any Group has only one widget create an exception report that documents the operator (from the WIDGET_OP table), date and time (from the RUN_DATE table) and the size and color (from the widget_size and widget_color columns in the WIDGET_BATCH table). The PK/FK will be the run_number attribute in all of the above tables.
   • Provide all specifications. Example: The application will use Client Access/400 data queues as the means of inputting data into the system. The application will use standard SQL queries to extract any necessary information from the system.

List service level management requirements: Example: Any problems with the application that are not detected in acceptance testing must be resolved in accordance with our standards for problem management. Definitions for severity and priority levels are provided in Attachment B.

Terms and Conditions. Although your organization probably has a standard format, make sure the following are considered:

• who owns the source code - if the vendor, will the source code be placed in escrow so you have access if the vendor goes out of business?
• specify expectations for corrective action for defects discovered after the software has been accepted
• specify in clear language acceptance criteria before payment will be made; if you you're using progress payments, what are the quality gates for each progress stage

Also be aware that acceptance testing is your responsibility and the criteria for acceptance needs to be clearly stated in the RFP.

Monday, March 25, 2002

 
Posted by Anonymous 8:04 PM
Connections. One of the joys is to be able to augment or complement Mike's or Linda's entries. Both have left me an opportunity to connect material from my technical specialties to entries that reflect their specialities. Today is a day of joy.

The whitepaper titled Value-Based Requirements for eCommerce Applications connects Mike's recent entries on both business requirements and service level objectives to competitive intelligence. This document supports Mike's assertions in his recent entries, and it is a blueprint for reverse engineering competitor requirements for CI specialists.

Managing Innovation Risks is clearly a document of interest to the competitive intelligence specialist, and if you stretch your imagination, it also lightly brushes against Linda's recent discussion of business continuity planning (yes - it is a stretch). A more direct correlation between Mike's business requirements and business imperatives discussions and competitive intelligence is found in A Scorecard to Assess Enterprise Innovation Capabilities.

 
Posted by Mike Tarrani 3:15 AM
Tarrani-Zarate Model: Service Level Objectives. In my last entry about the Tarrani-Zarate Model I wrapped up the discussion on business requirements. The next layer in the model is service level objectives (see the illustration). Because we've extensively addressed service level management in previous entries I am going to keep this discussion short and focused.

Short. Instead of wading through the previous entries, download and read the whitepaper titled Successful Deployment of IT Service Management in the Distributed Enterprise. It succinctly and comprehensively discusses all of the key elements of service level management, and places service level objectives in their proper context.

Focused. Service level objectives are goals that are defined as the level of service to be delivered to the business. Examples include:

• When the system will be available (principal period of operations)
• What percentage of the time it will be guaranteed to be available during the principal period of operations (this gives room for unplanned maintenance).
• How long will it take to respond to a reported incident.
• How long it will take to resolve a reported incident.
• How long it will take for a module to load or new screen to appear (key transaction performance)

As you can see these are measurable objectives.

Characteristics of service level objectives:

• Each service level objective must be traceable to a business requirement. If it does not meet this test then the business value of meeting it is questionable.
• They are defined by the business process owners. IT does not define them - a service level objective states a goal that the business defines.
• Service level objectives are used by IT as the specification for service to be delivered. Any gap between what the business requires and what IT can deliver is negotiated when the service level objectives are used as the basis for the service level agreement between the business and IT for the level of service to be delivered.
• Requirements and specifications for applications delivery for systems, applications and services are defined in part by service level objectives.

It's clear from the foregoing that any service level management initiative starts with eliciting business requirements. It's also clear that service level management is directly traceable to business requirements, which are driven by business imperatives, and the smallest unit in service level management is the service level objective.

There you have it: short and focused. That's not to say that it's easy - it's anything but. However, if you attempt to develop, implement and manage service level management processes without taking into account the definition of service level objectives, how they relate to business requirements, and their characteristics I'll predict failure.

In case I was too terse, or you want more information about service level objectives, I'll offer the following:

• Service Level Management Factors, which is a short paper I wrote in 1996. It's embarrassingly out of date and was hurriedly thrown together, but I'll trust you to take those into account as you glean useful information from it.
• Service Support Assessment, which is an assessment checklist in MS Word format. It has some excellent questions and forces you to examine the big picture. Tailor it to suit your own needs and save it because it's a valuable artifact for service level management practitioners.
• Commitment to Service: The Role of Service Level Management - an online paper that touches the key issues.

In the next discussion I'll continue up the vertical path of the model by discussing processes and organization.

Sunday, March 24, 2002

 
Posted by Mike Tarrani 4:57 PM
I just finished reading Doug Kaye's second issue of his IT Strategy Letter and am overwhelmed by the depth of analysis and array of topics covered. Doug is well-connected in the industry and is an insighful observer. Add the fact that he is an articulate writer who addresses topics that are of interest to consultants, IT managers and those in the trenches, and you'll understand why I listen to what he has to say.

Also out is the newest issue of Amy Wohl's Opinions. This newsletter is well worth reading, and for a limited time you can also read a special report on her web site titled Linux Comes of Age?