Aviarc Agility Centre

Innovation Delivery

The delivery of an innovation begins when an idea that has been developed is approved for completion. At this stage there has been much effort applied to ensure that the idea is sound, and the implementation of identified features will meet the user's needs and expectations.

The next phase of project life is to implement the requirements as collected in the Feature Manager. The Aviarc Development Team is engaged, a Project Manager assigned and development staff identified.

The Development Team, experienced in Enterprise Small Systems (ESS) development with Aviarc, begins with the following artifacts from the ID phase:

  • A prototype system identifying the style and approach to be taken for the application. Written in Aviarc, this is used as the basis for the final system.
  • A set of detailed requirements to be implemented to create features that will meet the user's needs.
  • A complete scope of the effort involved in the completion of all identified features.

With this information, the project's delivery timetable is first organised. Interim deliveries of functionality are planned and release cycles (sprints) may be as short as one week. Features are allocated to each release and assigned to developers for implementation.

While the ID phase tends to involve incremental improvements on requirements, during innovation delivery features tend to be implemented in chunks. This provides users with visible, discrete increases in functionality with each delivery, while keeping duplicate testing and rework low.

Note that during idea development some time will have been taken to clarify any complex areas of the system. This may have involved some prototyping of features, investigation of possible technical approaches or multiple discussions with users over their expectation and needs. It is therefore rare for prototyping to be necessary during innovation delivery and this phase will also include very few unexpected complexities or surprises that require rework or major system changes.

Users are not cut out of the loop during innovation delivery. In addition to frequent releases to the users, questions inevitably arise and requirements sometimes need clarification. Ongoing communications between the users and the development team continue as and when necessary.

The aim is to provide useful releases regularly to users, continuing the important feedback loops set in place during idea qualification.

To ensure quality, innovation delivery utilises proven methods of quality assurance, including system testing, code reviews, user interface checks, issue tracking systems, code management tools and solid release management techniques. While we provide quick results, we maintain high quality in the results provided.

We believe it is important to involve users in their innovative system from the earliest delivery. In doing so, users are able to flag issues or concerns early, lowering the cost of any changes necessary, whether they be changes to requirements or changes in implementation of requirements. While the requirements identified during idea development are implemented, we understand that user needs and our understanding of such needs can change rapidly.

Once the implementation of all features is complete, users will finish testing and reviewing the system (i.e. user acceptance testing). We defer to client process and procedure to ensure the project's successful signoff internally. The system is then installed in production, ready for use.

Yet this is not the end of the project. Successful innovations continue to be evolved and improved as time, and their use, increases. We therefore advocate a number of processes and support tools for the maintenance phase. The main tool we suggest is the organisation of a contractual arrangement whereby issue resolution and small enhancements are done under a pre-arranged maintenance contract. This removes overhead to get small changes made.

This is particularly useful for enhancements due to many of the ideas that users have can be implemented with relatively low effort. Without such a system in place useful ideas tend to be dropped or forgotten, put aside or held up in undue process and budget overhead. Innovation does not stop once the initial ideas are made concrete in software and it is vital that process and procedure do not stifle the ideas in applications built through the Agility Center.

The ideas and techniques described here and put into practice for Aviarc ESS development are based in the Agile Manifesto. While specific techniques and details of innovation delivery may change with the project and client, our desire is to always see that innovation is delivered successfully.