Case Review of a Logistics Software: “How A Software Project Can Go Wrong”

As a solution provider for business expansion, we run into many partners and stories along the way that provide detailed experiences that can be learned from.

Today we decided to analyse one of these stories we encountered on “how a software project can go wrong”.

Client Overview

A prominent logistics company, managed by an experienced professional with decades of experience in the industry, had a new innovative idea to digitise a traditionally pen-and-paper operation through an automated platform. 

The software’s goal was to connect customers needing large-scale deliveries with independent drivers who could bid on delivery jobs posted by customers. This was an innovative idea that was meant to fill an observed gap in the market.

Client Challenge

Despite having a broad vision for the platform, the client faced challenges to articulate specific features, functions, and plans. Additionally with limited time from the client, building a concise and full specification of the project requirements was limited.

Solution Proposed

As a result, the development team embarked on a purely iterative & flexible approach that was meant to allow the project to evolve with the changing requirements. Thus catering for the limited initial requirements list, and using a pure Agile approach to the development 

The development process was designed to be the following:

1. Quick Scoping: Initial meetings to understand the client’s vision and outline core features.

2. Mini Iterations: Small development cycles to build and review basic functionalities.

3. Normal Iterations: Comprehensive development cycles to build agreed-upon features.

4. Final Delivery: The final product is reviewed, published and signed off on.

Outcome

While having a flexible approach can work in some rare cases, more often than not it leads to unaligned visions and execution between the client and the service provider, which results in regular reworks and changes in the development process.

Sadly, this is what happened on this project.

Due to client being unfamiliar with the software industry plus not being available for in depth & detailed coordination, the developer company had to improvise and adapt. 

This led to multiple reworks and changes, which resulted in the development team working overtime and even committing to an additional 50% bonus features that was beyond the initial agreement. 

Despite getting a fully functioning application that had more functionalities than initially negotiated for by the client, the client lost interest and fully moved onto other business ventures.

What Should Have Been Done

This project underscores the importance of clear specifications and effective communication in ensuring project success. The following lessons can help avoid similar pitfalls:

For the development company:

1. Comprehensive Scoping: Thoroughly understand and document the project requirements. Walk through the requirements step by step as a user to identify necessary features and functionalities.

2. Ask Detailed Questions: Inquire about every aspect & step of the software, including its purpose, target audience, industry-specific processes, desired outcomes and what is required for those outcomes.

3. Document Everything: Ensure all requirements, workflows, and functionalities are documented in writing to avoid misunderstandings. Send these documents back and forth between us and the client and ask for additional information and directions.

4. Coordinate With The Client: It is vital to coordinate with our client. Making sure that we explain to the client how important it is that they create time to coordinate and listen to our feedback and advice. Especially if the client has no prior experience with software development.

For Clients:

1. Be Specific: Provide as much detail as possible about your needs. Specify features, functions, workflows, and desired outcomes.

2. Create Visuals: Use tools like Figma to create visual representations of the software, including page layouts, button functions, and user workflows. Note every part/data that changes or moves within the system, where it moves, and how it changes and what triggers it.

3. Write It Down: Document your requirements in writing to ensure everyone has a clear and consistent understanding of the project. Just saying something verbally might not be enough.

4. You are the expert: When it comes to your project, your industry or business, it is you who is the expert. A developer might not have the same experience, skill and knowledge about your specific approaches and workflows, thus often what is “self-explanatory” for you is not necessarily obvious to a developer.