• Login

What is computer software? And what determines the sustainability and maintainability of business software?

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?

What is computer software?

And what determines the sustainability and maintainability of business software?

By

James Robertson

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

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.


3.  Readability

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.


8.  Data

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.


9.  Reports

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


Random Selection of Articles by Dr James Robertson

Cnf 087 Critical factors for strategic business improvement success

A discussion of the factors that give rise to general business improvement success drawing on my experience with business information system and ERP projects
Std 019 Procurement: 10 Certificates for Use on the Project

A selection of tough Certificates designed to focus ALL parties attention on accountability for outcome, rigour and quality of work, create a platform for tough contractual responses in the event of non-performance.  Please consult your legal advisor in terms of exact wording in your jurisdiction
TxM 102 Taxonomy Manual Part 3: How to do it, Case Studies and White Papers and other References

Discussion of how to do it, real world complexity, challenges and opportunities, preparatory steps, design and development, coding conventions and standards, a series of case studies in which dramatic benefits accrued through use of Precision Configuration and other references


Random Selection of Articles by Dr James Robertson

Dr James A Robertson PrEng

Business Systems NOT delivering?

Call the Business Systems Specialist

Dr. James Robinson

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
James@James-A-Robertson-and-Associates.com

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

Click here to read more about the Engineering Approach

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.

Search Articles


Random Selection of Articles by Dr James Robertson

Std 023 Procurement: 01 Large Project -- Request for Proposal for Turnkey Solution

This is the RFP for larger projects referred to above, the document is too long to include on this webpage but is attached below
Cnf 068 Discovery -- An Essential Element of SOA Implementation

The importance of effective discovery and the issues that arise from inaccurate discovery including understanding the importance of communication in the first hour of engagement
TxM 102 Taxonomy Manual Part 3: How to do it, Case Studies and White Papers and other References

Discussion of how to do it, real world complexity, challenges and opportunities, preparatory steps, design and development, coding conventions and standards, a series of case studies in which dramatic benefits accrued through use of Precision Configuration and other references

Book -- The Critical Factors for Information Technology Investment Success

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:

Subscribe to our Newsletter

Click here to send us an email subscribing to our free newsletter -- all articles posted by James Robertson will be emailed to you

Detailed information about James Robertson on LinkedIn

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.

Contact Us

You can contact us on

Email: James@James-A-Robertson-and-Associates.com

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

Articles by James A Robertson and Associates

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



ArticleTagCloud for Articles Published by James A Robertson and Associates

