How seemingly trivial details can derail your valuable project
How seemingly trivial details can derail your valuable project
Small things can make a big difference
Many years back, I was working on a fixed-price project as a Quality Assurance Engineer. In a fixed price project, in theory, price and scope are fixed. In reality, price is fixed, and scope remains somewhat flexible. As a contractor, you can’t keep on saying no to everything and keep the customer happy. If you can, please give me a call. I’d like to learn from your ways.
The key to winning at fixed-price projects as a contractor is to be flexible enough that you keep the customer happy, yet you leave enough margin for yourself to make some money. That way, it’s a win-win, and the customer may hire you for more work. It’s a tricky and challenging game to play, especially because all estimates are made beforehand, and are often wrong.
Estimates made before the project starts are handicapped by only having the knowledge of beforehand. And this can be a considerable disadvantage because seemingly trivial details can obliterate your initial estimates. If you are skeptical that this is possible, let me tell you a story of a project that spiraled out of control due to differences flagged as trivial that weren’t unimportant.
We were working on a project where we needed to integrate with a specific version of a product. One of the risks we identified before starting the project was that the acceptance and the production environment were running a slightly different version. The acceptance environment was running an English version of the software product, and the production environment was running a Dutch version that was slightly older.
We attempted to convince the customer that we should upgrade them to run exactly the same version. The language did not matter in our eyes. But unfortunately, this was not possible, due to the licensing costs and effort involved with upgrading. As the version number difference was not that big, we let it go and added some additional padding on all of our estimates to tackle the uncertainty.
The fixed-price project lost the digital agency 5 times as much money, as it was supposed to make. And the biggest surprise was that it was not because of the version difference. It was because they were running a different language. So even if we had upgraded the production environment to be the same version as acceptance environment, it would not have solved our problems.
The API for said software product was different for each language, it was language-specific. The Dutch version had a different API, where you had to make your API calls in the Dutch. So if you would use the English API calls on the Dutch environment, they would not work and result in errors. This meant that nothing we built would work once we put it on production.
We needed to create something that would work on both the acceptance and the production environment, even though these two environments were fundamentally different. Another option was to migrate one of the two environments to a different language version, a costly endeavor as well.
In short: a different language version of the same software should not make a difference, right? Well, sometimes it does, and it cost a company a tremendous amount of money. Unforeseen complexity matters, and you never know how it will rear its ugly head in ways you least expect.
How could we have prevented this problem? By releasing something small to production sooner. Then we would have discovered the problem immediately. The result, in terms of the amount of work, would have been the same, but at least we would have discovered it sooner.
I am sure you have your own stories of seemingly trivial details that derailed a valuable project. Please write a response as I would love to hear about them!