No engineers, shifting requirements, and clinical trial deadlines to meet. Here’s how this web app got built.

Key aspects of this case

  1. Dan was under pressure. He needed to deliver a new web app for data collection and analysis supporting multi-location clinical trials.
  2. With the current system the opportunity for error was enormous. The inefficiencies attached to the disjointed, largely manual collection of data meant that mid-study redirection opportunities were slowed down to a crawl.
  3. Dan had no software engineers on bench. He had no defined budget for this project. He had unspecified requirements subject to change and subject to hiatus due to budget delays.

Despite the less-than-ideal circumstances he was unwilling to compromise on velocity. He wanted nothing more than to be able to relinquish some project ownership to a team that could get this over the finish line. But historically he’d had to micromanage vendors to get the outcome he wanted. He needed help. How would Integrant earn his trust?

The client

Dan had 20 patents to his name, mostly involving medical devices and displaying and exchanging device-related data. He had recently changed jobs, moving from Senior Principal Engineer at one of the world’s largest medical device manufacturers, to a management position with a rising pharmaceutical company. His new company was in the spotlight due to a potentially revolutionary method for fighting cancer and infectious diseases using electricity in a delivery device to enhance efficacy. One of the company’s most-watched clinical studies was testing delivery of a vaccine using this new and proprietary delivery device

The problem

Hundreds of study sites were involved in the company’s ground-breaking research. Myriad combinations of drug delivery with the new device were being explored, including delivery site, vaccine type, amount, and strength. Data collection at each site needed to:

  • Document the various scenarios according to defined protocol.
  • Summarize results.
  • Confirm that protocols were followed precisely.
  • Facilitate analysis of results in real-time to inform mid-stream study changes.

Enabling this data collection and analysis was Dan’s top priority. The problem was that he was as far away from what he needed as he could possibly be:

  • Individual test sites were entering test data via site-specific Access databases. These databases were not consistent among all sites and did not integrate with each other.
  • There was no automated way to download data from the vaccine delivery device and then upload it into the Access database. This was all done manually.

The opportunity for error was enormous, and the inefficiencies attached to the uncoordinated, largely manual collection of data meant that mid-study redirection opportunities were slowed down to a crawl.

In addition, Dan had no software engineers on bench. The company’s engineering talent was focused on the first-in-class hardware and firmware associated with the vaccine delivery tool. He needed talent dedicated to defining requirements and building a solution for the in-field data collection, consolidation, and analysis.

He also had no defined budget for this project, which had clearly become a priority. He would have to make his case as he went along, relying on PoCs and sprint demos among stakeholders to garner buy-in and additional money as the project progressed.

The suggestion

Over coffee one morning with a colleague from his previous company, Dan was lamenting the fact that he had neither internal bench nor the precise requirements doc necessary to hand the project over to someone else. “I knew when I joined this company it would be a wild ride. My creative juices are flowing, but things are so frantic no one has time for input. Like with this device data management project, everyone needs it yesterday but no one knows what they want exactly or how much they want to spend. I need outside help with this but I don’t even have a requirements doc!” His colleague, who had worked with Integrant in the past, suggested he give them a call. “They can do it. They’ll help with the requirements doc and if things change, they’re flexible. Give them a try. At this point, what have you got to lose?”   

Dan agreed, though with so much on his plate, even a no-risk meeting would be a burden and distraction if it didn’t work out. Nevertheless, he called Integrant to get a feel for their capabilities. He explained the problem and hoped to hear that the folks on the other end of the line got it and could help.  

Dan understood right away that Integrant was comfortable with the domain based upon similar clients. The question was, could Integrant work with Dan the way he needed? The initial meeting looked at how best to approach the project given unspecified requirements subject to change and subject to hiatus due to budget delays. Jointly, Dan and Integrant came up with a plan.

The plan

