There are times when you look back and ask yourself how you made certain choices. Not the ones you made in college, I mean the moments in your IT career when you had a great idea, a transformative idea.
But when you pursued it, you forgot to ask key questions. And then, the project either went down in flames or the project timeline was so long that it wrapped itself around your neck and choked the innovation out of you (and maybe your peers).
It happened to me.
I was the IT director for an agency. We had field staff, we had a small but growing portion of sophisticated external customers and we were balancing multiple funding programs, hundreds of community development projects and weekly meetings to determine what we would fund. In addition, we had staff onboarding issues.
Our agency was fighting a strong local economy that could pay so much more than we could that we were constantly losing staff. Turnover and training for our very specific compliance responsibilities or even understanding where the field staff was on any given day was a challenge.
And then it hit us … We need an intranet!
Code, and code, and code …
A shiny intranet with an electronic in-and-out board, a workflow that could create the weekly agenda and details for our funding meeting and a place to post documentation – so there was always one place to find the funding policies we needed to consult to comply with funding requirements and agency responsibilities. New employees could go to one place to access this information!
At the time, I had a staff person who was a crackerjack SQL coder. He had good listening skills and a general desire to improve processes and information sharing in our agency. And so, with a huge diagram on my whiteboard as his guide, he began to code, and code, and code.
He was so smart and normally so fast that I forgot to consider how many lines of code you might need to create a workflow from scratch. Or create an HTML form, write the code to gather data points, create an aggregated document of all forms submitted for a meeting and email it to the committee.
It took a while because, like so many of us in government, this wasn’t his only job. And, once the first version was done, users would have other requests and more code would be needed or changes had to be made. Ultimately, it took months, but it did work. At least until we changed systems again and needed more code and we gave up; it took too much time to manage the code and create new code.
And then, my crackerjack coder was gone, he got a better deal. Meanwhile, we could not sustain the solutions he created without documentation. In fact, we never had that position available to us again. Part of the reason was the fact that it took so long for solutions to emerge that my leadership had lost faith in the ability of IT to deliver solutions.
Fast forward to today. What would I do differently?
Putting aside that we have more tools than ever, here’s what I would ask if I was undertaking these projects today, working as a government IT leader in an equally sparsely funded, overworked agency.
3 questions every government IT leader needs to ask
First, do I have the tools to avoid custom code as the way to create a solution?
This one question and the answer (which should be “yes” if you are investing in a new platform) changes your ability to deliver, deliver quickly and affordably and manage any revisions that might be required.
Custom code is not sustainable, it’s expensive and it can’t easily support integrations or survive necessary upgrades and updates to core systems.
Next, can I undertake the project in small steps?
The problem with my project is that my own conception was bigger than it should have been. Today’s content services platforms can easily handle my needs and they can be achieved through micro-services, low-code or configuration tools and easy integration options.
And, because of these small bites, you can add features more quickly and this lets you respond to your users faster. Features rolling out more frequently is a great way to keep your progress front and center, ultimately building good faith with your users.
Finally, does the platform and provider offer tools that can consolidate the number of systems I support?
At first glance, this seems off point, but depending on how you answer the first two questions, your answers may be leading to business teams buying their own cloud-based systems and then expecting your IT department to support them.
This is the exact opposite of what we need to do in a public sector that is facing less staff and less funding. If our solution projects take too long due to coding or we wait to get needed enhancements, our business teams will look for their own solutions and then can use our own inability to deliver solutions fast enough as the reason for their independent buying decisions.
Consolidation of the solutions needing support can happen with a low-code content services platform that offers configuration, integration tools and automation while letting us abandon paper. The trick is to stop forgetting the questions that I forgot and move to platforms with proven low-code and repeatable solution components.
The right content services platform will support government’s new focus on shared services, consolidated systems and scalability that were developed to avoid the problem I created for myself. And, with the right vendor partner, it allows us to make sustainable solution decisions today and still deliver for our end users and customers into the future.
With the right platform, you’ll never have to ask when the solution will be ready and you can deliver transformative technology tools for your agency.
