What Went Wrong? A Project Manager’s Hard‑Learned Lessons on Quality, Trust, and Code Review

1. Project and Team Background

The project was a second‑stage development of a printing‑declaration system that needed to integrate with a national platform. It involved three main workflows, frequent requirement changes (over eight changes in one month), and an estimated effort of about 100 person‑days. The team consisted of three developers (two familiar with the earlier version) while the manager was juggling four concurrent projects and handled only progress coordination.

2. What I Did Wrong

2.1 Ignoring Quality for Speed

Although a detailed development plan was created and progress was tightly monitored, the focus remained on completing requirements rather than ensuring the quality of the delivered features. This led to numerous defects: a main workflow that could not be executed, a submission function that reported success without actually registering, printing data errors, synchronization failures, and database disconnections.

Reflection: Quality must not be sacrificed for speed; basic testing and core‑function stability are non‑negotiable.

2.2 Over‑Trusting the Team Without Guidance

The manager placed full trust in the three developers, assuming they could handle everything independently, but failed to provide timely direction or help when difficulties arose. Communication with the client was limited to relaying issues, leaving the developers to solve problems on their own.

Reflection: Trust should be balanced with vigilance; team members need continuous support and oversight.

2.3 No Clear Ownership

No single person was assigned responsibility for the entire project, so critical details fell through the cracks. All decisions were made informally, and the manager did not delegate authority to a dedicated lead.

Reflection: Assign clear ownership and delegate management authority to ensure accountability.

2.4 Lack of Design, Standards, and Requirement Control

Early design and planning were omitted, and no coding standards were defined. Requirement changes were communicated verbally without proper documentation, leading to chaotic development and uncontrolled scope.

Reflection: Conduct proper design, enforce development standards, and manage requirement changes with documented processes.

2.5 No Code Review

The manager spent only a couple of hours reviewing code after the project went live, resulting in numerous code‑quality issues such as inconsistent naming, poor reuse, and convoluted logic. The absence of regular code reviews amplified bugs and made later fixes costly.

Reflection: Implement early and continuous code reviews to improve quality and reduce rework.

3. How I Fixed the Situation

After the launch, the manager spent eight days intensively addressing the problems. He familiarized himself with all requirements, analyzed the entire codebase over three days, and performed daily code reviews and fixes—often working more than 12 hours a day alongside developers. He also optimized user‑experience issues and ensured the main workflows functioned correctly.

4. Lessons Learned

Design before development.

Delegate management authority; ensure one person is fully responsible.

Enforce code review in every situation.

Never compromise quality for speed; reject unreasonable timelines.

Control scope and document requirement changes.