![]() |
![]() |
|
![]() |
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.
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:
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. ![]() |
![]() |
|