What’s it really like to test software on massive federal projects? In this episode, host Mike Hrycyk is joined by Scott Dillon (Associate Manager, PLATO) and Paul Schenk (Accenture) for a deep dive into the unique challenges and worthwhile wins of working on Federal Government projects. From navigating massive team structures and governance requirements to prioritizing accessibility and user consensus, our panellists share their insights, lessons learned, and what makes federal testing both complex and deeply rewarding. Whether you’re starting your first government project or just curious about what goes on behind the scenes, the panel challenges assumptions and offers a fresh perspective on working in the public tech sector.
Episode Transcript
Mike Hrycyk (00:00):
Hello everyone. Welcome to another episode of PLATO Panel Talks. I’m your host, Mike Hrycyk, and today we’re going to talk about testing with federal projects. What do we mean by federal projects? We’re talking about big projects by the Government of Canada, and are they different? I think that people do consider them to be different, and if you haven’t worked in it, they can be big and scary and people just don’t know what they’re like. So, I thought having a conversation about that would help decrease the fear you might have or might increase your desire to work on one. Or might tell yourself that you never do want to work on one. Today, I’ve brought in a couple of speakers to help us talk about it and I’ll let them introduce themselves. So, first I’ll throw it over to Scott.
Scott Dillon (00:36):
Thank you, Mike. My name is Scott Dillon. I am currently with PLATO for five years now, part of Calgary’s first class of software testers. I am currently on ESDC project for EI on BDM. I have been on this project since April of last year. Beginning of this year, 2025, we just started a new phase of the project. So, I’ve seen two different phases of this project. And for myself, I have been raised in Calgary. I am Inuit and Cree, and I am proud of my heritage and I am glad to be able to speak on this topic.
Mike Hrycyk (01:09):
Well thanks for coming, Scott. Paul, tell us about yourself.
Paul Schenk (01:14):
Yeah, so Paul Schenk, I’m an Associate Director with Accenture based in Ottawa, in the technology practice. I’ve worked with provincial and federal government clients. I’m currently privileged to be working with Scott on Employment and Social Development, and I’m happy to be here to talk.
Mike Hrycyk (01:32):
Awesome. Let’s do a little bit of level setting. So, when we think of, without giving any secret information away – how big are the federal projects we’re talking about? So, maybe Scott, because you know ESDC, I’ll get you to just sort of talk about that and then, maybe Paul, you can generalize because you’ve had other projects before this one. So, Scott, let’s start with you.
Scott Dillon (01:52):
In regards to size, this project I would say is larger than anything my imagination probably could have come up with. It is because it just encompasses so many various teams, both from contractor side of point of view, as well as the government point of view. So yes, size-wise, I’ve never experienced anything this big in my life, and the experience I’m gaining because of that is bar none. I couldn’t get this any other way. I don’t believe so. I’m very excited about this.
Mike Hrycyk (02:23):
Yeah. For scope, I think what I’ve heard, and you can maybe just confirm, we’re talking hundreds of resources, like over 500 resources breaking down the project, and it’s hundreds of millions of dollars of project.
Scott Dillon (02:34):
That would sound about right. Yes.
Mike Hrycyk (02:36):
So, anyone thinking about that will think that’s big. Paul, is that a ginormous federal project or is that normal?
Paul Schenk (02:43):
That’s on the large side for federal projects. There are a few at that size, but often, at least when I get involved, they’re at that size because the federal government will look for organizations with the ability to manage the mass complexity in doing large-scale transformations and with the ability to work across different areas. So, for our current project, we’re doing change management and training, and so, there’s actually a testing and development side to that and business process redesign. We’re doing a lot of research to make some of these programs more accessible, and then the traditional software development. So, there’s a lot to the journey, and they tend to be very large projects when we get involved.
Mike Hrycyk (03:34):
And I mean, I’ve worked with other projects in the private sphere that approach those levels, but they’re very rare, right? They’re very big corporations that are similar to government size. But I mean that’s part of why we’re talking about this, is that governments do these big projects, and they’re sort of unique in that way. Which segues nicely into my next question next. What makes a federal project unique from other projects that you’ve worked on?
Paul Schenk (04:01):
Yeah, federal projects often there’s a lot of uniqueness in them, but I would say what sticks in my mind are a couple things. Federal projects, at least for the transformational side, tend to go into places where people have been delivering the service for usually quite a long time, because it’s pretty rare for there to be a new federal program or initiative, although it does happen. But people have been running the program successfully for a long time, and you have people who are deeply invested in providing really good service to Canadians, and they know the business very, very well, but they’re also very attached, often to how they run the business now. And so, there’s a lot of unpicking the why do things need to happen from the how do things happen because federal project people tend to be doing this why and how together for a very long time, and they know that instinctively. So, that’s an interesting challenge to figure out how to take the why over to a new system – how you’d be able to implement and do the business correctly and leave behind the old how. That’s often one challenge.
(05:15):
The other challenge on the federal side is that there is a lot of oversight because they’re spending the public’s money, and they need to be able to justify the value that they’re getting. They’re spending Canadians’ money, and they need to show that they’re getting value. And to be able to do that, they need to trace what’s happening in the project. And that’s usually very different from the private sector clients, where there isn’t necessarily such large oversight.
Mike Hrycyk (05:46):
And we have a subsequent question about governance, so that’s good. We’ll hop into that. Yeah, you said something that tweaked for me. You must have to take extra care when you get into UAT because someone who has been so tied to the way that things happen for 10, 15, 20 years and then you change it and you change it for good reasons, the first thing they’re going to do in UAT is say, this isn’t the same, it doesn’t work like it should. And getting them past that is going to take gentle care and handling.
Paul Schenk (06:11):
Yeah, absolutely. That’s really important, and that’s where the change management comes in. We think about change management, perhaps when we’re releasing to the general user population. But it actually comes in as we’re designing and as we’re preparing people for UAT, so they don’t see something for the first time and are very surprised that, oh, I was not expecting something like this. We have to bring them along in the journey because, yeah, otherwise they will be shocked often when they see the end result.
Mike Hrycyk (06:42):
So Scott, I mean, it’s the same question, but I think I just wanted to highlight that your perspective is pretty unique in this conversation because not only are your prior projects that we’ve put you on a lot smaller – smaller clients, smaller scope of the projects. But you’ve also shifted in the move to this project– you shifted from a testing hat to a project management coordinator hat. So, what have you seen that makes this experience unique from what you’ve seen otherwise?
Scott Dillon (07:08):
Well, it’s like Paul has said too there, there’s a lot of old ways of thinking, and so, a lot of communication is really important. The explaining of the why things have to go this way, and it’s not just a matter of communicating to one group, it’s a matter of communicating to multiple groups. And you have to really choose the type of communication you’re doing, how you communicate it. The scope is such that it incorporates so many people from different walks of life all over the country. And, as Paul alluded to, they’re using Canadian money. So, there’s a lot of scrutiny, a lot of microscopic work. So, really from the test project management point perspective has really, really opened my eyes to the organizational structures, work structures, process changes, change management, all these things I didn’t really think about as just a tester, but now wearing the hat I’m wearing, it’s a bigger picture overall that right now it’s in the federal government arena, but I can really incorporate this in pretty much anywhere because it’s really handling tools I can carry forward. And at first, yeah, the scope and the size of this was overwhelming, but the team that you’re working with, the people you work with on a daily basis, collaboration is so huge on this. And I’ve really learned that it’s a matter of relying on other team members, not just within my own team, but other teams as well. So, it’s definitely been an eyeopener, and a lot of experience has been gained in a short amount of time.
Mike Hrycyk (08:31):
Yeah, I think that’s a good point that I don’t think I thought about before this conversation. When you go bigger and you learn how to deal with a bigger project with interactions and the testing and the etc., once you gain that training, it’s easier to scale it back, but it’s harder to scale up. If you’re a tester working on a $25,000 project and you’re now jumping to a 100 million project and you don’t get any training, that’s a difficult step to really get your brain around how it’s different. But once you know big projects, it’s a lot easier to scale down to a smaller project and prioritize what it is that you really have to focus on. At least I think that’s true.
Scott Dillon (09:13):
I would agree with you on that for sure. Yeah.
Mike Hrycyk (09:16):
So, here’s a hard question. So, in testing, a lot of testers have a phrase that they use, which is testing, is testing. That when you’re hiring a tester and you’re like, oh, you’ve never worked in this vertical before, one of the first things they’ll say is, yeah, but testing is testing, so I can do it. Which isn’t always the same as what people who are bringing them onto a project want to hear, because we always want to have relevant experience. Can you guys highlight what are some of the differences in a federal project about testing? Is it as simple as team size? And I don’t think that’s true. So, I’m asking. Paul?
Paul Schenk (09:49):
Probably not just team size, it’s more about business context because in the end, we’re testing to make sure that something achieves the business outcomes. Business outcomes in the federal sense or even any government sense is a little different than the private sector, where there’s either a sales or market penetration goal. The federal projects tend to have different objectives that aren’t necessarily financially driven. They’re usually service-driven. And to be able to get that context for the testing requires a little bit of a mind shift in that you have to not only understand how the product will work, but the why the product works that why is often very different than people’s experience before. You may be working on a backend system, let’s say, at a manufacturing company, and its goal is very simple: we want to make sure that we can process orders faster or more efficiently. In the federal context, it may not be about speed and efficiency, but about correctness and fairness. So, the test cases need to take that into account because the government’s not really a business. They’re in many ways a service provider and a unique service provider. And I think that’s probably the biggest difference here is really the mind shift about why, and why sort of informs a lot of the test cases.
Mike Hrycyk (11:12):
Great. Scott, have you built any insights?
Scott Dillon (11:16):
Yeah, actually, those are great points that Paul brought up, because one of the projects I was on before was an American company, and I was in their marketing department, and their focus was on driving new sales, getting new customers, and reaching out to other markets. How can we reach this market? Change your marketing, change your colours. All these nuances and things like accessibility was kind of put on the back burner because they didn’t care too much. They’re like, well, we’ll work on that after, we’ll work on that later. Whereas with the federal government, they have a lot of stakeholders that they have to make sure that they’re getting it right, as Paul said. Not necessarily making money, but making sure it’s right and fair. And accessibility is huge because there’s a lot of Canadians who have accessibility issues, whether it’s blind, loss of limbs, whatever, there’s a whole scheme of things. And this project and the federal government they really focus on making sure that everything is accessible for all Canadians because if they miss out on one group, no matter what group that is, even if it’s colorblindness, for instance, that group can really suffer. So, accessibility for one thing, because I’m also part of PLATO’s Center of Excellence for Accessibility. I have been so happy from where I sit, seeing how much emphasis they put on accessibility for this project, because it is big. It’s growing internationally, there’s new standards always being set, so it makes you really happy to see things in this arena that they are focusing on things like accessibility.
Mike Hrycyk (12:41):
Yeah, I mean, if you think about it, a private commercial enterprise can look at their statistics and look at the cost and decide that 0.02% of their user base is going to be impacted by not caring about accessibility, and then they can make a decision based on that to not care. You don’t get to do that in government.
Scott Dillon (13:00):
No, that’s exactly it.
Mike Hrycyk (13:01):
That’s interesting. I hadn’t thought about that. So, this is a question that I think anyone who thinks about government is afraid of, and it’s okay, you’re allowed to frighten us back. And the question is simple: What about meeting load? Is it different in government projects? And just to highlight this, I was thinking about a crown project one of my people was working on and they had a kickoff, and so, there was an SI and there was a systems integrators part of it, and internals and lots of stakeholders, and there were 97 people in the technical kickoff for the project to start. Then I think about the number of people you might have, you’re not going to get anything useful out of a 97-person meeting, no interactions. So, you’re going to have to break that up into a whole bunch of other meetings. And so, is that something you have to track really closely? Is meeting load in these government projects huge? Maybe Paul, you’re at 97 hours of meetings a week, but what about a tester? So, I don’t know if there’s a good answer to this question, but we’ll start with you, Paul.
Paul Schenk (13:57):
Yeah, I think the sort of post-pandemic world I think is meeting-focused more than it was in the past. So, I think that everyone seeing that from all the testers and all every type of project, more meeting-focused than brief in-person interactions. So, there is that. I think on the federal government side, one of the things that’s very important is they have – there’s a culture of consensus that everyone involved, even peripherally in the project, is encouraged to become part of that consensus. Which makes the meetings very large, so people feel like they have been informed as they go through the process. So, the meetings can be very, very large. On our current project, it’s nothing to have a meeting where there are 200 people, and that’s usually, as you said, a presentation. But at the working level for testers, scrum meetings can easily have 20, 30 people, and it’s all about ensuring that there’s consensus formed as work goes on, as opposed to somebody feeling like they weren’t brought along for the journey and consensus isn’t obtained. So, it is very meeting-centric and more people than I would see in a private sector company, where it might not be as consensus-based as more than this is the outcome that we’re driving for, this is the direction, and we’ll just go do it. Federal projects tend to be a little bit more organic, as consensus is formed
Scott Dillon (15:28):
It is definitely the meetings that are much larger, and as I alluded to before, collaboration is really big on this. So, you could have a meeting with 200 people, and then right after that meeting, you’re breaking up into groups of 50 or 60 or 20. There’s subsequent meetings after a large meeting, and a lot of it has to do with explaining what you just went through, questions and answers. That’s kind of done in the smaller groups as opposed to trying to have 250 people asking questions at the same time. The federal government has set it up so there are multiple different ways to get your voice heard, to throw in questions and answers, whether it be email or over Teams. So that’s been really good. But for meeting-wise, yeah, the collaboration is so big on this project that we’re currently on that there are days where I’ll be on calls seven to eight hours of that day, depending on what’s going on that week or in that month or in that phase of the project. We have really, really high-level times where we have to meet with multiple people all the time. There’s other ones where we can breathe a little bit. But definitely compared to where I was in the private sector, this project in federal government is much more meeting heavy in regards to making sure that everybody is aligned, everybody’s on the same page, that if there’s any questions, we’re ironing them out right away as opposed to waiting until the end of the month to start bringing up any concerns. So, that’s one of the things I like, too, is that if there are concerns at any level, people have the voice and the ability to bring them up and talk about them.
Mike Hrycyk (16:54):
That’s something that I think connects to a bigger thing that I’m going to mention in a second. But when you say that as soon as you tell me it’s a 200 person meeting or it’s a 50 person meeting, my brain just says, okay, not everyone’s going to get to say what they need to say, but I like what you’ve said is that they’ve built a culture where you can have a say if you need it, and there is feedback. And so that relates into this other thing that the last two questions have sort of said to me that I think when you think about a federal project, there’s certain skills that you might need in small chunks in other places, but that really come to the fore in a big project. So, your program leads one of the giant skills that they need, one of the specializations, is the ability to facilitate past what I’m calling consensus paralysis, right? If you’ve got 27 groups pulling in 27 different ways, finding the one path that makes everyone, let’s call it not miserable, not everyone’s always be happy, that’s a unique skill, and you have to find it. That’s one of the reasons I think that government projects go back to different SIs over and over again. It’s because they’ve demonstrated that they have that skill. But to relate that topic back to our own conversation about testing, I think that one of the skills that a good federal focused tester brings is the ability to – so, one of the big things we do as testers is we put ourselves in the shoes of a user and test from that perspective to see if there’s something wrong. Well, you now have to amp that skill up to be multiple users in multiple ways and be willing to learn that there are multiple viewpoints and multiple users and build test cases that support it. And I think government projects do allow for that increased breadth of test cases to do that. Does that match with your perceptions, Paul?
Paul Schenk (18:37):
Yeah, I think so. I would say as you’re saying that I was reflecting, everyone navigates that requirement to build consensus differently, but it is always something on top of mind. It’s about providing service and I tend to work with people who care deeply and to know very intimately what’s happening. So, we need to always respect that. Even in a large transformation that we’re working on now where we’re radically changing how things will be done, it’s very important to show that respect and to make sure that people understand that you understand you’re making this large change. To help them understand that it’s required. It’s generally required either to improve service to Canadians or to enhance a program. So, they’re usually – at least the core reasons, usually resonate with the people we’re working with, and that helps build the consensus.
Mike Hrycyk (19:34):
Anything to add to that, Scott?
Scott Dillon (19:34):
Paul sums up pretty well. Yeah, consensus there are different ways of getting to it. I, myself, have been in awe of the leadership, Paul and company, because of their ability to be able to see and understand the different perspectives and be able to come to a consensus that yes, there will be some people that might not be happy with it, but overall from the project point of view, from government point of view, and from the Canadian’s point of view, the services are being enhanced. And that is the driving force for a lot of these decisions is, hey, we’re enhancing this, we’re updating this. And yes, we have to maybe step on some toes to get there, but it’s for the higher good of all. And to see it in action, I’ve been in awe, and I’ve just been very happy to be part of this whole experience.
Mike Hrycyk (20:20):
And that comes back to maybe back to the testing is testing idea. Testing is testing, but the one thing that experience in federal projects does is it helps you understand the different personas, right? So you’re going into planning your testing, understanding, yes, I’ve got 27 different personas that have to be represented in my testing. And so, that’s something you can teach a tester, but they’re not going to walk in and say, you know what? I understand all 27 personas that I have to work with.
(20:49):
Let’s talk about the dirty word, governance. First, I want all of our listeners to understand that every project you’ve ever worked on had governance, but for very small projects, we don’t call it governance, you just call it a status report, or you still call it part of your daily requirements they have to talk about or whatever. But governance becomes a big and important word in a federal project where you have 500 people in the project. So, we’re going to start with you this to this time, Scott, because you’ve been dumped in the deep end of governance, and part of your role is making sure we’re compliant with governance. So, tell us about, just sort of generalize your experience with governance, and then maybe if you have any insight, how does that governance impact testers?
Scott Dillon (21:32):
Well, I am speaking as a member of the governance team of this project, so to say, I’m in the deep end of it, this pretty much sums it up! But the one thing I’ve really understood with governance is that, especially with a project this size, there are a lot of responsibilities even before the project kicks off. There’s a lot of documentation, a lot of tools to get in order, in place before anything even begins. Once that happens, communication to the teams as well as communication up to leadership are always being done every single day. So, it’s really important to know, okay, why are we doing this, and how do I explain that why to say a team lead? Because people in the leadership will know, okay, we want this process changed as part of the governance team to take that and say, okay, this process changed. This process affects that process. We follow the whole chain of events. And when we communicate that to all the stakeholders. Sometimes 500 500-plus people have to be explained, okay, this is a new process for this. This is why it’s happening. Here’s our folders to save things. Step-by-step ways of doing that. So we have to create that as a governance team, then communicate that down towards the team level. And the status reports. It’s a continuous thing. For me, myself, that’s actually one of my main roles is to help with the reporting of this project. And that involves me using a lot of the soft skills. Communication is one of them, but as you were saying too, Mike, was you’ve got 27 different personas. I have to be able to cater my communication 27 different ways. Kind of going from a sports analogy, the New York Yankees and their heyday, their manager was asked a question, How do you manage a team full of egos and multimillion-dollar contracts? And he says, I talk to each one of them individually. I don’t talk to them as a team. Because I know they have different priorities. They think differently. That’s where I am as a governance team, getting to know these leads I speak to. Getting to know the leadership that I speak to and the managers. And understanding, okay, how do they like to be communicated to? And in governance, there’s a lot of responsibility for us too to make sure that processes are being followed, process changes are being communicated effectively. Reporting is accurate. Being a tester and dealing with governance, talking to you and handling different changes is one thing, but being part of that governance team that’s given the process changes or any other changes needed or reporting structure and then communicating it downwards is a whole other skill as well. So, it really incorporates a lot of customization based on what I’m talking about, who I’m talking to and how it affects that person.
Mike Hrycyk (24:29):
Awesome. Paul, do you have a perspective around that?
Paul Schenk (24:32):
Scott summed it up well. I think for people assigned to these projects – and often when we’re on these very large projects, we get to know the small parts that we’re on. And often people working on those projects wonder, oh, why do I keep getting pestered about status? Or why is this important? Why is that important? And I think in the context of these large federal projects, it’s important for people to realize that there may be hundreds of people on the project, and even let’s say, from the SI side, there might be hundreds. There’s also many hundreds of people who are often behind the scenes or on the federal side, and all that’s rolling up to one person in the government who needs to understand the health of the project and also needs to justify that the project is making progress towards the outcomes that have been authorized. And that’s got to feed up from the bottom. So, the governance structure and the reporting is really all supporting that the project is doing what the project has the authority for and doing it in the way that was planned. And if there are issues, the people at the top can take corrective action early to be able to get the outcomes that they expect. So, often I feel people feel like the governance is a little onerous in these large projects, but it’s necessary to ensure that Canadians’ money is being well spent.
Mike Hrycyk (26:08):
Yeah, I think based on what the two of you said, I’ve come up with a metaphor that might work. I’m going to say it, and then you guys can confirm or deny it. So, the metaphor to help a tester understand the importance of governance is think back to the RTM, the requirements traceability matrix. Most testers will agree that when you get a complex set of test requirements, that having an RTM to make sure that you’re testing all of those requirements and that everything’s getting a test and that your coverage is high, is important. When you think about a $500 million project with 600-plus people on it, making sure that everything’s getting done, the RTM for that, the global idea, is the governance, right? It’s making sure that you’re taking care of all of the things that need to be taken care of, and you, as a singular tester, don’t get to see all of it, but you feed into that. You’re feeding into that traceability matrix.
Paul Schenk (27:01):
Yeah, absolutely. It’s really about – that’s actually the governance is tracking that we’re meeting requirements, which is a little bit what testing does, right? Testing makes sure that whatever is being tested meets requirements. Governance is, in some sense, another test or control.
Mike Hrycyk (27:20):
Good. We’re all on the same page. One of the tropes, one of the tropes that people talk about with federal projects, is that they’re really inflexible. So, my question is, is there any flexibility or agility in a project? Are all the processes and set in stone, and do they need to be set in stone or as your project moves forward, can it evolve? Is that even possible?
Paul Schenk (27:44):
Yeah, I think two answers to that question. First is that I see across, at least the departments that I’m aware of, there is a desire to be more flexible, and we’re running a safe, agile project, which I would say five or 10 years ago that would’ve been unheard of in the federal government. So, at the working level and day-to-day execution, there’s a lot of flexibility and the ability to move. The thing that is unique about federal projects is that the flow from certain federal offices, either through the Treasury Board’s Secretariat or up and through the ministerial offices, those processes are inflexible, scheduled and very formal. They need to be because they’re the controlling authorities. So, even if you have a flexible or even an agile project, it needs to feed into a very rigid approval structure, which makes a little bit of contention as you go through the project, and the governance and leadership help you navigate that.
Mike Hrycyk (28:56):
Well, and I think there’s an analogy that will help there, too. If you think about an API, your inputs and outputs are structured so that the information moves in a way that can be consumed. How you’re gathering that information behind that integration point, that can be any number of ways of doing it, but it’s that you have to communicate in a way that will make sense.
Paul Schenk (29:16):
Yeah, absolutely.
Mike Hrycyk (29:19):
Alright, an extension of exactly the same question, but this one will be near and dear to most testers. What about tools? How easy is it to get a tool approved in one of these projects? Is it only giant enterprise tools because we’re in an enterprise, or are open source tools even an option?
Paul Schenk (29:36):
Yeah, I’d say all tools are an option. The important thing is that inside of the government’s network, the departments are custodians of very sensitive data. If you think about most departments, they have some sensitive data, and they have a duty to protect that. And part of that is validating what software they bring into their environment to look at the supply chain there and to make sure that they’re not bringing in threats that would have a threat to the operation of programs or threat to people’s data. So, there is a process getting tools in. We’re looking at SaaS tools, we’re looking at enterprise tools, we’re looking at open source tools. They all start the same with: Are these secure? And often that’s a very difficult question to answer. And then if that gets through that, then there’s the procurement fairness part of it. If we spend Canadians’ money, it has to be done in a fair manner. So, there may be a tool that somebody really, really likes that is, let’s say, a commercial tool, but there’s no mechanism to procure a tool because this team likes it. It has to be this team has a need, and then let every vendor of tools that provide that to supply that need to be able to sell to the government. So, there’s that process. So, if we go for large tools or tools you need to purchase, it has to be done fairly, and that tends to take longer than expected, just to make sure the process is fair. When it’s an open-source tool, usually it can get done quicker. It doesn’t mean that any of those get away from having to meet the security requirements. The tool has to be accessible. We can’t exclude employees based on their requirements, and also need to service both official languages, which, surprisingly for a lot of tools, is a problem. So, there are all these considerations that you may not have in private sector projects, that are just fundamental requirements of federal projects.
Mike Hrycyk (31:46):
It’s almost a little bit like karma. So, QA spend their life defending the requirements, defending that we’re meeting the requirements and making sure that they’re going to do that, right? And that’s one of our roles is being the defender of the needs of the end user. And because of the procurement rules in government, what we’re saying is, yeah, you don’t get to pick a tool. You get to tell me your requirements, and we’ll give you the tool. And that’s not unfair, right? So it’s almost karmic. Not how a lot of testers like, they do like the flexibility, but I think it’s kind of amusing to me.
(32:22):
Okay. We’ve got two quick wrap-up questions we’re going to ask each of you. The first one is, someone comes to you, they’ve never done a government project as a tester, but they want to. What can they do to help themselves be better prepared? Let’s start with you, Scott.
Scott Dillon (32:38):
First of all, I would say just work on your soft skills. Work on being able to communicate with people. I find that if you’re being asked a question and you’re stumped, a lot of people don’t know what to do if they don’t have the answer to the question. Sometimes they’re afraid to say, I don’t know, and to find the answers or just to speak up on something. So, I find if you’re coming into a project that is this big and it’s kind of overwhelming, you need to talk to people and say, hey, I’m kind of overwhelmed right now. Or, hey, I’m kind of lost right now. Or, hey, can you show me how to do this process? Because in the federal government, there’s a lot of processes, processes for everything. If you’re unsure of anything, don’t be afraid to ask out. I’ve seen so many people that I’ve reached out to, and they’re like, Oh, I didn’t know I was supposed to do that, or I didn’t understand that. It’s like, well, we’ll speak to your lead about that. Bring it up. So, it’s one of the things I would really say is to – the technical skills, the testing, things like that can be taught, and that’s part of who you are, but be able to branch out and being able to say, hey, I don’t know the answer to this question, or can you please help me? Those are two big phrases I find that will really help show that, hey, you’re willing to learn, and hey, you’re not afraid to say, I don’t know, let’s teach you. Let’s do some more knowledge transfer.
Mike Hrycyk (33:53):
That’s a good skill for any project. But yeah. Okay. So it’s especially important on this. Okay. Paul, from your perspective, what can people do to prepare to be a tester on a federal project?
Paul Schenk (34:03):
Yeah, I’m not sure if I would say much different than other projects, although get ready for the size. And what I always tell people when they’re starting their first project, usually in the sphere that I work in most of the time, is get ready for a very rewarding experience. I have worked in social assistance in provinces, and the times you hear about, we’re doing this because of these personal situations, and you fight back the tears because people are in this situation, you don’t know, but you end up creating something that helps people. And genuinely helps people, and people will use it and experience it. I think that’s one of the things people need to appreciate when they’re on these projects. They’re really helping create something that Canadians are going to use and they’ll rely on. If you work for a commercial company, people may use your thing that you built, but you’re not making their life different or better fundamentally, usually. But in the federal government, you are. And I think it’s get prepared for that and really have that mindset that you’re there to make a difference.
Mike Hrycyk (35:16):
In some cases, you’re helping people eat and feed their children, right? You’re making a real difference. Okay, last question, and I’m happy that we have these two perspectives. We have you, Paul, and you’ve got a nice big sample set. So, statistically, your answer is going to be one thing, and then for Scott, it’s really fresh. So, what do you love about working on government projects, and what do you wish was different?
Paul Schenk (35:40):
So, what I love is actually just what I said: I really love working on projects that make a difference for Canadian society. I think working on federal projects really gives you the opportunity to make a difference to Canada, and I love that. And what do I wish was different? Not a lot, except for day to day, the size of the projects brings a lot of frustration as you go through because you need to make sure everything is done correctly, that you’re not overstepping, and you’re being fair. That tends to make it seem like it’s slower than you want it to be, but it’s very important for the first reason that I said, that you’re doing something for Canadians. So, day to day, I wish it were faster, but I understand why it can’t.
Mike Hrycyk (36:33):
Great. All right, Scott?
Scott Dillon (36:35):
I love the people I work with, my team, the other teams, there’s just such a wide array. I’m such a people person. I love dealing with the different types of people I work with across the entire country, and even some in the States. And I also love the fact, as Paul mentioned too, that we are making a difference for Canadians, that, as you said, Mike, what we’re doing is helping families to put food on the table and to feed their children and to put clothes on their backs. These are things that I can take for myself and be like, hey, I helped do this. I might not be a construction person who drives by a bridge and says, hey, I helped build that, but I can go online and go to the Government of Canada website and say, hey, I helped create this. And that for me is really rewarding in its own right.
(37:18):
But things that I would change are also that, yeah, sometimes things just seem to be – I seem to feel like I’m under the microscope, and part of that might be because of the team I’m on and what I have to do, but I’m not really used to being under a microscope day in and day out. But it’s one of those things I’m learning to adapt with. Some of the structure and processes is inflexible at some points, but there’s a reason for that because we have to answer questions to maybe one person at the very, very top so they can understand it. So, things happen really fast. And I guess the one thing I would say to change is if I had more breathing room, it’d be awesome. But at the end of the day, when I’m done, I’m proud of what I’ve done. In the moments of frustration and the moments of stress and chaos is when we’re finding ourselves thriving. And for me, that’s something that I really experienced, that I’m getting off this, I couldn’t buy it anywhere else because I am succeeding. I am finding myself patting myself on the back more often, and it’s just something that, yeah, I wouldn’t change this for the world. I love it. I can’t believe I’m saying that right now, but I actually do love it because it does give that sense of pride and sense of accomplishment.
Mike Hrycyk (38:29):
Well, that’s great. Alright, well, thank you to our panel for joining us for a really great discussion about testing at the federal level. Thank you to our listeners for tuning in. I think that this discussion will really help people understand what they’re getting into and give them some perspective when things are different or change is different, or why governance is important. So, I think that conversation’s been useful.
(38:51):
If you had anything you’d like to add to our conversation, we’d love to hear your feedback, comments and questions. You can find us at @PLATOTesting on LinkedIn and Facebook or on our website. You can find links to all of our social media and websites in the episode description. If you are enjoying listening to our technology-focused podcast, we’d love it if you could rate and review PLATO Panel Talks on whatever platform you’re listening on. Thank you again for listening, and we’ll talk to you again next time.