Ellis Hughes | Packages and Process | Posit (2022)

Hello, everybody. My name is Ellis Hughes, and as you can tell probably from this title slide here, I work at GSK. I'm a data science leader in the Statistical Data Sciences and Innovation Hub, same as Becca, who presented earlier, and we're responsible for innovation and developing of our packages to try to improve processes and whatnot. So I thought I'd come here today to talk about that a little bit.

So I think, sorry, I think we've all worked on a process before that promised the world that it was supposed to solve all our problems, make our lives substantially easier, and it didn't do that. In fact, it made it harder. It made it tougher. It made it slower. You were confused the entire time, and I call those Edsels.

The Edsel story

Do you know what an Edsel is? The Edsel is the automotive world's biggest flop. So I'm going to tell you a little bit of a story about the Edsel. So in 1957, Ford is hinting about the next car that they're going to be producing. The car of the future, it's going to be. They've spent 10 years developing this thing, $250 million of 1950s money, which is $2.5 billion today, and it's supposed to be this fantastical thing that's going to take us all into the future, and it's going to be full of technologies that are going to make our lives easier.

In 1958, the Edsel arrives with a lot of fanfare. They've got advertisements all over the world or all over the states. They've got a TV show about the Edsel, a TV show about the Edsel, of all things, and it's got all this wonderful technology. Like in your steering wheel, you can select your gear. You don't have to gear shift. It's just in your steering wheel. It's right there for you. On the dashboard, there's a button that squirts oil on your front suspension to keep it from squeaking. Isn't that amazing?

But in 1959, they kill it. It's done. It's no longer out there anymore. In 1960, the last Edsel rolls off the line. This is a screen capture from a Times magazine where it's the wrong car, the wrong place, the wrong time. But what happened from 1957, where it's the car of the future, supposed to be doing everything for us, to 1959, it's dead, it's gone, stop asking about it.

Well, there are a couple different problems with the Edsel. First, Edsel was designed by a committee. There was no real why driving the development of the Edsel, other than it's the car of the future. It's got to have everything. It's going to be fantastic. During this time, also, Ford was going through some restructuring, some changing, and so a lot of different executives were in charge of this project. Over the ten years, it was being developed, of course. So they all wanted to put their thumbprint on the Edsel to enable to, you know, push their careers forward without really paying respect to what is this supposed to be? What are we trying to actually accomplish here?

And then as I alluded to earlier, ten years of development. So when it was first released, they were all in on this. There were 18 different models that were available for people, not including colors, internal trims, all those other things. This was just all the models that were available for the Edsel. Then going on the idea of there was no real why behind it, there were no real requirements or constraints when they were designing it. So the car design, the horseshoe that you saw at the front there, was thought to be really ugly, and in fact, people didn't like the way that it looked. Now I don't really think it looks too bad, but, you know, whatever.

And then they also had a bunch of technology that didn't really solve any problems for us. There were a bunch of technological solutions that were searching for a problem. You know those automatic gear shift selector in the steering wheel? People hated it. You know what you're used to in the center of your steering wheel? A horn. They'd hit the horn and they'd accidentally change gears.

In addition, there was a lot of QA and QC issues related to all those technological solutions. They weren't really meant to be in production that early. And that led to issues where the factory was sending incomplete cars to their dealerships with just all the different pieces that they didn't complete just sitting in the boot, waiting for the dealerships to sort this out. And so that's why, of many other reasons, the Edsel failed.

A case study in fixing a slow process

But how can we take lessons from this and keep our next project from becoming the next Edsel? So I'm going to go through a little case study of a project that we worked on where we identified a slow process that we wanted to fix.

So inside of our organization, we have a programming team that does all our data analysis and data prep. They process this data, they do all this formatting, and they've output to several different files and intending for downstream users to use this to generate reports and presentations and reports and whatnot. These downstream users take this, the statisticians will generate reports or presentations, and our medical writers will generate reports of differing levels of programming backgrounds and whatnot.

The issue with this is our programmers are generating data in formats that our downstream users couldn't use directly. That meant that there was a lot of manual reproducing of data, a lot of copy and paste from the format that we were producing into their PowerPoint and Word documents. When people are copying and pasting, that leads to formatting inconsistencies. They're like, oh, I'll just delete that, I don't like the way that percent looks, I'll just put it at the top there, or I want more spacing here, I want to merge these columns. Not fundamentally changing the data, but the way it's displayed. And because we're doing all this copying and pasting and reformatting, we have to do a lot of really intense QC on data we've already generated and already QC'd to make sure that we're not showing anything that's incorrect.

So there's all this effort going into this process that is just we're not producing the correct data, we're not working, we're not talking together to make sure that everything works together nicely. But we saw this as, you know what, that's not a bad thing. That's an opportunity for us to step in and help and try to improve the process. Because the data is being used by the same downstream user, or the same data are being used by the downstream users, we can use this as a starting point and try to build processes and build a package to try to make their lives easier.

Next, we found out and learned about packages that have come out like the Officeverse, which is a series of packages by David Goel that interact with Office products and help you write your OOXML to allow you to inject and work with your Word and PowerPoint package or presentations and documents and whatnot. So Officer. And there's also FlexTable, which is a package that helps you make tables into PowerPoints and Word documents. Kind of seems like it will be pretty useful for us.

Designing with purpose

So before we really went and just went all full tilt to develop anything, we wanted to make sure we had a full set of expectations so we understood what we were trying to build before we went to go build it. So if we're designing a new workflow, we want to create collaboration. That was what was causing problems before between our programmers, statisticians, and medical writers. We wanted to work with our existing systems. We don't want to have to try to create and roll up a new system. What do we have that what can we reuse? Where can we extract the data from? Can we pull from existing streams?

