System development s and implementations in the modern world tend to become increasingly complex and much more difficult than they used to be in the past. The growing life of projects as well as their increasing scope has led to software and system implementations running into long periods of time.
Since projects run into longer periods today than in the past, there are more chances in projects nowadays of not meeting the user’s requirements fully and completely. This discrepancy between the designed system (made by the analysts and the programmers) and the system desired by the customers is known as the “gap”. Analysis of this difference between the designed system and the desired system is called “gap analysis”. Gap analysis has become an important tool nowadays in software implementation projects. It analyses the difference between the “real” needs, as expressed by the customer and the “assessed” needs as perceived and understood by the designers (analysts and programmers). Gap analysis can be directly applied to the systems development life cycle. Although die-hard followers of the systematic approach might argue over this fact but IT professionals in favor of the “waterfall” model will definitely agree. (Russell & Yilmaz, 2006)
The importance of Gap Analysis as a tool in the Systems Development Life Cycle (SDLC) is significant. The usefulness of gap analysis has been proven time and again. It can be applied to the SDLC in various formats. Since SDLC itself is not a mandatory list of processes in the modern world i.e. it has become very flexible and varies from scenario to scenario, gap analysis should be implemented within the SDLC at a stage where it matters most.
Most systems analysts would consider including the gap analysis as a part of the SDLC process during the analysis stage. However, other analysts will consider it as a feedback after the designing stage to check on the progress of the designed solution to be in conformity with the customers’ needs. As described by Russell and Yilmaz, gap analysis assesses the difference between the real needs and the assessed needs it sure is an important feedback (or check) tool in the SDLC. This means that gap analysis can effectively be made a part of the SDLC as the check-back stage after the design activity.
It is worthy to note here that gap analysis was not previously considered a part of the SDLC process. The SDLC process was the simple Introduction-Analysis-Design-Testing-Implementation-Recommendations model. There was not much room for feedback or check-backs upon the requirements gathered during the analysis stage. But this model could not remain intact for very long. Analysts soon began to find huge differences between what they had understood and what the customer really wanted.
One reason for this was the “creeping requirements syndrome”, This is a phenomenon where the users’ requirements change over time as the project progresses. Earlier, analysts used to do the analysis and gather the system requirements, which they passed onto the programmers to develop into code and interface. After this design activity, the system was implemented. The creeping requirements syndrome was that the customers’ demands changed after the analysis activity. But since there was no interaction between the analysts or programmers with the customer after that, these changed demands were not reflected in the designed system. This often led to the “gap” which then had to be re-worked upon. Many analysts then employed gap analysis at this stage to re-work the project and update the changes into the built system.
This means that gap analysis gradually was adopted as a part of the SDLC process but was placed as the last stage where the differences in the customers’ needs and the assessed needs were bridged. There is no hard and fast rule to this and there can be several occasions where the gap analysis may be a part of the SDLC but after a different activity in a different order. It all depends on the situation and the system nature rather than theory. For example, a small school is implementing a system, having a low scope that will cater to its library management. It will keep a track of the books issued and returned and will only allow record addition, retrieval, updation or deletion, i.e. it does not support reporting. (printable reports). Such a system designed through the SDLC might have gap analysis at the end of the design activity before implementation to check upon the deviations or the differences that exist between what the end-user demanded and what the programmer has built.
Another case may be the design of a hospital management system which has a high critical scope. In this situation gap analysis can be performed at the end of the SDLC process. Then the system would have to be re-designed to a great extent with huge losses of time, effort and money. However, considering the scope and importance of this project, it is wise enough to have gap analysis right after the design activity. The design activity comes after the analysis. Having a gap analysis immediately after the design activity seeks to eradicate any differences before the system is actually built into code and interface. Thus, this results in an effective time, effort and costs saving activity.
Gap analysis need not be there in the SDLC process for the designing of new systems only. Re-designing an old system or Business Process Re-engineering are also cases where gap analysis is a most important tool for measuring the deviation of a project from its actual requirements. This deviation is not the deviation caused by the programmers or due to a misinterpretation of the data provided to the programmers by the analysts. Rather, this is the deviation caused by the lack of completeness of the requirements gathered during the analysis stage.
Consider the case of a hotel management system that already is computerized. However, due to the technological advances the system needs to be re-engineered and the management has asked for newer functions and modules to be added to the newly designed system. Since, the system is already in place, the conventional SDLC is reduced to a shorter version in which the Introduction phase need not be carried put. This can be gathered from the previous system documentations. The analysis will be shorter in terms of time taken since the system needs a technical refurbishment and very few additions. However, when the system design is finished, there will be a certain level of discrepancy between what the management had demanded and what was provided by the team of programmers as the final product. This means that the “gap” between the real needs and the assessed needs cannot be eliminated even during the re-engineering of an existing system. This gap is bound to be there in every systems analysis project and the aim of “gap analysis” is to reduce or minimize this difference so as to make the end product more and more in conformity with the requirements of the customer, since it is the customer for whom the system has been designed for and who will be the end-user of the system in future. And the primary purpose of any system development project is to fulfill the customers’ needs first and then worry about other things.
It is up to the analyst to use different tools to eliminate this gap effectively. Gap analysis is the best known tool that is used widely in systems development projects nowadays due to its proved effectiveness. It is made a part of the conventional SDLC process so that its purpose can be delivered to the maximum extent.
In conclusion Gap Analysis can be a part of the SDLC process without any difficulty or going-out-of-the-way. It is a suited process to the designing of any system and an effective tool that can be part of the SDLC process at any stage and in any order. This depends more on the situation rather than on theory. Practical experience shows that even the same scenario’s having different scopes may have gap analysis at different stages. This does not matter since the aim of a gap analysis is to study and analyze the differences that exist between the real customers’ needs and the needs assessed by the analysts. In short, gap analysis is an effective tool that can be part of the SDLC process depending on the situation and the purpose of the system.
Russell, I., & Yilmaz, J. (2006). Information Systems Management Vol. 23 Issue 4, p37-42, 6p.