Not every new thing is an innovation

My friend Alice shared that she conducted a talk and shared that they were using so-and-so tool in their project, whereas typically projects use this other so-and-so tool. That seemed to have wowed her audience and they said that could be considered as an innovation. Alice and I agreed that it felt like it wasn’t. Unless you’d call it an innovation if I suggested to use Google Docs as opposed to Microsoft Office.

But isn’t innovation simply a new idea, device or method? Something new that will make things easier for yourself and others? Yes and yes. But taking that definition kind of opens the floodgates where anything new could be taken as innovation — which shouldn’t be the case because not every new thing can be regarded as truly innovative.

In googling what is not innovation in the hopes of getting more insights on this, I found this whose points I do understand:

First, an improvement that only meets the market standard or reacts to innovation that your competitors have already introduced into the market is NOT innovation. It’s playing catch-up.

Second, introducing an improvement that does not significantly differentiate you from your competitors is NOT innovation. It’s simply just an improvement—evolutionary, not revolutionary.

And finally, introducing improvement that may give you a competitive advantage but also can be easily copied by your competitors is NOT innovation. It’s just a temporary advantage.

…Here’s the takeaway: It’s easy to confuse improvement with innovation. But only innovation creates a unique outcome that, despite the superior financial returns resulting from the action, competitors are either unwilling or unable to match.

Now, innovation or not, I still believe in looking for and sharing things that helps us make things easier for ourselves and others. Whatever ideas we put onto the table and help realize, just push for it if it holds the promise of making things better. And you can just let other people decide if it’s an innovation or not.

Looking into improvement opportunities… Laziness FTW

20120524-095504.jpg I found this bit (screenshot at the left) a couple of days ago as I was going through a Business Analyst reference. It lists some common examples of improvement opportunities that a BA is likely to identify. But I think it extends to any role, after all, continuous improvement can and should be everyone’s business. Sometimes when I’ve got time to kill at the office, instead of visiting Facebook, 9gag or other time sinks, I make it a point to think about my work and my team’s work to reflect on what can still be improved. I try to leverage on “laziness” to look for ways to do things faster or make things simpler. 😉 Looking into the common examples given in the list can be a good starting point.

Automate or simplify the work people perform.
For instance, in a previous project, there were SQL queries or Unix commands that I had to run frequently. What I did was to tie them all together into scripts so I just need to run the script and then review the results afterwards. Another example is the sharing of shortcuts or other quick workarounds to the team during our test team meetings. If there are tedious tasks – especially those that have to be performed repeatedly – these could be something worth reviewing or automating. If you come across a tool that could help you do your work faster, share it.

Improve access to information.
Consolidating references into a repository that is accessible to those who need them is an example. Another example is generating reports from our defect management tool which captured information that we had to focus on (e.g., number of days the bugs remained open). In both cases, you make the relevant information easily available to those who need them. If there are things that are hard to find or hard to retrieve, yet should be available to the team, then this could be an area for improvement.

Reduce complexity of interfaces.
For most of the tools deployed to a previous team, I prepared a README reference to hopefully make it easier for them to use the tool. Another example is creating a view for our defect management tool which displayed only the fields that were relevant. The default view displayed all fields which could look a bit daunting as there were so many columns. If there’s something that looks far more complicated than it should be, then this could be something that needs to be worked on.

Increase consistency of behavior.
In my old team, there was a tendency for meetings to start late – so folks who actually come in on time end up penalized since it’s their time that gets wasted the most. This wasn’t the consistency I wanted though. What I did was I took ownership of the test team meetings and made it a point to start on time and with a prepared agenda. Another example is preparing a set of standard test cases for checks that are needed across certain applications. Without this in place, the tendency is tester X tends to miss out on some stuff, while tester Y covers them but misses out on other stuff. If there’s something that has to be done consistently, support it by reinforcing the behavior behind it or by providing some structure to reinforce it.

Eliminate redundancy.
In one project, a colleague and I did a review on test cases and we managed to eliminate some overlaps. There was tester X who worked on A, B, C; and tester Y who worked on C, D, E. They might not have been aware that they were working on C had it not been for the more holistic review. Another example is we had a couple of scripts that functioned quite similarly. One summed up a couple of fields from a text file, while another did the same thing but with the ability to do groupings. I asked a volunteer to merge them so that there’ll be only one script to use and maintain. If two folks are working on the same thing, then that might be a waste of effort; their energies could be diverted into something more useful or worthwhile. If you have more than one working solution, it could be worth examining whether the cost of maintaining them all outweighs the benefit.