We have experience of working on projects of large size, scope and budget and from those projects we have established working practices and project phases that work well for all project sponsors and participants. Our ISO certified business processes are followed in all of our development projects.
Our quality management system and quality plan are both available for examination should you require it. Each stage in the process is clearly defined, scoped and budgeted so that the project as a whole is controlled, managed and measured throughout the project lifecycle. Even on small projects this process is followed and because our systems are designed around this ISO process then following the process is not time consuming, bureaucratic or expensive.
The Project Stages
1. Business Process Workshops
This first phase is critically important to the success of the project and to maintaining a business focus on what some may feel is an IT project. This phase is already being conducted by the internal business systems team so although we would like to be involved in digesting these process models we do not need to be involved in the actual gathering and modeling exercise. The output from this stage is a full set of Business Process Models that then form a documented reference for the business, not just for the sake of the software development project. Additionally this phase will provide an opportunity to confirm the scope of the software and which processes are to be supported by the software.
2. Functional Requirements Specification (FRS)
In this phase the Trigger consultants work with the internal technical architect to design the software solution and document the required changes and additions to the application. The solution is presented in a Functional Requirements Specification (FRS). This document aims to accurately describe every process, algorithm, screen and output that will be included in the final system. This results in confidence that the software will match the business processes and that the usability of the solution has been tested before a line of code is written. The FRS then becomes the design bible for the project and must be reviewed, amended and approved by all appointed stakeholders in the project. The output from this stage will be the Functional Requirements Specification document and associated wireframe screen designs, project plan and fixed price costing for the development of the software. At the end of these two stages the design process is complete and the full functionality, deliverables, architecture, cost and timescale of the project will be clear to all involved.
3. Approve Specification
Once the complete FRS is available then the project team will meet to go through the draft document and discuss all points within it. It is likely that a revised version of the document will then be issued which will address any issues raised in the meeting. Once the FRS is finalised then the development of the software can proceed.
4. Program Software
The new modules that are required to satisfy the user requirements are then developed according to the functional specification. As each distinct area of functionality is developed the engineers will write unit tests that confirm the technical operation of the code prior to being passed to quality control testing by the Quality Assurance team.
5. Pass Quality Assurance
Although the first step in testing any of our solutions is the engineer running their unit tests these are not considered to be part of the process of testing the software as a whole. This functional testing is carried out by our dedicated QA team. The QA team will go through the following steps, detailed in the next section, of Application Function Testing on every delivery to ensure that the software which is delivered for User Acceptance Testing has already passed rigorous functional tests. In addition to the normal functional testing on the QMIS application the QA team will also run integration tests on the software to ensure that it will fit and function correctly within the suite of applications which will make up the solution architecture. This will ensure that areas identified as integration points within the FRS will be thoroughly tested prior to you carrying out the next stage which is the User Acceptance Testing.
6. User Acceptance Testing
User Acceptance Testing can begin once the User Acceptance Deployment phase has been completed. Your key employees with expert knowledge of the functional areas delivered in that phase of the project will undertake their own series of tests. The creation and running of these tests is undertaken by you. Any issues found during this stage of testing will be created as cases by your team members using an online interface into Trigger's case tracking software (NetSuite – Advanced Partner Centre). This will give both parties visibility of the issues found during this phase. During this phase the user will be able to refer not only to the documentation to guide them through but Trigger will also provide a business analyst on site as required during the UAT period to answer questions and provide informal training for expert users.
7. Training
Following the successful implementation of the project training would be provided on the system to your internal users. This can be in person or via remote training tools such as Webex. Further training may be requested on an ad-hoc basis. This would be performed by a member of the Relationship Team (consisting of the Account Manager, Business Analyst or the Service Coordinator) depending on the focus of the training. Once training has been completed the production stage of the project is considered complete and will be followed by our project wrap up procedure which includes a lessons learned review and a 360 project evaluation.