How to avoid bad quality from programmers and data management

As statisticians, we rely on good quality from programmers and data management. And if you talk to your colleagues, everybody has a story about a poor experience. But the questions are:

How do we collaborate with other departments to create a quality deliverables?
How to strike the right balance between working on processes and managing people for maximum efficiency?
How to we take ownership and drive responsibility to learn from mistakes and not blaming each other?

Tension often arises between statisticians, programmers, and data managers when it comes to delivering quality products in a timely manner.

In this episode, Benjamin and I discuss how you can maintain a high level of quality that satisfies everyone. We talk about the importance of good communication. We discuss the balance between processes and people. While sophisticated processes may be necessary, relying too much on documentation can lead to missed opportunities or overlooking potential solutions.

Listen to this episode now while we dive deep into these points below:

  • How can statisticians, programmers, and data managers work together to develop quality products quickly?
  • What measures can we take to ensure that everyone involved has an understanding of the project’s goals and processes?
  • How we can strike a balance between rigorous processes and trusting individuals to make decisions without cutting corners?
  • What strategies we can implement in order to ensure effective communication between all parties involved in a project?
  • In the event of mistakes or setbacks, how can postmortems and lessons learned meetings help to resolve issues with lasting solutions rather than pointing fingers?

Listen to this episode and share with your friends and colleagues!


Subscribe to our Newsletter!

Do you want to boost your career as a statistician in the health sector? Our podcast helps you to achieve this by teaching you relevant knowledge about all the different aspects of becoming a more effective statistician.

How to avoid bad quality from programmers and data management

[00:00:00] Alexander: Welcome to another episode of The Effective Statistician, and I’m really happy I’m talking with Benjamin today. How are you doing?

[00:00:13] Benjamin: Thanks, Alex. Yeah, it’s been a while, right? So last time I think we canceled the last meeting and today it’s really an interesting topic and it’s already winter in Germany, so that’s been a long time ago we spoke last time.

[00:00:26] Alexander: Yeah. It’s, the topic today is something that is coming up quite a lot. Yes. So whenever there are two functions working linked together. And there’s handovers and these kinds of things. There’s always a tension. Yeah. About quality. It’s when we hand over tables to medical writing or physicians and then they need to work with it and they’re not happy with it then, that creates tension on that side. But of course, there are also the People that deliver stuff to us like data management and programming. And now, yeah, since then, go south there as well. .

[00:01:09] Benjamin: Yeah. I mean it’s the statisticians who usually feel like being the end in the line, right? We actually deliver the results. So meaning that anything that comes before, so anything that has been processed, the data, whatever is if everything goes well, it’s fine, if it comes late, who’s gonna who’s having the trouble, to deliver. It’s the statistician. So that’s there. Why, that’s why I real, I am, I had this quite often in my career that there was quite a bit of, as you said, tension. Misunderstanding, let’s put it this way, miscommunication, and especially really fighting. Then at the end, if it’s getting late and there’s a debt, there’s a timeline to deliver for and there’s not much on flexibility that we usually have at this time.

[00:01:52] Alexander: Yeah. And then, it’s a very often there’s a finger pointing and the blame game starts and these kind of things, which are all situations you don’t wanna end up in. Now, and what are your kind of approaches to ensure that this doesn’t happen?

[00:02:08] Benjamin: There’s no this is a difficult question. It’s a long answer. First of all if it’s delivered in poor quality or if it’s delivered too late. It is too late. So the most pragmatic or the best approach is really to avoid getting there. And what we usually, what I’m trying to, incorporate is first of all a good under, like good communication. You shouldn’t be surprise if there’s something not going right. It should. So there could be, and data quality could be that, about dry runs. It could be about data checks whatsoever that the statistician could do. Or maybe at least, in general have this performed before for any delay. Always keep on asking if everything’s on track. And I know it doesn’t have, you sometimes you often get the response of, yeah, everything, everything is on track. And then actually last night before delivering, there’s some problem coming up. So there’s a lot of communication needed and mutual understanding. So in a way of, our counterparts or like our partners, let’s put it this way, rather. They should understand why we in this content, like maybe good quality and delivery and time to understand maybe our process at least get a sense of how long does it actually take for us to perform our part of the work at the end. And on the other hand, it’s good for us to understand what’s going on their desks.

So what is, what are their concerns? What are their, troubles in, in getting it done? I, none of them happy if they deliver bad quality or too late. So there must be like a reason, like a pain for them as well. And so that’s why, that’s the like very basic approach of the mutual understanding and a lot of good communication.

