Implementation

Implementation

The implementation stage of any project is a true display of the defining moments that make a project a success or a failure. The implementation stage is defined as "the system or system modifications being installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements" (DOJ, 1). While all of the planning that takes place in preparation of the implementation phase is critical, I am of the opinion that the implementation itself is equally as important.

When working through the process of defining and selecting my organization's new enterprise business system, the implementation stage became the most anticipated and important part of the SDLC for the organization. A tremendous effort had been exuded in planning and preparation for the application development and deployment. The start of the implementation phase was an indication that progress was being made and the system was well underway.

For my organization, the implementation phase kicked-off with the coding of the application. Because we were using a retail system with a few customizations, the coding stage was not nearly as long as it might be with other business systems. With regard to coding, two things had to occur. The first was to customize some of the fields and interfaces in the retail system. The second was to develop the web-based front-end that would serve as the primary interface to our application. Both of these coding tasks were completed in a reasonable amount of time.

After the initial coding was complete, the customized application and web interface were presented to my organization for approval. For the most part, the presentation was successful. We had decided to modify a few of form fields and change the color scheme of the web interface. The consultant made the necessary code changes and presented the modified versions for our approval. The changes were precisely what we expected and we accepted the final versions. After receiving our approval, the consultants finalized the code and prepared to move into the testing phase.

In testing, the objective is "the bringing together of all the programs that a system comprises for testing purposes" (SDLC Glossary, 1). The testing phase for our application was broken into two halves. The first half was to test the entire application from a programming perspective to ensure as many bugs as possible were detected. This part of the testing process was completed by the consulting organization. Upon completion of their testing, a document was given to my organization that detailed all of the problems encountered and what actions would be taken to remedy the issues. After acknowledging the issues, the consultants took some additional time to fix the known problems and repeat their half of the testing phase. Again, we received a report detailing that no new issues were discovered and that all prior known bugs had been resolved. At this point, it was time to begin my organization's half of the testing phase.

We selected six of our power users to test the application in their daily work environments. In many instances, this phase of testing was similar to a parallel system deployment. The employees were asked to perform their job functions using both the old and the new systems. We understood that there may be loss or corruption of data in the new system, so it was necessary to have the users make use of the old system as well. We also realized that this testing approach was time consuming and would case a significant loss in productivity. As such, it was decided to limit our portion of the testing phase to ten business days. During those ten days, each of the users was asked to maintain a log of any problems, concerns, or issues they had encountered while using the new business system.

At the conclusion of the ten days, the entire group of test users and the consultants met to discuss the logs that had been maintained. As it turned out, the number of problems were minimal, but nonetheless, had to be addressed. Similar to the first part of the testing phase, the consultants were given some time to make the necessary programming modifications to compensate for the issues discovered by our employees. After a short period of time, the same group was convened to review the modifications and ensure that everyone's concerns had been addressed. After agreeing that all of the issues had been addressed, it was time for the official installation of the application.

In our particular case, the installation process was fairly simple. We decided to remove the test system completely from the server and install the final system from scratch. The consultant provided all of the final code and a fresh instance of the system was installed on our in-house server. Because we had designed the system to be entirely web based, the only client installation necessary was for system administrators. The administration client was deployed to each our system administrators within a matter of minutes. All other users would make use of the system through their web browsers.

At the end of the new installation, a small test phase was completed again. The purpose of this phase was only to ensure the new installation was functioning as expected. We simply tested all aspects of the application while checking for errors. Fortunately, we didn't discover any additional problems, so we were ready to begin using the new system.

We had decided to use our old and new business systems in parallel for the first month of operation. The reasons behind this choice were two-fold. First, even though it would be time consuming to enter duplicate data, we wanted to ensure that our business flow did not suffer should the new system fail or require extensive modification. We felt the productivity loss was well worth it in comparison to losing an entire month's worth of data. Secondly, we needed to train the end