Version 1.9 Build 1367

News	FAQ
Search	Home

Next: Strategic Planning Up: No Title Previous: Technical Development and Infrastructure

Subsections

Organization and Project Management

The AIPS++ Consortium

The AIPS++ Consortium is an informal collaboration between dissimilar institutes with different short-term agendas. The only common ground of the institutes involved is a motherhood-type long-term goal. In addition there are cultural differences between the adhering countries. To illustrate some of the differences:

European countries have been involved in many collaborative projects in astronomy for many decades at a variety of levels:
- government, e.g., ESO (D-DK-S-I-CH-NL-F-B)
- agencies, e.g., IRAM (D-F-E), ING (NL-GB-E)
- institutes, e.g., EVN (D-NL-PL-I-GB-S)
Australia has some experience as well. In the US international cooperation has only recently started.
National facilities are sometimes run and directed by national bodies, but in other cases they are autonomous, providing a national facility with only retrospective accountability.
Some of the partners are private institutes, some national facilities.

A collaboration comparable to the AIPS++ Consortium is the EVN (European VLBI Network). It is an open collaboration between European institutes (some national, some private) to coordinate VLBI observations. In addition to the members it even has associate members (F-CHN-USSR). The EVN assumes control of the telescope infrastructure of its members for certain periods of time (for coordinated observing campaigns) and has recently instituted a European VLBI Institute. The EVN has also built a satellite receiver as a joint but distributed project.

The general operation of the EVN is as described by the rules above, some of which were copied from organizations like ESO and of which came into existence after the signing of the initial ``motherhood'' MOU.

Recommendations:

For such an organization to work, the following ground rules should be observed:

A clear MOU should be defined, stating the responsibilities of each of the partners in the collaboration, and the goal to be attained.
Partners should have a vested interest in the goal of the project.
Political decisions about the adherence to the MOU and changes to it should be made by representatives of the institutes that can make decisions about financial and manpower matters (Steering Committee).
Technical and scientific advice on the project should be given to the SC by an Advisory Group consisting of scientists (in this case astronomers and computer scientists). This advice could be on matters raised by either the SC or the AG itself.
Project management should report to the SC (and give information to the AG if requested), but it, and the project workers, should not be members of the SG.
Partners should be ``equal,'' i.e., they should contribute according to their relative size and/or benefits.
A clear work-plan and design should be present and be regularly updated and detailed by the PM. The PM should report to the SC on this plan, and any changes should be vetted by the SC.
Whatever happens, it should be clear where and when decisions are made (and should be made) and they should be communicated to all project members.
Communications between project members should be regular and open.
Distributed groups should have well identified (sub-)tasks, with planning and design criteria attached.
A collaboration budget (even if only minimal) should be available to the Project Manager.

Steering Committee

The Steering Committee has been ineffective in providing clear strategic and management guidance to the Project Manager and the development teams. This has led to a severe lack of credibility and direction for the project. Much of the development is now motivated by technical prerogatives, rather than user-specified requirements.

The minutes of the Steering Committee contain evidence of many good intentions that have ultimately failed in their execution. The statement that the concerns of the Steering Committee are with policy is all well and good, but a bit pointless when it is clear that much of the policy has little impact on the everyday reality of the project.

The structure of the Steering Committee is anomalous in that site Technical managers are, in most cases, also Steering Committee members and in that the Project Manager also represents one of the Consortium partners on the Committee. Consequently, it is not surprising to find a confounding of motives and viewpoints among Steering Committee members. The lack of control over resources exercised by most of the Steering Committee members means that there are serious problems in getting Consortium Members to commit and supply the resources necessary to meet Project goals.

Recommendations:

The Steering Committee should seriously consider reconstituting itself in such a manner that binding decisions can be made, without appeal to higher authority.

The Steering Committee needs to formulate a clear and agreed strategy for achieving the AIPS++ mission statement, that is then communicated to the Project Manager as an unambiguous determinant of his/her role.

The Steering Committee needs to provide clear guidance to the Project Manager on both technical and end-user priorities, so that he/she is empowered to make decisions that reflect the intentions of the Steering Committee.

There should be no confounding of roles within the membership of the Steering Committee.

Project Management

The AIPS++ project is not managed, despite the existence of a Project Manager role, in any conventional sense of the word. The AIPS++ project can best be characterized as

anarchic and out of control;
driven by egos, private agendas and personal chemistry;
having most decisions justified on a post-hoc basis;
not guided by a clear set of requirements;
having ill-defined release functionality;
suffering from a fluctuating resource base;
having no meaningful schedules, milestones, or understanding of internal dependencies; and
surviving only because of the skill and dedication of a few individuals.

Recommendations:

A full-time and effective Project Manager needs to be put in place immediately.

Realistic project management techniques must be adopted immediately for the AIPS++ project. This should include the following, as a minimum requirement:

Sensible (can be achieved) and meaningful (based on defined requirements) schedules, work-plans, and resource allocations (with committed resources), all driven by the Steering Committee's strategic plan.
Regular management and technical reviews, with reports to the Steering Committee.
Recording of actual effort (so that estimation techniques can be refined and so that real costs can be calculated).

Appropriate project management skills must be acquired.

AIPS++ should not be considered as a research project, but rather as the construction, in software, of a ``research instrument'' which can be deployed by astronomers to advance their science. It is recognized that new software technologies are important in the development of the system, but their usage in the project should be carefully considered.

Skills Base

There is a longer-term issue that relates to the provision of the software engineering skills needed to support the distribution and evolution of successive version of AIPS++ once it is used as a ``research instrument'' by practicing astronomers. Software engineering capability will become important as AIPS++ evolves and becomes increasingly relied on. New modules and applications developed by astronomer programmers will need to be guided by ``best software engineering practice.''

Recommendations:

Establish a small software engineering support group (2 or 3 persons) at the AIPS++ Project Center.

Next: Strategic Planning Up: No Title Previous: Technical Development and Infrastructure Contents