The word "software" is widely used and most people think they understand what it is, but most business executives and managers are, in fact, seriously ignorant and often make seriously bad decisions about software based on this ignorance. This article seeks to address this issue by presenting the basics in language that business executives and managers can understand
<<< PREVIOUS SUB-SECTION: Standards for Custom Software Specification
NEXT SECTION: IT Effectiveness >>>
What is computer software?
And what determines the sustainability and maintainability of business software?
In recent weeks I have been engaged in several discussions with clients with regard to issues of sustainability and maintainability of business computer software.
Accordingly it seemed appropriate to write a short document to outline what computer software is and what determines its maintainability and sustainability.
The critical components of business computer software – what is software?
The following items comprise the critical or primary components of a computer software solution:
1. Conceptual design and logic that models the real world
1. Conceptual design and logic that models the real world
A fundamental requirement for easy to use and easy to maintain software is that it must accurately model the real world.
For this reason there is a lot of merit in making use of software that is customized for a particular situation where that situation is unusual relative to common or widespread practice.
The conceptual design is reflected in text and diagrams which explain how the software will work in practice.
2. Data tables (databases)
Data tables are simply lists of information. Metaphorically they can be compared to filing cabinets and to files within filing cabinets. Well organized filing cabinets are easy to use and to retrieve documents from, jumbled, cluttered and badly maintained filing cabinets are difficult to retrieve documents from.
The same physical cabinets and folders can be used in both cases.
Computer databases are exactly the same. It is possible to use the same tools and technology to create data tables which are filled with jumbled data or which are filled with neatly ordered data. It is a function of how the filing scheme is designed and operated, NOT a function of the technology.
In designing a software solution it is vital that the data tables are designed in such a way that they accurately model the real world, this is called an “Entity Relationship Diagram” or ERD and defines the relationships between different logical entities such as projects, people, etc.
In order to facilitate maintenance and therefore sustainability it is vital that naming conventions should be applied that reflect the purpose of the table, e.g. “Project_Master_File” is much easier to understand than “P01” and that the fields or columns in the tables are also named in a manner that facilitates ease of understanding, for example “Project_Number” is much easier to understand than “P#”.
When building new software a set of naming conventions should be defined before anything is created and these should be rigorously adhered to in creating and maintaining the software.
When seeking to increase the robustness, sustainability and maintainability of existing software existing conventions should be identified to the extent that they exist and then documented and rigorously applied thereafter.
The more understandable and consistent the conventions the easier the software is to maintain. If it is easy to read and understand the documents and the source code it is generally easy to maintain it. The less understandable the conventions and less consistent the application of the standards the more difficult the software is to maintain. When we are confronted with information that flows with our understanding we digest it easily, when it does not “make sense” and we have to struggle to decipher what is being said, we “chill out” and struggle to operate effectively.
“I do not understand computers” can frequently be translated to mean “what I see here does not make any sense at all, you tell me it works but I cannot see how it works so I chose to reject it OR I chose to trust you” – in the latter case when it does not appear to work then it is very easy to abdicate and trash the system because the “you” clearly cannot be trusted or does not know what they are doing.
In simple terms, most published books and formal white papers and even newspaper articles are subject to review by an Editor who reviews and revises the document to make sure that it is easily understood, easy to read, makes sense, does not accidentally communicate the wrong message, etc. Thus, easy to read books are easy to read because the author AND the editor went to a lot of trouble to make them easy to read.
I forwarded the draft of this document to a number of people whose opinions I trust and got feedback that enabled me to improve the readability and other aspects of the document.
Software documentation, comments, etc are subject to the same human constraints. The comments make perfect sense to the person who wrote them as they were writing the software but they do NOT necessarily make sense at all to a third party reading them months or years later or even the same day if they are not fully informed about what the software is supposed to do.
When creating new software the table design should be comprehensively thought through and documented BEFORE work commences on building data tables.
4. Screen forms and maintenance forms
Maintenance forms are simply the screen layouts that are used for capturing data into data tables or viewing the data in the tables in order to execute procedures, etc.
A maintenance form can be very simple or very complex, in broad terms three levels of complexity are easily recognized and impact the ease of maintenance of a screen form.
A screen form that is laid out in a way that logically follows the workflow that will be applied by a human being sitting in front of the computer will be easy to use and therefore might be dubbed “user friendly” whereas a screen form that does not correlate with practical reality will be found to be “unfriendly”.
In applying the concept “user friendly”, it is important to recognize that we live in a world of devices and machines that are not in fact that friendly. A motor car is not user friendly the first time one sits behind the steering wheel, particularly if one has never seen a motor car before. But we learn to use them nonetheless.
In designing software screen forms should be laid out in detail in a spreadsheet with comprehensive documentation of what happens on the form BEFORE any work begins to create software. These prototype forms should be reviewed with the client and refined until there is a clear understanding of how things will work. The design of the forms can also impact the design of the database tables and other elements of the software design.
Use of a spreadsheet allows major changes to be made easily and allows the human beings who will have to interact with the software to get a good understanding of the logic of the screen designs before effort is devoted to creating the forms in development technology. While there are development environments that claim to offer ease of changes to screen layouts there is still merit in laying out screens in an easy to edit environment first.
Software with well designed screen forms will be easier to maintain than software with badly designed screen forms. In this case also naming conventions, neatness of working, etc are vital.
5. Configuration settings
In all but the simplest software there will be configuration settings.
This is particularly the case in “off the shelf” systems that require considerable configuration.
A single configuration value or “switch” can cause software to behave significantly differently by turning on or off certain functionality in the software.
It is vital when using software that is designed for multiple deployment situations to fully understand the implications of configuration settings.
Badly configured software can be a nightmare to use and maintain whereas orderly configured software can be extremely powerful. One badly configured logical switch setting can make the difference between an appropriate software solution and an inappropriate solution. The problem is not the software, it is the setting.
In large integrated systems where modules post data to and from other modules the configuration can become extremely complex.
In such situations the concept of “precision strategic configuration” becomes vital. This is a subject for another memorandum as this document is focusing primarily on custom software.
6. Computations, procedures, logical working steps, etc
Throughout a piece of software computations, procedures, logical workings, etc will be encountered.
This can range from very simple “Field Entry” and “Field Exit” procedures which are executed when screen fields are entered or exited to very complex computations and procedures which are executed when certain menu options are selected or buttons on screen forms are clicked.
The design and construction of computations and procedures, as with the points discussed previously, can be done in orderly and systematic ways with clearly defined rules, standards and conventions which make them easy to write, test, maintain, etc or they can be designed and built in ways that are scrappy, with no or inconsistent standards, etc.
Ideally any computation, procedure or way of working should be written first in “Structured English” or “Pseudocode” and then the computer language instructions should be written in between the structured English which should be retained in the form of comments which explain how the software works.
Such computations, procedures and logical workings make use of variables which are simply named logical entities in which values of data are stored. As with field names and other components of software design there should be clear naming conventions so that when the programming instructions are read it is easy to understand what the computation, procedure or logical working is actually doing. This makes it easy to write in the beginning and also makes it easy to maintain.
Everything that a computer actually performs is stored and executed in “Binary”. Binary is simply “0” or “1” (naught or one). What we see in English or other human language is simply for ease of use by human beings. Before these English words like “IF”, etc can be acted on by the computer they have to be converted into binary “00110101”, etc.
Thus from a computation perspective it is entirely immaterial what programming language is used to create a particular piece of software. Some languages have richer functionality for particular types of computation than other languages. Thus the language is purely for the use of the human beings who program the computer. Accordingly provided a company is willing to invest in training programmers to use a thirty year old programming language there is absolutely no reason not to continue to use thirty year old software. The only reasons to change are fashion and an unethical tendency on the part of the computer industry to force customers to change software which is working perfectly well.
Insofar as source code is therefore “instructions for the bricklayer” in much the same way that building drawings are instructions for the artisans building the building it is reasonable for the client to receive a set of source code subject to reasonable contractual guarantees with regard to confidentiality, commercial exploitation, etc.
Well written computer software that performs a valid and valuable task can be retained indefinitely subject to some limited constraints which have more to do with unethical conduct by the industry than they have to do with any technical considerations.
Badly written software can be a nightmare to maintain and in extreme cases it may be found easier to write new routines from scratch than to try and sort out badly written code.
There are plenty of guidelines with regard to good practice with regard to the writing of code and any formally trained software developer today should adhere to a set of standards that produce good code.
As a guideline no block of code should exceed more than one A4 page when printed in ten point font and use should be made of sub-routines / objects / procedures to break large blocks of code into easily maintained blocks that perform specific pieces of work.
Code writing conventions should also include use of indents, blank lines, comments, etc in order to be easy to read.
Well written code is easily recognized and so is badly written code. In both cases a non-technical viewer should be able to form an opinion as to the quality of programming instructions quite easily.
Configuration control during maintenance, proper recording of changes – by whom, when, for what reason, etc should axiomatically be applied.
7. Content -- validation lists, taxonomies
Creating well designed data tables, maintenance forms, program code, etc is not enough. It is necessary to capture the logic of the business in validation lists, such as “Project Type”, “Chart of Accounts”, etc in such a way that the logic of the business is accurately reflected.
Such content can be well designed and maintained and well structured in which case the software will be experienced as easy to use or it can be badly structured in which case the SAME software will be experienced as difficult to use.
This is in itself a vast subject, please contact me for a copy of a PowerPoint presentation on the subject of data taxonomies.
Software that is difficult to use because of badly designed taxonomies can be drastically improved by redesigning the taxonomies.
In broad terms, taxonomies that are carefully designed to make sense from a strategic management perspective will make sense at all levels of the organization. Such taxonomies will support high quality executive strategic, operational and tactical inquiry and reporting and therefore high quality decision making that supports “thrive” decisions. Thrive decisions are decisions that enable the organization to be better at the essence of what it does and how it thrives.
Axiomatically, in order to obtain strategic executive level information out of a system it is necessary to put strategic executive level information into the design of the taxonomies and code schemes. This requires a strategic architect who can operate at the executive level to engage with executives and senior managers and facilitate the discussion and resulting design with strategic executive goals in mind.
Leaving taxonomies to mid-level staff and managers will result in, at best, an operational view of the data and an operational taxonomy that will not fully support strategic decision making.
Not having taxonomies at all, such as having a chart of accounts which is more or less / sort of / roughly / maybe alphabetic and which bears no relation to modeling the real world guarantees that business users will not understand the system, that posting accuracy will be low and that at best the software will be clumsy and awkward to operate. This will result in ongoing high support costs with regard to the writing and maintaining of management reports, management reports for different users that do not agree, reports that do not reconcile and, in the financial domain, long visits by auditors and high audit costs.
Such poor configuration will frequently be evidenced by staff keeping their own statistics in Excel, battling to get answers to questions, etc. All of these items appear to point to a need to replace the system, don’t they? In FACT they do NOT.
All these consequences of deficient taxonomies result in software appearing clumsy and expensive to use when the problem is with the lack of logic in the master data and validation data. Take the same software and reimplement it with exceptional taxonomies to the sort of standards that I advocate and you will achieve a high value outcome at much lower cost than buying a new system. The implementation must also be properly executed.
If the software is reasonably well designed and maintained and you are able to tailor the software to your exact needs then a high value outcome is guaranteed.
I have seen badly designed implementations with badly designed or missing taxonomies that are completely defective at a level that the implementation has to be scrapped. There is nothing wrong with the software, the problem is with the implementation. I recently advised a client to scrap and reimplement a R27 million Rand investment in one of the biggest international brand ERP systems in the world because of highly defective validation data in the Chart of Accounts and elsewhere.
This is one of the biggest reasons why your current system is likely to appear clumsy and costly and why you might be considering replacing it. If you replace it and take the same shoddy validation and master data into the new system you will produce exactly the same outcome – the new system will look just like the old system because the data, which is the heart of the system, IS the same or nearly the same.
In this regard, taking the “history” across is one of the biggest mistakes you can make. Leave the history in an instance of the old software for those inquiries you do need to make, bring the history into a datawarehouse and clean it up so you can marry it with the new data but do NOT drag all the history with you at the transaction level unless there is history that is not subject to bad taxonomies. Which happens very seldom. Dragging the history across can cause delays of months, months that could be used to build high quality history.
Content, NOT software, determines the value and ease of use of any computerized system.
In addition to the configuration data and taxonomies there is the actual transaction data that is recorded in the software.
This data, when accurately recorded, will enable the software to work effectively and when inaccurately and incompletely recorded will cause the software to be experienced as cumbersome and clumsy.
Building rules based on street names and then using inaccurate clerks to capture street names is a recipe for disaster.
We expect all staff who drive company vehicles to have the appropriate drivers license and years of incident free experience yet people are allowed to use complex software with little or no training and without first ensuring that they can type fast and accurately. By fast I mean touch type at least sixty words per minute with at least 99.99% accuracy – the standard we took for granted for data typists and secretaries thirty years ago.
Data that is full of typing mistakes will be difficult to read and use.
Once data has been recorded we make use of reports to extract information.
Reports can be printed or can be directed to screen. They can take the form of sophisticated “Dashboards” or simple computed indicators.
Where sophisticated analysis and reporting is required a separate “Data warehouse” should be implemented in order to take the processing load off the data processing systems.
Well written software that is not combined with a rich variety of useful reports that package and present information in ways that facilitate value adding decision making is of little or no value.
As with all other aspects of software, the design and construction of reports can be done to high standards of precision with standards and conventions with regard to naming conventions, variables, etc that make the reports easy to use and maintain or they can be built to ad-hoc standards in a way that makes them difficult to maintain.
Well designed and well maintained taxonomies are a vital element in creating high value reports.
10. Decisions that lead to actions that create value
Finally, the principal reason that we use business computer software (ERP, CRM, etc – all Integrated Business Information Systems) is to facilitate better decisions that add value to the business. Yes we store data for retrieval, we flag actions and workflow that is required, we automate processes and we do all sorts of other things with business software but the final return on investment is determined by better business decisions that enable the business to thrive.
Software that is badly written and badly used in an environment where there is no expectation of value adding decision making and no accountability for quality of data, etc will be experienced as value destroying.
Well written software well used in an environment in which there is clear custody of the system and accountability for decisions made using the data in the system will be experienced as value adding.
Well written software badly used will destroy value and badly written software well used will create value.
In all aspects of computer software the value is determined by the human beings who use the system.
11. Build versus buy and retain versus replace
Easy to maintain software with a long investment life is determined by the right technology choices at the start of the life of the investment and by the right standards and adherence to standards throughout the life of the software. Well designed, well written and well maintained software can last for decades.
The bottom line is that the debate should not be about “build” or “buy” it should be about the appropriate use of appropriate elements of the technology for the required business outcome. Where there is an “off the shelf” solution that is a good fit to the business, then “buy” is the way to go. Where the business has elements that are very specific and very different then “build” should be the automatic choice.
Thus, if you have a system that is working but you are concerned about sustainability and maintainability, do whatever is necessary to raise standards of documentation, etc to appropriate levels. If there is a very small team of people supporting the software invest in training up an additional person or persons to be able to support the software.
Where appropriate invest in keyman insurance.
Treat the system the same way you would a factory and ensure that your investment is secure for many years.
12. It is ALL in the name? – not so
A fully functional integrated business information system comprises dozes, sometimes hundreds or even thousands of data tables, maintenance screens, executable programs, etc. One should be careful about giving such things names. They are complex factories, warehouses, etc, etc and if some element is not working correctly it should be adjusted as necessary.
Frequently the reasons for non-performance relate to the actions or inactions of human beings and not the technology itself. If we call the who system “Fred” then it becomes seductively and misleadingly easy to say that “Fred” is not working correctly when we should actually say “there is a minor error in the way the xyz module computes abc under certain specific circumstances”.
When we give a system a name then it is only a small step to start conversations about “is Fred the right system” or “is Fred out of date” etc when from consideration of the preceding sections it will be apparent that there really is no such thing as Fred and we should focus on whatever remedial work is required to the element of the technology portfolio that is not performing as expected, including looking at what the human beings using the system are doing.
I have assisted clients with conversations like this about “Fred” where “Fred” ranges from “SAP” to some home grown system cobbled together over the years. If it is badly implemented and badly configured it will be a mess no matter what world class technology is used.
Please contact me for further information.
Dr James Robertson PrEng
30 April 2010
Download What is Computer Software? -- White Paper in Adobe pdf format
A simple confidentiality and non-disclosure agreement which you can tailor and elaborate on as you see fit and which may vary depending on your legal jurisdiction and your attorney. I recommend that this initial document is kept simple as you want ALL persons attending the initial tender briefings to sign this
You would possibly have a much more comprehensive agreement for your short list bidders and possibly more comprehensive still for your final choice although I personally hold that very detailed documents of this sort tend to be excessive
Business Systems NOT delivering?
Call the Business Systems Specialist
Dr James A Robertson -- has been involved in the effective application of Business Information Systems, including but NOT limited to ERP, since 1987 and in the profitable and effective use of computers in Business since 1981.
Drawing on a diversity of experience, including formal military training in Quick Attack techniques at the Regimental Commander level, Dr Robertson has developed highly effective methods of investigating any sub-optimal Business Information Systems situation -- be it an established system or a stalled project or any other source of Executive frustration -- quickly and concisely diagnosing the root cause of the problem and prescribing concise practical actions that Business Executives can effectively act on see the Pulse Measurement page and also the Sample Reports page for redacted real reports.
He has also developed highly effective methods of strategically enriching systems to unlock the full potential of existing investments, see the Precision Configuration page and couples this to architecting small pieces of clever software that harness the full potential of your investment, see the Software page.
If you are having problems with your systems, your project or your IT Department, call The Business Systems Specialist
Business System Failure is RIFE -- we offer insight into why this happens AND WHAT is required to prevent it.
Failure is at epidemic levels with massive damage done to client companies -- if you are NOT aware of the extent of the problem please visit the About Failure page for a catalog of major failures running to billions of Pounds and Dollars.
All evidence indicates that the established players do NOT know how to deliver stable, reliable high value solutions that WORK.
There HAS to be a better way!
This website provides information relating to that way with a large collection of white papers, presentations, standards documents, etc that you can use to start bringing the situation under control
We also offer high level advisory services with regard to the application of the principles advocated on this website
We offer an ENGINEERING APPROACH to addressing these issues
By Engineering I mean the formal, structured, highly disciplined, highly systematic, highly practical approach that consistently delivers results in ALL areas of human endeavor where formally trained and certified engineers are the ONLY practitioners permitted to operate -- think large buildings, factories, motor vehicles, aircraft -- highly complex systems that work at a level that we take it for granted that they WILL work and where failure is all but unthinkable and, when it happens, attracts immediate public attention and rigorous investigation directed at ensuring that such failures are prevented in the future -- in fact, everything that the management consulting industry that implements complex software systems is NOT
This approach is discussed further on the Engineering Approach page.
In 2003 I undertook an in-depth analysis of all the information and experience that I had gathered with regard to the factors giving rise to Business Information System failure including ERP and general IT and classified this information into a number of categories including "The Factors Causing Failure" and "The Critical Factors for Success" based on this I developed a two day Course "The Critical Factors for Information Technology Investment Success" which is still offered today.
Based on this I wrote the book of the same name, which is available in electronic form here for download:
Click here to send us an email subscribing to our free newsletter -- all articles posted by James Robertson will be emailed to you
James has a very detailed profile on LinkedIn should you require further information about him.
You can also connect with him on LinkedIn at http://www.linkedin.com/in/DrJamesARobertsonERPDoctor
James has an open networking profile -- click on "Connect" and use email address James@LinkedIn-at-JARA.com.
You can contact us on
LinkedIn at http://www.linkedin.com/in/drjamesarobertsonerpdoctor
Facebook at https://www.facebook.com/james.a.robertson.393
Mobile: +44 (0) 776-862-2875
Landline: +44 (0) 207-059-0007
Fax: +44 (0) 844 774 4580
There is a large body of white papers, articles and other content produced by Dr James Robertson available on this website
Please click here to visit the detailed listing of articles
About Dr James A Robertson PrEng -- The Business Systems Doctor -- and Other Topics
Catalogue of Major Business Information System Failures
About the Engineering Approach
James Robertson's Value Add
Attributes of a HIGH VALUE solution
Recognizing Business System Failure
The Critical Human Foundation
Old Software IS Viable
From South Africa
Competencies of Dr James A Robertson PrEng
About Professor Malcolm McDonald
Table of Contents
About my relationship with the Almighty Creator, Yah the Eternally Self-Existing
Comments relating to the Business Systems Industry and other topics
Testimonials and other positive material regarding James Robertson
List of Articles
Achieving High Value Business Information System outcomes
Executive Custody -- What is it and HOW do you get it?
The REAL Issues in Integrated Business Information System Success
Part 1: Introduction
Part 2 -- Mythology and Lack of Executive Custody
Part 3 – Strategic Alignment and Precision Configuration
Why your ERP is NOT delivering and HOW to FIX it
IT Project Management
CEO Anthony Lee Comments on his experience of the Pulse Measurement
No Charge Guarantee on the Pulse Measurement Service
Examples of Pulse Measurement Outcomes
Critical questions regarding the Pulse Measurement™
The Pulse Measurement Workflow
The Critical Factors for Business System (ERP+) Investment Success in the Pulse Measurement
Indicative Pulse Measurement Durations
What is a JAR&A Pulse Measurement?
Survival of the fittest – why it makes sense to measure the pulse of your business
Examples of Pulse Measurement Outcomes over 24 years
Sample Pulse Measurement Reports
Strategic Essence: The Missing Link in Business Information Systems
Strategic Essence: Overview
Strategic Essence: Part 1 -- Strategy Defined
Strategic Essence: Part 2 -- Differentiation
Strategic Essence: Part 3 -- The Essence IS Different
Strategic Essence: Part 4 -- The Essence should be the Point of Departure
Strategic Essence: Part 5 -- Discovering Strategic Essence
Strategy -- the Essence of the Business: What is it and how do you develop actionable strategic plans?
Simple Steps to Increase the Strategic Value of your ERP Investment
Free Strategic Snapshot Toolset and Manual
A strategy focused planning system beyond traditional budgeting
Tough IT and ERP Procurement and Contracting that Works
Robust Business Systems Procurement
Part 1 -- Introduction
Part 2 -- Bill of Services, Laboratory, Go-live Certificate, etc
Part 3 -- Executive Engagement, Bid Compliance, Adjudication and other matters
Guidance and Advisory Services
The Art of Project Leadership
Why Regular Communication with the CEO is Vital
The Business Simulation Laboratory
Precision Configuration and Strategic Business Information Architecture
Precision Configuration based on Strategic Engineered Precision Taxonomies
The JAR&A Cubic Business Model
Highly Structured Strategic Chart of Accounts -- a Vital Element of your Corporate Information Arsenal
The Product Catalogue -- an Essential Element of any Precision Configuration
Attributes -- answers to the questions you have NOT yet thought to ask
Case Studies of Notably Successful Projects with high value Precision Configuration
092 Doing things differently and better -- ASCO Case Study 2-- BPM Summit 2013
088 Strategic ERP Invesment -- ASCO Case Study -- Service Management Conference and Exhibition Africa
026 Information Architecture and Design of FIS for Rennies Group -- Financial Information Systems Conf
018 CRM Risk Control: Designing and Implementing an Integrated Risk Mgmt Sys -- Integrated Risk Mgmt Conf
011 V3 Consulting Eng: Benefits of MIS to Professional Practice -- SAICE 15th Ann Conf on Computers in Civil Eng
Strategically Enriching your Business Information Systems
Part 2 -- Principles of Data Engineering
Part 3 -- Steps in applying these recommendations
Simple Steps to increase the strategic information value yield from your Business Systems Investment
The Full JAR&A Taxonomy Manual
Part 1: Introduction, Problem Statement, Definitions and Examples
Part 2: Why Use JAR&A, Required Knowledge and Experience, Cubic Business Model and Chart of Accounts and Taxonomy Software
Part 3: How to do it, Case Studies and White Papers and other References
Example General Ledger Manual
Business Process -- Irrelevant, Distracting and Dangerous
The RIGHT Approach
Custom Strategic Software Design and Oversight of Construction
Standards for Custom Software Specification
What IS Software?
Critical Factors for I.T. Success
A Moral and Ethical Dilemma -- Systems that Fail
Case Studies examining Business Information System failures
The BBC Digital Media Initiative Debacle
The Bridgestone -- IBM Conflict
Speaking and Training
Showcase of Conference Presentations
Most Viewed Presentations
Briefings and Seminars
Why your ERP/BIS is NOT delivering and HOW to FIX it
ERP and IT Procurement that Delivers Results
The Critical Factors for IT and ERP Investment Success
Conferences and Public Presentations
Conferences 80 to 99 -- 2009 to Present
Conferences 60 to 79 -- 2005 to 2009
Conferences 40 to 59 -- 1996 to 2005
Conferences 20 to 39 -- 1994 to 1996
Conferences 01 to 19 -- 1989 to 1994
On-Line Seminars (Webinars)
Webinar on Preparing and Presenting Webinars
Contacting James A Robertson and Associates Limited