Software Project Traps

This week was published a law-suit between the car rental giant Hertz and the enterprise software development company accenture. You can read here and here what happened. With this article I want to share my views and opinions about it. Maybe, we can explore how it can come to such a disaster. Because we do not want to blame any of the two involved parties I will refer to Hertz as the client who need a software developed. And accenture as the software agency. The outcome of that project is caused by a number of factors. I want to understand an want you to understand the situation, so we can avoid such miserable results.

From the text in the Law-suit, we can see that they followed a 4 step process, to do the project before fully commit on the final terms and deliverables. As the project managed in the software agency you are under pressure. You want to get this client, this huge project and the huge revenue for your company. This might make you tempted to make some promisees for good results that can be hard to realise.On the other hand, as client, they needed the best possible results. With its millions of customers the project is of major importance for its business. Then will prepared a large set of requirements. And for sure consulted multiple agencies. You choose a partner you trust, someone who guarantied to deliver great results and show a great understanding for your business and future requirements. The 4 phases process, was supposed to ensure, the requirements and the amount of work is clear understood by both sites.

When looking at this situation, it is important to see, there are not just standing two established companies, but there are people. I already spoke about two, the engagement manager and project manager. As project manager in the Software company you want to win the contract. He has to keep close communication with the client as well as experts from his company. His task is to get the contract as well as keep the requirements under control. When he is putting more features into the product, the client is more likely to accept the proposal. From my view, the engagement manager is in a tricky situation. When he get the contract and the project went well, he is getting and good bonus or a better position in his company. When the project does not go well, he gets a new job in a new company. I believe the risk he is allowed to take is to much. taking more risk can offer him a great reward, while having minimal risk. As the company carry all responsibility. From the outside, we can not do any judgment about this. lets just keep it in the back of our head for now.

Next I want to discuss the point about the missed requirements. There was the 4 step process, from purely agreeing on designs and requirements, before delivering any useable product. This is great to bring both sites in line, build up some trust, before buy into the whole project. At stage two they started the implementation. At this point they introduced angular2 as there frontend development framework. In 2016 it was quite new and promised to be ready for the future. I believe at this point in time it was impossible to hire a trained angular 2 developer. so the engineers learned it on the job and probably made several decisions on how to work with the framework, that are different from where the angular community has moves later on. In the law suit this might cause complains of ‘bad unmaintainable code’. But there is an other point, when starting the project incremental, having the engineers develop a subset of the final features (desktop only, canada only) can also set the projects course in a wrong direction. Focussing on a subset, has the high risk that the project develops into a dead end. As a engineer and as a manager, as a single person, it is easy to say, ‘the software has to be well structured, it has to be extensible for future needs. As Steven Covey said: You have to start with the end in mind. But in a team and a tight deadline, going for maintainability and extensibility is no longer as easy.

Last, You can really wonder, why do they use in a project with high relevance and high pressure such experimental technology? First there is the already stated Angular2. This might have been chosen because just some developers wanted to try, learn, use it. In an early stage, building a prototype, that is a feasible option. It is good to try some new tech on a prototype, some piece of software, that get shown and never really to production. The problem arises, when to decide what tech to use for the real product. Managers are very tempted to reuse the prototype, at least many man-days of work flew into this thing. Starting over might seem like waisting previous work. So it might be tempting to save some hours at this front, but then the foundation is not allowed to be experimental. Experimental, not only that Angular2 was new in twenty-sixteen, also an established framework, and a prototype build with an inexperienced new engineer, is considered experimental.

RAPID, was the second tool, to streamline the CMS. RAPID is so exotic, I was not even able to find it. I mean RAPID, you find a million things on the internet under that word, it seems impossible to find the CMS. Personally, I always wonder why people use CMS. When coding the requirements down can be even more effective as tweaking, adjusting, patching a system build by others. I believe clients, if small business or global enterprise, have different requirements. Adjusting and teaching/training the client how to operate the CMS, accept workarounds and live with compromises is absolutely not what a good customer deserves. Choosing the RAPID system seems to me, like the biggest flaw in the Software Agency made. When introducing such a major piece of technology into the project, the Software Company has to guaranty that results are fabulous. Still, at this stage, it is not clear, where the guild lie. The Client accepted the introduction of this technology, it has to be analysed very precise, how the tech was introduced. The fault could even lie at the third party vendor for the RAPID system, making false clams about there own system. And how was the collaboration with the third party vendor, have support services been used?

As we see, there are multiple layer in this situation. I hope, that understanding some of the traps, can help all of us avoid projects that go so wrong.