Paradox Community
Search:

 Welcome |  What is Paradox |  Paradox Folk |  Paradox Solutions |
 Interactive Paradox |  Paradox Programming |  Internet/Intranet Development |
 Support Options |  Classified Ads |  Wish List |  Submissions 


Paradox Solutions  |  Paradox Case Studies  


Change Partners: A Technology Dance
by Dennis Santoro
© Copyright 2000, by Dennis Santoro. All rights reserved.
Please see use restrictions at the end of this document.
A downloadable pdf version of this document is available on the Paradox Resources page at RDAWorldWide.com.


"Your database software no longer conforms to the corporate standard. You must either justify your existing database or switch to the corporate standard immediately."

Most of us have had the experience of hearing this, or variations of this (and not just regarding database applications). It may be that the company has recently swapped software standards. Or perhaps there were no previous standards. Especially over the last several years, as Microsoft products have squeezed out other software products, this has become a common experience.

Frequently these "standards" decisions are made for the benefit of corporate management or the IT department’s convenience. Just as frequently they are made without any rigorous analysis of the standards selected and how such standards will benefit the organization and its ability to achieve its mission. More often than not it translates into "we are switching to Microsoft’s product line." Often it is being done because "no one ever got fired for buying Microsoft" just as in the 1970s and 80s the common refrain was "no one ever got fired for buying IBM." This was not a good justification for standardizing on IBM then, as history has shown, and isn't a good justification for standardizing on Microsoft, or any other company’s products, now or ever.

Standards can be very useful to an organization, and do have their place. However, standards should be selected based on an analysis of the organization’s needs, not on the current market conditions in the software industry. Although the latter may be one factor to consider, it is rarely a critical one for an organization. Regardless of the standards selected, there should be careful consideration of possible exceptions to those standards for certain cases in future development efforts. Even more importantly, there should be careful consideration before the application of those new standards to existing systems.

Frequently, once a standard is selected, existing systems and their organizational owners or sponsors are presented with an ultimatum to justify their existing system or switch to the standard. Such pronouncements are clearly in the interests of the decision makers who determined the standard. It helps them consolidate their decision and justify it. Since it is usually the IT department that makes such decisions, it allows them to reduce or redistribute resources by narrowing their training and support needs (internally to the IT department and to the organization) and by denying support to groups using "non-standard" systems. Such pronouncements may not be in the best interest of the organization itself or its ability to achieve its mission, however. Further, in the context of existing systems, especially ones which are functioning adequately or better, and with which users are reasonably satisfied, it is exactly backward to the approach that should be taken.

This is an amazing switch from the way most organizations make changes. With almost any other change, those proposing the change are required to justify that change over maintaining the status quo. But with technology, the reverse is often accepted; maintaining the status quo must be justified rather than the change. This is largely because of external conditions promoted by hardware and software companies. These companies have managed to convince people and organizations that older, but working, technology must be replaced regularly with newer, less proven technology simply because it is newer. Somehow "newer" is supposed to be better, even when it is unproven, and when the "older" works, and works well. While this benefits the technology companies’ bottom lines it often does so at the expense of the organizations that buy into these frequent upgrade cycles.

In the context of applying standards to existing systems built on other technologies, even assuming the standards were selected through a reasoned needs analysis, other criteria apply. The choice and implementation of standards involves more than just questions of technology. Organizations should not be driven solely by the IT department any more than they are by the Accounting, Production or Marketing departments. So rather than go on the defensive or accede to such dictates, organizational owners of working, but non standard, systems should turn the tables. This is actually in the best interest of the organization.

