When it comes to LIMS implementation methodologies there seems to be as many as there are stars in the heavens. At least it can seem that way, especially if you consider the various LIMS vendors’ branded methodologies. However, if you take a careful look at all these, you can categorize them into 4 main categories; Waterfall, Prototypical, Time Bound, and Hybrids.
For many years the most tried and true as well as the most popular LIMS implementation style was the Waterfall Methodology. This classical IT system implementation method is very regimented. One benefit is it produces very clear and detailed documentation (requirements, design) to guide the implementation and the subsequent testing and verification. As shown below in the waterfall methodology, progress flows from the top to the bottom, like a cascading waterfall.
Proponents of this method feel that the time and effort spent in the early stages of the project leads to greater economy of effort for the later stages. It is common that 20-40% of the project time will be spent in the first two stages, 30-40% in the implementation stage, and the rest in the testing and verification stage.
Opponents believe that it is impossible to be successful with this method since so much time is taken up front defining everything without full knowledge of the capabilities of the system by the potential users. Also, some parties feel that project momentum can be lost when such considerable effort is expended without any tangible system being available until much later. It is difficult for non-IT people to visualize, based on documentation (i.e. requirements, functional requirements, design spec), what the LIMS will look and feel like without having something to try out and play with.
Prototyping LIMS implementation methodologies came into use to overcome the objections with the Waterfall methodology. In a prototypical methodology, basic requirements are developed and then an initial LIMS prototype is produced. This is then reviewed by the LIMS implementation team who provides feedback, which is used to revise and enhance the prototype. This cycle is repeated multiple times before a final version is arrived at.
Proponents of this methodology praise the speed with which prototypes can be developed and the immediacy of feedback. Unlike the Waterfall methodology, the LIMS users get to play with the LIMS as it is being developed, making it much easier for them to visualize how the LIMS will work for them.
Opponents will cite the possibility that the developers will not do complete analyses of the needs and requirements in the press of getting the prototypes out. Also, end users can sometimes get confused or disappointed if some features and functions in the prototype that they really loved do not make it into the final version. While designed to be fast, there is a danger that the prototyping process can seem to “go on forever” especially if the developers try to get everything into the prototypes.
This category of LIMS implementation methodologies includes Time Boxing, Chunking, Incremental, Iterative, and Agile methodologies. There are differences with all of these but the common theme is one of limiting the implementation cycle to a slice of time. The basic goal when employing these methods is to keep the LIMS implementation moving and not get caught spending excessive time or effort on developing any one aspect of the system.
Proponents of Time Bound methodologies feel that since small chunks of functionality are tackled in each time slice, there is an opportunity for very quick review and adjustment based on end user feedback. Likewise, testing can be accomplished quicker since smaller pieces are being created. Lastly, faster delivery of the final LIMS and at lower costs is claimed by users of these methods.
Opponents will point out the possibility that as incremental functionality is developed and delivered using these methods problems may arise with the overall architecture of the system. Conflicts can occur and extra rework may be needed to resolve them. Also, opponents will point out that although the final LIMS may be delivered fast, functionality that was not completed during a particular time slice may have been left out so the final system may lack critical capabilities.
Some of the most used and successful LIMS implementation methodologies today take aspects of the aforementioned methodologies and blend them together to make a Hybrid Methodology. A good example of this would be a methodology that calls for the development and documentation of requirements and the functional design of the LIMS but then utilizes an iterative, time boxed implementation process. Prototypes are iteratively produced until the final version of the LIMS is realized.
All things being considered, Hybrid LIMS implementation methodologies provide all the benefits of the various methodologies discussed above and minimize all the deficits. These can be some of the most effective and efficient methodologies if executed well.
Tell us which LIMS Implementation methodology you used when implementing your LIMS. Did you use Waterfall, Prototypical, Time Bound, or a Hybrid methodology? Would you use the same methodology if you were to do your LIMS implementation over again? What lessons did you learn during your LIMS implementation?
Comments