Friday, July 29, 2016

Project Quality Audit Reviews Process Q110

Q110 - Check Work Done against Plan

SIIPS Quality Audit Reviews Processes (Q).png

DEFINITION

SIIPS Q110.pngCheck that all planned tasks have been completed.  Explain and document any discrepancies, and agree any remedial actions required.

SUMMARY

The work required according to the project’s path plan and segment plan is checked against project tracking data to ensure that all planned tasks have been undertaken.
Any deviation from the planned work should be identified and reviewed with the project sponsor and those persons responsible for ensuring the project’s quality.  They may either:
  • certify that the deviation or omission is acceptable, or
  • define corrective action that should be taken.
Any impact on timescales, costs or resourcing should be identified, but the detailed evaluation of the impact should be handled by the normal project management and control procedures.  It may be appropriate to update the project’s issues control process.
Where a project or the client organisation is operating according to formal quality standards, these should be followed in performing this process.

PATH PLANNING GUIDANCE

This process is optional.  It is only used if project tracking is being used such that the work done conducted can be measured and reviewed.

DEPENDENCIES

Prerequisites (Finish-Start):
  • Production of the Segment Plan
Prerequisites (Finish-Finish):
  • All preceding segment processes
Dependent procedures (Finish-Finish):
  • QA signoff (Q180)

RECEIVABLES

  • Quality Plan
  • All deliverables from the preceding segment

DELIVERABLES

  • QA signoff checklist - Processes and Tasks form
  • Revised Path Plan / Segment Plan for remedial work (if any)
  • Corrective Action Requests (as required)
  • Corrective Action Request Log (updated)

TOOLS

  • Examples: QA signoff checklist - Processes and Tasks form
  • Skeleton deliverables: Corrective Action Request
  • Path templates for the segment
  • Process descriptions and examples for the segment

DETAILED DESCRIPTION OF TASKS

Review the work done

The processes and tasks will normally have been defined and planned during the project and segment launch processes.  The actual work performed should be checked against these plans to assess whether:
  • the tasks were carried out, and
  • the tasks were completed.
Evidence for the work carried out is normally taken from the project’s tracking system, but other techniques may be used to establish whether the work was conducted as planned.  Where a task was not conducted or completed, it should be investigated why this was.  The results may be recorded on a QA signoff checklist form.

Define and agree remedial actions

Any deviation from the planned work should be identified and reviewed (if appropriate) with the project team members involved, the project sponsor and those persons responsible for assuring the project’s quality.  They may either:
  • certify that the deviation or omission is acceptable (this would usually be noted on the QA signoff checklist form), or
  • define corrective action that should be taken, normally by issuing a Corrective Action Request (CAR).
Any remedial action required should be discussed and agreed in principle with the project’s sponsor.  This work should normally be viewed (and tracked) as a re-opening of the deficient tasks and processes within the preceding segment - not as a new area of work to be undertaken.  It should be performed (in principle) by the same people and under the same budget as the original deficient tasks.
Where remedial work is to be undertaken, it should be considered whether:
  • the deficiency requires attention before continuing with the following segment, or
  • the deficiency could be corrected by work during the following segment.
In all cases, it is appropriate to set time limits for completing the required actions.  Details of the required actions, responsibilities and dates are entered both on the Corrective Action Request (CAR) and summarised in the CAR Log.
Any impact on the project’s overall plans, the cost/benefit projections, resourcing needs, timing/scheduling, and contractual issues should be identified.  It should be dealt with according to the project’s normal approach to project management and issues control rather than being treated as new work or as part of the QA process.

Reviewing the remedial work

This process does not normally deal with undertaking the remedial actions.  The remedial work would be the subject of other processes and tasks.

The person responsible for monitoring QA reviews (normally as defined in the project’s Quality Plan) should monitor and review the outstanding Corrective Action Requests (CAR) based upon the CAR log.  When the actions have been completed, the results must be re-submitted for review under this process.

Sunday, July 24, 2016

Project Quality Audit Reviews Process Q100

Q100 - Check Deliverables against QA Checklist

SIIPS Quality Audit Reviews Processes (Q).png

DEFINITION

SIIPS Q100.png
This is a formal review to ensure that all required deliverables have been produced, reviewed and accepted following the methods and quality controls stated in the pre-defined Quality Plan.  It is not a review of the quality of the work or deliverables.

SUMMARY

