Watching a major project you’ve been a part of crash and burn is heartbreaking. I was a test lead in one of the early forays into decision-making software. The project had big ambitions – the goal was to take personal interpretation out of the decision-making process for applications relating to a grant program.
The project had pretty good requirements, and a large number of the Business Analysts and testers had a technical and practical understanding of the process being automated. We were excited to be a part of this type of innovative and progressive project. Sadly, 13 months and $20,000,000 dollars later, the entire project team was told not to come in on Monday. It was 2pm on a Friday afternoon, and I still remember the moment our project was declared dead. But even from the ashes of a failed project, there are a few things you can still learn.
I’ve been on underfunded projects, and projects where “make it work” was our motto. This project was neither, we were both well-funded and well-staffed. The team leads didn’t have to go to battle over obtaining additional resources. In the end, even with everything we needed, we just couldn’t realize the ambitious visions of the software developers. What is simple today was a huge challenge in the 90’s. We just couldn’t find hardware to handle the software requirements.
There were whispers, subtle changes in attitudes among the higher ups. We knew there was trouble, this was QA, and we literally spell out and report the problems to them. An emergency manager and team lead meeting was held mid-Friday. Everyone went in stressed out and trying to figure out how we could overcome these hurdles. They came out looking a bit vacant, taken aback and disengaged. Moments later, our project manager said, “Thanks for your hard work, the project has been terminated: effective immediately, no need to come in Monday. Good luck” and that was it.
The key reason to this project failing was one simple factor. The software design and architecture did not take into consideration the state of the current hardware capabilities. The first day was hilarious as the testing of each rule took anywhere from 24-56 hours! There was even some betting going on for the first to finish. The whole office erupted with cheers as the first error message came up after 4 days, with many not making it that far. Nowadays decision-based software is everywhere, packaged neatly with all of the special features. Sad to say, it was the project’s Achilles’ heel and no matter how good the design was, it couldn’t overcome the hardware limitations.
No matter how long it’s been, you never forget your first project to crash and burn. I’ve been fortunate enough to not have it happen again. The experience taught me to always have open communication and be transparent with my colleagues and teams. Also, always strive to understand the big picture and see what you can do to keep your project on the good track.
To find out more about how to manage test estimations and mitigate project risks, click here.
Qualitester Contributor
Elle Gee – Delivery Manager
I’ve been in QA for over 20 years and I love testing and the impact (or non-impact!) our work has on users every day.
