The Arizona Medical Board’s Chief Technology Officer Pushpa Gregory shares her process for managing IT projects from meeting with leadership to incorporating budgets and involving stakeholders. She offers four tips for successful IT projects.
GL Solutions helps governments run, grow and adapt. For more information about GL Solutions and our modernization service for regulatory agencies, visit us on the web at www.glsolutions.com. Or connect with us via Facebook, Twitter or LinkedIn. Reach our host, Sam Hardin, at hardin@glsolutions.com. We look forward to hearing from you.
The Arizona Medical Board’s Chief Technology Officer Pushpa Gregory shares her process for managing IT projects from meeting with leadership to incorporating budgets and involving stakeholders. She offers four tips for successful IT projects.
GL Solutions helps governments run, grow and adapt. For more information about GL Solutions and our modernization service for regulatory agencies, visit us on the web at www.glsolutions.com. Or connect with us via Facebook, Twitter or LinkedIn. Reach our host, Sam Hardin, at hardin@glsolutions.com. We look forward to hearing from you.
Hello. Today I'm talking to Pushpa Gregory. She is the Chief Technology Officer for the Arizona Medical Board. And we're talking about IT projects and managing those IT projects. Are there any current IT projects that you are working on right now?
Pushpa Gregory:Yeah, definitely. We are in the process of moving to a new version seven for GL Suite, for our licensing and enforcement system. The second one, the second project is, we've just recently started working on creating dashboards for our decision makers. So that has been well, it's been requested a lot. So and I think there, we've made small modules and small projects for that. And we've seen a lot of good feedback from our board members from our, you know, leadership at the agency. So that's, that's one of the projects we want to expand on and create more dashboards for the decision makers.
Sam Hardin:When you talk about dashboards, you're talking about like, work queue, how do you assign work?
Pushpa Gregory:Yeah, financial dashboards. That's been one of the things well appreciated. And a lot of there was a lot of need for it too for leadership at the agency. So this is dashboards for decision makers. That's why we are focusing on at this time, we do hope to expand it further. But right now, that's our focus.
Sam Hardin:Okay. Are you using PowerBI or what technology?
Pushpa Gregory:Yeah. PowerBI.
Sam Hardin:Okay. Gotcha. So, when you look into it projects, and I, you listed out the three categories. So the first category is, you know, legislatively. The second one is what your licensee population will, will communicate you to you through surveys. And then the third one would would be, you know, staff, internal staff, is, I'm sure budgets considered, you know, can you speak on that process a little bit? Or is that more something that goes over to the fiscal, or the accounting department, and then, and then they kind of, you know, confirm what the budget is, and the money there?
Pushpa Gregory:Yeah, we definitely put in the requests or wishlist items. But budget is definitely an integral part of planning projects by any state agency. It has to be approved in advance. There's a process right, which is the financial department is obviously involved. Leadership is involved. Sometimes the state is involved too, the leaders at the state. So at different levels, budget is definitely considered. We have to keep that in mind.
Sam Hardin:Do you guys get together? So do you guys get together and meet about it? So sometimes, what I hear is that, you know, the the finance department, and then the leadership involved, and then the ITT team, there, there's some knowledge there that has to be transferred. Because sometimes, you know, when it's written down on a piece of paper or project plan, it's, it's kind of hard to understand. So do you guys ever get together? Yeah.
Pushpa Gregory:Definitely meet with our leadership, just so they understand the scope and benefits of that project, right? The main unless we explain it to them, sometimes they may not understand what what would be the long term benefit of it. So justifying a project is part integral part of the process. Same way with the staff, sometimes the staff has to come in to explain to IT staff, okay, this is why we want this. This is the implication of it. And then it goes down goes up the chain. We understand it, and then we have to put it to leadership. And then they have to understand it. So it's a lot of a lot of communication and collaboration.
Sam Hardin:And then, at what point in the project are you identifying, who are the subject matter experts? And then do you have staff that are project managers? Or, how's that identified?
Pushpa Gregory:Yeah, our agency works a little differently. I don't know how others manage it. But we have a full fledged in-house IT team. So we have a software development team. We have few software developers in house. So the way we approach projects is when it comes to a project request, the software developers actually talk to the staff, understand their process, maybe view what they're doing, understand what it will take to automate that process. So then they identify each departmen. So they get all the stakeholders together so that each department understands what their vision is and how it would impact the other people in the agency, because it's also correlated right? Then one department may not understand the change that they're making and what impact that change will have on say, finance or on licensing, so on investigators, so we do try and bring all the stakeholders together when discussing the requirements of a workflow process. I think that has helped us a lot. So that way, everyone, we have buy in from all the departments, it's not after we roll out something, then somebody says, hey, this will not really work for us, right? So when we say subject matter experts, it's software developers, identifying the subject matter experts in each department, and then bringing them to a table and having discussions about okay, this is the functionality, and this is how we're trying to implement it. So that they all know what's coming, and there is no shocks at the end of the cycle.
Sam Hardin:Is change difficult for the agency? So you know, if you as as the software development team, say, you know, we've gotten this request from our licensee population, or, you know, hey, this has been mandated by legislation, we have to do this. Do you find implementing those changes difficult sometimes? Or do you do you find that the agency staff can can, you know, sometimes, there can be some roadblocks or it can be challenging to implement those changes?
Pushpa Gregory:Our staff in the agency have seen so many improvements over these years with all the automation. Their expectations are pretty high. It's become part of an expectation now. Yes, when changes are mandated, you know, those mandated changes that come? Those are mandated. So really, we have to do it the best way possible, without too much pain for the staff. Those changes, I think, it's, it's a little difficult to accept sometimes, but that has to be done. There are no options there. And then the changes that come from licensees, I think, because as an agency, we are so customer focused, make sure our licensees have a good experience, or the general Arizona public have a good experience. I think that they understand that the staff understands that. And so they're open to those changes. We don't have issues where, you know, they're resisting the change so long as they are. And that's why I think it's important to involve them right from the beginning. If things have been already implemented, and then you go and tell them, but something which is going to change in the art process, they may not accept it so well. But we make sure to bring everybody to the table right at the outset. Right from the, you know, the conception of the project even.
Sam Hardin:I'm assuming on the tail-end of the project, your team is providing training for those end users or, you know, how would you utilize this once? It's once it's fully implemented?
Pushpa Gregory:Yes, so we start involved in them right from the UAT stage. So as the step the software team has tested some of the changes that have come. And once we figured out okay, this is working as per our requirement, and most of all the expectations are met, then we bring in the team from the respective departments, the subject matter experts, and ask them to use it for a while on UAT. Test it out for us. So that way, when it goes to production, they are already aware of what the changes are and how it's going to impact them what workarounds they need.
Sam Hardin:Is there a project management methodology that you use at your agency?
Pushpa Gregory:Depends on the project. Okay, so for, like for GL related projects, or anything that changes that we're making in collaboration with a GL staff, we pretty much rely on the waterfall methodology. We get the requirements upfront, make sure everybody is on board with the requirements. They all agree. There's consensus. And then we hand it over to the GL team for design and development and testing. And once it's tested at that stage, we do include the subject matter experts, so they get to see. But we prefer this methodology because I think it is so much more structured and there are well defined goals. It helps our staff to kind of think about, okay, what are the things that they're really looking for? What is the end goal? And there is less scope creep and feature overloads in this method? So this, so yeah, for GL related projects, we always use the waterfall methodology. But for some other projects, like the dashboards, where there's so much client input, right? Client into so much more client interfacing there, it's so much dependent on what the client wants. In those we are using agile or a hybrid. But yeah, depends on the mostly for us, it depends on the project, what type of project we're doing, and what the needs are.
Sam Hardin:When I would, I would think because, you know, you guys are taking on that project internally, and you guys kind of have the ability and freedom to, you know, get a get an understanding of what the users are looking for with the dashboards, for example. And then and then you develop something, and then they'll give them your feedback. And then you'll say, okay, we can make this tweak, we can make that tweak. So that that definitely makes sense.
Pushpa Gregory:So the audience right? Dashboard that we're working on, the the audience is the decision makers in the agency. And they have, you know, when, as it goes, there needs evolve, like, Oh, this is nice, but I would like to have this as well. So yeah, we definitely use both methodologies.
Sam Hardin:Is there a preference for one or the other?
Pushpa Gregory:GL related, when we are talking to our staff, understanding their processes, we've had more success with waterfall, just because of the two features. I said. Scope creep. Otherwise, you know, there'll just be so much scope creep, the timeline for the project will just extend, and then shifting priorities, right, because of the nature of where we are, as an agency, there's always shifting priorities. So in order to make sure all that doesn't happen, we tried to do waterfall there. And we've had more success with waterfall. That way, even with, you know, even here in this process, they know, okay, this is the time, we need commitment from our staff in terms of time and resources for testing and for requirements definition. And I think they're able to do that with waterfall because it's only in like in the beginning and during testing, right. We're not going back to them all the time. That seems to make a difference to them. They're willing to give that commitment of time if they know okay, it's only at the outset. And almost at the end.
Sam Hardin:Can you speak on some some general roadblocks that you see to project completion or project success?
Pushpa Gregory:Requirements? I think, yeah, requirements is the most common roadblock. The staff sometimes cannot articulate what their processes are. They're not able to articulate enough. They're not they may not be technically savvy to have a vision of how it should work, right? Or they may not be able to relate that vision to us. So that takes us to the requirement. We make sure we spend a lot of time in that phase to make sure all we understood the requirements, documented it verified it. Then the second roadblock is shifting priorities, you know, something comes down the line and we're working on it, and then something else, then we have to work on something else. So I think that's just the nature of where we are.
Sam Hardin:Well, let me ask you, project post mortems. Is that something that you guys do? Do you believe them? Do you believe they're beneficial?
Pushpa Gregory:Just absolutely. Absolutely. We definitely do that. We've been able to improve our own processes, because of that. Right? It's always a continuous learning process. So yeah, we definitely see value in that and we make sure we do that. It's easy to kind of skim over but I think it has a lot of benefit.
Sam Hardin:Do you have any tips or tricks to support successful IT projects are some things that you may have implemented that that other agencies departments could benefit from?
Pushpa Gregory:Select the right people to be part of the project team. Right? As I mentioned, we have a different structure in our agency where we have a small group of developers in house. And that has been a big reason for our success. Because the developers, especially with GL Suite, the developers are the ones who are getting all the gathering all the requirements, understanding the workflow processes, and then they are able to speak the language with the GL staff. They're able to put the request through in a manner that there's less rework or the expectations are met. So I think that has been, you know, getting the right people to be part of the project has been one of the, I think the main factor. And then second is take the time to plan the project in detail. We see a lot of projects just, you know, just start the project. People just start the project. There is not enough time and energy gone into planning it in detail so that the rest of the steps goes well. Again, you know, I can't emphasize enough about requirements being well defined. And then make adequate time for resources for testing. Generally, that's one I think place where people don't give enough time and resources and then causes production issues and project delays.
Sam Hardin:All right. Well, thanks for for answering those questions. I really appreciate your feedback. And I think that will be helpful for other agencies and departments and just some of the success that that you guys have had with with IT projects.