Best Practice = Best Skills + Best Processes + Best Solutions + Best Resources + Continuous Improvement

You have just been hired at an IBM i shop. You are the new kid on the block, and they have assigned you the project of searching for a particular tool that fits in the application development realm. I am not going to be specific here; the application could be change management, help desk, security, cross reference, or any other of at least 20 different categories. The big question is where to start.

Our first instinct is to rely on our previous knowledge, comfort level, and experience with tools that we have worked with in the past. Another common source is querying our friends and colleagues for their recommendations. Is this the best way to go? It is definitely a good start, but maybe we should employ some best-practice methodology to our search.

What Is Best Practice?

Today, the term "best practice" seems to be a common headline in our trade journals. Is this just a current buzzword, or is there any real substance here? I went to the source to find out. Wikipedia defines "best practice" as follows:

Best Practice asserts that there is a technique, method, process, activity, incentive, or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. The idea is that with proper processes, checks, and testing, a desired outcome can be delivered with fewer problems and unforeseen complications. Best practices can also be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people.

One of the global resources in IT best practices is Information Technology Infrastructure Library, or ITIL. Before you think, "This is crazy. I don't need certification to look for a tool," you may want to review some of the information available in ITIL.

ITIL is a framework of IT best practices that has something for everyone. You will find that there are two versions, ITIL V2 and ITIL V3. They title the areas differently but cover such things as application management, software asset management, security management, and more. Adopting an ITIL discipline is a culture shift for many organizations. Your focus will change from the technology to the service that it provides.

An example might be that you are choosing an incident-tracking tool. Your organization may not have a formal process in this area; requests are made of you while you are walking down the hall. ITIL suggests that there be a recording of the incident so that it is not lost or forgotten. ITIL also suggests that the incident or request be serviced in a timely manner in a way to restore business operations. Therefore, in looking for your tool to provide incident management, you would want it to have a framework that fosters these service improvements.

What Are Our Resources?

Today, we have at our fingertips an abundance of information.

• Just putting a keyword such as "Best Practices definition" into Google gives us over 9 million results. Google "Change Management," and there are over 97 million results.
• Our electronic trade magazines, such as MCPressOnline.com, typically have buyer's guides with vendors listed by tool category.
• Each day in email, we are invited to attend both free and fee Webcasts. If we are unable to attend the Webcasts, recordings are often available.
• Attending national (COMMON) and local education events where the vendors have display booths allows us to get brochures and talk to the vendors.
• The vendors' Web sites typically provide case studies so we can view other organizations' successes.

What Steps Are in the Process?

Is there a magical number that will allow us to be successful in our application development tools selection effort? We are bombarded with articles on the "seven keys" or "six myths" or "ten steps." Since my wizard hat seems to have been misplaced, here are some methods that you may want to employ in your selection process.

• Do a needs analysis. Create a list of features and functions that are necessary for your organization. This should be the basis for the evaluation. If you do this in spreadsheet form and send it to vendors, you will be able to do a side-by-side comparison with the results. Some of the requirements you may need to consider might be integration, languages, APIs, modern technology, cross platform. Others might be compliance-related, such as SOX or HIPAA.
• Do some window-shopping. Obtain the vendor's brochure and dig the meat out of the marketing literature. You don't want the wrong tool for the job.
• Create a Request for Proposal (RFP). This should include no more than five vendors. Typically, this is done when the dollar amount of the purchase exceeds a certain figure ($50,000 for example) or in industries where this is standard practice, such as the government. The RFP then becomes the basis for the contract.
• Arrange for product demos. Many vendors can provide a live demo over the Web to show you features and functions in their product. This is presented by a real person and allows for interactive discussion of your specific requirements and environment. Some vendors have a demo that you can download and watch at your convenience, and others have a recorded demo that you can try on the Web.
• Try before you buy. A Proof of Concept (POC) may be warranted, particularly if you have unique requirements. Most times the POC is paid for by you, the buyer, up front but may be negotiated as a discount if you buy the product.
• What is the bottom line? You need to consider the return on investment (ROI) so you can convince management that this is a good solution.
• Identify potential risks. What is the impact on the organization? What is the viability of the vendor? How much more hardware might be necessary to run the software? Is there available talent either in your organization or in your area that has worked with this product?
• Check contracts. Understand licensing. Are there per-seat costs? What are the maintenance costs? Do you get the source code? Will the vendor escrow the source code in case they go out of business? Can you readily move the product to another machine? If there is a disaster, what are the procedures to run the code on a temporary machine? How many upgrades a year? What is the method of receiving upgrades?
• Is training available? What is the documentation quality? Can you see an example before you buy?
• Test-drive the vendor's tech support line. Some software contracts today are email questions only.
• Get references. Talk to other customers. Find out if there is a local users group for the software.

Best practice is methodology that produces outstanding results. Whether you employ one or all of the techniques mentioned, as long as you have a process that is reasonable, you will most likely be successful.

Acquiring the tool is only the first step in applying best practices. You now need to have a measurement process that validates your decision. There is nothing worse than spending that very hard-to-come-by capital in the IT budget only to have your tool become shelf-ware.

Good luck to you in your endeavor.