We're already using PowerPoint and DocX, so let's output to that. Let's not make our end users relearn everything. And then as we generate these inputs, let's automatically tag those, because you can use comments in PowerPoint and DocX, tag those with comments that, hey, you're going to need to QC this. This was generated, you know, custom. And then ultimately this process originally was very slow. We wanted to reduce the timeline into less than a week.

Then as we went to go develop the team, now that we had our expectations, we had a small team of experienced individuals that were both understood the process, what they were trying to replace, as well as understood what they were generating or how to program. This was important. So we understood what were the constraints. What could we feasibly make or not make? We had a single point decision maker. They were ultimately responsible for making a call if there was a disagreement. Then we worked with the experts, the people that we're using, our downstream users as well as upstream users, to define, okay, what are the core things that we need to create? What are the features that need to be on the roadmap eventually? We maybe don't need them immediately. But ultimately they did not have the final decision. They weren't the executives at Ford that were telling us what to do. They were saying, hey, it would be really nice if.

We tried to simplify things. We didn't want to try to recreate the wheel. Like I said, we didn't want to recreate systems. So let's use existing tools. Let's use Office first rather than trying to make our home cooked version of Office first to interact with the XML and PowerPoint and DocX. Let's use the tools that already exist and try to maybe improve it as we need to. People were adding their own standards and their own changes to the outputs. So let's revert back to what are the standards? What exactly is it that we have to make and then we can maybe iterate from there? And then identify areas of common rework by the staff. What are the common reformatting that is being done? And can we do this programmatically? Is it reasonable to do it programmatically? What are things that we need to capitalize or lowercase or change?

While we developed this, too, we wanted to watch our scope. So we wanted to make sure that the system could grow as we need it to change as we need it. The world is a changing place. Let's try to keep that in mind. The feature requests that we got, we would compare them against the feasibility of doing that. Once again, can we do this programmatically? Should we be doing this programmatically or should we push back and go, maybe this isn't the time? We also have limited resources. We had a small team of people working on this. So that made us keep in mind that everything that we did was in strict adherence to the goals. What are we actually trying to achieve and try to push away things? This might sound a little bit familiar. This is kind of agile. I don't know if you've ever heard of that.

So I'm happy to report that this actually, this project did turn out pretty well. We've reduced the reporting time significantly. We've been able to generate reports in under a week. There's no programming skills required by our non-programming staff. They are not required to write any programming. We're able to generate their reports using the programmers and then just running it through this tool that we've created, and as everyone asks in pharma, it is validated. Per our internal process.

So the reason this project succeeded, I believe, I've named a couple of those as well, we established our requirements. We knew what our outputs were. We knew what we were trying to create, and we didn't deviate from that. We knew what our measurement of success was. We knew if we achieved this goal, we succeeded, and anything that we did was only in trying to achieve that goal.

We were relentless. When people asked us to add new features, we'd go, okay, do you need this now or is this something that can happen later? We kept perspective of the values that we were adding and tried, once again, it's all about not doing things we don't need to do. Don't add unnecessary things unless you need to. And then also single point decision making. Ultimately, one person had to make a call.

We were relentless. When people asked us to add new features, we'd go, okay, do you need this now or is this something that can happen later? We kept perspective of the values that we were adding and tried, once again, it's all about not doing things we don't need to do.

Making a GT, not an Edsel

I'm going to close with a final story from the same company, Ford, and we're going to make a GT, not an Edsel.

So 1966, Ford wins the world-renowned hardest race in the racing world, the 24 hours of Le Mans, which is a race where people drive for 24 hours and the winner is determined not by how many laps they do, but how far they drive. This is a true endurance test of the quality of your car, how good is it made, how well did you design this?

The impressive thing about this, this is the second year Ford had ever competed in Le Mans. They'd never competed in it before. The prior winner had been Ferrari, who'd won for the last six years and has a long history in racing. So how did Ford go from a company that made a thing like the Edsel to the GT and won the whole darn thing in their second year of competing?

Well, they had a small dedicated team. They set out to beat Ferrari. That was their goal in mind. Not just win the 24 hours of Le Mans, but let's beat Ferrari. They got together a small team, Carroll Shelby and Ken Miles, who had a history of success doing this sort of thing. Carroll Shelby was an old racer, so he used to race, he actually won Le Mans I think a decade or two before and started his own car company called Shelby American. You might know him from the Shelby Cobra. As well as Ken Miles, who had been a successful driver in Britain, racing various cars of various degrees.

And then everything they did for the next two years was focused on results. What could they do to make the GT faster? How could they win Le Mans? They've worked through aerodynamics. They had an initial concept. They did, they constantly drove around. They had their drivers that were going to be in the race drive the car around, give feedback to the engineers. Even this is a picture of the engineers and drivers with little pieces of string that they taped onto the GT to see how aerodynamics worked and if there were any areas of low pressure that they would need to address. And they trusted the driver's experience.

In addition to that, they pushed technologies forward. They took the Ford's proven racing engine from NASCAR and improved it. They made it faster, they made it stronger. They took existing technologies and made it better. And they also innovated. They took the quick change or they invented a quick change brake pads and rotors. The GT was a very heavy car. They brake a lot in Le Mans or they have to press the brake pad. So they needed a quick way to redo this. So they created new technologies in order to solve the problems at hand. And that was all they were ever focused on. How can we do this faster? How can we do this better?

So I'm going to end with this. Projects and packages should be designed with purpose and be relentless in pursuing their goals. And that's how you make a good packaging process. Thank you.

Projects and packages should be designed with purpose and be relentless in pursuing their goals.