[00:03:46] Alexander: Yeah, I think the what you said, giving them a bigger picture. What is the ultimate deliverable here? Yeah. How will that look like? Giving them more kind of understanding of the little things that they’re doing. How is this fitting into the bigger picture? If they’re look into techno core medications or things like that would that be a protocol Correl? or would that, trigger some kind of, looking into AEs or whatsoever. Giving them more kind of understanding of what exactly they’re doing there and why they’re doing it. I think that is really important because otherwise it’s really difficult for people to understand what to do when, these weird patients that we always have? Yeah. There, there’s always a weird patients that kind of falls through the cracks and comes up whenever you do your programming check. There is patient. There’s these couple of patient numbers that always come up and if you don’t know what are, what’s the ultimate goal is. It’s really difficult to manage these patients. The other point is also you can of course have lots of details in your documentation, but you can never forced everything. Yeah. And then the people need to have the trust with you to bring these up. Yeah. So I think the trust part in building trust is really important at the beginning.

[00:05:14] Benjamin: Yeah, I think there’s, in theory it’s ideal, right? If the statistician is being involved as the trusted partner from the very beginning and throughout everything. In reality we often, get shell, especially on the CRO side in terms of the time. That the statistician actually has. So the involvement, so the planning, so there’s a lot about planning. . But for example to, when we discuss individual cases of, weird patients or weird subject data, there is something that the decision is not always happy being involved simply because of they don’t have time to discuss data management, patients issues. So that is, there is and I do agree to that. And that in general, that is not the statistician’s responsibility to discuss every question. But there are, there should be some questions that they should be involved and what to do is this for, the simplest approaches to getting them on the table saying is it important to have this data? So what would we do with the data if we have it? Does it have any impact in anything? Like on the primary, secondary, whatsoever end points, or is this simply now about complete data so there’s that is like a general discussion that the statisticians of data management or everyone on the table should have at some point in time. But on the other hand it, we shouldn’t end up. Saying I have a question of, let’s ask the statistician, so that’s not gonna work. Let’s reality.

[00:06:36] Alexander: It’s striking a balance there.

[00:06:38] Benjamin: Yeah, exactly.

[00:06:39] Alexander: So of course, the critical questions you want to be asked. Yeah. But of course, on the other hand you don’t want to get, lots of questions that the data management could solve themselves. But that, if you have a good relationship, then this mutual understanding kind of comes over time. Yeah. And this mutual understanding of what good looks like. Just saying we want high quality doesn’t mean anything. Yeah. Because what exactly is high quality?

[00:07:10] Benjamin: Complete data is not good data. Yeah, no, that is absolutely true. And that looks back to the point of the good planning and the good communication. So where we say, really, they need to be closely working together and understanding what is needed. And then you can definitely just, check in on some data point saying is this of, what is the, priority of where should we start with? And you can, teach or under make them understand what actually goes into what endpoint, et cetera. So there’s a lot of communication, but again it’s always a it’s a bit of a balance between time and responsibilities.

[00:07:47] Alexander: The other balance is regarding, I think, process and people. Yeah. I think the when you know over time things go all since this mistake and this mistake in different companies, then people try to put more and more effort into more sophisticated processes, more checks. And I’ve seen that go so far that, the statisticians, check everything in the end. Yeah. And that’s the wrong approach, I think. You can only manage with process to a certain point, you also need to, involve the people side. And sometimes it’s just more effective to pick up the phone or set up a meeting and talk to each other rather than to try to document everything in somewhere. Yeah. To the last detail and have everything kind of cross-checked. The other point in terms of cross-checking I think is ensuring just by checking, you don’t transfer responsibility. Yeah just because as a statistician, I checked something, it’s not become my responsibility that everything is fine. The responsibility of delivering high-quality data, the responsibility of delivering high-quality tables, figures, and listings still stays with the programmers and the data managers. Yeah. Just because you have checked something doesn’t mean that No. It’s your responsibility.

[00:09:28] Benjamin: Yeah. And also just to turn it around. We discussed this in earlier episodes that the responsibility of our interaction with, for example, medics, right? We do require, or we often experience that the more important people get the less they actually look into, the SEPs and the shelves because, they look into the shelves because there’s, they don’t have time look into the shelves once they are filled with numbers. And then they realized actually it’s not, it’s not telling me what need to see. But, so why wasn’t this picked up? When reviewing the SAP or the shelves because they didn’t spend time or they didn’t, not enough. Not enough, and not thoughtful enough. And that is exactly the same. That, one, when we turn it around and say, when we get data management documents, for example, or for programming specifications, just saying, yes, that’s fine. I trust you, it’s a good thing. However, at the end it’s what they deliver to us. And if we don’t spend the time to at least review. Specifications is not everything, definitely not. But this is giving the framework of what we receive at the end. So we need to spend time, think it through, understand what they’re going to discuss it if needed. So if you’re understanding, if you feel your understanding isn’t good enough, then discuss it. Pick it up. Because this is how they need our support. And at the end, they would deliver something incorrect or maybe, suboptimal if we don’t spend the time now with them.

