About
Services
Sign Up
Support
Home
About Us
IQ Approach
Portfolio
Affiliates
Contact Us
Overview
Design
Deploy
Promote
Package Deals
Design & Build
Domain Names & Hosting
Website Promotion
Website Package Deals
Shopping Cart
Checkout
Conditions of Purchase
FAQ
Feedback Form
Site Map
Terms and Conditions
THE IQ APPROACH
IQ Web Technologies has a distinct project methodology that is broken up into the following phases:
A condensed version of the generic methodology follows.
Keywords:
User requirements, Project Charter
In this phase the project is constituted and the required approvals of obtained for the project to be set up as a virtual entity. For this purpose, the user requirements are captured clearly and completely, and the user and IT representatives agree on the purpose, benefits, high level scope and resourcing requirements. Once the highest level approval is obtained and the project charter has been signed off, this constitutes the passing of a major stage gate and the procession with the next phase of the project.
Keywords:
Scope, Functional Specification, Proposal, specification, terms of reference
In the ‘Define’ phase of the project, the scope and the design of the system is articulated in a focused, clear, and objective manner, such that no part of the project delivery can be questioned at a later stage. It will clearly indicate what will be delivered, including the technical product/ service, integration and dependency on other systems, training, support and service agreements. Equally as important is to define what is NOT in the scope to be delivered by this project. On the basis of technical merit and reasonable cost/ti,e schedule the technical functional specification document can be drafted, in which the detailed system design is documented. This is important as it serves as the basis of the acceptance criteria and test cases.
Keywords:
Build, Alpha testing, test cases
The physical build of the solution takes place in this phase. The build should proceed exactly according to the functional specification, and any deviation from this design should be brought to the table at the change management committee. Furthermore, any risks that may impede all hamper the progress of development (for example the potential obsolescence of an add-on), or the running of the solution (example heavy CPU utilization causing slow performance) must be recorded in the risk register. It is then the task of the steering committee to assess the risks had to decide whether any mitigation steps may be necessary (for example, altering the design are providing better supporting infrastructure).
Keywords:
Configuration, Training, Beta Testing, Parallel Runs, Go-Live
The Deploy phase is further subdivided into the following activities:
Configuration:
All the end users and administrators should be identified, their machines set up with the required software and supporting tools and required permissions should be granted.
Training:
Classroom type training is usually most effective for more complicated systems that typically enable a complex workflow. The training should have presentations centred on the main concepts, business context, and showcase successful use of the application (perhaps other local deployments).
Beta Testing:
In Beta testing, the users now work on a realistic work scenario, but the users are encouraged to ‘explore’ all facets of the functionality as well as all workflow scenarios. This is done in a structured fashion using the test cases written during the Develop phase. A testing issue log should be kept in which issues are clearly logged.
Parallel Runs:
This phase is only relevant if the project is replacing an existing system. In this phase users are expected to populate the new system with “live” data, such that an objective comparison can be made between the old and new system outputs, as well as performance metrics.
Go-Live:
The definition of go-live is the event at which the new system becomes the primary tool for decision making and data input & output, and the old system (if there was one) may be used only for verification purposes only. The system should be declared as Live when: - All testing issues have been resolved; - Users have been migrated to the production environment; - Business sponsor agrees that go-live should be announced
Keywords:
Stabilisation, Decommissioning, Handover to Support
After go-live there should be a period of Stabilisation of about 3 months, in which the project team is still active in assisting users, resolving P3 issues, and ensuring that all the final elements are put into place. This includes updating the system and user manuals, ensuring that the helpdesk is available, accessible and prepared, that production environment is stable, and finally engaging the support organisation to prepare them for handover. The legacy system may be run in the background after Go-Live has been announced for verification/backup purposes only.