Wednesday, November 08, 2006

November 13, 2006


The use of commercial software products to fulfill all or parts of our Information Systems has been with us for some time. The 1970's marked the rise of such products, particularly in the banking industry. Now, thirty years later, you can find off-the-shelf software for just about everything from manufacturing, to order processing, to human resource management, etc. In fact, the trend (most notably in the United States) is to purchase commercial software and modify it for the nuances of the customer as opposed to developing whole systems internally. However, mixed results often occur. As one manager in General Electric recently told me, "My most recent experience, which is somewhat of a surprise, is that the new platform has less functionality than the 25 year old in-house system it replaced." In other words, his new "packaged" system now features state-of-the-art technology but doesn't adequately fulfill his business needs.

Nonetheless, commercial software packages can be a viable alternative for producing parts of an information system if applied intelligently. Whether to purchase a software package or build your own is often a difficult decision for companies to make. The purpose of this article is to provide evaluation guidelines when making this decision.


Packages are developed by vendors to provide general solutions to typical application areas and the package is usually described as being a complete information system. In reality, they are only tested computer programs or procedures that are sometimes accompanied by user procedures for input preparation. Because of this, the overall system, sub-system and administrative procedures may have to be added to convert a package into an information system before installation can be accomplished.

As with any other information system, the first objective must be to clearly define the business problem and information requirements. This sounds rather obvious but it is too often accomplished in a superficial manner. This problem is alleviated through the proper execution of "PRIDE"-ISEM Phase 1, "System Study & Evaluation."

During Phase 1, the project scope is defined, information requirements are specified, and a rough design of the overall system architecture is produced. When this is done, various approaches to implementing the system are now considered; e.g., build a new system, modify an existing system, purchase a package, or combinations of the above.

Failure to do this upfront work can come back to haunt a company. To illustrate, not long ago I was working with a major electronics manufacturing company in New Jersey who had purchased a Payroll system for a million dollars (which they considered cheap at the time). However, they had a devil of a time modifying it to suit their needs. Since they didn't properly define their information requirements or produce a rough design of what they wanted, this project turned into a nightmare. They ultimately spent another $2.5 million changing the package to suit their needs. Afterwards, they realized it would have been considerably cheaper to develop the whole thing in-house themselves.


The first step for Systems Engineering is to determine the availability of packaged products to solve the business problem. A list of packages may be created by reviewing the advertisements in various trade journals and by checking with publishers which provide lists of available products. Most of the listing services provide descriptions of each package that assist in generally determining if the package covers the required areas.

There is a variety of publications that routinely prints product descriptions of various software packages:


* CDW (Vernon Hills, IL)

* CompUSA


* IBM Products & Services



* SOFTMART (Exton, PA)

Computer hardware vendors are also an excellent source for information about software products.

When the prospective list is completed, each vendor is contacted for sales materials. It will be helpful to provide each vendor with the project scope and information requirements, then ask that they demonstrate how their package fits your specific needs. Systems Engineering should also provide the vendor with a list of other questions to be answered. These questions should be as specific as possible so they will be easily understood and properly answered by the vendors.

It is important to discuss the business problem to be solved and the information to be produced. Avoid telling the vendor how the product should be programmed, defining techniques to be used and other such technical requirements. There are many ways of implementing software and being too specific in these areas may cause you to miss an excellent solution for evaluation. Since the vendor is in this business and you are not, it is possible they may know something you do not. Some junior or inexperienced analysts sometimes write specifications only to showcase their knowledge of a subject which in fact may be very limited.

Some suggested questions are as follows:

1. What business problems does the product address?

