I recently caught this article about the management company, Accenture, getting sued by Hertz for a botched software development job. Over the years, we’ve covered a lot of topics on what can go wrong in a project like that. But I wanted to use this example to reiterate some of those for you.
As a quick recap, here are some of the things that went awry on this project:
As you can see, that spells more than disaster. It spells a lawsuit.
The biggest issues exposed on this project are the bad code, the purchasing of unnecessary middleware, and the lack of quality control. Those all point to the vendor’s unqualified teams and ultimately cause the symptoms that bring on lawsuits: missed deadlines and milestones. The skills and talent required to create custom software, along with the management skills needed to run the project efficiently, cannot be emphasized enough.
So what could Hertz have done to ensure that Accenture was qualified to take on this project? The truth is, there’s not a lot that can be done. A client can always look into contributions to open source projects. Assuming the developer regularly makes sound contributions, there's a good chance they are used to adhering to specific styles and standards of code. I've even been asked to provide an independent analysis of code in the past.
But once a project has begun, then the way to avoid such a catastrophe is to keep an eye on things. The first sign of problems is usually a missed deadline. At that point, start asking questions about testing and QA. If you receive a ho-hum response, that isn't a good sign. It might be time to make that hard decision before it gets out of hand.
Learn More: Do you need to break up with your developer?
Before you take the step to fire your developer, though, try to identify the root cause. If it's a communication issue, that can probably be resolved (listen, nine times out of ten, that’s exactly what the problem is, a communication issue). If it's late in the process and something workable is likely going to come out of it, stay the course. If it's early on and the communication issues can't be resolved, it's probably time to make a change before things get worse. You also need to consider existing contracts. Larger companies tend to have stricter contracts, so there may be a financial consideration there.
The big question in all this is, “How can a client protect themselves in a case like this?” The first step is education. Clients don't need to know how to code, but they should make themselves familiar with basic concepts of software design. A good developer will help the client understand the process and then communicate better with them. I try to educate people up front, but many times clients don’t take the time to get involved. That's not healthy for the success of a project. Development projects are a two-way street and require communication from both parties.
Communication is key to a successful project. I need to have a clear understanding of what the client needs, and I need to clearly communicate the scope of the project, the milestones, the costs, and the ultimate outcome. Communication is a two-way exercise, and both parties need to have a full understanding of the development of the project. When we communicate, there are very few surprises that aren’t quickly resolved.
And of course, with Sol Minion Development, you’re dealing with a team that are experts in coding, quality control and testing, and the full technology stack.
Do you have a project that might be coming off the rails? Contact us. Maybe we can help.
Further Reading: