Editor’s note: This blog is the fifth in a seven-part series on TrialCentralNetSM (TCN), a single infrastructure for managing everything from enrollment metrics to clinical trial reference documents through all phases of development and approval, as well as customized reports, training, and communications. The goal of this series is to give you the “backstory” – a BBK insider’s view of the system from the perspectives of those who build, manage, and rely on it. In their own words, our executive leadership, developers, and power users all tell it like it is. They’re passionate about the system they so tirelessly build and manage – and you’ll hear that come through in their writing.
Matt Kibby is our principal who oversees TCN. In this blog, he explains what happens when the system “isn’t working.”
TrialCentralNetSM (TCN) is an amazing piece of software that provides unprecedented process improvements for, and strategic insight into, the patient recruitment arena. However, as with every single piece of software ever developed, from time to time there can be usage issues that require redress.
We sit, hungrily by our Help Center, waiting to pounce on any and all electronic “tickets” so that we can analyze the nature of the issue and assign the correct resolution. But sometimes as a development team, we get comments in from the universe of TCN users that can be misleading about the nature of a particular problem or observation.
“What do you mean, ‘It’s broken?’”
“Can the programmers fix TrialCentralNet please?”
“Could you give me a few more specifics?”
“Hmm . . . I need to be able to remove a document from the Document Manager system because I uploaded the wrong file.”
“Did you know that you can cancel a document?”
“So it’s not technically broken then?”
“Well, no, it isn’t broken but I need help with that.”
In order to provide our best consultation, we focus squarely on our four Ps, but not the classic four P’s of marketing (product, price, place, promotion), but the four P’s of development: process, procedure, people, and programming. These help to alleviate the pressure of all things defaulting to a programming solution – which is always the most expensive option.
When we evaluate a request or observation about TCN, we ask ourselves – is this a process issue? Can the process be reviewed and changed so that it makes more sense to the user, adds additional security, facilitates the transaction, and so on. This kind of change is relatively easy to spot, manage, and change.
Similar to process, is there a way that an issue can be resolved by simply mandating that users adhere to a specific procedure? Ensuring that a data field is mandatory, or that data formats are given the highest respect can often also ensure that problems down the road are avoided.
Does this request look like the user requires additional training on how to use the system? Is there a way that the user is using the system that is incorrect? Sometimes this can be a difficult thing to spot, especially if the expectation is that the user knows the system based on training that has already been given. Perhaps the training itself needs revision in some cases.
If it’s really something that needs a developer’s attention after all the other possibilities have been explored, then it’s time to pass it over to the developer team for assignment into a sprint cycle. This has obvious timing and cost ramifications. Not to mention that the backlog can be significant and that applying priority to development issues with a finite set of expensive resources is often a juggler’s task.
The lesson that often comes out in the wash – at least for the BBK users of TCN is that a rush to address issues with programming is often a headlong rush into the wrong conclusions.
Stay tuned to this and other BBK Blog series by subscribing to our blog!