A wise mentor once told me “Done is better than Perfect.” While it is always wise to have a formal Strategic Technology Plan and a Project Planning Methodology in place, are there times when a quick fix that has low risk, low complexity and immediately solves a problem will do the trick? I voice a resounding, “Heck yeah!!”
At Cornerstone, we’ve assisted in the development of many Strategic Technology Plans and implemented Project Planning Methodologies for numerous clients. Good news for the consultant-resistant out there: a Band-Aid is often something a bank can do on its own.
No matter what the institution’s maturity level, there are processes, procedures and protocols in place since the ink on the charter dried that are manual, laborious and could go away with a little code-hacking, otherwise known as Process Reengineering. The trick is to select the right process for a Band-Aid. The hacked solution should be simple, narrowly focused and extremely easy to use. A Band-Aid. Not a cast. There should be very little maintenance required to the focused application or “applet” when the coding is complete. If the development takes longer than two months from start to finish, it’s an application, not a Band-Aid.
Here are a few examples of Band-Aids I applied in my former life as a bank SVP of Loan Operations:
So Gonzo mongers, as opposed to the classic “waterfall” method of systems development, the rapid-fire steps involved in creating an effective Band-Aid are:
Step 1: The first step of identifying the processes that are candidates for Band-Aid reengineering is also the easiest part. No need for time studies here. Just ask someone that actually does the work one question: “What is the most frequent, manual process you do that is an integral part of your job?” Or rephrase it as, “What frustrates you and gives you carpal tunnel?” Take the responses, verify with others that do the same job, determine if it is something that needs to continue and if so, you have your first Band Aid candidate.
The process selected for automation should be one that can be run in dual mode (manual and automated). If the applet has to be turned on like a light-switch with no manual backup available, the selected process is the wrong one to automate. By light-switched we mean turning the applet on at one time for every instance of the process everywhere in the organization. This type of setup presents too much risk of operational interruption. The best philosophy to bring to Band-Aid developing is triaging. You bump your head, take an aspirin; cut your finger, get a Band-Aid; slice your forearm, get stitches; sever a major limb, start looking for a prosthetic and rehabilitation. With the hacked-together development of process Band-Aids, we want to stay in the medicine cabinet and out of the ambulance or hospital.
Step 2: The second step, design, is a bit more difficult only because if something has been manual for a long time, then obviously either the tech group has ignored it or the business unit does not believe that automation is possible. After all, who would want to keep re-keying data from one form to another five times per form and 50 forms per day? Get someone in your organization who is a killer process analyst to observe the inputs, processes and outputs for a couple of hours.
Step 3: Then sit them down with the Mountain Dew guzzling ASP/SQL jock and lay out (a.k.a. document) the two or three screens needed and a couple of database tables. Here’s one technical tip: don’t forget date/time stamps on all SQL transaction records. The coder will have something the analyst can play with in three or four days. The young coders love building this stuff. That’s why it’s called hacking.
Step 4: Have the analyst test it, break it, redo the UI (user interface) since the coder took some liberties and then write a two-page training guide. Even though the guide will never be read because the applet is so simple, the crustiest employee won’t be able to use the absence of it as a crutch. And you can never have enough documentation to satisfy Mr. Sarbanes and Mr. Oxley.
Wondering “where are the users in this process?” If it is necessary to obtain user input after the identification and observation phases, it is a case of selecting the wrong process. Sure, there might be a clarification question or two. But don’t slow the process down with a committee. The users in this Band-Aid building process come at the beginning and the end. Remember, we’re talking important but non-mission critical, non-customer facing processes. Necessary bureaucracy.
Testing is important to retain credibility as much as to ensure accuracy. Testing should include running some table dumps before, during and after the process. Only by looking at the raw data in the transaction tables will the analyst know if the applet is performing correctly.
Steps 5 and 6: Finally, add the applet to the intranet, have some non-change-averse users bang on it and then let it rip. Once the applet is installed and running, there may be some resistance from the input generators, the processors or the output recipients. Training for a Band-Aid is mostly OJT and driven a great deal by best practice users of the new applet.
Step 7: Use those obstacles to tweak the applet and move on to the next identified process. After three or four months of use you will have enough transaction data to produce some interesting management reports with a tool like Crystal Reports.
The end-product applet may be one that can be expanded, but this is the point where caution must be exercised. These are not enterprise-wide, mission-critical applications being built using the typical software development model. Chances are it will scale easily enough for volume but not for complexity. At the point complexity is introduced, the applet has transitioned from Band-Aid into cosmetic surgery. And nobody wants Jacko’s nose being part of their operations.
Have you looked in your medicine cabinet lately?
Sure, the end result is an assortment of applets without similar look-and-feel and maybe some minor reuse of control tables. But you will also have processes that can be executed the same way every time with known quality and easily reportable management data for speed and volume metrics. And that’s what operations is all about.
Process improvement does not always require forklift upgrades or quarters of project management. In many instances, incremental process improvement can be achieved with aspirin and Band-Aids – which are just as important in total health care as sutures and casts.
-mc