Any project which has been both conceived and approved in my workplace is subject to compliance with an in-house operating model which intends to ensure that all solutions developed in the workplace are done so in an efficient and professional manner. The operating model employs a combination of both iterative and incremental development principles and as such at regular intervals during the development of any solution, the needs of the customer are re-evaluated and if necessary a request for change can be made; potentially influencing the repetition of the entire process until the solution is deemed to be complete by the developing team, governance, testing, and the client. For this reason, I would liken the software development lifecycle implemented by my employer to the incremental lifecycle.
The cycle consists of (at minimum); the approval from Planning Lead based in part on a two-page opportunity statement, the creation and evaluation of a project proposal, and plan with complexity relative to its scope. Continuous development then follows; segmented with regular evaluations of project requirements, testing and the potential implementation of any significant requests for change approved by the change advisory board or smaller bug-fixes and minor feature implementations.
The opportunity statement when put most simply is a short statement underlying why a project or change is a good idea. This document is required to be sponsored by a service lead and accepted by the appropriate governance group in order for the change or service to be continue to be developed and potentially implemented.
The project proposal can possibly cover a range of topics, however usually takes the form of just two major points. The first; identifying any current problems that the proposed solution aims to address. Secondly, the document aims to describe how the solution would rectify any identified issues if implemented, and how the company could benefit from the implementation overall. As a part of this process, the proposal is analysed to determine whether or not it fits the company strategy and is an appropriate solution for the identified problem. Beyond this the opportunity statement aims to identify the opportunity itself, which involves breaking down any user requirements into a brief summary, identifying any improvements that could be made to an existing system, service, capability or process and documenting the outcome that the developing team hopes to achieve with their proposed solution.
Following the identification of an opportunity, key dates and the potential consequences of not meeting them are documented. Points such as compliance deadlines or the potential loss of custom are appropriate examples of what this would cover.
Information such as an estimate of the likely required financial investement are also extremely important to cover in the opportunity statement as it is a factor that can easily influence any final decision. A start and end date are also expected to be provided, demonstrating the range in which the project would ideally be in production by.
The statement is also expected to contain a brief summary of benefits expected to be introduced with the implementation of the finished solution which is expected to be accompanied with a statement underlining any support for the company strategy. This generally involves identifying which strategic objectives the proposed solution complies with.
The key benefits the solution would provide are also expected be covered in the project's opportunity statement, documenting how the system would be improved with the implementation of the solution. Generating additional income, improving the speed or reducing the operating cost of current systems, improving customer service or user experience and maintaining complience with current and future legislation are all possible benefits of any new solution. This also involves documenting who will benefit from the project and how.
The success of any project is required to be measurable, and as such, it is also important to document how the success of a new project will be measured in the initial opportunity statement.
The design authority exists to ensure that the appropriate technical approach is taken in order to solve any given issue when producing a project design specification as is required. The design authority has the authority to either approve or reject proposed designs based on whether or not the project design specification complies with any given standard or is deemed by them to be an appropriate solution for the task on hand.
When it is determined through these rigorous processes that the project meets all proposed requirements, the project is deployed as is appropriate. This usually consists of first being implemented in a testing environment, which allows any involved customers to determine whether or not the solution is fit for their consumption and is free of any bugs that are likely to negatively impact their experience when employing the solution as appropriate.
Following this often lengthy procedure, the entire process is reviewed, with all involved parties considering how the process could potentially be improved and which stages of development were handled effectively. Additionally, the benefits of the developed solution are evaluated, determining whether or not the project was a worthwhile investment of resources, and how the solution could be implemented in the most effective way.
Following the implementation of a solution in accordance with the operating model, maintenance is delegated to a disparate team solely responsible for providing customer support for solutions previously implemented. When change is called for, control is passed back to the development team as is appropriate and the entire cycle is repeated.