Typical Pitfalls in Government/Enterprise Software Delivery
Preface: It's that time of year again, planning new projects
Based on my own experience, here are some of the classic moments that make projects start high and end low—and how to avoid being dragged into the ICU.
1. Beautiful goals, brutal reality
Crash scene:
Some projects start with the client aiming for a headline: build a "domestic leading" integrated platform within a year. Reality: the team is still on Struts + Hibernate.
What to do:
Make goals follow SMART:
- S (Specific): not "improve UX" but "reduce crash rate by 50%"
- M (Measurable): not "speed it up" but "query time ≤ 200ms"
- A (Achievable): do not build rockets before checking if you have fuel
- R (Relevant): do not force AI into everything when users just want a usable form
- T (Time-bound): no projects that last forever
2. A perfect plan on paper, near-zero execution
Crash scene:
The plan is detailed down to half a day, but execution looks like a college student making a PPT: two weeks of "thinking about life," one week of last-minute 996 crunch, barely meeting milestones, with code quality like bargain-bin goods.
What to do:
- Do not draw a Gantt chart on a whim. Break tasks reasonably; cycle lengths should not be shorter than food delivery.
- Leave buffers. Do not keep the team living on countdown mode.
- Agile is not "agile requirement changes". Define MVP and run small steps fast.
3. A shoestring budget, but you want to build an F1 car?
Crash scene:
The budget buys a cheap minivan, but the requirements doc reads like an F1 spec. Even better, the client keeps saying: "Can you optimize more? Our budget is really tight!"
What to do:
- Do what the money can support. Do not get trapped by low-bid wins.
- Manage expectations early. Do not wait until delivery to say "pay more for special effects".
- Do not use "human-wave" tactics. Use tools, frameworks, and automated tests where they matter.
4. Requirements change like a tornado
Crash scene:
Week 1 build A, week 2 change to B, week 3 back to A, week 4: "Actually B." The vendor team learns the art of waiting: do not code until requirements stabilize.
What to do:
- Use a change evaluation mechanism. One boss sentence should not force a full rewrite.
- Client PMs need decision power; do not let "meeting literature" kill the project.
- Lock change windows, e.g., "only two changes per month".
5. Client and vendor: each a king
Crash scene:
Vendors want to survive; clients want to cut budget. Clients change requirements daily; vendors play Tai Chi daily. One day before delivery, everyone realizes: it does not work.
What to do:
- Align goals regularly.
- Communication is not just meetings: fewer PPTs, more demos.
- Clients need people who understand the domain; do not let an admin assistant evaluate an AI project.
6. A team like a "loose band"
Crash scene:
The PM feels like a babysitter: "Did you finish yesterday's task?" Dev: "Almost." QA: "Bugs are just a tiny bit." Ops: "The server exploded and is smoking."
What to do:
- Do not let the team run like headless flies: OKRs + task decomposition, one role per responsibility.
- Reduce churn. Three developer turnovers a month makes handover more expensive than development.
- Do regular code reviews. Do not discover quality issues only at delivery.
7. No clear rewards and penalties
Crash scene:
The project launches. Developers are bald from overtime. HR says: "Here's a 200 RMB JD gift card." Meanwhile, someone who changed requirements daily gets a 200,000 RMB year-end bonus.
What to do:
- Focus on the process, not only the outcome.
- Rewards should be sincere.
- Penalties should be explicit too. Do not let the author of a legacy mess get great performance reviews every year.
8. No risk management: constant firefighting
Crash scene:
- Halfway through, the key tech lead quits
- Cloud goes down and you realize the backup is from five years ago
- One day before delivery, PM discovers the API design does not match business logic at all
What to do:
- Every key role needs a Plan B.
- Drill emergency plans; outages should not be solved by praying.
- Testing is not a checkbox; do not discover usability issues right before delivery.
9. Inexperienced PMs on either side: blind men touching an elephant
Crash scene:
Client PM: "We want an AI-empowered digital twin." Vendor PM: "Got it. We'll build a mini program." Final delivery: an Excel auto-fill sheet.
What to do:
- Client PMs should understand tech; not everything is solved by "adding AI".
- Vendor PMs should understand the business; do not do whatever the client says—guide requirements.
- Data-driven decisions: fewer PPTs, more real analysis.
Epilogue
Software delivery is like a marathon. It is not about who sprints fastest, but about who does not drop out.
Hope today's rant helps you step on fewer landmines.