Strategies for Product Managers to Address Project Delays Source

Translated

Ⅰ. Reasons for Project Delays

Project delays are a common and frustrating issue for managers, which can be difficult for those outside the industry to understand. Many wonder why there always seem to be so many problems even when plans are made in advance. However, the nature of software development as creative work means that it is not a straightforward process. We don't know how many lines of code we'll need until we actually start writing it.

Based on personal experience, there are two main reasons for project delays:

1. Emergencies and Unexpected Problems

Workloads are typically assessed based on past experiences, which is unreliable in the unpredictable world of software development. Unexpected problems can arise at any time, and there are many unforeseen issues that can occur during development.

2. High Collaboration Coupling

The work of technicians involves high levels of collaboration and interdependence. The product manager proposes the requirements, followed by UI designs, UX designs, programming, and testing. If there is a problem at any of these stages, it can delay the entire project.

Ⅱ. Common Reasons for Work Delays

Here are some common reasons for delays in software development:

• Changing requirements, such as new requirements or constantly changing details
• Insufficient workload assessment and underestimation of function difficulty
• Misunderstanding of requirements leading to incorrect functions, which are discovered during testing or integration
• Additional temporary requirements, such as fixing online bugs
• Logical problems in new requirements that are not discovered until the project is underway
• Carelessness during self-testing leading to more bugs
• Temporary personnel changes
• Failure to take countermeasures after deviating from the plan
• Issues arising from technical difficulties, which require a change in approach
• ...

Although there are many potential issues that can cause delays, there are also many ways to address them. By finding solutions for each problem, it is possible to launch projects on time. While solving complex issues may take time, iterative processes and project reviews can help ensure successful outcomes.

Ⅲ. How to Address Project Delays?

To address project delays, I propose the following solution: Review, Identify the problem, Break down the problem, Develop a solution, Iterate, and Review again.

Image Source: 51miz

1. Review and Identify the problem

We need to review the cause of the previous delay and identify the problem. For example, the previous delay was caused by changes in requirements.

2. Break down the problem and Develop a solution

Next, we need to break down the problem and find a solution. We should ask ourselves questions like why the change is needed, if the change is valid, and if there are criteria to assess the change. By answering these questions, we can decide whether to include the new requirement in the release or not. If the delay was caused by the new requirement, we can consider extending the development time for new requirements in the future.

The benefit of this approach is that we can see progress every step of the way. The downside is that it can take a long time to implement. However, we can learn from others' experiences and avoid making the same mistakes. We don't need to reinvent the wheel every time.

Ⅳ. Three Essential Tips for Resolving Project Delays

Based on my project management experience, I believe that three key actions must be taken to resolve project delays.

1. Before the project: requirements management

There are four essential steps for requirements management before the project starts.

1.1 Agree on requirement priority

Firstly, it's necessary to reach a consensus on requirement priority. What are the most critical requirements that need to be met? Every company may have different priorities. In my experience, I base my ranking on two dimensions: business value and user value.

Business value refers to functions that can generate profits for the company, reduce operating costs, and achieve the company's long-term strategic objectives. User value refers to functions that can enhance user experience and efficiency and address user pain points.

Using these two dimensions, we can create a four-quadrant graph to classify all requirements based on their business value and user value. For products with high commercial and user value, we should prioritize them. As for requirements with high business value and low user value, or low business value and high user value, it depends on the company's actual situation.

Why prioritize requirements? Because time is limited, and there are too many functions to handle. If we still have many requirements left after prioritizing based on business value and user value, we can continue to prioritize them based on their importance and urgency.

1.2 Understand the purpose of the requirement

Once we reach a consensus on requirement priority, the next step is to ask the product manager to explain the purpose of each requirement during the requirements review. We need to understand not only what we want to do, but also what we want to achieve. This has two benefits:

• It gets everyone involved, allowing all team members to contribute their ideas, and helps us find better solutions through collective creation.
• It helps us understand whether the function we develop is a step forward towards our goal. If it's not, we can identify the problem's cause more accurately during the review.

1.3 Understand the details of the requirements

Thirdly, developers need to understand the details of the requirements. Every developer should have the ability to see through details.

In the world of code, there are only 0s and 1s, with no room for arbitrary choices. When product managers give us requirements, they may not know the system's specific execution and some details. Therefore, many details need to be confirmed repeatedly during the requirement implementation process. If these details are not thought of during the review, they will surface during testing.

For instance, suppose the product manager tells us that we have an activity where customers can enjoy free shipping if they place an order worth 29 yuan or more. This may seem like a simple requirement, but if the system is complex, developers need to think about cross-store, virtual goods, conflicts caused by other stores' activities, and whether the requirement will change to 49 yuan for free shipping later. If we don't think about these things during the review, we need to keep communicating with the product manager during the project's implementation. Some newcomers may feel embarrassed to ask at first, but that's okay. It's something that everyone experiences, and it takes time to build up.

Clarifying requirements has two benefits:

• It ensures the amount of work assessed is accurate.
• It identifies potential requirement problems earlier.

1.4 Create a comprehensive schedule for launching the project

