Above is a generic but basic software development project life cycle.
If you’ve worked in or have been exposed to the software industry, you’re more than likely familiar with this model above. This is the development life cycle of a project between two parties.
While I personally think the “Requirement gathering” phase is the utmost important, I have often seen the implementation phase become the wildcard in smaller to mid size agencies.
Implementing a design doesn’t mean literally
Implementing a project means engineering it to the spec you’ve went over with the client, including the UI. The issues I’ve seen is spending too much focus on the actual UI instead of the product as a whole. In layman’s terms: sculpting a Ferrari body but postponing building the engine.
This hurts both parties and I feel determines how the remaining life cycle of the project goes. Postponing core functionality over trivial UI/design decisions, which we know are subject to change, can cause major backups. Tasks like testing can become lower priority, large features may be half baked if not pushed out past the initial launch.
I believe these particular pitfalls arise from not clearly communicating to your client. Not every client is tech savvy, so the only way you think they can understand progress is showing them a nice UI. This is the contractors failure to educate your clients!
Educate your clients of the actual process, push back when needed. It is on you to protect their best interest and provide meaningful project progress.