Many new ideas have come and gone, with only some of them being successful in reaching into people's workflow. Here I look at what the elements for success might be.
In the course of doing our work, we often notice that there could be some improvements in the process, workflow, or design of the tools and resources we use, that could make our work easier or better.
Being able to take advantage of new ideas and suggestions for improvement needs a fairly formal means of capturing and evaluation them. Without that, most will likely fall through the cracks, unless they have a passionate and influential advocate.
Unfortunately, good ideas are not limited to those who have the drive to get them past a lot of resistance. Conversely, those with the power and influence may not have the best ideas. Therefore, a neutral process that guarantees vetting of all ideas and suggestions is the best method of ensuring innovation has a fertile gound for nurturing.
Many ideas can come from those who have to work with problem processes or equipment every day, but they can often feel like they don't really get much opportunity to make improvements. Ensure the capturing process is not discriminatory as to sources of ideas.
Some factors that can go into deciding whether an idea or suggestion is desirable are whether it will:
Sometimes an idea may be simple, and of its own, seems fairly inconsequential, but it can sometimes enable a lot more consequential improvements.
For example, I implemented a file naming convention for a client. The file name incorporated the:
Now, while a name like that makes it easier for us people to identify the content without opening the file, the naming convention came into its own when I developed a VB utility that read all the file names from all the product document repositories, copied release versions to a web server, and created a one page site, by product, from which all project teams around the world could download them.
That turned a half hour a day job into one requiring a tweak every three months or so. As a plus, the utility sent me an email listing any files that were named incorrectly, so I could easily fix them on that day.
The online help HTML files also used the same naming convention, so I built another VB utility that took the master HTML file for a product release, recursively identified all the links to its particular versions of pages, and copied the files to the product version's master release distribution location.
These show that the evaluation needs to be wider in scope that just what appears immediately useful.
Ideas are one thing, but implementing them is another, and discovering whether they can be requires some research and experimentation.
Important considerations in evaluating feasability are whether the idea will:
When evaluating, the current and future operating costs of the existing process need to be used when comparing to the new alternative(s). The existing situation is never zero-cost, but has the advantage of there being no new implementation costs. In practice, I would expect a 5 to 10 times improvement in time or cost, and even a break-even well before a year is up.
Good ideas and workable implementations are not enough to be a success. Those left to use the implementation will be the ultimate deciders of whether it is really successful.
This is probably where most implementations fall down, as adoption is highly dependent upon the thinking and culture of those having to live with the implementation. If they can't really understand how it benefits them, or it is operationally awkward, there will be an operational disconnect, leading to excess operating costs, using alternatives or fixes, or even abandonment.
Therefore, any feasibility needs to incorporate some input from those who will live with the implementation. It is much cheaper to improve something before it's implemented than after.