The fourth step involves aligning requirements and generating a schedule for them. Initially, requirements are broken down into smaller parts to assess effort and generate a personal schedule. Then, the department integrates the requirements to generate a departmental project schedule. Finally, the entire team works together to create an overall project schedule, often presented as a Gantt chart, to identify potential issues in the process.

Exceptions

Although these four steps are simple in theory, they can be challenging to implement. In general, managing requirements will not be a significant issue if the steps are followed correctly. However, there are exceptions, such as when a requirement needs to be changed after it is established. Unless there are extenuating circumstances, it is best not to alter the requirements.

But what constitutes extenuating circumstances? This is where the rules regarding requirement priorities become essential. If a requirement has a high business or user value and a lower cost, it may be possible to change it, provided the entire team agrees to the rule.

What if the leader does not follow the rules?

The person in charge has the final say. Although a task may seem highly valuable to one team member, it may not be from a different perspective. In general, team members can provide feedback and suggestions until the requirements are established, but once the leader approves them, everyone should follow through.

2. During project execution: Process management

The key to process management is to address the issue of information asymmetry. My solution is as follows:

2.1 Conduct daily stand-up meetings

Some people believe that morning meetings are pointless and an indication that managers have no other way of driving progress than through meetings. However, I disagree. Morning meetings are not complicated or time-consuming, and they provide a fixed "communication" agenda that helps everyone stay on track with their work. Here are the specific steps that my company follows to conduct a morning stand-up meeting:

• Build consensus among the team members first. Make it clear that the purpose of the morning assembly is to collaborate, not report. Each person is allotted two minutes to speak, and speaking time is controlled.
• Determine what to report. Each person reports on how their plan for the day aligns with their actual progress. Are there any issues? Do they require any support?
• Establish the order of speeches. During speeches, others do not comment or respond. Specific problems are discussed with relevant personnel after the meeting.
• The moderator of the morning assembly is critical. They need to manage the flow and timing of the meeting and alert people to off-topic speeches.
• Lastly, minutes of the meeting are taken, noting only the questions or requests someone had and whether the project is on track.

Meetings are recommended 30 minutes after the official working hours, such as 9 a.m. They can start at 9:30 and finish by 10:00. Note: Flexibility is allowed for starting time.

Morning stand-up meetings can resolve the problem of information asymmetry within the team, allowing everyone to better understand each other's project progress and collaborate more effectively. Additionally, people take pride in their work. If they fail to complete a planned task, it is stressful for them to explain the reason in public. This pressure can subconsciously affect their ability to complete daily tasks with concentration.

Many companies convert the morning assembly into a briefing, resulting in a meeting with minimal information. The issue is not with the tool but with how it is implemented. By following the principles mentioned above, teams can organize morning assemblies that are suitable for their specific needs.

2.2 If it is a cross-department collaboration, check the schedule every day.

If the project involves cross-department collaboration, it is important to check the schedule daily to ensure synchronization of information.

2.3 Follow-up of timeline

It is crucial to follow up on the timeline of the project to identify any problems and address them in a timely manner before the project launch.

2.4 Develop a mechanism to deal with abnormal problems

It is important to develop a mechanism to deal with abnormal situations during the project. By having a well-defined process and response plan, people can be more prepared to handle unexpected issues, making it easier to resolve problems.

2.5 Build the bill of problems

Creating a bill of product problems can greatly improve the efficiency of problem-solving in development. By having a standardized format and keyword search function, colleagues can quickly find solutions to problems that have already been encountered by others. However, it is important to define the format of the bill of product problems for effective management.

While implementing the above processes may not guarantee that the project will launch on time, people management is a crucial element in ensuring project success, and we will discuss this further in the future.

3. After the project: review the project

After the project is completed, it's important to conduct a review meeting in which everyone should participate. The aim of the meeting is to identify what was done well, standardize it, and make it replicable. Similarly, for areas where the team didn't perform well, it's essential to develop a plan to address those issues.

V. Several Strategies to Prevent Project Delays

Image Source: 51miz

Lastly, I would like to share my personal experience in preventing project delays with you.

1. Conduct staged testing for large projects

Avoid focusing all your testing and design efforts on a single period. Version iterations should not exceed one month.

2. Allocate time for testing

Developers should set aside time for testing after completing a task. Additionally, we should agree with the developers that if there is a delay in development, they should catch up with the progress by working overtime without affecting their colleagues' progress.

3. Establish standards for handling common anomalies

As mentioned earlier, it is crucial to have a standard for handling requirement changes. Requirements can change, and it's important to know how to address them. Some can be solved by working overtime in the current version, while others can be resolved by removing some requirements. It's best not to make changes when the product is nearing completion.

4. Have a contingency plan

What is the plan in the event of an emergency? For instance, what if there is an unforeseen request? What if there are technical obstacles that cannot be overcome? As a manager, you need to think about alternatives ahead of time.

5. Create two release plans

One plan is based on the internal launch time, while the other is based on the external launch time. Our team strives for the internal launch time. The reserved time is our buffer zone if something goes wrong. Alternatively, you may provide a rough launch date, such as September 10 for internal launch and mid-September for external launch.