We are almost done. The final stage of our 4D Methodology, the deploy stage, marks an important milestone. This is the stage where we turn the application over to your users, and IT Staff. We want to make sure everyone is prepared for the transition, and we have a few more details to address. Let's look at them now.

Production Requirements

• Conversion Checklist
• SLA 
• Phased Delivery Checklist
• Production Staging

During this step our goal is to understand the requirements to move the system to a production, or live state. And like every other step before it, we want to first understand the requirements, and then put in place a plan. So let's review the Conversion and Implementation plan next.

Conversion and Implementation

• Contingency Plan
• Application System Set-Up
• Directories/Libraries/Queues
• Scheduling
• Convert Databases
• Validate Production Databases
• Final Validation of Transactions/Reports/Security/Equipment/Batch
• Parallel Testing
• Turnover to Operations
• Notification to Operations/Help Desk/Users
• System Monitoring
• Cleanup Development/Test Areas
• Warranty Period 

I'd like to mention a couple of important points about this step.  First, initially the production data is converted and stored in an special instance, called the Release Candidate (RC) instance. This is done so we can run a parallel test with your current system (if one exists). Only after all outstanding issues have been resolved will we go live. The second point I want to make is that it is not uncommon for issues in the deploy stage to initiate a mini process, which involves the define, design and develop stages. Here is why this happens. Let's say we discover a problem with the invoicing module. It might be something that slipped through testing, but more than likely it works as designed, but doesn't work as intended. We may need to revisit the requirements, Functional Design, Database ER Diagrams, etc. for this one module. Don't panic. This doesn't mean we start over. But it does highlight the dynamic nature of our software methodology. It is not uncommon for portions of your application to revisit each of the 4 stages throughout the life of your project. 

Alright, now we need to make sure the support team and users are up to speed. Let's look at that step now.

Support Teams/User Training

• Infrastructure Training of Support Center & Other Support Teams
• Executed Training Plan
• Move System To Production State

This section is pretty straightforward, so let's go to the final step. With every project, we conduct a Post Implementation Review. This is a critical aspect of the project, as we want to benefit from any lessons learned during the project. Let's take a look at this final review.

Post Implementation Review / Project Sign Off

• Comparison of Original Plan and Schedule to Actual Events
• Identification of Success/Failure Factors & Estimating Errors
• Evolution Plan
• Support/Enhancements
• Fixes
• Team Evaluation of the Project
• Additional Training Requirements
• System Architecture
• Replaced & Retired Systems
• Final Project Status Report
• Lessons Learned
• Improvements to 4D Methodology

The final review is an important step in the process. As a company, we want to know what we did right, and more importantly, what we need to improve on. That's why we are constantly striving to improve our 4D Methodology. 

Conclusion

I hope you enjoyed learning more about our 4D Methodology.  We have hundreds of hours invested into it, and it has proven itself very capable over the years.