Presentation is loading. Please wait.

Presentation is loading. Please wait.

Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005.

Similar presentations

Presentation on theme: "Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005."— Presentation transcript:

1 Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005

2 Funding The SDSS was `incrementally funded'. This makes for an interesting game for the institutional fundraisers, but is not particularly productive for the scientists. It is terribly important to have the funding in place early.

3 Partners 1. In collaborations, as in life, pick them carefully. Collaborating closely with people you do not like is possible, but unpleasant and difficult to make productive. 2. Institutional partners, whatever their merits, are likely to have vastly different capabilities. This must be recognized by all concerned at the outset, and the organization and management must be flexible enough to cope with this smoothly. 3. In-kind contributions as part of the project budget are especially difficult in a consortium and must be managed very carefully and skilfully to avoid trouble.

4 Organization at the University Level The SDSS was run as a project under the ARC umbrella; this in general worked well enough, but was not necessary; a consortium built especially for the project would probably have been better. The governing body for the SDSS was an Advisory Committee which was a subbody of the ARC board of governors. Not a good idea. Makeup of the AC was half scientists, half university financial administrators. Maybe a good idea. Consortium is a corporation. Very good idea, allows funding and spending flexibility.

5 Management 1. Must have complete fiscal control (and as a prerequisite complete trust of the consortium.) The fiscal authority of the management was never properly defined in SDSS, and the result wasdisastrous. 2.It is not a good idea for the project manager to be an employee of a consortium institution. 3. The project manager must be able to control in-kind efforts. Tricky, but necessary. In particular, in-kind must be measured in real dollars, and, (we see in in hindsight), should be handled as a contract which can be cancelled as a result of poor performance, endebting the parent institution. 4.All of this is easier if the PM has an institutionally well- represented and carefully chosen advisory committee.

6 Special Considerations for Running a Survey 1. The project is much broader than building a telescope and instruments, and demands attention to the broad software suite, data model, data QA, data distribution, data access tools, etc. 2. In particular, these `data tools' need to be ready on the same timescale as the telescope and instruments, and their commissioning needs to be integrated into the commissioning of the hardware, so that at the end of commissioning, the data are ready to flow. 3.Arrangements for public distribution of the data need to be worked out in messy detail with the consortium and with the funding agencies, in particular the proprietary periods (which in our view are necessary for data quality control if nothing else.)

7 In a survey, the software task is much broader and more difficult than for a telescope project alone. If the PM is not an expert software manager (and probably even if he or she is) a software manager is needed, reporting and responsible directly to the PM and his/her advisory committee Software Management

8 A survey is very different from the scientific organization point of view from building/commissioning a telescope and first light and subsequent instruments. Several questions need to be asked at the outset: 1. Turf. Is there any? Who gets to do what science during (and after) the proprietary period. 2. Should there be `Key Projects?' If so, how should they be organized? 3.Should outside collaborators be allowed? encouraged? How should they fit into the goals of the collaboration? 4. How should the telescope/instrument scientists be integrated into the survey science output? Scientific Organization

9 And some general issues: 5. Data releases and data QA are very time-and-effort-consuming, and must (we find) be largely executed by the scientific core of the project. These tasks must be distributed equitably. 6. A mechanism must be in place (even if never used) to arbitrate disputes over authorship, individual rights, protection of students, etc....and these issues must be dealt with for general cases ab initio and clearly. 7.There is no substitute for communication, face-to-face whenever possible, certainly often enough and for long enough for the principals to be comfortable with each other, and by phone regularly. Scientific Organization 2

10 Take the time and the money to do it (whatever IT is) right the first time whenever possible. Shortcuts are never cost-effective, either in dollars or time in the long run....and usually the long run is pretty short. The quality of the data at the output of the survey is dependent on an enormous array of factors, and it takes very little shoddy input to contaminate the whole affair. And, Finally, a Management Platitude:

Download ppt "Some Lessons from the SDSS J. Gunn, CCAT science workshop Oct 2005."

Similar presentations

Ads by Google