ENDO IT is an endoscopy and procedure management solution that is currently being used in one of top gastroenterology clinics in Latvia. It provides data input, endoscopy image capture and procedure planning, while facilitating workflow and data management for the Healthcare organisation.
Project from the start was meant to be a co-development with another company. The deadline was very tight, as was the budget. In this case the co-development meant co-management as well. We had to step out of our comfort zone, because we could not use the development resources and tactics we were used to. With the tight deadline it was meant to be a waterfall development process. Due to the changes in managers from the other parties, it slowly developed into a well managed agile and then a creatively disorganized scrum. It was a complete storm before it was fresh and calm, and breathable, and before we knew it, the end product was being used in one of the top gastroenterology clinics in Latvia.
CO-MANAGEMENT WITH ANOTHER COMPANY
CHANGE OF WORK METHODOLOGY
TIGHT DEADLINE
THE END USERS ARE HEALTHCARE PROFESSIONALS WHO DO NOT UNDERSTAND OR FORGIVE MISTAKES
The Problem
When we took on the project, we had identified three main problems that we needed to work on: the co-development, the tight deadline and the fact that it had to be fool-proof. So we came to the conclusion, that the best was to approach this was to work in waterfall development flow and not begin the technical development before we have not set clear and specific goals and gotten approval of all parties, so that the web developers wouldn’t have to do anything twice. That failed as quickly as it had started to thrive. The other companies’ management restructured and changed. And the previous treaties were nowhere to be found. The client had been neglected and deadline had been crossed.
The Solution
We had internal team discussion about whether at this point the project is salvageable. The whole development team came up with ideas of fixing what we have and making something useful. We had lost contact with the other team and therefor the client, so we made the conscious decision to go to the client and renew a healthy communication with the client. We once again went over client’s wishes and compared and updated our user stories. From that point we could go through developers ideas and pick out the relevant ones that could work in this scenario and within our newly set timeline and budget. When we had this and some work that could be shown, we contacted the other team and took lead on how and when and why we will be shipping further updates. We stressed that we would start testing on site and do some pro bono work to compensate the missed deadline, to which we already had agreed upon with the end-customer.
The Results
We were pushy. I was the pushiest. My team and the co-development team heard many no-s from me. I did cross boundaries that many were not happy about. But in the end this was the right approach. By taking a firm stand in what I believed (of course, based on analysis and developers, and clients input), I was able to steer the project and product towards successful deployment. I did spend many, many hours on site, testing and fixing and doing all the grunt work that potentially lowered my image to the “IT gal that fixes computers”, but I also showed that me and my team are reliable and they can safely use the product, with complete assurance that if something is not right – we will explain and fix.