Today I want to talk about how learning software isn’t always just an IT thing. I’m frequently called in to address a technical skills deficit when in fact the IT skills gap that I need to address is also being blamed for an underlying process-based skills gap.
This post builds on my previous post on templates: Templates, Audit Trails, and Client Confidentiality.
I’ll assume that you’ve created a series of template files to support your business flow, standardize your documents in a professional-looking way, and maintain client confidentiality.
In this post, I’ll discuss a couple of ways you can make sure they’re collected together in a way that makes them easy to find and easy to use.
A client of mine was struggling with a slow Microsoft Excel-based application. This application brought in data from multiple database sources, and utilized pivot tables to explore, analyze, and summarize that data. My client had requested hardware upgrades from their IT department, which their IT department turned down. IT was right; the problem was with the design of the software application itself, that is, how they were utilizing the resources they had.
A few months ago, I was the client of another business person. At the close of our business, this person sent me a standard business letter (i.e., date, name/address, subject, salutation, body) with the intent of summing up the transaction. A quick review of this letter made obvious that the business person had opened a previous client’s letter with the intention of using it as a template, but had forgotten to change anything other than my name and address at the top; the information contained in the remainder of the letter was enough to piece together who that other client had been and the exact nature of their business transaction. This oversight/blunder poses a problem in three key areas: the audit trail of the project, client confidentiality, and professionalism. A minor process change could address and alleviate all three.
Brainstorming as a practice can seem completely nebulous, and so can quickly devolve into a practice that is completely unstructured. Like any productive practice, it takes a lot of mindful preparation and a lot of structure in terms of dealing with group dynamics and being capable of changing directions when the session isn’t fruitful. Some common questions your participants might be wondering are: What should I say out loud? Who gets to talk? When is it my turn? What if I don’t have any ideas??
I’ve already covered tips for preparation in earlier blog posts. Now it’s time to address those common questions.
By definition, brainstorming is a “spontaneous” group activity in which participants try to generate as many ideas as possible, however outlandish, without criticism. Brainstorming can take a lot of forms, and the “spontaneous” part is often misinterpreted as “if you invite people into a room and tell them to brainstorm, then magic will happen.” That (almost) never works. I believe that brainstorming requires a lot of structure and planning to be productive.