As in most projects the delivered software doesn't always meet the requirements to make it fit into the business processes. Often, due to available time, the cost of implementing the solution or the risk for implementing, the "new" requirement is "created" by a workaround.
Wikipedia saying the following about Workaround: "workaround is a bypass of a recognized problem in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. Frequently workarounds are as creative as true solutions, involving outside the box thinking in their creation"
I think the keyword in this definition is temporary.
Due to the temporary kind of workarounds, they are often written down separate documents or as addendum of manuals. They are only not embedded in the software, functional designs and business process documentation.
There are processes how to handle with issues, change requests, manuals, courses and how to define and manage requirements.
Often a workaround stays in the mind of the project or creator. And after a period the temporary solution becomes the only solution. The business has forgotten that the workaround exist and using it as standard procedure in their business process. The initial process became less optimal. The main risk here is that when implementing new systems or functionality they translate the workaround in those requirements.
I think the pitfall here is the synergy effect of workarounds. If a workaround is not identified as such in the current process, it becomes a requirement for the new functionality. If this cannot be embedded correctly a workaround for that workaround will be created. This results in the match between system and the actual business process becomes less pure.
Another situation is the effect of the workaround on the data. Sometimes, when requirements are not build as intended, a workaround is defined. The chance here exist that data is not stored in databases as intended. This might result in partial suitable data. When new functionality is added, it might result in a new data model and perhaps transforming existing data. Only is the data model now based including the workaround or is it defined based on desired structure?
My suggestion is to maintain the relationships of workarounds to requirements, code, functionality, issues, manuals and training materials.
Identification of workarounds
If we want to maintain the workarounds we need to understand the process of workarounds. I think the following phases can be identified:
Workarounds identified during:
- Business Process Definition phase
- Requirement phase
- Application selection phase
- Development phase
- Testing phase
- Implementation phase
- Production phase
During the definition phase of business processes it is important to be able to identify were workarounds are already embedded in current process activities. It might be important before starting defining requirements first think how the initial process can be improved by measuring and defining current and new activities. This might lead to a situation that workarounds has to be removed. This should result into new requirements to avoid implementation of existing workarounds.
During the requirement phase, decisions can be made to stop investigation towards new requirements in a certain area. This might result in some workarounds also.
Application selection phase
Not always systems as build from scratch, Often existing applications are bought. One of the steps of the selection phase is matching requirements towards those systems. And often a system doesn't fit those requirements. The mismatches are often translated towards new functionality in those systems or accepting workarounds.
Sometimes during development we noticed that functionality intended to be build is more complex to create then initially thought. The costs and time of building certain functionality becomes a risk for the project. Sometimes decisions are made in this phase to ignore the requirement and accept a workaround.
During the testing phase issues are found which will not be solved immediately. Workarounds are defined for those situations.
In implementation phase manuals are created and training materials are developed. Here the actual workaround is made final and visible.
When users are working with the application the initial are using it according manuals and training materials. After a while they found their way in the system and define their own "short-cuts" in the system. This way of working is how they workaround intended functionality. Sometimes they also develop their own workarounds for workarounds.
Static vs Dynamic workarounds
In my opinion you have static workarounds and dynamic workarounds. The static workarounds are primarily defined during the first phases. And is a product of the project. The dynamic workarounds are defined in production phase. If those are written down they become a product of the business.
Registration of workarounds
In all phases there are ways of registering workarounds. As far as I know there is no defined notation and location to do this.
Perhaps it is done this way:
Business Process Definition phase: Separate paragraph in process description;
Requirement phase: marking a requirement in scope or out of scope;
Application selection phase: marking standard functionality as customizable;
Development phase: embedding comment in code, functional and technical designs;
Testing phase: in issue tracking tool;
Implementation phase: In manuals and course materials;
Production Phase: personal emails, memo's, additional workaround documents.
Combining workaround registrations
The main challenge would be combining workaround registration. I think it is necessary to get an overview when somewhere a change is involved all teams now what to do. And more important, know that they have some additional work to do. To combine workaround registrations you need some formal registration of them in their separate documents. The basis could be a unique identifier and short description. This should be registered in one document. You might call it the workaround backlog.
Having one document where relations to workarounds are created is not enough. Also the life cycle of the workaround should be defined. As workarounds are temporary solutions, the end date should be defined and monitored. If end dates are approaching, it can help defining the new scope of the next release.
I think you need one owner for this backlog. He becomes responsible for at least providing information about:
- Where workarounds are defined;
- If workarounds are mentioned in all necessary documents;
- What they are;
- How they can be identified;
- What the planned end time is;
- Impact on processes;
- Impact on data;
- Impact on functionality;
As workarounds can have impact on processes, functionality and data they have to be tested. I think they can be tested in the following stages:
Unit Test: Check if newly build functionality is not interfering with defined workarounds;
System (integration) Test: check and measure how workarounds are interfering with standard and new functionality and their impact on data;
User Acceptance Test: Check if the workaround as mentioned in manual still fits the business processes. And check if the relation ships between workarounds are logged correctly.
Workarounds are of temporary kind. Where the chance it becomes a final process is quite huge. We should be aware of the existence of workarounds and monitor them during all phases to avoid a negative synergy effect of workarounds on business processes and systems. To manage them an owner should be assigned and they also have to be tested during the development phases.
Of course there are more ways of registering, managing and testing workarounds. Still I think there is some gains when approaching workarounds more formally and adapting them in the product life cycle.