CU Home
Columbia University in the City of New York  

AcIS > Dev > Docs > Project Guidelines


Overview

Too many poorly defined projects of uncorrelated priorities with ever increasing requirements and fluctuating specifications reduces our ability to produce high quality, maintainable work. In addition, poorly coordinated projects create confusion and reduce our ability to provide support. These project guidelines are intended to address these issues.

Policy

Unix Systems projects proceed through eight phases. The intent of these phases is to ensure proper requirements and development guidelines are followed. It is not our intention to make project development overly bureaucratic, rather we want to make sure resources are allocated to the correct projects in the correct order.

Projects subject to Project Management are

  1. All user facing projects, regardless of size, except bug fixes
  2. All projects identified as "major" by the group manager and lead
  3. Personal or research projects only when there is a conflict of time committment

Phase I: Request For Project Consideration

Items that must be defined during this phase (by management)
  1. A brief summary of the project, including
    1. In detail, the problem to be solved
    2. Why the problem must be solved
    3. What must be accomplished in order for the solution to be acceptable
  2. The project proposer. This is the person or group that originally proposed the project.
  3. The project owner. This is the person who accepts responsibility for the project concept, and is usually the person who initially proposes the project. The project owner must be one person, it may not be a committee or a group. The project owner is similar in concept to a "customer", except that there could be multiple customers for a given project.
  4. Any interested parties. These are other persons or groups who should be notified of the project or involved with it because the project intersects with their work. For user facing projects, the support center should identify a liason to the project.
  5. What level of support the project will require and who will support it (the production supporters). By default, the group developing the project retains responsibility for maintenance issues other than those related to normal operations.
  6. If known, the expected life cycle of the project.
  7. Project phase requirements. The project owner, group manager, and group lead may agree to exempt the project from subsequent phases or parts of phases.
Sign off for completion of this phase
  1. The group manager must sign off to indicate project acceptance.
  2. The group lead must sign off to indicate project acceptance.
  3. If the group developing the project is not the same as the group supporting the project, the supporting group's manager and lead must sign off to indicate project acceptance.
Conditions for refusing sign off
  1. A detailed reason must be provided to the project proposer and project owner to explain why the project was declined.

Phase II: Project Assignment

Items that must be defined during this phase (by management, in consultation with the developers)
  1. The principal developer. This is the person who has responsibility for the development of the project.
  2. Any associate developers, and their roles.
  3. The project priority. In coordination with the project owner, the priority is set relative to other projects. Project priorities are from 1 (highest) to 5 (lowest), using the following guidelines:
    1. Critical functionality missing or ongoing breakage.
    2. Preventative development or recurring breakage.
    3. Medium term goal or occasional breakage.
    4. Long term goal or low impact.
    5. Desirable, but no clearly definable need, or no impact.
    Priorities may then be adjusted up or down according to the magnitude of users affected (or lack thereof).
  4. An estimated completion date, except for priority 5 projects.
Sign off for completion of this phase
  1. The group manager must sign off on the project priority and estimated completion date.
  2. The group lead must sign off on the project priority, selection of developers, and estimated completion date.
  3. The principal developer must sign off on the estimated completion date.
  4. The project owner must sign off on the estimated completion date.

Phase III: Project Design

Items that must be defined during this phase (by the project team)
  1. The implementation proposal, including
    1. The technical specification, including a description of logging facilities
    2. The implementation schedule, including identification of major milestones and developer assignments if the project has associate developers, as a series of estimated times per phase, not as proposed calendar dates
    3. Risk management assessment, including identification of potential problems and alternative paths if these problems occur
    4. Plans for implementation testing (Phase IV) and deployment testing (Phase V)
    5. Dependencies and necessary resources, including provisions for redundancy and scalability
    6. Requirements for decommissioning the project at the end of its life cycle
    7. Documentation for both end users and production supporters must be addressed, and where possible should be drafted in advance of coding/development
  2. A tally of the estimated costs (programmer time, expenses, etc) as identified by the implementation proposal.
Sign off for completion of this phase
  1. The group lead must sign off on the implementation proposal.
  2. The principal developer must sign off on the implementation proposal.
  3. The project owner must sign off on the implementation proposal.
  4. For public facing projects, the support center liason must sign off on aspects of the implementation proposal relating to user impact and interface.
  5. The interested parties should sign off on the implementation proposal.

Phase IV: Project Implementation

  • At this point, the design has been finalized. The only changes permitted are
    • To correct errors
    • To add new features if adding them later would represent a significant burden
    • With the approval of the group lead
    Any changes must be brought to the attention of the interested parties.
  • At each milestone, the implementation proposal is reviewed by the development team with the group lead against experience, and the project owner and interested parties are given an update. Complex coding projects should undergo code review at appropriate milestones, to familiarize the code to other developers and secondarily for technical evaluation.
  • It is the joint responsibility of the group lead and the principal developer to ensure the project implementation is proceeding as proposed.

Phase V: Project Development Completion

Items that must be completed during this phase
  1. Project evaluation by the group, to discuss what was learned from this experience.
  2. Testing in a non production environment.
  3. Documentation added to the systems manual, including a pointer to the source code.
  4. Training for who will support the deployed project.
Sign off for completion of this phase
  1. The group lead must sign off on the completed project and that testing was successfully completed.
  2. The principal developer must sign off on the completed project.
  3. The project owner must sign off on the completed project.
  4. The production supporters must sign off on having received adequate training.
  5. The interested parties should sign off on the completed project.
Conditions for refusing sign off
  1. Sign off on the completed project implementation may only be withheld if the implementation proposal was not adequately followed and if the project goal was not achieved (ie: the required features were not met). New feature requests are insufficient to withhold sign off, and must be considered a new, separate project.

Phase VI: Project Deployment

Items that must be completed during this phase
  1. Appropriate monitoring incorporated into the systems monitor.
  2. Deployment scheduled in consultation with the interested parties, and an announcement made with sufficient advanced notice.
  3. Transfer of routine operational support to the production supporters.

Phase VII: Project Maintenance

(There are no specific topics for this phase covered by this document.)

Phase VIII: Project Decommissioning

(There are no specific topics for this phase covered by this document.)
$Revision: 2.0 $


http://www.columbia.edu/acis/dev/unixdev/doc/project-guidelines.shtml Wednesday, 11-May-2005 11:47:14 EDT