How to Manage Project Risk with Murphy's Law?

Image Source: PMtimes

Summarizing risk management is difficult when considering the concept of "risk." It cannot be summarized into a general concept due to the unique form, frequency, and probability of risk in each project.

Summarizing and analyzing risk with cases is also challenging as they are not replicable and may have different situations and content each time.

The realization dawned on me that the biggest risk variable in any project is the individuals involved. This insight left me stuck in my efforts to summarize risk management.

Recently, while reading Murphy's Law, I had an epiphany. Isn't it a summary of lifelong risks? This led me to consider using Murphy's Law as a tool to study and summarize risk management. After careful consideration, I had a breakthrough and decided to begin summarizing risk management using Murphy's Law. Let's start by summarizing some of the key principles.

1. Negative consequences will occur if there are any issues in the process.

At the commencement of a project, the product or project manager will organize the overall process and timeline of the entire product or project. During this phase, unexpected problems may arise that could result in a bug that affects the later stages of the project.

Despite their coding abilities, we may assume that Junior Zhang will not make a mistake in a minor issue, or that Senior Li, having designed many architectures, will not overlook a small problem. However, they sometimes make such errors and fail to identify them.

Tips 1:

In project management, all problems, no matter their size, should be documented and conveyed to team members as unavoidable "risks," even if they consider you to be wordy.

2. The most critical and fundamental part of a project is the bug.

Each project has a "critical path," which is the significant part that could be the e-commerce product's ability to pay, the OA product's workflow engine, or the IM product's push channel. These are so common that we often regard them as basic abilities and fail to notice their importance.

However, since they play such a critical role, they are bound to fail at the end of the project execution.

For instance, when I worked on an e-commerce product for a real estate project, everything went smoothly. The product's function planning, design, communication, and reporting were perfect, and I even began to envision with the customer that the product would generate a turnover of more than 10,000 RMB per day after the launch of the function. But the day before the estimated R&D completion time, the leader informed me that the payment directory of the customer WeChat public account had not been applied, and we needed to go through the application process, which would delay the launch by about two weeks.

It was a devastating blow to me. I wondered why such a basic thing as the payment directory was only mentioned now and why no one paid attention to it during development. However, the feedback I received was that every client had this capability except ours, and it was such a basic feature.

Tips 2:

During the project's initial review stage, focus on essential and fundamental capabilities such as the ability to pay, server, database, workflow, storage, or others. As long as they are vital and fundamental, they are bound to have mistakes.

3. Whenever you feel that everything is going well, there are bigger problems waiting for you

In project management, problems are a common occurrence and even if everything seems to be going well, there may be bigger problems lurking. I have worked on numerous projects and very few have been executed exactly according to the initial plan. I once worked on a million-dollar project for a joint-stock enterprise where everything was going smoothly halfway through the project. The bugs were fixed, the preparation for launch was ready, and the operation scheme was discussed with the client. However, one day, when I was preparing the acceptance documents, the client informed me that a consultant had been assigned to the project, and they wanted to replace me. This led to a series of fault-finding audits and made the final work extremely challenging.

Tips 3:

Don't be fooled by a seemingly smooth project process, always check and communicate with your team members to ensure that there are no hidden problems.

Image Source: Quora

4. The longer the progress report, the lower the work progress

During a project, team members are often required to submit daily or weekly reports to update their progress. As a manager who has been out of report writing for a few years, I have noticed two types of reports: one that is concise with key results and another that is lengthy with a lot of content but may not necessarily solve any problems. I often struggle with why my team members feel the need to include so much detail in their reports when a simple summary of results would suffice.

Tips 4:

Don't assume that the longer the report, the better the progress. Sometimes a concise report with key results is more effective than a lengthy report that doesn't solve any problems.

5. Meetings are often minutes saved and hours wasted

In my experience, large meetings can be a waste of time, and key issues can be resolved more efficiently in small stand-up meetings with a few key leaders. I once worked on an intelligent project for a large real estate company, and although we had finished our project, there was a delay in the weak current project. The person in charge of the weak current project, whom we called Jack, was a typical old-school manager who liked to hold weekly business update meetings with over 30 people from related enterprises. These meetings would take up a whole morning, and although they were intended to solve problems, they often didn't. In the end, the business update meeting proved to be completely useless.

Tips 5:

Large meetings can often be a waste of time, and it's better to have small stand-up meetings with a few key leaders to resolve key issues efficiently.

6. You must not have what the customers need most

As a project manager during my first two years, I discovered that customers require various materials at the acceptance stage such as detailed documents, design principles of database, prototypes, explanatory documents of the product, and relevant certificates. Although I had most of the materials, the customers required additional information.

Moreover, while we had launched the ABC function, customers demanded the ABCDE function.

Tips 6:

Regularly communicate with customers about their expectations and requirements during project delivery, including function, operation, acceptance, or other stages. Share your thoughts with them to avoid any missed issues.

7. The price of unexpected money is the unexpected loss with the same amount.

The cost of unexpected expenses is the same as the loss incurred by those expenses. This is similar to the saying "penny wise, pound foolish." The term "money" here doesn't always refer to actual money; it can also apply to project polishing.

In 2017, at the end of the year, the project team decided to gift the latest product function F to a state-owned enterprise to promote project acceptance. In exchange, the customer would give the green light for our initial acceptance process.

However, an unexpected situation occurred when the company decided to remove F function from the product in early 2018. Our company found it to be cumbersome, and no other customers were interested in buying it. When promoting the final acceptance in mid-2018, the customer found many bugs in the imperfect F function, even though it was given as a gift. They expected a high-quality product. As a result, we had to spend more than 20 R&D working days to improve the function, leading to certain losses for the company.

Tips 7:

When polishing a project or product, be careful not to be penny-wise and pound-foolish, as unexpected expenses can lead to significant losses.

8. If the problem can not be solved, let it be a characteristic.

In project management, it's important to accept that no project can be perfect, and customers may not be completely satisfied with all functions. When faced with unsolvable problems, it's better to turn them into unique characteristics of the project.

For instance, when we worked on a contract management project for a real estate company in 2018, the complex process we designed did not address the customer's concern about ease of use. After analyzing the situation internally, we realized that this problem could not be solved.

To address the issue, we changed our approach with the customer, from promoting the function to providing exceptional after-sales service. We assigned special personnel to train customers and offer on-site guidance for a week to ensure their proficiency.

As a result, while the customers were not completely satisfied with the function, they were impressed with our after-sales service.

To sum up, while it's impossible to predict and solve all problems, it's important to face and manage them. Doing so can even present new business opportunities. The principles of risk management and Murphy's Law can be applied broadly to various types of projects, beyond software delivery.