Mastering Project Management: The Power of the “Main R” Role and RACI

This article originates from an internal sharing session of the New Oriental Online front‑end team and presents a personal, somewhat exploratory discussion on project management.

Project Management

The four essential aspects of project management are:

Scope : what needs to be done.

Time : when it must be completed.

Cost : how much money is required.

Quality : the level at which the customer is satisfied.

Other issues such as communication, resources, and risk serve these four goals, aiming for the best possible balance.

What Is the “Main R”?

The concept of “Main R” first appeared to me at Meituan, where I initially thought it was an abbreviation of “RD”. It actually derives from the RACI model and has a solid theoretical basis.

The RACI model is a common tool in project management and organizational transformation for defining roles and responsibilities in an activity. It consists of:

R : Responsible

A : Accountable

C : Consulted

I : Informed

In some Meituan practices, an additional

S

(Support) appears in the extended RASCI/RASIC model, splitting the Responsible role:

R : Responsible

S : Support

Effective project management must be both feasible and actionable. RACI is simple yet powerful, clarifying participants’ roles. In practice, the “R” in “Main R” is the same as the R in RACI— the executor—while the “Main R” also carries the “A” responsibility, acting as the primary owner of the task.

Main R’s Role

The main R drives timely delivery by ensuring reviews, development, testing, deployment, and retrospectives proceed smoothly; it coordinates product, development, design, testing, and operations teams. In short, when decisions are unclear, look to the Main R. Its benefits include:

Clear responsibility, preventing fragmented ownership.

Risk reduction through early detection and mitigation.

Main R’s Core Qualities

Responsibility : Project management is not a formality; it requires genuine problem‑solving. For example, when a task is delayed, merely mentioning it in a report is insufficient; the root cause must be identified and addressed.

Effective Communication : The Main R must both understand others’ intentions and convey their own clearly, a skill that is deceptively difficult.

Correct Execution : Following proper processes and standards leads to efficiency; the article does not elaborate on specific methods.

The book *The Mythical Man‑Month* describes a “surgical team” where a lead surgeon directs the operation while others provide support. The “Main O” role in our context is analogous to that lead surgeon.

As teams grow, responsibilities expand, often leading to manpower shortages. We address this by dividing work into two tracks:

Owner : High‑skill individual responsible for a project or business direction, mastering technology, business logic, and cross‑functional coordination. The Owner must embody an “Owner mindset”.

Developer : Skilled coder placed in a resource pool, supporting high‑priority demands and gradually growing into an Owner role.

During frequent personnel changes, the Main O ensures project continuity and development efficiency. Owners guide and assist others, enabling rapid onboarding. This structure avoids idle resources and filters out low‑priority work, keeping the team focused.

Risk Sources

Early exposure of risks reduces cost. Common risk sources include:

Frequent requirement changes : Uncontrolled changes disrupt schedules; without support, delivery suffers. Changes should be evaluated for cost versus benefit.

Unlimited additional requests : As Brooks notes, time is finite; projects must set realistic boundaries and make trade‑offs.

Resource adjustments : Personnel shifts require prompt communication and new agreements.

Technical or condition constraints : Skipping thorough requirement reviews leads to infeasible designs; early technical validation is essential.

Dependency‑induced risks : If the Main R lacks push power, identified risks may remain unresolved, leading to stalled collaboration.

Risks are ubiquitous; the article cites a personal anecdote about pushing code early to avoid loss, illustrating proactive risk mitigation.

Risk Control

Teams often debate optimism versus pessimism when assessing tasks. Leaders should provide strong support for pessimistic assessments and risk warnings for overly optimistic ones.

Understanding each member’s capabilities helps avoid assigning tasks beyond their ability, which would waste resources. Providing growth opportunities is valuable, but must be balanced with realistic expectations.

Risk should be viewed dialectically: while every action carries risk, over‑preemptive avoidance can halt progress. Trusting established contracts and avoiding unnecessary “extra days” for doubtful partners is recommended.

Conclusion

The content is intentionally abstract; its usefulness varies per individual. What works for one may be detrimental to another—choose the practices that fit your context.