Chief Technology Officer for the Arizona Medical Board Pushpa Gregory shares tips for successful project management in an interview with GL Solutions.
Pushpa Gregory: Select the right people to be part of the project team. 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 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.
And then second is take the time to plan the project in detail. We see a lot of people just start the project. There is not enough time and energy going into planning it in detail so that the rest of the steps goes well.
Again, I can’t emphasize enough about requirements being well defined.
And then make adequate time for resources for testing. Generally, that’s one place where people don’t give enough time and resources and then that causes production issues and project delays.
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. 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.
Then they identify each department. 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 all so correlated. 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, or on investigators.
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, 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 the table and having discussions about this is the functionality, and this is how we’re trying to implement it. So that they all know what’s coming, and there are no shocks at the end of the cycle.
Pushpa Gregory: Depends on the project. So for GL (Solutions) 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.
But for some other projects, like the dashboards, there’s so much client input…It’s so dependent on what the client wants. In those we are using agile or a hybrid…It depends on the project, what type of project we’re doing, and what the needs are.
Pushpa Gregory: Absolutely. We definitely do that. We’ve been able to improve our own processes, because of that. It’s always a continuous learning process. 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.
To hear the whole interview, listen to our Talkin’ SaaS podcast episode.
Editor’s note: Answers edited for clarity and brevity.
