Event operation: a complete event project review process!

Reviewing past events is an essential skill for operations. Whether it is as small as a grocery shopping experience or as large as investment projects worth tens or hundreds of billions, you can summarize patterns and improve your level through reviewing past events.

Simply put, there are two effects that can be achieved by reviewing:

1. Optimize weaknesses and strengthen strengths
2. Clarify your own value and the value of your work

So, how to do the review? In other words, is there a more efficient and practical way to do a good review? some.

The following content is based on my thoughts at work, and also refers to Liu Chuanzhi’s methodology on review, in an effort to present a complete and practical project review process.

1. The underlying logic of the review

The first thing to do in a review is to state the facts. An effective AAR (After Action Review) must be based on "hard facts" . If the reality is difficult to state clearly and reach a consensus, the review will progress slowly or be unable to go deeper.

Once the facts are established, we begin to diagnose and analyze the reasons for the differences, find out the root causes of success or failure, and then summarize the patterns. Understanding why success occurred, which key behaviors worked, whether these behaviors were applicable, and whether they are valuable in improving the success rate of subsequent actions.

Therefore, a complete review came into being, which includes the following four steps: review of goals, statement of results, process analysis, and summary of rules .

1. Goal Review

What was the original intention or purpose of the action?

What is the event/action trying to achieve?

What do we plan to do?

What is the pre-planned plan?

What was envisioned to happen?

1. Result Statement

What actually happened?

Under what circumstances? How did it happen?

What is going well compared to the goals? What didn’t meet expectations?

1. Process Analysis

Is there any difference between the actual situation and expectations?

If so, why do these differences occur? What factors caused us to fail to achieve our expected goals?

What is the root cause of failure?

If there is no failure, what is the key factor to success?

1. Summary of rules

What new things did you learn from the process?

If someone were to make the same move, what advice would I give them?

What should we do next?

What are the things we can do directly?

2. Stages of project review

A project basically includes several core stages: goals, requirements, design, development, testing, and launch. Only by breaking down the specific work in each stage can we analyze whether the progress of each task is smooth, where the problems are, and how to better optimize it.

Here is a little tip for project review: keep a work diary according to the project execution timeline .

It is not necessary to write every day, but you must leave work records at each important time point so that you will have a clear understanding of the entire activity process. When reviewing, you only need to go through this part of the diary again, list a schedule for the actual work, compare it with the planned schedule in the plan, which part of the work is advanced, which part of the work is delayed, which part of the work is added temporarily, and the degree of completion.

For example, the first step is to review the project goals. High-quality projects are often accompanied by clear preset goals. If the goals themselves are unreasonable, the conclusions drawn from the review will hardly be convincing. Therefore, when reviewing, we also start with the rationality of goal setting and the conditions under which the goals were set in the first place.

If the overall project goal is large, it is recommended to break down the goal, determine the project implementation milestones, and form sub-goals or phased goals to facilitate the measurement and follow-up of the goal. Taking e-commerce event planning as an example, the sub-goals that affect transaction volume include: traffic, conversion rate, average order value, and repurchase rate.

The subsequent steps are the same. Through continuous decomposition, a complete and quantifiable analysis of the entire project process is made, so as to understand the actual and expected comparison of project indicators.

3. How to review a product project?

The two most important aspects of review are past interpretation and review optimization , which can clarify the reasons for deviations and put forward targeted suggestions.

1. Project goal review

1.1 Project Progress Review

• Was the delivery made as per the originally planned delivery time?
• How many of the originally planned demand points have been achieved? Which demand points were not met as planned?
• What are the reasons for the delay of each demand point?
• Which milestones are delayed and why?

1.2 Project Results Review

• What unexpected events occurred during the project? Why do these accidents happen?
• Is the user acceptance of the new features consistent with the project plan?

1. Demand phase review

• Is a complete demand output provided? Including: prototype, MRD, PRD, UML, etc.
• Are the requirements clear to designers, interaction designers, and developers? If the requirements are unclear, it will seriously affect the progress and quality of the project.
• Is there a clear description of typical users and usage scenarios?

1. Design phase review

• Has the final reviewer of the visual design been identified?
• Do UI design outputs meet unified standards?
• Does design work affect the progress of development work? What is the cause of the impact?
• When and by whom is product design work done?

1. Development phase review

4.1 Project period evaluation review

• Is there enough time to estimate the duration before development is implemented? On the one hand, duration estimation allows project members to prepare for the overall progress of the project, and on the other hand, it is a process of sorting out project requirements in detail.
• Whether there is a difference between the estimated construction period and the actual development time, and the reason for the difference.

4.2 Development Document Review

• Is there any development documentation?
• Does the development documentation comply with the specifications?

4.3 Review of emergency situations

• Is there a situation where demand cannot be met? What is the reason?
• Are there any changes in team members? How to deal with member changes? How to avoid it later?
• Are there any functional modules that do not meet the requirements? What is the reason?

1. Testing phase review

5.1 Test plan review

• Are there complete and accurate test cases?
• Is there a testing plan? Is such a plan effective?
• How does the team test and track the effectiveness of product development?

5.2 Test tool review

• What testing tools were used to aid in testing? Can it be used continuously?
• Are there sufficient time, manpower, and software/hardware resources for testing?

5.3 Test Results Review

• Which functional module generates the most bugs and why?
• Which bugs were rolled back and what were the reasons? (Rollback: program version rollback. When a major bug occurs, the program rolls back from 1.1 to 1.0. After the iteration, it is full of bugs and the cost of repair is high)?

1. Review of the launch phase

6.1 Acceptance Review

• Has a formal online acceptance been conducted?
• Did anything go wrong during the official release? How to avoid it in the future?
• Did you communicate fully with operations and copywriters before going online?
• Have you checked the data collection points? Do they meet the operational requirements?

6.2 Review of the effect after launch

• Did any major bugs appear after the launch? Why weren’t they discovered during the testing phase?
• Is the feedback channel for issues after the product is launched a process?
• What kind of feedback did you collect after the product was launched? What types are they? How to improve?

Every project review is a self-examination and tempering. For iterative products, a review is conducted every three versions. Generally speaking, the release rhythm is one version per month, so the review can be carried out at a rhythm of 3 months.

After the review is completed, a review meeting should be held as soon as possible. This way, many activity execution details and user feedback are vividly remembered, and the reliability of the review is relatively high.

They analyzed the issues frankly with each other, neither shirking responsibility nor belittling themselves, but trying their best to present a complete and true project process. Every participant has an equal voice and can express their ideas authentically.

There should be someone dedicated to control time and record key points. The worst thing about a meeting is that it is long and boring without any purpose. It is important to control the time for each part. In addition, recording key points is also a kind of output of meeting results, which is conducive to summarizing experience and taking the next step.

Author: Stev

Source: Stev