DreamApps Wiki

As per the current business model for delivery of customized system, three parties are involved

1. Customer, who orders, specify, accept the system,
2. Business Partner (BP), who sells, scope, quote and close the sale, implement the system and train the customer, and
3. Development Center (DC), who delivers the customized system.

In order that the process of sales to implementation is effective, efficient and quick, the following process is required to be strictly complied with.

• BP closes a sale with Customer based on a mutually agreed scope document, either an Order Form, system generated Customer Order or a well-scoped Purchase Order/Work Order from the customer.

• BP conducts a user requirement study and generates a URS document. The URS must be complete in the sense that all enhancements and/or customization requirements are clearly spelt out including input/output document formats, if necessary. There should not be any need for any third party domain expert to refer to the Customer directly to understand the requirements clearly.
• After it's mutually accepted by Customer and BP, BP uploads it to DC's document repository and notifies DC by email. URS along with all documents/formats, etc must be made available in DC's document repository. No hardcopy document must be passed to DC before uploading scanned copies of the same.
• DC, after studying the URS must accept it, ask for additional clarifications, or simply reject it if it's incomplete or unintelligible. This will avoid wasting of time by all parties trying to work on an inadequate or incomplete document.

• DC will create an SDP which will clearly specify additions, changes, removal, enhancement and configuration of features required with reference to the standard system. Whenever required, SDP should also provide explanations for using a particular approach to meeting the requirements in URS.
• SDP will also act as a checklist for actual work needed to be done. This could be used as a tool for monitoring progress as well documenting change in strategy, etc. SDP is an ever-changing document. It will be complete, only when the project.
• DC will load SDP on the repository to be shared by BP.

• DC will designate a specific server with a public URL through which all stakeholders may access, with variable rights, the work in progress. DC will periodically upgrade the server with latest work done.
• During the process of customization, DC may seek BP's help in creating/entering test data or any other special content required for meaningful demonstration.
• On completion of customization/enhancement, DC will test the completed system and after satisfying itself that the system is deliverable and meet the specs in the URS, will notify to BP that the project is complete.

• BP will create a UAT, a simple document, essentially a check list comprising features to be tested. UAT must be uploaded in the repository and shared with DC.
• BP will conduct a complete test according to UAT and revert back to DC, if for some reason it cannot continue with the test. DC must immediately attend and rectify any such problem.
• At the end of the test, BP will share with DC, a change list refering to the URS and UAT.
• BP will repeat UAT, after DC has rectified all problems in the change list.

• BP, once satisfied that the system is ready as specified in the URS, will invite customer to test and make sure that the customer had been adequately trained to do so.
• No deployment of the system should be made unless the customer has accepted the system, being in compliance with the URS.