Stopgap solutions, what characteristic do they have in common? In part two of this series, I discussed the many faces of Excel and the idea that there is no one single solution that can address all of the functions, however manual, it can do. Functionally, stopgaps are all over the map, from workflow fixes to financial modeling fixes to reporting fixes, they lurk in all corners of technology. And, the one characteristic that all stopgap solutions have in common is that they are usually implemented hastily.
This makes sense, after all, without time restraints no one would implement a stopgap, they would simply wait until an ‘industrial strength’ solution could be implemented. But business doesn’t wait for anyone, particularly these days. Given the choice between waiting several months for an IT project to solve a need or throwing together a quick fix in Excel, most business people will choose the latter. This drives perhaps the most critical requirement for a gapplication program, speed. While gapplications don’t have to be implemented as fast as an Excel fix, they have to be able to be implemented a lot faster than most IT capabilities – in weeks not months.
A need for speed drives the technical requirements, as mentioned in my previous post about application flexibility and user self-service. However, it also drives a much more complex set of requirements around organizational processes. To put it another way, the most flexible technology in the world won’t allow you to implement a solution quickly if you have to go through a six month approval process to do it. This means that the second key component of a successful gapplication program, in addition to the technology itself, is an agile development process.
Now to be clear, I’m using agile with a small ‘a’ not a capital ‘A’. I’m not advising you necessarily need a scrum master or burn down charts or an agile tool set or any other trappings of formal Agile development methodologies. But, you do need to follow some of the key tenets of agile, namely business user immersion, iterative development, verbal communication vs. written specs, and a test-first mentality. Following these principles will allow you to implement quickly and change quickly, while putting testing front and center helps to balance the speed of implementation with the kind of control and risk mitigation that gapplications need in order to be better than the stopgaps they’re replacing.
How you kick off and implement a gapplication program in your company depends a lot on the nature of your IT department, the health of the business/IT relationship, and whether you’re coming at it from within the IT department or from within the business (you can do either). Rather than go through every permutation of these, I’ll talk about two general scenarios and will leave filling in the blanks as an exercise for the reader.
Implementing from the IT side
If you’re a CIO, or other IT leader, and you decide there would be value in a gapplication program, the first thing you need to do is identify a business stakeholder who is available on a full time basis to drive your first project. Like all successful agile initiatives, the business has to be immersed and the stakeholder will need to provide near real-time requirements, testing and sign off of the applications being produced. The second step is to mobilize a dedicated team to execute the work. In an Agile shop, this may just be a question of standing up a new scrum team with the business stakeholder as Product Owner. In a non-Agile shop, this is more of a challenge, and you’ll have to set up a team that is explicitly allowed to operate outside the normal project management bounds in a faster turnaround model. If you’re considering moving to Agile, this first gapplications team can be an ideal Agile pilot.
Implementing from the business side
The other scenario is a gapplications implementation lead from the business side of the organization, typically starting from a single department or perhaps the office of the COO. This can be organizationally challenging as it may involve creating, at least temporarily, a shadow IT organization. However, in today’s business environment, access to cloud solutions and a myriad of consulting service providers means that a business stakeholder with sufficient budget can stand up this kind of skunk works without much difficulty. The two biggest challenges in this case are ensuring that you have the project management and quality control capabilities to be successful, and not getting seriously yelled at by the CIO. A detailed discussion of the organizational dynamics and strategies around this pitfall is beyond this blog, but I’ve seen programs be successful when the sponsor clearly articulates the business case, gets CEO level support, and can communicate a clear strategy for integrating the gapplication program back into IT once it has reached maturity.
Overall, gapplications should be seriously considered by both the IT and business units as an integral part of delivering systems support to the business. With the appropriate technology and organizational approach, such a program can fill functional and organizational gaps that are hindering business agility and preventing organizations from reaching their strategic objectives.