• Is delivery going against approved Contract/Statement of work/work order? If not, is the mail for approval from senior management available for the delivery?
• Has the requirements document / FSD validated and approved by client?
• Are all the requirements implemented as per approved requirement document or specification document or as agreed with the client? If not, is it documented in the release notes / delivery note etc and approval taken from customer / delivery head?
• Are all Non-technical / non-functional requirements satisfied / completed?
• Is the build verification done before each Testing?
• Are all test cases updated to ensure complete test coverage?
• Are all cycles of testing completed and defects closed ? If any defcet is open, is it documented in the release notes / delivery note etc and approval taken from customer / delivery head.
• Are all review defects closed?
• Is the test Coverage Goal met as mentioned in test plan?
• Is the traceability from requirements to source code to test cases to test results documented and available for review?
• Is the goal for System testing / functional testing or any other type of testing is met?
• Are all the test cases for acceptance testing identified and documented?
• Are all audits done for the all items as identified in the software quality assurance plan?
• Are the findings of FCA / PCA / other audits closed (if any) ?
• Has the test cases executed on target environment (or similar of target environment) ?
• Is acceptance criteria for system validation available?
• Does end product / application meets the acceptance criteria during system testing ?
• Is the code modification history updated and code files are labled properly in the configuration tool?
• Are all the work products, deliverables and code consistent?
• Are the CIs of the entire release package identified?
• Is each CI in the release package CI tested / reviewed / approved?
• Are all findings of testing / review of CIs closed?
• Is the FTP credentials or CD key etc documented? Are these communicated to client / customer?
• Is release media and its access verified before sending the information to client?
• Are the following documents / deliverables / work products ready: FSD, ADS, DDS, Test Plan, Test Case, Release Note, Installable Product, Source Code, Test Programs, Drivers, Read me File, License File, Known Problems List, Installation Procedure, Install Scripts, User Manual, Programmer’s Manual, Administrator Manual, Test Reports, Training Material or any other deliverable required by client?
• Is the delivery made from the static folder of VSS?

Apart from above points, the status of below points can also be checked:

• Baselining of deliverables in configuration management tool
• End of project backup and restoration of the backup
• Readiness of maintenance / support plan
• Is the problem reporting procedure documented and communicated to client?
• Are the contact persons documented and communicated to client??
• Is the post release defect reporting template ready?
• Whether request has been made to IT for making the project repository under VSS read only?

Please Note: This is a sample checklist containing some general checkpoints. These checkpoints may vary from project to project or organization to organization. These checkpoints depends on the Quality Management System defined in the organization.

Project Charter: The WBS takes the project charter as its starting point. The highest level element in the WBS should represent the project’s overall end-point product(s), service(s), or outcomes as described in the project charter. If the project’s major products cannot be described during the creation of the WBS, then the project management team should examine the charter to determine if it has been sufficiently defined.

Project Scope Statement: The scope statement for a project is intended to clearly and succinctly describe what the project is and is not intended to accomplish. The high-level elements in the WBS should match, word-for-word, the nouns used to describe the outcomes of the project in the scope statement. If the project management team has difficulty identifying the objects in the scope statement and applying them to the high-level WBS elements, the team should carefully examine the scope statement to determine if it sufficiently captures all project outcomes and deliverables. The WBS Dictionary can also be used to further document and clarify each deliverable.

Program and Portfolio WBS: The WBS can be used to define scope for projects, programs, and portfolios. For example, program offices are typically established to share tools, techniques, methodologies, and resources in managing one or more collections of related projects as program(s). The project WBS must illustrate a clear understanding of the relationship among highly decomposed work packages within individual projects and program (or higher order) scope definitions. If strategic changes are made, the impact on projects, resources, and budgets can be easily calculated, assuming the project WBS has been constructed correctly in consideration of these higher order factors.

RBS: The Resource Breakdown Structure (RBS) describes the project’s resource organization and can be used in conjunction with the WBS to define work package assignments. The link between work packages and the RBS can be used to verify that all members of the project team have been appropriately assigned work packages, and that all work packages have owners.

OBS: The Organizational Breakdown Structure (OBS) is loosely related to the WBS. The OBS depicts the organization hierarchy, allowing the project’s work packages to be related to the performing organizational units. This tool reinforces the guideline that each work package should have a single point of responsibility. The OBS can be a useful tool for project managers in that it clearly demonstrates the hierarchy of people or groups, whereas the WBS is strictly organized by deliverables.

WBS Dictionary: The WBS dictionary is a key document that accompanies the WBS and carries critical project information. The WBS dictionary defines, details, and clarifies the various elements of the WBS to ensure that each component of the WBS is accurately articulated and can be communicated to anyone referencing the WBS. The development of the WBS dictionary often uncovers ambiguity or other errors in the WBS itself, and results in revisions to the WBS. The WBS dictionary contains information about each element of the WBS, including a detailed description of the work, deliverables, activities, and milestones associated with each element. The WBS dictionary might also include an indication of the type and number of resources required and contract control information, such as a charge number or other similar data. Often, a WBS dictionary will include traceability matrices linking the WBS to other scope control documents such as statements of work or requirements documents.

Project Schedule Network Diagram: The network diagram is a sequential arrangement of the work defined by the WBS, and is essential to uncovering project dependencies and risks. The activities within the WBS work packages are arranged to show recedence and order. Developing the network diagram often uncovers problems in the WBS, such as incomplete decomposition, the assignment of too much work in an element, or the assignment of more than one person for an individual WBS element, thus resulting in needed revisions.