A checklist of deliverables and their required acceptance / authorisation procedures will normally have been prepared during quality planning in the launch processes.  This is a formal review to ensure that all required deliverables have been completed and accepted according to the pre-defined quality plan.  This is not a review of the quality of each document - it is only a review that the correct approval methods and procedures have been used.  Following the agreed approval procedures should be assuring the actual quality of the end-products.
Any deviation from the planned deliverables should be identified and reviewed with the project sponsor and those persons responsible for ensuring the project’s quality.  They may either:
  • certify that the deviation or omission is acceptable, or
  • define corrective action that should be taken.
Any impact on timescales, costs or resourcing should be identified, but the detailed evaluation of the impact should be handled by the normal project management and control procedures.  It may be appropriate to update the project’s issues control process.
Where a project or the client organisation is operating according to formal quality standards, these should be followed in performing this process.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):
  • Production of the Quality Plan
Prerequisites (Finish-Finish):
  • All preceding segment processes
Dependent procedures (Finish-Finish):
  • QA signoff (Q180)

RECEIVABLES

  • Quality Plan
  • All deliverables from the preceding segment

DELIVERABLES

  • QA signoff checklist - deliverables form
  • Revised Path Plan / Segment Plan for remedial work (if any)
  • Corrective Action Requests (as required)
  • Corrective Action Request Log (updated)

TOOLS

  • Examples: QA signoff checklist - deliverables form
  • Skeleton deliverables: Corrective Action Request
  • Path templates / Process Lists for the work segment
  • Process descriptions and examples for the work segment

DETAILED DESCRIPTION OF TASKS

Review the deliverables

A checklist of deliverables and their required acceptance / authorisation procedures will normally have been prepared during quality planning in the launch processes.  The actual deliverables produced should be checked against this list to assess whether:
  • they have been produced
  • they address the subject, objectives or scope as described in the plan
  • there is evidence that they have been distributed and reviewed according to the plan
  • there is evidence that they have been accepted and signed off according to the plan.
The results may be recorded on a QA signoff checklist form.

Define and agree remedial actions

Any deviation from the planned deliverables should be identified and reviewed (if appropriate) with the project team members involved, the project sponsor and those persons responsible for ensuring the project’s quality.  They may either:
  • certify that the deviation or omission is acceptable (this would usually be noted on the QA signoff checklist form), or
  • define corrective action that should be taken, normally by issuing a Corrective Action Request (CAR).
Any remedial action required should be discussed and agreed in principle with the project’s sponsor.  This work should normally be viewed (and tracked) as a re-opening of the deficient tasks and processes within the preceding segment - not as a new area of work to be undertaken.  It should be performed (in principle) by the same people and under the same budget as the original deficient tasks.
Where remedial work is to be undertaken, it should be considered whether:
  • the deficiency requires attention before continuing with the following segment, or
  • the deficiency could be corrected by work during the following segment.
In all cases, it is appropriate to set time limits for completing the required actions.  Details of the required actions, responsibilities and dates are entered both on the Corrective Action Request (CAR) and summarised in the CAR Log.
Any impact on the project’s overall plans, the cost/benefit projections, resourcing needs, timing/scheduling, and contractual issues should be identified.  It should be dealt with according to the project’s normal approach to project management and issues control rather than being treated as new work or as part of the QA process.

Reviewing the remedial work

This process does not normally deal with undertaking the remedial actions.  The remedial work would be the subject of other processes and tasks.
The person responsible for monitoring QA reviews (normally as defined in the project’s Quality Plan) should monitor and review the outstanding Corrective Action Requests (CAR) based upon the CAR log.  When the actions have been completed, the results must be re-submitted for review under this process.

Saturday, July 23, 2016

Project Decision Process D900

D900 - Decision to go Live

SIIPS Delivery Processes (D).png

DEFINITION

SIIPS D900 - Decision to go live.pngFinal review of the readiness of the system and formal decision to commence live running.

SUMMARY

The ultimate governing body or manager for the project should take the definitive decision to go live.  It must be certain that all vital pre-conditions have been satisfied to at least a minimum acceptable level, eg testing, data validation, training, organisation.  It does not require that all aspects of the project are completed - only those essential for live running.
Responsibilities for accepting the start up of the system should  have been agreed in advance as part of the System Handover Plan IP.  It may also be useful to agree in advance the precise acceptance criteria.

PATH PLANNING GUIDANCE

Mandatory

DEPENDENCIES

Prerequisites (Finish-Start):
  • System Handover Plan IP
Prerequisites (Finish-Finish):
  • Data conversion and data load
  • System Testing
  • set up of acceptable environment, eg facilities, support, trained staff
Dependent procedures (Finish-Start):
  • live running

RECEIVABLES

  • System Handover Plan IP

DELIVERABLES

  • Decision to go live

TOOLS

  • Examples: System Readiness Questionnaire
  • Examples: System Readiness Questionnaire
  • Examples: Package System Implementation signoff letter

DETAILED DESCRIPTION OF TASKS

A final review and check should be performed to ensure that minimum acceptable standards have been achieved (or surpassed) in those elements of the project essential for live running.  These might include minimum standards for:
  • functional testing and signoff
  • technical testing (including volume testing) and signoff
  • technical environment including schedules, backup/recovery provisions and operating supplies eg special stationery
  • staff availability, training and skill levels
  • definition of responsibilities and procedures
  • reference documentation
  • supplies of forms
  • data load or conversion and acceptance signoff
  • functional and technical support provisions and procedures
  • system management, administration and control
  • approvals from any other relevant bodies, eg auditors, parent company, government control authorities etc
  • awareness of other bodies, eg customers, vendors, employees, other departments, senior management, associated organisations, control authorities, data protection registrations etc
The criteria for acceptance may be discussed and agreed in advance.  It should be possible to make a detailed checklist for the project to indicate the precise checks to be made.
Most of the essential needs will have been met before the cutover, (eg system testing signoff).  It should be possible to note and agree that these requirements have been met in advance of the actual decision to go live.  By the time the start-up data is loaded and accepted, it should only be the acceptance of starting data that is required to complete this process and to agree formally that the system should commence live running.

Signoff

A computer system is never perfect.  The business costs or risks of imperfections should be balanced against the costs of obtaining a perfect system.  It is important that the start up of the new system is not unreasonably delayed by errors that can be resolved after it is live.  Note should be taken of any non-critical errors that are detected so that they can be addressed as soon as possible after live start up of the system.  The responsible users should indicate their acceptance that the system can commence live operations, and, if appropriate, that the old system should cease to operate.  This acceptance should normally be noted in writing.

Signoff should not require a large number of reviewers or a highly formalised process as this might unreasonably delay the cutover process.  It should, however, carry executive authority.

Project Decision Process D897

D897 - Conduct Final User Review

SIIPS Delivery Processes (D).png

DEFINITION

SIIPS D897 - Conduct final user review.pngA final review that the users and user management are ready to take control of the system and that they accept the system as delivered to them.

SUMMARY

This process involves conducting a final review of the new system and the implementation process with user staff and management prior to putting the application into production.  Also, forms, manuals, and business procedures should be distributed.  The objective is to confirm that users are prepared for the implementation of the new system, to provide last minute status and procedural information to facilitate a smooth transition, and to identify and address last minute concerns and issues.

PATH PLANNING GUIDANCE

This process is optional.

DEPENDENCIES

Prerequisites (Finish-Finish):
  • Define, plan and agree hand over / cutover (D830)
Prerequisites (Finish-Finish):
  • Validate start-up data (D890)
  • Conduct final operations review (D895)
  • Conduct final production / data control review (D896)
Dependent procedures (Finish-Start):
  • Decision to go live (D900)

RECEIVABLE

  • User procedures and manuals
  • Final operations review
  • Final production / data control review

DELIVERABLES

  • Feedback as required

TOOLS

  • Examples: System Readiness Questionnaire

DETAILED DESCRIPTION OF TASKS

Introduction

This process involves looking at results from the entire implementation and reviewing it generally as well as examining the detailed procedures.
Scope of review
The following activities should occur in a final user review:
  • review team member’s work
  • schedule  and conduct user review sessions
  • a system implementation review meeting
  • review system requirements and procedures to ensure their readiness for conversion and cutover activities  and daily job functions under the new production system.
  • complete any additional procedure recommendations, activities or documentation necessary to accomplish a successful production cutover
  • provide input to final preparation for user manual and other additional support documentation
  • distribute user manuals and any additional user support documentation required
  • assists in resolving final outstanding issues
The key to the final review is ensuring that the system is in order and that the users are comfortable with their ability and the availability of reference material

Decision to go live


The decision to go live is taken as the result of a formal agreement with the key representatives of the client organisation.  This is performed in Process D900.  Input from Process D897 would be reviewed in D900.