Gateway Review 2013

In February 2013, a Gateway Review was conducted to assess the level of preparation and realisation of AERIUS.

In preparation of the review, PBLQ HEC conducted a study into the quality of the development process. The results from this study are presented below; the results from the Gateway Review itself are intended for the participants in the study. 

Observations

PBLQ HEC characterises the context of the development process as innovative in content and complicated in governance. On the one hand, a study must be conducted into the ways in which calculation methods could be implemented most effectively for determining the nitrogen depositions of certain installations. On the other hand, during the development process, the AERIUS team has to work on both government and public support for the instruments to be developed. Discussions are still ongoing between the competent authorities.

The reviewers have complemented the development team on the way it made its ideas and suggestions open to discussion via workshops with people in the field, and subsequently has used the results in aid of functionality. However, the reviewers also stated that the instrument still needs to prove itself in actual practice. Other important observations concern the lack of a functional architecture and of sufficient functional and technical documentation.

Recommendations

1. Carry on with the current development team

The reviewers recommend that no far-reaching changes will be made to the composition of the AERIUS team, because of the fact that the collaboration and interaction between the members of the development team will only get better with time, and because together they form the memory of AERIUS. Another reason is the current level of ambition of the AERIUS programme.

2. Organise the front end of the development pathway

Create a functional architecture as a transitional product between the content and the system development pathway. Such functional architecture is to:

  • enable better estimations of the planning and costs of the functionalities to be realised, and to be able to make realistic projections of costs as well as delivery dates;
  • enable impact analyses to be conducted before the start of the sprints, and to refer costly or difficult-to-achieve wishes back to those responsible for the content;
  • enable further structuring of the development process and realisation of functionalities in a single effort, resulting in productivity improvements.

3. Organise the back end of the development pathway

  • When delivering AERIUS II.0 to the envisaged manager, try to act as if this concerns a complete delivery to a management organisation. This means that, at the time of delivery, the architectural requirements and programming qualities must be met, and that the documentation is ready for user testing and maintenance. 
  • At the completion of each sprint, spend sufficient time to update the documentation and to ensure that it continues to meet the requirements for transference.  

More information