7 steps to FIX your ERP      80:20 regarding software replacement      aborted projects      abstract      abstractness      accounting      actionable      adjudication      Advantage Data Transformer      advisory      agreement      all possible classifications      all reports      all software elements required      all spreadsheets      all tasks required to execute the project      Alpha Omega      analysis of data      analytics      animation      answers to the questions we have NOT yet thought to ask      Armscor      arrogant ignorance      art of strategic business information system project leadership      ASCO      attendance register      attorney      audit      audit cost reduction      bankrupt organizations      basis for achieving alignment      basis of payment      basis of pricing      better way      bid adjudication      bid adjudication score sheet      bid compliance      bid compliance checklist      bill of materials      bill of services      BIS      BIS failure      BIS success      boots in the mud      BPM      BPM dangerous      BPM distracting      BPM ineffective      brainstorming      break it until it does NOT break anymore      break it until it will NOT break any more      budget      budgeting      business engagement      business executives      business improvement      business information system      business information system failure      business information system success      business information system taxonomies      business information systems      business information systems procurement      business information systems projects      business integration      business intelligence      business intelligence models      business knowledge and experience      business participation      business process      business process mapping      business requirements focused      business requirements specification      business simulation laboratory      business systems      business systems laboratory      business understanding      by the book      care      case studies      case study      CEO      CEO -- project leader communication      CEO as custodian      CEO definite views      certificates      challenges      challenging presentations      change facilitation      change for strategic reasons      chart of accounts      classification schemes      clever software      client changing scope      client compact      clinical codes      coaching      Cobol      COBOL CAN be retained      Cobol still viable      code schemes      coding conventions and standards      cognitive span      collapse      communication      competitive advantage      competitive advantage through precision configuration      competitiveness      compiler      complexity      compliance      compliance checklist      comprehensive testing      Compuware      conference speaking      conferences      confidentiality      configuration      consultant NOT delivering what required      contract      contract certificates      contract law      contracting      contractors      corporate planning      cost      cost-quality-time      CPT 4      CPT4      critical factors      critical factors for IT investment success      critical factors for success      critical factors for technology success      critical human foundation      critical issues      critical issues analysis      critical requirements      CRM Risk Control      cubic business model      custom development      custom software      customer focused      data      data content      data engineering      data entities      data warehouse      DB2      definitions      design against failure      design and development      design for success      determination of strategic essence      determining strategy      diagnostic code      diamonds in the dust      differentiated      differentiation      diffusion of innovations      discovery      dislike of failure      dispute resolution      do NOT change systems because of alleged software redundancy      do things competitors could NOT do      document pack      Dr James A Robertson      Dr James A Robertson PrEng      dramatic benefits      dramatically improved strategic management information      driver of success      Dunning-Kruger effect      ease of use      economic collapse      economics      effective communication      effectiveness      efficiencies      efficiency      efficient filing of emails      eliminate light bidders      email      engineer against failure      engineered data      engineering      engineering approach      engineering approach to strategy      engineering failure      engineering laboratory      engineering services      engineering solution design      engineering techniques      enhance differentiators      enhance the differentiators      enhancing the value of your present investment      ensuring project success      enterprise resource planning      ERP      ERP configuration      ERP failure      ERP procurement      ERP success      ERP taxonomies      ERP value      essence IS different      essence of business      essence of the business and how it thrives      ethics      examples      exceptionally bad code design      executive briefing      executive briefings      executive custody      executive decision support      executive engagement      executive forum      executive frustration      expose hidden agendas      facilitation      factors causing failure      factors causing IT investment failure      factors causing technology failure      factors to manage for success      failure      failure to address soft issues      fashion      file table of contents      Financial Information System      financial information systems      financial management      fixing your ERP      focus for projects      folder design      foundation for delivery      full training      functional entities      future      Gantt Chart      gap analysis      general ledger      George Paton      go-live      go-live certificate      governance      governance = care      governance failure      group consolidation      Group Consolidation Chart of Accounts      growth      gut feel factors      hand holding      harshest judge of governance      hate failure      head count reduction      health management software      hierarchies      high level requirements      high road      high value      high value implementations      high value solutions      high value systems implementation      highly effective chart of accounts      holistic view of solution      how do you achieve executive custody      how the organization differentiates itself      how to      how to do it      huge opportunity      human foundation      hype      Hyperion      IBIS      ICD 10      ICD10      importance of executive custody      improved management information      in-box rules      incremental enhancement of existing systems      ineffectiveness      inefficiency      information required from third party suppliers      information technology      information technology failure      Information Technology Strategy      information technology success      Informix      in-house courses      innovative software solutions      innovator      inside head of CEO      insightful      instructions      intangible      integrated business information system      integrated view of business      integrity      intelligent data      interactive training material      interview      invitation to bid      isolated CEO = explosion      IT      IT and strategy      IT Audit      IT failure      IT governance      IT lies      IT management      IT mythology      IT non-performance      IT people who lie      IT personnel socialization      IT procurement      IT projects that fail      IT strategy      IT systems      IT systems procurement      IT the harshest judge of governance      James Robertson      Jof Nelson      key performance indicators      Kirsten Speer      knowledge management      laboratory      lack of an engineering approach      lack of precision configuration      lack of strategic alignment      lawyer      leadership      legal agreement      legislation      lies      list of required software      listen carefully      litigation      logical entities      loss information      low road      loyalty      MacDonald      maintain code schemes      maintenance      maintenance management      Malcolm McDonald      management      management information      managing contractors      manual      marketing hype      master data      master data classifications      master test data      mature facilitation      mature facilitator      measurable      measures of alignment      mentoring      Microsoft Outlook      misrepresentation      missing link      mistique      morals      Munich      mystique      mythology      new future state      New South Africa      no drill down      non-disclosure      NOT classic project management      obsolete is a fashion statement      obsolete software      old software IS viable      once software works it always works      on-line seminars      opportunities      opportunity to turn the economy around      organizing Microsoft Outlook      orientation of IT staff      own business experience      passion to enable clients to thrive      people are part of the system      personality matrix      planning      platform for a tough contract      precisio      precision      precision configuration      precision configuration advisory      precision configuration leadership      precision data      precision taxonomies      Predictive Index      preparatory steps      prescribed table of contents      presentation technique      presentations      preventing failure      preventing falure      preventing project failure      pricing      principles      problem statement      procedure code      process      processor ignorant of language      procurement      procurement timeline      professional speaker      Professional Speakers Association of Southern Africa      profitability      programming languages are for the programmer      project facilitation      project leader      project leader -- CEO communication      project leadership      project management      project management IT project management      projects      prove it works      PSASA      psychology      psychometrics      public conferences      public presentations      public speaking      Pulse Measurement      quality      REAL issues in Business Information Systems      REAL value      recognizing failure      redaction      reduced audit costs      reduced head count      reference documents      Reg Barry      regulatory body      relationship Almighty      relationship orientated      remediation of existing systems      Rennies Group      reports      reports not reliable      request for proposal      requirements specification      results orientated      RFP      right things      rigorous process      rigorous strategic planning      risk management      Robert Priebatsch      robust business information systems procurement      robust business systems procurement      robust contracts      robust procurement      robust solutions      SAICE      SAP ABAP is similar to COBOL      scheduling procurement      scientific professional      score sheet      screen design      seminars      SEPT      service orientated      Service Orientated Architecture      simple techniques to enhance business information systems value      simulation      sloppy configuration      SOA      socialization      software      software assets      software design      software does NOT wear out      software is instructions for the bricklayer      software schedule      software specification      software specification standards      solution experience      solution knowledge      South Africa      South African Institution of Civil Engineering      speaking      Spirit Led      standards      strategic      strategic advisory      strategic alignment      strategic analysis      strategic analysis and design      strategic business improvement      strategic custom development      strategic definition      strategic discovery      strategic driver      strategic driving force      strategic engineered precision configuration      strategic engineered precision taxonomies      strategic essence      strategic financial information      strategic gap analysis      strategic governance      strategic information      strategic management      strategic management information      strategic plan      strategic planning      strategic project leader      strategic snapshots      strategic software      strategic solution architect advisory      strategic solution architect leadership      strategic solution architecture      strategically designed chart of accounts      strategy      strategy defined      strategy focused planning      Strategy Snapshot Toolset      StratGap      StratSnap      strengthen differentiators      structured analysis      structured chart of accounts      substantial management information      succeed by engineering against failure      success      successful deployment      survive      system knowledge and experience      table of contents      tailored presentations      take notes      taxonomies      taxonomy      taxonomy software      technology      technology failure      technology issues      technology management      tender document pack      tender pack      tender pack table of contents      test data      testing      The Critical Factors for Information Technology Investment Success      the Critical Factors for Success      the essence of the business      the essence of the business and how it thrives      the essence of the organization and how it thrives      the factors causing failure      the first hour      The REAL Issues in Business Information System success      things right      third party suppliers      third world countries      thrive      time      tipping point      tough certificates      tough contract management      tough contracts      tough procurement      tough terms      training      training material      treatment code      understanding of data      understanding the engineering approach      Uniface      unlocking value      use different languages for new components      V3 Consulting Engineers      validation data      value      versus process      video      webinar      webinars      weighted factors      what is executive custody      what is strategy      what is the essence of this organization and how does it thrive      what to do      where is IT going      why executive custody is required      why the organization exists and how it thrives      why your business information system is NOT delivering and HOW to FIX it      why your ERP is NOT delivering and how to fix it      workflow      writer     

Table of Contents

Home

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

Reference Articles

List of Articles

Article Catalogue

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

Pulse Measurement

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

Strategy

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

Procurement Documents

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 1 -- Introduction

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?

IT Effectiveness

Organizing Outlook

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

Other Seminars

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