The project would include several phases and a lot of room for flexibility:  

  • Phase I would be creation of a new download utility software. The tool would download log/pulse data from the devices using infrared (IR) communication. The new download software would maximize ease of use for operators in the field, keep all current features as part of an administrative mode of operation, work seamlessly with all device firmware versions, and be compatible with the latest device firmware (using serial communication). This would require an upgrade of the existing C++ (using old C++ Builder IDE), including conversion of the current code base to C# and supporting the most recent Windows versions (7, 8, 8.1, 10) 32/64 bits. 
  • Phase II would be a web-based device data management (DDM) application. The application would allow users to upload device files (downloaded by the download utility software above) and device binary log files, parse the data in the uploaded files, filter the imported data, export it to Excel and review treatment details, add review notes, and manage treatment review.
  • The Integrant team would include a technical project lead, developer, and QC engineer. The allocation of these team members would flex based upon necessary starts and stops in the project in response to competing priorities and budget shortfalls. In addition, because of the flexible allocation Dan required, Integrant would cross-train team members so that if he were ready to ramp up again and a team member was assigned elsewhere, there would be no delay for the project.
  • The Integrant team would work directly with Dan in an agile environment. Sprints would occur every two weeks.

Project details

Dan had a lot more going on than just supervision of this project. He was in the middle of many initiatives that were constantly shifting in priority. He needed his vendor to drive this project forward despite the chaotic environment surrounding it.    

Integrant dove into the project using the Scrum process framework to implement agile. This included: sprint planning, daily stand-up, sprint demo, and sprint retrospective; along with “baked in” meetings and planning among stakeholders and team members regarding next steps. In addition, the team used Kanban as a visual framework to show progress and receive incremental feedback. Dan would have visibility to critical technical issues as they arose and the iterative process would hopefully lend itself to immediate resolution. With this structure, Dan felt he would be able to maintain velocity as the project proceeded.  

He and the Integrant team defined requirements and agreed on technical details. Tools would include Microsoft Visual Studio 2015, SQL Server 2014, Jira, and Bitbucket. For the database app technology the team would use Microsoft ASP.NET, MVC.NET, LINQ, Bootstrap, JQuery, Ajax, and REST API.  

Of course there would be obstacles and this is where he was counting on the Integrant team to step up. Of note:

Converting C++ to .NET and C#–without the device

Dan had originally told the team they wouldn’t need C++ knowledge on this project—a good thing as Integrant is a C# shop, not a C++ shop. However, this turned out not to be the case.  

The Integrant technical lead had two decades of experience and happened to be an expert in C++, but the rest of the team was not. The diversity of professional maturity among team members at Integrant meant that these types of situations could be addressed. Sometimes a senior developer would teach a new developer a legacy language and sometimes a new developer would teach a senior developer a new method or tool. Mentorship goes both ways and in this case it ensured optimal conversion of C++ code. When dealing with C++ conversion, the tech lead would sit side by side with the programmer to dig into the issue. The two would share thoughts and suggestions on how to investigate the issue, identify the root cause, and resolve it. Sometimes there were multiple solutions and the discussion focused on choosing the best one. This meant that Dan’s Integrant team grew with the project and every member owned it. 

The download utility software needed to be converted from C++ including serial ports and low level APIs, but because of regulatory issues Dan couldn’t get the team access to the device until 30 days into the project. The team made its own emulator of the device in C# and used open source tools to make virtual communication ports on Windows. 

The team compiled the existing code to test and debug the legacy app. This would give them a good sense of how the C++ code was dealing with communication serial ports, executing, and handling different cases and dealing with normal workflow of data.  

Then the team converted the C++ code class by class.  It was easy to match C++ code to C#, but the legacy code was mixed and in the new code the team wanted to separate the responsibilities of each class, including separating UI from internal communication functionalities.  

Dan had gone into the project as he usually did, sure that unless he spelled out how he wanted his vendor to execute technically, things would go south. But given his crazy schedule, he had  to relinquish some ownership to a team that could get this over the finish line. Watching Integrant work independently to emulate the device so as to avoid a 30-day delay, gave him pause. He started to feel he might be able to trust these guys.