Project Schedule: The various elements of the WBS are used as starting points for defining the activities included in the project schedule. Implied dependencies can be recorded in the WBS Dictionary, and the activities as described in the WBS Dictionary are then included as detail in the schedule.

• Metrics provides objective information throughout the software organization. This reduces the ambiguity that often surrounds complex and constrained software projects.

• Measurement helps managers to identify, prioritize, track and communicate project issues at all levels within the organization.

• Metrics can accurately describe the status of software project processes and products. It is key to objectively representing the progress of project activities and the quality of associated software products across the project life cycle. Metrics helps to answer questions such as “Is the project on schedule?” or “is the software ready to be delivered to the user?” etc.

• Project metrics facilitates a proactive management startegy. Potential problems are objectively identified as risks to be assesses and managed. Existing problems can be better evaluated and prioritized. Metrics fosters the early discovery and correction of technical and management problems that can be more difficult or costly to resolve lator.

• Software Project Managers can use metrics as a resource to anticipate problems and to avoid being forced into a reactive, fix \on fail approach.

• Metrics help the decision maker to assess the impacts of decisions objectively and make informed trade-offs to best meet project objectives and to optimize software project and product performance.

• Metrics provides an effective rationale for selecting the best alternatives. For example, the current software and IT business environments demand successfull project performance. Business, technical and project managers must be able to defend the basis of their estimates and plans with historical performance data. Then, they must be able to justify changes to plans with current performance data.

Analysis of metrics can give the following benefits:

• Increase return on investments
• Pinpoints opportunities for improvement
• Manage workloads
• Reduce Overtime
• Reduce cost

You must remember that risks can have negative and positive impacts. Positive risk is a risk taken by the project because its potential benefits outweigh the traditional approach and a negative risk is one that could negatively influence the cost of the project or its schedule.

The purpose of project risk control is to

- Identify the events that can have a direct effect in the project deliverables
- Assign qualitative and quantitative weight—the probability and consequences of those events that might affect the project deliverables
- Produce alternate paths of execution for events that are out of your control or can not be mitigated
- Implement a continuous process for identifying, qualifying, quantifying, and responding to new risks

The main goals to risk monitoring and control:

- To confirm risk responses are implemented as planned
- To determine if risk responses are effective or if new responses are needed
- To determine the validity of the project assumptions
- To determine if risk exposure has changed, evolved, or declined due to trends in the project progression
- To confirm policies and procedures happen as planned
- To monitor the project for new risks
- To monitor risk triggers

Risk triggers are those events that will cause the threat of a risk to become a reality. For example, you have identified the fact that you only have one pump set available and the replacement takes six weeks to arrive. In the middle of your irrigation and recycling process tests, you discover that water pressure tends to fluctuate beyond pump tolerance levels. If you do not find a way to solve this problem, your risk will become a reality.

Make sure that for each identified risk, you must provide a response plan. It is not much help to you if the risk becomes a reality or issue and you do not have an alternate execution path or some other emergency procurement plan.

Main inputs to to effectively monitor and control risks:

- Risk management plan
- Risk Register / Risk Tracker
- Risk response plan
- Project communications
- New risk identification
- Scope changes

Outputs of Risk Monitoring and Risk Control:

- Workaround plans
- Corrective / Preventive actions
- Change requests
- Risk response plan updates
- Risk database
- Checklist updates

1. Contribution to Quality

2. Risks Associated

3. Context of adoption

Model Name: Waterfall Model

Contribution to Quality: Phase End Checks

Risks Associated: Expects a task to be well done in the first go

Context of adoption: When the requirements are structured and competence is high

Model Name: Software Development Lie Cycle Model (ETVX Model)

Contribution to Quality: Entry task verification exit definition and quality control through feedback.

Risks Associated: Final Product available only after the complete cycle

Context of adoption: When the requirements are quite structured, but scale is large. One may need to go back for rework if required.

Model Name: Prototype Model

Contribution to Quality: 1. Seeing is believing. 2. Go iterative and involve customer. 3. Produce working models to give faster delivery and have concrete feedback.

Risks Associated: The scrap may go uncontrollable

Context of adoption: When needs to try out things before making a commitment to deliver.

Model Name: Spiral Model

Contribution to Quality: 1. Avoid scrap as well as rework – do right the first time. 2. Analyze risks before undertaking the next enhancement.

Risks Associated: Inadequate experience and subjective method of risk management

Context of adoption: When the scale is large and planned; passed development would give confidence to move ahead or stop as suited.

Model Name: V-Model

Contribution to Quality: Plan for testing of artifacts much before their actual completion

Risks Associated: Testing techniques applied may remain subjective

Context of adoption: It is a philosophy that can be applied with any other models you choose.

Model Name: Unified Process Model

Contribution to Quality: 1. Iterative evolutionary use case centric development. 2. Defines workflows and milestones for better project management.

Risks Associated: Identification of phases needs experience.

Context of adoption: When the scale of project is large.

Model Name: Agile Models

Contribution to Quality: Anytime delivery through flexible design, limited scope and quick reviews.

Risks Associated: Flexible design techniques not well established. The designers lack an understanding of business need for agility.

Context of adoption: When business needs are dynamic and need to be fulfilled immediately.