The degree to which formal methodologies are adopted on software development projects vary according to the size of the project. Unswerving adherence to, for example, the PRINCE2 project management methodology for a small Microsoft Access project involving a single developer over a 2 or 3 week period would be totally inappropriate.

Nevertheless, it is important that project teams adhere to certain standards and methodologies to ensure that there is effective control over costs and timescales.

Maddox Ford maintains standards covering requirements specification, technical functional specification, project management, software development and test strategy and planning, for use in situations where our clients do not use their own methodologies.

For example, our approach to project management is derived from the standard PRINCE2 methodology. However, we recognise that different projects (both in size and client organisational preferences and cultures) may require different approaches to the project lifecycle – for example, we also use features of the RAD Dynamic Systems Development Methodology (DSDM) where appropriate.

Software development projects tend to have three distinct phases: initiation, control and delivery; closure.

Project Initiation / Analysis

Typically, project scoping will have been done by our clients before we are commissioned to undertake the project (or work jointly with our client). The scoping involves production of a Terms of Reference document to identify business needs at a level of details sufficient to allow technology implications to be identified and a project plan to be developed.

Thereafter, a Project Initiation Document (PID) is produced describing the approach to the project, responsibilities, lines of communication, etc., together with a more detailed analysis of the requirements (Technical Functional Specification).

Depending on the complexity of the project, the PID addresses the following areas – Project Background, Project Definition, Assumptions, Quality Plan, Project Organisation Structure, Project Plan, Project Controls, Exception Procedures, Change Control Procedures, Configuration Management Procedures, Version Control, Risk Log, Test Strategy, Documentation, Training Plan and Knowledge Transfer, Filing Structures, Acceptance Criteria.

Production of the Technical Functional Specification involves reviewing, with business users, each of the required functional areas in detail. This analysis will aid in the production of (or updating of that which already exists):

Use Case Scenarios	Describes the interaction between a user and the functional areas of the application
Data Flow Diagrams	Examines how data flows into and out of processes
Entity Relationship Diagrams	Maps the data as entities with attributes and relationships with other entities
Navigation Story Board	Describes how users navigate through the application
Preliminary Screen Designs	Follows on from the story boards

A technical Functional Specification document, incorporating the above, is produced for sign-off.

Project Control and Delivery

The procedure followed during the initiation/analysis phase provides the foundation for successful development and implementation. By now, everyone involved in the project has a clear idea of exactly what is expected and who is responsible for what. Nonetheless, we recommend regular progress meetings throughout development, not only at the project management level but also so that users can be kept abreast of progress and provide comments on the software as it is being developed.

With software developed to defined development standards (either our own or those adopted by our clients), together with a structured approach to project management and the procedures defined in the Project Initiation Document, the project is controlled and focused throughout.

All code is unit and system tested in a development environment before it is made available for user acceptance testing (UAT).

Project Closure

Closure signifies that the project is moving from a development and test phase to a go-live and support phase. It is triggered by a formal acceptance that all of the agreed deliverables have been completed to the required standard. Typically, successful completion of the User Acceptance Testing is the catalyst for project closure.

At this stage, if required, Maddox Ford completes a Project Review Report incorporating both its own comments and those of its client. Such a report includes an assessment of management procedures, project plans, technical design and system architecture. It is a valuable commentary for subsequent phases of the project and/or in drawing up a Service Level Agreement (SLA) for supporting the application.

Maddox Ford has many SLAs in place with a number of our clients. They are all based on the same structure which has been tried and tested over many years.