Support different file types–to be identified along the way

This type of hurdle is not that unusual. We simply don’t always have the luxury of complete visibility to requirements. This case was no different. Dan knew only that the app needed to support binary files. Then text files were added, then entire Access database files, then a new version of a binary file, and so on. To do this the team used a layered architecture technical design including backend or services layers. This, along with best practices regarding software design and .NET framework, meant the app would support adding multiple file types in a “plug and play” way without having a significant impact on already implemented components. 

Uploading and processing various file types in the background

Similarly, the iterative process accommodated additional requirements identified at each sprint. The first prototype allowed multiple users to upload one file and the user needed to wait until parsing was finished to continue. After code review and stakeholder input Dan requested functionality include uploading different file types and processing them in the backgroundOn the next release multiple users were allowed to upload multiple files and get file upload status immediatelyUploaded files were added to a queue to be parsedno need to wait until parsing was finished to continue. A user could view progress on parsing of the uploaded files by checking the file status periodically. Also, an email would be sent to the user once parsing was finished. The final release allowed multiple users to upload multiple files at the same time, and get file upload status (success/fail) and file parsing status (parsed successfully/parsed with errors/failed to parse)The incremental improvements allowed Dan to gain stakeholder approval and budget he needed.

Deriving business rules through code analysis

Another hurdle Dan had not anticipated was the need to understand business rules by reverse engineering a proprietary, MS Access database containing nested SQL multi-level queries. Business rules were implicitly known by the company’s previous internal team, all of whom had moved on, so the team had to get those implied business rules without having access to the originators. There was no formal documentation. In addition, there was no formally documented file structure. The query names were not indicative of purpose or dependencies. (They usually looked something like “query_[number].”) There existed multiple MS Access versions (using different MS Office versions) with different structures (using different tables, queries, and VBA code) which had been developed over a 10+ year interval.  

The Integrant team addressed the challenge by reviewing and analyzing each and every line of VBA code, SQL queries, and nested joins. Because of data privacy issues the team didn’t have real data sets so they mocked up sample data. Sometimes the team’s queries returned errors or unexpected data because they didn’t have real data or because there was a business component they had not understood or accounted for. After the Integrant team’s reverse engineering was complete it went through the internal team’s validation process. Dan was relieved that the required changes were relatively minor and would not have an impact on implementation.

Ramping up, ramping down

Throughout the project, every two months or so, Dan needed to pause the Integrant team to get stakeholder approval on new features and/or more budget. The Integrant team kept a cross-trained bench to accommodate the starts/stops. Its use of kanban and scrum tools meant that things could pick up quickly where they had left off. 

Results and next steps

Despite the hurdles and delays, Dan’s project was completed according to stakeholder priorities and specifications. 

The biggest relief to Dan was the recognition that he could trust these guys. Specifically, trust meant that at critical moments the line between staff and vendor was quite simply not there. If Dan needed help and his Integrant team could provide it, they would find a way to do so. As a post-project example of this, after the app launched Dan decided he wanted to publish on Azure. This was not part of the original project, and was not Integrant’s area of specialty. Still, Dan asked his Integrant tech lead to help him because he trusted the lead’s ownership. Without delay his tech lead supported him in preparing machines, SQL server management, administration tasks, and storing files on shared network storage. For the Integrant team, moving from being viewed with skepticism to being viewed as “the only people I trust with this” was the ultimate reward. 

The new app launched successfully to great feedback from stakeholders, and just in time for Dan to get Integrant started on the next project: A new version to accommodate additional patient privacy rules surrounding next step in FDA clinical trial process. When he next met his former colleague for coffee, he had a completed app under his belt and was ahead of the curve toward preparing for the app’s next generation. Dan told his friend he knew the entrepreneurial environment and quick pivots of his new company wouldn’t change, but he now had a partner to perform with on the stage on which he thrived.