Lessons Learned from a Failed Project: A Project Manager’s Reflection

Project and Team Background

The project was a secondary development of a printing application that needed to integrate with a national system, involving three main workflows, frequent requirement changes (over eight changes in May alone), and an estimated effort of about 100 person‑days. The team consisted of three members, two of whom were familiar with the base version, and the manager was handling four projects simultaneously without direct development involvement.

I Did What Was Wrong

Besides Monitoring Schedule, I Should Have Managed Quality

In the early stage, a detailed development plan was created and strictly followed, focusing on progress but neglecting the quality of delivered features. This resulted in numerous defects such as non‑functional main workflows, false success messages, incorrect print data, synchronization failures, and database connection timeouts.

Reflection: Speed cannot replace quality; when they conflict, quality must win, basic testing is essential, and core functionality must always work.

Trust Must Be Balanced with Vigilance

Although the three developers were competent, the manager gave them full trust without providing timely guidance or assistance, leaving the manager’s role limited to client liaison and schedule pressure.

Reflection: Always monitor team members’ status, combine trust with oversight, and offer help rather than using time constraints as an excuse.

If You Cannot Control Everything, Assign a Dedicated Owner

The manager failed to designate a single person responsible for the whole project, resulting in fragmented knowledge and no one having a complete view of all project details.

Reflection: Delegate authority, empower a team member to manage the project, and recognize that managing one person is more effective than managing many.

Control Requirements and Processes

Due to the project's small size and tight schedule, the manager neglected early design, planning, and coding standards, and relied on verbal communication for requirement changes, leading to uncontrolled scope and chaotic development.

Reflection: Conduct proper design, record all changes, enforce change‑control procedures, and reject unreasonable requests.

Code Review Is Mandatory in All Situations

The manager spent only a couple of hours reviewing code, resulting in numerous issues such as inconsistent naming, poor reuse, and complex logic that later caused extensive bug fixing effort.

Reflection: High code quality reduces bugs; regular peer code reviews are essential and should start early to save time later.

My Role in the Failure

The manager acknowledges full responsibility for the project's shortcomings, noting that his focus on schedule and client communication left little attention for quality, team guidance, and process control.

How I Fixed the Issues

After the project went live with many problems, the manager spent eight days (up to 12 hours per day) reviewing and fixing code, working side‑by‑side with developers, and deploying patches to restore core functionality.

Key Lessons Learned

1. Design before development. 2. Delegate management authority to a dedicated owner. 3. Enforce code reviews in every situation. 4. Never sacrifice quality for speed; reject unreasonable schedules.

PS: If you find this sharing useful, feel free to like or watch.

END