Another day; another new concept.
Let's start with a story. Computer programming always held a certain allure to me. My interest was first piqued in the 70s when my cousin — the one with whom I played chess, Risk, and various other strategy games rather than go to our college classes — got into programming and told me it was the closest thing he ever found to playing games. I got the chance to occasionally dabble, but never did much more in the field until the late 80s. At that time (at least, I think it was the late 80s; time is causing my mind to slough off information it thinks is useless even when I think I still want it) our internal audit department got some of the first portable computers in the company. I began experimenting.
Eventually, I was using Lotus 1-2-3 and WYSIWYG to write database programs for our agency audits. For many of you, a couple of those words are gibberish. But, for those of you old enough to know what I'm talking about, you surely recognize that the last thing either of those tools was meant for was database programming.
Over time, we got new software (including a decent database program) and I was able to adapt and improve my original programs, streamlining our handling of agency audits, the planning process, and timekeeping.
The software continued changing and my role wandered away from such projects. But the fundamentals of what got developed, to the best of my knowledge, still play out in some of the programs being used by the department today.
Which leads to my recent discovery of a new concept. (Followed by urgings and beseechments that will seem familiar, but this time include a different spin and urgency.)
Recently, while doing research on robotic process automation (RPA – and, no, that wasn't the new concept; but if you haven't heard of it, you better start learning now), I came across the term "citizen developer."
Here's a quick synopsis of what I think this means. (And, with that, a barrage of warnings. I know just enough to be dangerous; what follows will be inexact and potentially wrong. Objects in the mirror may be closer than they appear, your mileage may differ, content may cause drowsiness, do not operate heavy machinery after reading, keep out of the reach of impressionable children and internal auditors, and this is just a swing at what it all might mean.)
Inquisitive minds want to know things. And, in that search for knowledge, many people explore the potential of programming. They are not a part of IT, they are not a part of a specific project (yet), they are not assigned to learn to program. They just see a tool that might provide value and they start exploring.
During that exploration, they learn that, not only is the tool useful, but they figure out practical applications. And, upon discovering those practical applications, they start building tools that help the department be more efficient and effective. Programs are written, time is saved, and the involvement of the IT department is not required. These are citizen developers.
Now, on the one hand this may seem like it would lead to pandemonium — an out-of-control conglomeration of programmers working on individual projects with no overriding rhyme, reason, or governance — the anathema of internal audit's desire for appropriate controls. However, in the real world, real value is coming from these approaches. And while there is increased risk, the benefits from these skunkworks outweigh those risks. In fact, the controls we would so love to see come crashing down on such situations restricts the value that can arise.
Part of the reason success is coming more easily is that programs are becoming easier and easier to understand and develop. In particular, part of the reason RPA is taking off at such a fast rate is that individuals with limited programming experience can jump in and, in very short order, start developing tools, applications, and programs that work.
Of course, there can be control issues. And internal audit should be aware of the risks and be cognizant of the work that is going on in this area. But awareness of a risk does not mean shutting down the cause of the risk. And, in this case, value triumphs.
But let's bring this one a little closer to home. Is there a citizen developer sitting in your ranks? Are there a few of them? Are you allowing them to play — to find ways to make internal audit better? Or are you chaining them to a schedule that does not allow room to experiment and grow?
Because I had the desire to learn and because I had bosses willing to allow me the time to experiment, I was able to make fundamental changes in the way we did our work. And I have talked with individuals who have like-minded people (and leaders) working in their internal audit departments right now — people making a difference and helping things get done differently.
For internal audit leaders, the message is one you've heard before. Let people be curious, let them experiment, and give them the time and latitude to find things that may not have been thought of. And the message for everyone else is similar. Explore, experiment, and take the time to make a difference. And, if it is the right thing for you, become a citizen developer.
But in this case, let's be more specific. RPA is something big. It is revolutionizing operations at departmental and organizational levels. And, if you have a hint of curiosity, an inkling that something might be there, any desire to find out what new thing might be found that can make a profound difference, this may be your chance. It is the opportunity to learn something new; it is the opportunity to change the way work is done; and it is the opportunity to become a champion for change in your department, your organization, and in the profession.