2. What documentation is provided for the User (Administrative Procedures), Systems Engineering (general systems documentation), Software Engineering (program documentation) and DP Operations (specific to the organization's hardware/ software configuration)?

3. Will the documentation provided be customized to meet installation standards?

4. What normal hardware/software configuration is required?

5. What is the cost of the product?

6. Does the package provide sufficient Data Base information to interface with other applications? If not, can they be provided and at what cost (if any)?

7. What education is required and the costs associated with this?

8. What materials or forms are required and the costs associated with them?

9. What changes to the product are required to meet the Information Requirements furnished?

10. Does the vendor provide modifications to the product or at an additional charge? If so, what type of modifications are typical?

11. Is there any maintenance or other on-going charge for use of the product? If so, elaborate on each specific charge.

12. Are there any other costs involved with installing and operating the product? If so, elaborate on each specific charge.

Also, has the vendor supplied a copy of the contract and a list of references.

A matrix or chart should be prepared by Systems Engineering to graphically compare the various packages strengths and weaknesses. The product criteria, product implementation and vendor evaluation should be one part of the matrix/chart while the vendors are the other. Then a grading scale is developed. In doing so, consider the possibility that some items may be more important than others.

Product integrity points to consider are:

1. Flexibility of product in application.

2. Integration with other applications.

3. Utilizes (or is adaptable to) organization standards.

4. Warranty.

5. Features.

Product implementation points to consider are:

1. Easy of use.

2. Not be an administrative burden.

3. Have wide acceptance in the industry.

4. Have an effective implementation program.

5. Easy to install.

6. Have organized reference and instructional materials.

7. Provide for vendor consulting to assure the proper use of the product.

8. Easy to maintain after initial implementation.

9. Have a standard bill of materials and services.

10. Have a well-defined maintenance program.

11. Have an effective "hands-on" training program.

Vendor evaluation points to consider are:

1. Have a good corporate reputation for reliability.

2. Have a professional attitude and a high credibility rating in the industry.

3. Reflect financial stability.

4. Provide for a staff with in-depth knowledge and background.

5. Provide for professional corporate facilities.

6. Be able to provide for a demonstration of the product.

7. "Practice what it preaches" - the vendor uses the product themselves.

8. Have an intimate knowledge of their products.

9. Be totally committed to the support of the product.

10. Provide additional services to support the product.

11. Easily accessible and available to its clientele.

12. Maintain effective communications with users.

13. Have long range plans for the support and development of the product.

14. Have long range corporate objectives.

After the materials are received from the vendors, Systems Engineering should carefully review all items provided. Delete vendors from the prospective list if their package does not even come close to satisfying the requirements. Then contact some of the references for the remaining vendors. When calling a reference, ask specific questions. Have a list of questions prepared before the call and carefully record the answers either during the call or immediately after the call is completed.

Some suggested questions are as follows:

1. Does the product perform as stated?

2. Did the vendor provide file layouts or do they have some other means to conveniently interface with the product?

3. Was the documentation as complete and correct as stated?

4. Did the product require more, less or about the same amount of modification originally planned?

5. Does the product require an inordinate amount of maintenance?

6. When a problem arises, does the vendor service the problem?

7. If the vendor services the problem, is the response prompt?

8. Who executes the required modifications?

9. Were there any problems encountered during implementation? If so, what were the problems, how were they resolved and by whom?

10. Is the customer generally pleased with the product?

11. Was the cost of the product as stated or were there hidden costs (elaborate)?

12. Would the reference allow your organization to visit their site to see how the package is operating?

After the preliminary investigation, the findings are reviewed, the list of prospective packages for further study is prepared and the matrix/chart is updated. Each of the remaining vendors is contacted and a sales presentation is scheduled. Each vendor should be asked to supply their documentation for evaluation, either privately or in the presence of their representative. It is often best to review the documentation with a representative present since questions can be answered as they arise.

One very important and often overlooked point to consider is in the Data Base area. A clear definition of elements is essential, otherwise, reports produced from the package will be meaningless. Quite often, the vendor's description is different from that of the purchaser, e.g., "ORDER DATE" could mean the date an item was ordered by the customer, the date the order was received, or the date the order was processed. There are three choices at this point.

Since the package is used to implement the system, it should be documented like any other system, hence it is a consideration in the selection process. The System, Sub-Systems, Procedures, Operations, Inputs, Outputs, Files, Records and Data Elements are required to be documented using the organization's standards.

When a sales presentation is scheduled, Systems Engineering should assure that all appropriate decision making personnel will be present. This group would include selected Users, the project team, Systems Resource Management, Data Resource Management, and DP Operations.

During the sales presentation, carefully review all of the material presented. Be prepared to resolve all possible questions during the presentation. After the formal presentation, carefully review the product documentation. Make use of the checklist to determine the completeness of documentation provided by the package and which components must be developed or supplements prepared in-house.

After the sales presentation process is completed, the findings are again reviewed and any unqualified packages are removed from the prospect list. Now Systems Engineering must evaluate which of the remaining packages will best fit the User's needs. It would be a good idea to have the users involved in this process and any presentations that are conducted.

When this process is completed, Systems Engineering and Project Management prepares a "make versus buy" comparative analysis. This becomes the basis for the purchasing decision.

When approval is received, the Purchase Agreement should be reviewed by the organization's legal counsel. Since this review process may take a reasonable length of time, agreements should be submitted for review as early as possible. Remember that the agreement must state specifically all of the items that have been agreed to by both parties. Most contracts state 'this is the only agreement between the two parties and all other agreements either verbal or written are not valid'. Obtain legal assistance with this part of the agreement preparation.

It is important that the agreement contain a complete "bill of materials and services" that accompanies the purchase of the product. This lists the specific materials that come with the product, e.g., manuals, forms, object code, source code, etc., along with the services provided, e.g., training and consulting. This list eliminates any confusion as to what exactly is to be delivered by the vendor and points out any hidden costs.

The package payment schedule should coincide with the delivery of the various parts of the package and the installation process. To assure the schedule is followed, the agreement should stipulate periodic review points where all concerned can discuss progress and assess project status. All of this may, on the surface, appear to be too much control, however, this is identical to the control expected for 'in-house' development.

As with any other newly implemented Information System, an audit should be executed to assure that the product performs as expected and the economic benefits are realized. The audit report should analyze the estimated development costs versus the actual costs.


The decision to purchase a package to reduce development time and costs, can produce satisfying results for a company if it does its homework and goes in with its eyes wide open. If it doesn't, disaster will inevitably follow.

Today we are hearing a lot about On-Demand computing and SOA (Service Oriented Architecture) to implement whole systems for companies. It all sounds nice but I do not see how it is any different than purchased packages. As such, companies should treat today's SOA solutions in the same manner as mentioned above. A package is a package, regardless if it is purchased "off-the-shelf" or implemented via a third party on the Internet.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"An elegant solution to the wrong problem solves nothing."


Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at:


The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at:

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to


We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:


Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.


Boy am I glad the U.S. midterm elections are over. I never saw so much eye pollution as I did recently in the American television ads. I think I saw more attack ads than ads describing what the candidates actually stood for. There was more misinformation than anything else. So much so, that the public didn't know what to believe.

Something else that bothers me is the phrase, "I'll fight for you." This really hints at the divisiness of the country. Do we really need a lot of fighting or do we need some calm logical discourse to work through our problems? If you listen to the ads carefully, you would get the impression that America is at war with itself. Maybe we are and just don't know it.

Instead of the negative sound bites on the television and the spin by the media, I wish we had nothing more than a profile of each candidate listing their credentials, their record, and where they stand on the issues. It seems to me that the only ones that capitalize on today's campaign advertising is the media.

I also wish the media would keep their opinions to themselves and let the voters decide for themselves as opposed to influencing us.

Down in my neck of the woods, we have the St. Petersburg Times, a large and powerful newspaper. I don't agree with most of their editorials. Frankly, I think they are way out in left field. Nonetheless, prior to each election they publish a box in their editorial section listing their endorsements and recommendations for how we should vote. I dutifully cut this box out of the newspaper and take it with me to my voting precinct. It make an excellent reference for how to vote. Everything they recommend, I vote against.

Like I said, I'm greatly relieved the elections are over; now I can get back to watching all of the drug and car ads on TV.

Such is my Pet Peeve of the Week.


Folks, we've just released a new book on management entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

We have also just produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

While there, look for our new MS PowerPoint presentation describing both the book and the training program.


I received an e-mail from a Martin Dimond in Ohio who wrote me regarding last week's essy on "Methods of Processing."

Martin writes:

"I am having problems digesting your concept that all processing involves the use of transactions. Can you please explain this further."

Thanks Martin for your note,

First, understand this, "transactions" does not mean old technology. We have been recording transactions well before the advent of the computer in such things as journals and spreadsheets. Basically, we're trying to record any significant event in a process. Perhaps the best way to think of a transaction is when we record product orders, shipments, and the debits and credits in a bank account. Interactive processing has clouded the issue somewhat, particularly in the area of graphics, multimedia, and video games. Nonetheless, they are all processing some type of transaction the moment we record the event in part or in full, be it a score, a sound bite, or a graphical shape, Not all transactions come in ASCII text form, some are done in binary.

Consider this, the concept of "Undo" would not be possible with the concept of a transaction.

Again, Thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."



Post a Comment

Subscribe to Post Comments [Atom]

<< Home