Why I lost my work?

One of the frustrating aspects of utilising a digital system is when the system experiences an unexpected behaviour. It is frustrating, as all the work previously done tends to get lost and has to be done all over again.

In the early years of word processing, the auto-save feature or recovery functionality (popular in the Microsoft Office Suite) were not available. Even most of today’s applications still don’t provide a failsafe mechanism not to lose everything when the application crashes. This leads to the one of the frequently heard phrases when dealing with technical people, the famous “Save frequently and make sure to take backups or make copies”. But I have invested in the application I’m using, so why I have to still be bothered that it might lose my work?

I think this is how it’s normally done. But what if…

A lot of digital systems are around for every kind of work. When a solution is requested to a software house, normally it is done because the company processes are specific and a tool that fully fits the company process is not available. This is usually reflected in the requirements gathering stage, when it is not uncommon that other systems are referenced to explain the process. But which business runs its processes from A to B without minor diversions or from now and then has interruptions within the process?

Interruptions or divergences to the process occur on a daily basis, but it is not possible to foresee them all. Thus, during requirements gathering workshops, it is not uncommon to have a Business Analyst or someone who is gathering the requirements to state that these anomalies in the process will not be handled but the normal/standard process will be the only thing implemented.

So as the client requesting the work, you are asking a software company to provide you with a solution that is specific to your business demands and this ‘so called’ expert they sent to gather the requirements is removing your specific requirements just to simplify the program. So how you go around this hurdle and achieve partially what you require? The answer is simple, “Ask for failover mechanisms”. How?

During the requirements workshop you have identified a number of instances where the normal process will not satisfy completely your business. By introducing failover mechanisms, a number of actions can be taken afterwards to compensate for the initial trade-off of requirements. For example, if incorrect data – in terms of the inputs to the software being used – is captured, it is possible to ask the service provider to update the solution to deal with the captured data. Another example is where communication with other systems becomes unreliable. Why the solution provided shouldn’t automatically attempt to transmit or receive the information without getting funny error messages.

Sections:

• Introduction
• My technical design is flawless
• Why I lost my work?
• Conclusion