Resource Index > Reviews: Project, Design and Deliverables

Reviews: Project, Design and Deliverables

=== View Know-How by Subject === Skills - People    —Leadership    —Team Building    —Conflict and Issue Management    —Time Management    —Communicating Skills - Project Management    —Planning and Scope    —Scheduling/Estimating    —Tracking and Control    —Risk Management    —Financial Analysis and Cost Management    —Requirements and Change Management Skills - Technical    —Architecture    —Reviews: Project, Design and Deliverables    —Testing Techniques    —Configuration Management    —Documentation Organizational Processes    —Implementing Project Management    —Virtual/Distant Teams    —Metrics    —ISO 9000 and Regulatory    —Managing Multiple Projects    —Product Development Processes    —Knowledge Management    —Project Management Tools    —Career Development

Every project should involve a number of reviews, even if some of those reviews are informal. Project reviews provide the customer, sponsor, and stakeholders an opportunity to assess progress and approve the project moving forward. These meetings are typically held near the end of a major project phase and are typically called project Phase Reviews. Deliverables reviews (including "design reviews" on some types of projects) are held to make sure requirements are being met, remaining risks and work are understood, and the deliverables themselves are correct. All reviews are aimed at making sure the project work is on track to meet completion criteria and ultimately ready for release to the customer, and provide timely feedback to the development team.

The theme of an end-of-phase management review is to ensure that sufficient work has been completed in the current project phase to allow the project to enter the next phase without an unacceptable increase in project risk. Thus the checklist covers not only the work done in the previous phase, but also checks that foundations have been set for the next phase's work.

Phase Signoff Process
A short process guideline developed by a company whose product life-cycle called for team and executive signoffs at the end of project phases and at two other key project checkpoints.

End of Initiation and Planning Phase Checklist
At the end of the Initiation and Planning Phases a fully-represented cross-functional team should have fleshed out the project definition via detailed requirements, made major design or project approach decisions, completed an economic analysis of the costs and benefits of the project, and created detailed plans for time and resources.

End of Execution Phase Checklist
Once this phase is done, this overall project deliverable has been created and shown to work and meet the requirements and the project business case.

End of Approval Phase Checklist
The Approval phase is focused on examining/testing/reviewing the nearly-completed project deliverables from the customer's viewpoint, using the original requirements, and against the company's business case for undertaking the project in the first place.

End of Delivery Phase Checklist
The Delivery Phase is the final phase of the project, during which delivery/deployment to customers or users will begin. Thus the phase checklist for Delivery is the final project review of successful completion and readiness for release to customers.

Many projects involve designing something new — the "deliverable(s)" of the project — whether it be technology-related or new marketing collateral or some other type of creation. The goal of design or deliverables reviews is to find omissions, problems, misunderstandings and mistakes as early as possible in the project. The "design" stage, when the entity being created still exists on paper, is when problems are the fastest, easiest, and cheapest to fix. Therefore having good reviews of deliverables and designs as you go during a project is key to staying on track with scope, time, and costs. These review tools help a project plan for thorough reviews of the designs at key points in the project, along with, very importantly, making sure that based on the current designs, the project is still on track to meet its overall goals.

Review Meeting Planning Worksheet
A format to use to plan an upcoming review meeting, to be sure it will accomplish what you need it to, and plan the appropriate pre-work to ensure the meeting itself can achieve those goals.

Coding Review Guidelines
Example of Code Review Guidelines, providing a look at the whole landscape of a good code review process, along with detailed checklists and forms for capturing what's found in the reviews.

Review Checklists: Preliminary Design Review
Checklist for Preliminary Design Reviews (PDR), to allow the Project Leader and team to suggest and review alternatives in solution options to meet the project's goals, and the corresponding scope, schedule, costs, and risks of the possible alternatives.

Agenda for Preliminary Design Review Meeting
This template provides a detailed agenda with typical timeslots for a Preliminary Design Review (PDR) meeting on a project.

Review Checklists: Detailed Design Review
A checklist for conducting a Detailed Design Review after a preliminary specification has been written, and sufficient detailed design work and/or simulation has occurred.

Review Checklists: Critical Design Review
A checklist to guide a Critical Design Review, held when a "prototype" of the project deliverable exists that everyone can review thoroughly. At this point the design has been brought to life in an initial form, and the team is making a "critical" assessment that it will meet the goals of the project before proceeding further.

Review Checklists: Final Design Review
A checklist for the Final Design Review, the last milestone in the design process before the team moves from "development activities" to validation and production-type work. This review must ensure that the deliverables are truly ready to take this major step, because beyond this point typically many more people will become involved, and more money spent, as deployment to customers nears.

Completion criteria are explicit goals that must be attained to call an element of a project, or the entire project, "complete." They are a communication tool and an important aspect of "quality management" on a project. They ensure the team agrees up front on when a particular activity or phase will be considered "done" and then plans work, testing, and reviews accordingly. Finally the criteria are used to assess whether a deliverable is ready to 'release' to the customer.

Guidelines – Completion Criteria
A guideline for how to set completion criteria for your project or parts of your project-explicit goals that must be attained to call an element of a project "complete."

Software Quality Release Criteria
A succinct document that summarizes the testing and release criteria with which the software's quality and completeness will be judged at various stages of the project and what criteria it must meet to be released.

Checklist for Manufacturing Release Readiness
A checklist for ensuring that before a product's documentation is released to Manufacturing to begin production builds for customers, all important aspects have been covered.

Release Decision Process Guidelines
Guidelines to be used near the end of a project to systematically review open issues and determine which ones must be corrected before the deliverable(s) can be released and the project considered complete.

Customer Acceptance Checklist and Signoff
Checklist to use with a customer while walking through a review and test of a pre-release system, allowing the customer to record issues, indicate which must be resolved before acceptance, and ultimately sign off on accepting the new system.

©Copyright 2000-2012 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy