This is a photo I took 8 years ago. It is from a textbook for the A-Level Computer Science Subjects. It uses the NHS IT project as an example of a failed project for a case study. I used the syllabus of the A-Level Computer Science as an example to encourage the education department and the IT industry in Hong Kong to update the syllabus and the teaching materials to include more real-life examples and case studies. This is to help the students understand real-world problems and prepare them for future challenges in the IT industry. The photo popped back up on my Facebook, reminding me I did this 8 years ago.

In my extensive experience as a project consultant, software architect, and developer, I have encountered numerous project failures and successes. Through these experiences, I have identified many reasons why projects fail and succeed, as well as various strategies to prevent failure and ensure success. While I may not have a definitive solution, I have learned valuable lessons about what should and should not be done.

Projects can fail for several reasons, which are common in many large IT projects. First, the project involved many stakeholders, each with their own requirements and expectations. These requirements often contradicted each other, leading to confusion and delays. To avoid this, it is crucial to ensure that all stakeholders’ requirements are aligned and do not contradict each other. Regular meetings and clear communication channels can help achieve this.

Additionally, the project’s goals, flow, and operations were not clearly defined. Without a clear vision, it was hard to align the efforts of everyone involved and measure progress effectively. There was not enough effort put into capturing requirements, leading to hidden and unclear requirements. This resulted in insufficient material to analyze risks effectively. Setting clear, achievable goals for the project is essential. These goals should be communicated to everyone involved and used to measure progress.

Another big issue was the disconnect between managers/clients and front-line operators. Managers and clients were not fully aware of the issues faced by front-line operators. They were often stuck in their own world, making decisions that were not realistic or practical. Managers and clients should spend time understanding the issues faced by front-line operators. This can be achieved through regular feedback sessions and site visits. Actively seeking and incorporating feedback from front-line operators throughout the project will ensure that the system meets the actual needs of its users.

The complexity of the project was also underestimated. The assumption that adding more programmers would speed up the project only made things worse, as described by Brook’s law. Developing a realistic project plan that considers the complexity and potential challenges is crucial. Additionally, the technology used in the project was not advanced enough to meet the ambitious goals, leading to technical challenges and delays. Ensuring that the technology used is advanced enough to meet the project’s goals is essential. Regularly reviewing and updating the technology stack as needed can help achieve this.

Poor communication and organization further compounded the problems. The project involved too many vendors, developers, managers, and stakeholders. The lack of organized communication channels resulted in misunderstandings and inefficiencies. Establishing clear and organized communication channels among all parties involved will help prevent misunderstandings and ensure that everyone is on the same page.

Lastly, there was no well-defined test plan or strategy, and not enough time was allocated for testing. This led to the deployment of a system that was not thoroughly tested, resulting in numerous issues and setbacks. Creating a well-defined test plan and strategy, and allocating sufficient time for thorough testing, will help identify and resolve issues before deployment, ensuring a more reliable system.

By addressing these issues, future projects can avoid the pitfalls that led to the failure of similar projects and increase their chances of success. Understanding the reasons for failure and implementing the recommended strategies can help ensure that large IT projects are completed on time, within budget, and meet the needs of all stakeholders. The lessons learned from my experience can be applied to other projects to improve their outcomes and achieve their goals more effectively.

UPDATE: 世界各地抗武肺病社群: https://bit.ly/3bizew3

P.S.: Hong Kong Team Number: 10294

在武肺全球爆發的時間, 科學界現在出盡一切辦法, 去找新疫苗. 我們一介平民, 除了勤洗手, 少出街外, 還可以做什麼?

只要你有電腦, 有電, 有上網, 就可以幫科學家盡快搵到疫苗, 以對抗武肺.

係咪咁簡單? 真係咁簡單.

只要到 https://foldingathome.org/start-folding/ 下載程式, 就可以將閣下家中電腦的運算力, 加入全球Folding的雲端運算, 去計算不同的蛋白質結構, 以盡快找出對付武肺病毒的方法.

詳情, 可以到 https://foldingathome.org/2020/03/15/coronavirus-what-were-doing-and-how-you-can-help-in-simple-terms/ .

Folding@home是一個研究蛋白質結構及由此引起的相關疾病的分散式雲端系統, 由史丹福大學化學系的Pande Lab主持. 研究的項目包括柏金遜, 老人痴呆, 瘋牛症, 癌症 同病毒, 如流感, 伊波拉, HIV, 同最新的武肺病等.

用法簡單, 安裝完後, 會自動直接在BLACKGROUND行, DEFAULT設定, 是在電腦無人用(IDLE)時就會開始下載運算. 運算有2種模式, 1 是用CPU, 2 是用GPU. 各位可以在晚上或外出時, 不關機, 加入這個PROJECT, 以幫助科學家盡快搵出解藥.

若好似本人有多過一部電腦, 可以將備用電腦入面安裝的FOLDING@HOME, SET做全速(While in working), 全天域在這非常時期, 幫科學界找答案.

人人為我,我為人人, 舉手之勞, 何樂而不為. 而且, 更為了人類未來.