|
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
- All user facing projects, regardless of size, except bug fixes
- All projects identified as "major" by the group manager and lead
- 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)
- A brief summary of the project, including
- In detail, the problem to be solved
- Why the problem must be solved
- What must be accomplished in order for the solution to be
acceptable
- The project proposer. This is the person or group that
originally proposed the project.
- 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.
- 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.
- 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.
- If known, the expected life cycle of the project.
- 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
- The group manager must sign off to indicate project acceptance.
- The group lead must sign off to indicate project acceptance.
- 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
- 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)
- The principal developer. This is the person who has
responsibility for the development of the project.
- Any associate developers, and their roles.
- 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:
- Critical functionality missing or ongoing breakage.
- Preventative development or recurring breakage.
- Medium term goal or occasional breakage.
- Long term goal or low impact.
- 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).
- An estimated completion date, except for priority 5 projects.
Sign off for completion of this phase
- The group manager must sign off on the project priority
and estimated completion date.
- The group lead must sign off on the project priority,
selection of developers, and estimated completion date.
- The principal developer must sign off on the estimated
completion date.
- 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)
- The implementation proposal, including
- The technical specification, including a description
of logging facilities
- 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
- Risk management assessment, including identification of
potential problems and alternative paths if these problems
occur
- Plans for implementation testing (Phase IV) and deployment
testing (Phase V)
- Dependencies and necessary resources, including provisions
for redundancy and scalability
- Requirements for decommissioning the project at the end of
its life cycle
- Documentation for both end users and production supporters
must be addressed, and where possible should be drafted in
advance of coding/development
- A tally of the estimated costs (programmer time, expenses, etc)
as identified by the implementation proposal.
Sign off for completion of this phase
- The group lead must sign off on the implementation proposal.
- The principal developer must sign off on the implementation
proposal.
- The project owner must sign off on the implementation
proposal.
- For public facing projects, the support center liason must
sign off on aspects of the implementation proposal relating to
user impact and interface.
- 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
- Project evaluation by the group, to discuss what was
learned from this experience.
- Testing in a non production environment.
- Documentation added to the systems manual, including
a pointer to the source code.
- Training for who will support the deployed project.
Sign off for completion of this phase
- The group lead must sign off on the completed project
and that testing was successfully completed.
- The principal developer must sign off on the completed project.
- The project owner must sign off on the completed project.
- The production supporters must sign off on having received
adequate training.
- The interested parties should sign off on the completed project.
Conditions for refusing sign off
- 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
- Appropriate monitoring incorporated into the systems monitor.
- Deployment scheduled in consultation with the interested
parties, and an announcement made with sufficient advanced
notice.
- 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 $
|
|