A quarterly newsletter for clients and friends of Chenault Systems
Three new major clients have been added to the Chenault Systems client base during the last quarter. Bristol Hotels and Resorts, Marfield, and Mobil Oil Corporation are now using Chenault Systems for consulting and systems development.
Computer consultants define the year 2000 problem as "the inability of computer programs to correctly interpret the century from a date which only has two year digits." For example, suppose a bank sets up a 5-year car loan for a person on March 12, 1998. The bank's system calculates the expiration date to be March 12, 2003 and sets a reminder to stop debiting payments from that person's checking account after that date. If the bank's system was not changed, on March 13, 1998 (the next day), the system will think the expiration date of 03/12/03 has passed, interpreting as March 12, 1903, and quits debiting the person's account.
Year 2000 was the least of our problems twenty years ago. In the past, when mainframe high storage costs were an issue, only two digit years were used. Actually, date arithmetic has always presented challenging problems to systems analysts, regardless of the year.
With the new millenium approaching, the old date problems will look simple. In addition, for those of us who have been around for awhile, the year 2000 problem will be worse than estimated. In this industry, problems are always underestimated. So far, it has been estimated that the international cost of fixing the Year 2000 problem will be about 500 billion dollars.
This is not easy to justify to upper management, since upper management never likes to spend money unless there is a tangible benefit. We all know that it is not be the first time upper management could not see the long-term effects of keeping the company alive. Many of us have this difficulty.
The two-digit year has been a part of our culture for nearly 100 years for checks, application forms, driver's licenses, etc. When was the last time anyone in business or school wrote 11/16/1997? People write 11/16/97. It was only natural for systems designers to use two digits instead of four; processing two digits was faster and required less disk storage. Unfortunately, dire consequences could be the result to this thinking.
There will be many other problems. Consider the amount of unexpired prescriptions that may be unnoticed by doctors and hospitals on January 1, 2000. How about electrical service is being cut off to thousands of homes because the public utility lacked the sense of urgency to fix this problem. The telephone companies will be busy. If you start a telephone call at 11:59 PM on December 31, 1999 and end it at 12:01 AM January 1, 2000, will you be billed for 2 minutes shy of a negative 100 years?
Simple calculation modifications might remedy the problem for some systems. They could be altered to assume any year, for example, 65 or greater belongs to the twenty century, while 00 through 64 belong to the twenty-first, and change calculations accordingly. This would allow the system to work without changing data entry screen or data storage methodology.
For many systems this concept will work, and the issue is resolved until 2065 for our example. Then what? We find ourselves dealing with the same problem again; only this time the problem must really be resolved. Furthermore, this solution does little to help those systems which have dates stretching back to nearly the first of this century, such as with the case of birth dates.
Desktop systems (PCs) and their installed software will greatly help with the year 2000. Much of the software found on PCs is provided by outside vendors and is often upgraded by them in order to stay competitive. Modern software vendors, such as Intuit (Quicken), Microsoft, Oracle, Sun, etc. will provide the enhancements to ease the user into the next century as part of their normal upgrading process. There will be exceptions of course, but you can bet that these companies will not let this issue slip.
The main problem will be with the old, internally written programs, many of which reside on mainframes. Many years ago, before PCs and third party software, the hardware companies supplied rudimentary software with no competitive incentive to provide for year 2000. Back in the 1970s, no one anticipated that a system would be used for 20 or more years. And if so, no one expected to be around that long, so they would not have to face the problem - another problem will be with custom built software systems on mainframes and PCs, the authors are often not available for consulting.
Many do not realize how important this problem really is. It will effect the entire world economy. Every industry and country is related to each other in some way. The larger mainframe or networked systems will have software changes made on weekends because they cannot be taken off-line during the week. There may not be enough weekends left. We believe modifications should be completed by the end of 1998 to allow for at least one year of testing and changes.
Now that our consulting practice is over five years old, we have developed a pattern of attributes associated with successful consulting engagements. These observations have led us to come up with the following conclusions on how to approach a project using outside consultants.
Define the project in terms of return on investment. We make sure that the client will benefit in terms of return on investment, or we simply will not embrace the project. If the client is not sure, in business terms, of the expected returns of a project, then the project will not be a business success.
Recently, we helped a client save $1.5 million per year in long distance telephone cost - his pre-project estimate. The client knew the return on investment and savings before the project began. Our fee of $16,000 could seem high to some prospective clients, but quite reasonable to this client who already did the homework.
Good consultants will not take a project unless they perceive a reasonable return on investment, both in terms of money and reputation. The money fuels their business by making more training, experienced personnel, marketing, computer hardware, and software possible. The reputation provides more business opportunities.
Understand expectations and make sure they are realistic before any work takes place. Reliable, accurate estimates regarding the scope of the project are necessary. Calendar deadlines should also be realistic. You should be wary if a consultant makes unrealistic claims in terms of low estimates or short timetables.
It is not uncommon for a client to underestimate manpower or time requirements for a project. Good, independent consultants are unmoved by political pressure to pursue impractical deadlines. They will fight for reasonable manpower and timetable estimates; and if the chasm cannot be bridged, withdraw from the engagement rather than suffer the consequences for accepting an impossible task.
Maintain constant communication with the consultant. Successful projects seldom develop in a vacuum. Many projects fail because the client did not make at least one person with a good understanding of the project's goals available to the consulting firm for questions and guidance. Many projects fail because consultants assume they know better how things should be done, and will not pursue the client's advice.
Make sure the consulting firm has reasonable experience and rates. This may seem an obvious point, but there are too many pending lawsuits where consulting firms have not delivered what was promised.
Some larger firms have resorted to inexperienced personnel and inflated rates. Recently, a very large consulting firm was sued for $100 million for breach of contract and fraud. The client felt that the large firm "oversold, overcommitted and underperformed, and didn't have the technical competence or the experience that it represented it had. As a result, the project was doomed from the start." The large consulting firm may lose this lawsuit, since their inexperienced staff left electronic mail messages to co-workers indicating their inexperience.
With this in mind, smaller firms should be considered. They are often staffed by seasoned professionals who are tired of the rat-race associated with the larger firms. Smaller firms normally do not have the larger economic appetites associated with the larger firms, where additional overhead and high partner salaries are the rule, not the exception.
"In general, the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire (1694-1778)
"It is difficult to get a man to understand something when his salary depends upon his not understanding it." -- Upton Sinclair
|
Chenault Systems, Inc. |
(972) 306-3839 Voice |
E-Mail: Chenault Systems,Inc.
Copyright © 1998-99 by Chenault Systems, Inc.
All rights reserved.