Owners of existing "non-standard" systems should ask the sponsors of the new standard for a written analysis which includes most or all of the following.
  1. What is not working adequately in the existing system and how would a switch to the new standard make it better?


  2. What resources are the proponents of the new standard prepared to spend on the change?


  3. What commitment will they make that those resources will actually be provided?


  4. Will that commitment and those resources be sufficient to provide a system that exceeds the utility of the current system?


  5. How do the proponents of the new standards propose to demonstrate that their numbers and estimates are reliable?


  6. How do the proponents of the new standards propose to test the two systems to prove or disprove their predictions, and what penalties they propose to accept in the case that they are incorrect in any or all of their predictions.


  7. What training resources do they propose to provide to get your staff up to their current functional level with the existing system?


  8. Why would the resources for development and training not be better spent on improving the existing application?


  9. Will the expenditure justify itself in return on investment in comparison to the existing system?
Make sure this analysis includes quantification. For example, if they say the new system will be faster, have them indicate in what areas and functions, by how much and how they can demonstrate this. Make sure they create a good specification document (based on your system) or use the one from your current system if such a specification document exists. If good specs are not already available much of the cost will go toward defining them. This is an essential part of the development process. A good plan, and the developer's clear and thorough understanding of the organization and its processes, is essential to a successful project. To illustrate this, recently The Standish Group, of West Yarmouth, Massachusetts, USA, published a study (as reported in InfoWorld on Mar. 5, 2001) which states that:
31 percent of software projects are cancelled before they ever reach a customer's hands, and 53 percent ultimately cost 189 percent or more of their original budgets. Software projects that do get completed by the largest American companies typically retain only about 42% of the features that were originally proposed. The primary culprits are bad requirements.
I have to agree this sounds quite reasonable. Had they included a representative sampling of small to medium size companies I expect the numbers would have been far worse.

In addition to the justification that should be provided, make sure you do not give up a working system until a new system can be shown to at least have all the functionality of the current one. Generally the new system should not only have that functionality but should, in some way, be an improvement over the existing system. Further, the switch must not reduce your productivity but rather improve it within a reasonably short period of time.

Remember, the end goal of technology systems should be to improve your organization’s ability to meet its goals. If moving to a standard or switching an existing system for a new one will help then it is valuable. Otherwise it is not. It is the proponents of the change that should justify that change, not the owners of existing, functioning systems who need to defend the current situation.


Thanks to reviewers Larry DiGiovanni, Neil Krull, Elmar von Muralt, Nathanael von Muralt and Peter Zevenaar for their valuable contributions.

Conditions of Use and Reproduction:

This content in this paper is provided as is, with no warranties, guarantees, or claims regarding its accuracy, completeness, or usefulness. While all efforts have been made to ensure its quality and accuracy, you are solely responsible for your own use of this information.

Any statements of fact contained in this article should be interpreted as the opinions of the author, which may or may not reflect the opinions of any other entity involved in the transactions that led you to this article.

You may not distribute this information unless you meet the following conditions:
  1. You obtain the permission of the author prior to such use including the specifics of what use is requested, any compensation you expect relating to use of this material. Any permissions will be deemed to be granted only for the use specifically agreed to in the document granting permission and only for the time period designated in said grant of permission. (Contact can be made via e-mail at RDAPermissions@RDAWorldWide.com. Please allow sufficient lead time).


  2. All content (including this statement of conditions of use and reproduction) is provided completely unchanged.


  3. Any additional conditions contained in any grant of permission are met by the user prior to any such use.
Commercial distribution can be arranged by contacting the author.

Feedback is strongly encouraged, especially constructive criticism and/or typographical/syntactical corrections. Response or action is left to the discretion of the author. Flames, abusive language, unsolicited commercial email messages (aka SPAM), and other forms of rudeness will be cheerfully ignored. Professional responses will receive priority attention. Unprofessional contact will be ignored.

All trade names, trademarks, and service marks are acknowledged as the property of their respective owners.


Discussion of this article


 Feedback |  Paradox Day |  Who Uses Paradox |  I Use Paradox |  Downloads 


 The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation.
 Paradox is a registered trademark of Corel Corporation.


 Modified: 15 May 2003
 Terms of Use / Legal Disclaimer


 Copyright © 2001- 2003 Paradox Community. All rights reserved. 
 Company and product names are trademarks or registered trademarks of their respective companies. 
 Authors hold the copyrights to their own works. Please contact the author of any article for details.