• Evaluate from time to time the potential risk that could affect project schedule, cost & quality
• Estimate the chance of occurrence, i.e. high, medium or low probability
• Estimate the severity of impact, i.e. critical, high or low
• Register and report the risk by matrix to inform related parties immediately but not wait
• Discuss with all responsible parties, seek for advice on how to put the project back on right track

* Management should never work on own assumption but check with staff advice

• Involve earlier top management making final decision or front-end staff well-known of operation
• Prefer continuous & incremental change limiting project scope instead of big change
• For new technology, if staff without 2 years of experience, work with partner and let them to do
• Don’t use different terms between users and development teams to avoid misunderstanding
• Use common technology and tool to avoid no market solution or no staff could follow up later on
• Not use latest software but stable one with talent and solution available
• Aware of security & privacy control leading to disaster and loss of sensitive or personal data
• For security bug fix, if software incompatible, need to think of another workaround
• Source code control to keep major version of different time
• Code change and deployment need to pass through validation of potential problem and approval
• Allow fallback of last version by using daily backup of application and database
• Prepare stand by resources to avoid serious effect on project for staff sick or leave, e.g. training
• Peaceful management and work, extreme action could only make situation worse
• Not to hide problem but encourage open discussion of finding solution together
• Fallback and failover plan and procedures for staff to follow in case of incident
• Reference to inventory list showing license or warranty expiry date help to follow up earlier
• Prepare stand by resources in case staff leave suddenly