What is a "Project"?

Any (one-off) task for the CO group will normally be treated as an official Project if either:

  • It is likely to take more than about 2 person-weeks of effort
  • It implies a significant change in technology or procedures

However, CEG may decide in individual cases whether or not this is appropriate.

Project proposals may arise from several sources:

  • Project proposals will frequently arise from within the CO group itself, as requirements for development of the infrastructure (internal projects).
  • Requests for research and teaching projects (including projects for the ITO) should be made directly to the head of the Research and Teaching Unit.
  • Requests for other administrative projects should be made via the service managers group, to the appropriate CEG representative.
  • Other requests for developments should be made directly to the head of the appropriate unit.

The "Development Meeting"

The Development Meeting is intended to monitor the quality and progress of development projects. It is also intended to make the priority and effort transparent to the whole School. The Development Meeting is not intended to make decisions on the relative priority of projects:

  • R&T Projects will be prioritised by the leader of the R&T Unit, in conjunction with the project requestors.
  • Internal projects will be prioritised by the appropriate unit leader, taking into account overall priorities determined by CEG.

Projects which require coordination of resources between Units will be assigned a leader by the HOC. R&T projects which require significant resources from other units must be agreed and prioritised with the HOC.

The Development Meeting will monitor the following stages in the implementation of a project:

0. Project Listing

(a) A description of the proposed project is entered into the project database.

1. Project Proposal

(a) When it is proposed to start work on a project, the proposal should be advertised for comment. This should be available at least one week before the Development Meeting. The project manager should include in the initial proposal a brief statement about any equivalent provision from the centre (IS) or other schools. The software that is proposed to be used on the project should be stated and a justification given for the choice. If the choice of software has not yet been made then this information should be provided before the project can move to the implementation stage.

(b) The proposal must be accepted in principle by the development meeting. This is simply an opportunity to prevent potential problems; for example, duplication of existing services, fundamental technical difficulties, etc.

(c) Any appropriate technical review procedures should be agreed at this stage.

(d) Any appropriate timescales should be agreed at this stage. This may be a "background" project with no timescales, or there may be fixed deadlines. Note that deadlines for internal projects are likely to change with internal priorities and should not be dependend upon without agreement of the project leader.

It is preferable that stages (b,c,d) occur at a project meeting. However, in urgent cases, these may be agreed by email (between all unit heads).

2. Project Evaluation

(a) In many cases, it may be necessary to undertake some preliminary investigation and experimentation to determine the most suitable solution. If there is equivalent provision from the centre (IS) or other schools then these should be reviewed as part of this investigation. In some cases, the solution will be clear and this stage will not be required. If the effort required for the evaluation phase is significant, it may be appropriate to assign timescales and monitor the progress at Development Meetings.

(b) An outline of the proposed solution should be entered into the project database and advertised for comment. This should include milestones, and timescales (if appropriate).

(c) The proposed solution must be subject to any agreed technical review (including agreement that the software language that is to be employed is appropriate - if not already agreed at the proposal stage).

(d) All Unit leaders (and the development meeting convenor) must actively confirm acceptance of the proposals before the project can proceed with implementation. This is necessary to ensure that all units are aware of any implications for their own areas.

In simple cases, where no evaluation is required, this phase may be combined with the previous phase and a project may proposed, together with its solution, at one Development Meeting.

3. Project Implementation

(a) The project is implemented. During development, progress will be posted regularly to the project database, and the project will be monitored against the milestones defined in the proposed solution. If a date for a milestone has been proposed and then subsequently this needs to be changed (postponed) then agreement should be sought at the Development Meeting for this change. The milestone proposed date should not be changed until after an amended date has been agreed at the meeting. If it is agreed that the proposed date for a milestone can be postponed then any other milestones for the project that are dependent on the changed one can also be postponed by the same amount. For projects with no defined timescales, it will be necessary to monitor progess regularly to ensure that they do not become delayed indefinitely.

(b) Documentation and procedures will be made available to all COs for acceptance. This documentation should include a short description of difficulties and lessons learned from the project process.

(c) Any projects which may affect the LCFG documentation must ensure that this documentation is suitably updated.

3s. Project Stalled

If a project was stalled then this fact should be brought to the attention of the Development Meeting and then its stage should be changed to 3s_Stalled in the project database.

4a. Project Acceptance

If a project produces a new service it should in general go through a settling in period for user acceptance prior to sign-off. In this state the project has effectively been completed but there may still be small ongoing amounts of work driven by issues identified by the users.

4. Project Signoff

(a) On completion, the implementation will be subject to any agreed peer review.

(b) External projects must be signed off by the external "customer".

(c) It is expected that projects introducing new or upgraded services, either to ourselves or external customers, will need to be running in production for a couple of months or so before being brought for sign off to allow for end user evaluation and addressing of bugs and deficiencies.

(d) The request to sign off a project should be mailed to computing staff at least one week before the Development Meeting. The project will be considered for sign-off by the Development Meeting.

(e) If the project has produced a new or upgraded service then an entry for that service should be created by the project manager in the Informatics Service Catalogue

(f) If the project has produced a new or upgraded service then it should be checked for compliance with the Platform Support Policy

(g) If the project has produced a new or upgraded service then it should be checked for compliance with the Logging Policy

(h) If the project has produced a new or upgraded user-visible service then a systems blog article and poster should be produced to promote the service.

(i) Once signed-off by the Development Meeting and any service catalogue entry has been created it will be considered by CEG for ratification.

4d. Project Dropped

If a project is to be abandoned or dropped for any reason then this fact should be brought to the attention of the Development Meeting and then its stage should be changed to 4d_Dropped in the project database.

Topic revision: r24 - 02 May 2011 - 11:16:56 - TimColles
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies