Checklists: To make sure you don't forget anything...Stick-Figure-with-Cheklist

Here you will find an ever growing number of checklists. Every third checklist we publish is available for the general public.
Checklist to make sure the Project Board effectively governs the project.
 
  • Mark all that apply.
  • Does the Project Board ensure the project Business Case remains valid?
  • Does the Project Board provide assistance to the PM when requested?
  • Does the Project Board review the Highlight Reports?
  • Has the Project Board approved the...
    • Initiation Stage Plan?
    • Project Brief?
    • Project Initiation Documentation?
    • Project Product Description?
  • Has the Project Board communicated the status of the Project?
  • Has the Project Board confirmed that ...
    • lessons from previous similar projects have been reviewed and incorporated?
    • the Benefits Review Plan covers all expected benefits?
    • the Business Case is viable, desirable and achievable?
    • the Configuration Management Strategy will deliver the approach expected?
    • the Quality Management Strategy will deliver the quality expectations?
    • there has been a risk assessment and that the risk response actions have been planned?
    • the Risk Management Strategy will safeguard the project?
    • the Business Case meets corporate or programme management standards?
  • Has the Project Board confirmed the validity and achievability of the Project Plan?
  • Has the Project Board informed corporate or program management that project initiation has been authorized?
 
Checklist to be used as a guide to navigate the 5 stages of the 6 Sigma DMAIC project methodology.
  • Mark all that apply.
  • DEFINE
    • Have you defined the project scope, objective, and schedule?
    • Have you defined the project team members?
    • Have you defined the stakeholders?
    • Have you gained authorization from the necessary project executive sponsors?
    • Have you assembled and trained the project team at a high level?
  • An appropriate benchmark has been chosen?
    • The Benchmark is based on statistical similar projects?
    • Average/median practice was used instead of best practice?
  • The benchmark has been compared to the forecast?
    • The variance of the forecast has been compared to the benchmark variance?
    • The forecast of ramp-up has been compared to the benchmark ramp-up?
    • The data used to create the forecast ramp-up has been provided?
  • The forecaster's track record has been reviewed and considered?
    • Did the forecaster provide ex post data on actual forecasting accuracy?
    • The available data for actual performance indicates accurate forecasts?
    • There is no "Bad Press" on the forecaster?
  • Further demand risks have been identified? Consider using PESTEL analysis:
    • Political
    • Economic
    • Social
    • Technological
    • Environmental
    • Legal
  • The expected outcome based on the benchmark analysis has been calculated?
  • The forecaster has been given the opportunity to respond to the analysis?
    • The forecaster's response is factual and supported by evidence?
    • The forecaster's response does not rely on the "uniqueness" of projects?
    • The forecaster's response does not rely on the "confidentiality" of projects?
*As based on original work by Professor Bent Flyvbjerg
 
Checklist to be used when creating and reviewing the Project Risk Management Strategy. The checklist ensures risk management strategies are defined and that a risk management strategy is in place.
 
  • Mark all that apply.
    • Quality Responsibilities are clear and understood by both customer and supplier.
    • Risk reporting requirements are fully defined.
    • Scales, expected value and proximity definitions are clear and unambiguous.
    • The chosen scales are appropriate for the level of control required.
    • The risk management procedure is clearly documented and can be understood by all parties.
    • All people working on the project are informed about the risk management requirements for the project
    • Key roles and responsibilities have been defined.
    • Key resources are trained and adequately skilled to take on the required risk management tasks.
    • The tools and techniques to be used for risk management are appropriate for the project and the environment they are to be used in.
    • The risk management records have been clearly defined including the risk register.
    • Risk reports have been defined including purposes, timing and recipients.
     
    Checklist to be used when creating and reviewing the Project Quality Management Strategy.
     
  • Mark all that apply.
    • Responsibilities for quality are defined up to a level that is independent of the project and Project Manager.
    • The approaches to assuring quality for the project are appropriate in light of the standards selected.
    • The defined ways are sufficient to achieve the required quality.
    • The strategy clearly defines ways in which the customer's quality expectations will be met.
    • The strategy conforms to the corporate or programme quality policy.
    • The strategy conforms to the supplier and customer quality management systems.
    • The tools and techniques to be used for quality management are appropriate for the project and the environment they are to be used in.
    • The quality records have been clearly defined including the quality register.
    • Quality reports have been defined including purposes, timing and recipients.
    • All people working on the project are informed about the quality management requirements for the project
    • The quality assurance process has been clearly defined.
    • Key roles and responsibilities have been defined.
    • Key resources are trained and adequately skilled to take on the required quality management tasks.
     
    Checklist to be used to define what the project must deliver to be successful. This includes the customer's expectations and the acceptance criteria for the project.
     
  • Mark all that apply.
    • The Project Product Description has been accepted
    • The Project Product Description is date stamped
    • The Project Product Description has a clear and well defined purpose statement
    • The composition defines the complete scope of the project.
    • The necessary key skills and resource requirements have been defined
    • The acceptance criteria address the requirements of all key stakeholders.
    • The acceptance criteria have been prioritized
    • The (customer's) quality expectations are defined and prioritized.
    • The method of acceptance has been defined and agreed upon.
      • The Project Product Description defines how the users and the operational and maintenance organizations will assess the acceptability of the finished product(s).
     

    Subcategories