[00:10:57] Alexander: Yeah. Completely agree. Speaking about when things need to be reviewed, how how much they get review what exactly gets reviewed? These kind of things. Is this also neutral understanding of what will happen. Yeah. And making time for that. Yeah. I think that’s a more and more important topic that I see all the time. That people are so much under pressure that yeah, people have seen. Maybe so much under the pressure that they, try to get into shortcuts. They say, oh yeah, I trust, I just review at very high level .

[00:11:34] Benjamin: Yeah. I trust you. But it’s still, it’s going back to my earlier point is that we still need to find a balance in everything and I strongly believe, and I see that this is especially in the company I’m working now, that the leads, like the people that are responsible for their, tasks as data management or especially a programming lead they take their responsibilities, right? So the statistician is involved. However, it’s not trying, the association should not, or is not trying to cover everything. So these people they’re great, right? We do have, not only statisticians are great, right? So, it’s really that they have, everyone has the capacities to and the skill set to do their job usually.

So I would expect this, and if not, that is something that they need to, challenge internally. But so it’s not about taking over the. It’s not about being involved in everything. It is about, it’s about being involved as needed and under, have a good communication, so understand what’s going on, and be on top of at least like timelines and and the, the next steps in the whole process. What’s coming up? Where do we stand? Get understanding, but don’t, mess around and try to do them, data. It’s not gonna work. So we have to find a very good balance so that everyone is satisfied with, with moving forward and internally.

[00:12:49] Alexander: Yeah. And if there’s, something that, and the other point is when things don’t go as you think, you shouldn’t have been done. Yeah. The quality is not what you expected. You need to have good way of dealing with these kind of things. Yeah. Don’t directly get upset ask why, where is this coming from? Yeah. Is there something, that we haven’t thought about? Is there something in the process that we missed? There’s so many kind of reasons why something, didn’t went as planned and looks odd in the tables.

[00:13:26] Benjamin: Yeah. But I would say that, first of all we should be focusing on getting it still done, right? Yeah. Yeah. I fully agree with what you said, but I always say, once we delivered, Once things are out or whatever task this is we need to sit together and understand what’s going wrong. So this is really like a question for, lessons learned meeting or whatever you might call it. Because first it’s, we need to be very pragmatic and moving forward and getting, if you have a delay your quality workarounds, find workarounds, find, I don’t know, maybe support or anything that helps us to get. Get it corrected, but for the questions that you ask. Yeah.

[00:14:02] Alexander: Yeah. So a word you shouldn’t do is directly escalating things. Oh. And yeah so directly copying the supervisor, obviously as a person and things like that. That’s yeah. Not good practice. Yeah. Pick up the phone, talk to the people and just ask questions, or, I thought these two different sample sizes should be the same. Why is it not?

[00:14:26] Benjamin: That’s a tough question. So if you ask a question, you are quite in trouble.

[00:14:30] Alexander: Maybe there’s, has this kind of, oh for here, there was a missing co variant. Yeah. And therefore, , that number is reduced whatsoever. I don’t know. Yeah. Maybe there’s good reasons for that. You never know. And then you can always say, oh yeah, that’s out of footnote. So that’s it’s clear. These type of things.

Okay. Very good. So we talked a lot about, how to avoid getting into these problems by having good discussions about, big picture, about having mutual understanding of what quality looks like. Having mutual understanding about how the process looks like, having mutual understanding on what is a revenue level and all these kind of different things and being clear on who’s responsible for. I think this is really important. And then when things, are mistakes happen or look like mistakes, have a good discussion about them without, with a mindset of fixing it rather than blaming people. I that’s really important. And later on have some kind of postmortem where you look into lessons learned to we need. Change something. Any final thought on this topic? Benjamin?

[00:15:43] Benjamin: Yeah what you said, but just adding is, we are human, right? So it’s about, working together with colleagues. So that’s the primary understanding that I usually have and saying, we all mis make mistakes, as you said, it’s, but it’s really be calm, keep it open. You are brainy, so you’re smart. So you’ll work it out. So you’ll make it happen. Be positive about it.

[00:16:02] Alexander: Yeah. Keep calm is often easier that than done if you,

[00:16:06] Benjamin: Absolutely.

[00:16:07] Alexander: It’s timelines pressing. Yeah. But keep calm is a, it’s a really…

[00:16:11] Benjamin: Yeah. But it helps and at the end you are quicker if you keep calm and because you’re just more you allow your head and your brains to still function if you’re not upset.

[00:16:20] Alexander: Yep. Okay. Very good. I hope you enjoyed this discussion about quality and working together, and turn it in for the next episode.

[00:16:33] Benjamin: All right, bye-bye.

Never miss an episode!

Join thousends of your peers and subscribe to get our latest updates by email!

Get the shownotes of our podcast episodes plus tips and tricks to increase your impact at work to boost your career!

We won't send you spam. Unsubscribe at any time. Powered by ConvertKit