Testing 1 - 2 - 3
Moving an idea to reality takes effort and planning. It also takes a bit of testing. What may start as a flash of insight may be just a flash in the pan unless it is nurtured and progressed along.
Here are the four main steps I follow to take an idea from infancy to maturity, or abandon it along the way. In the August issue we talked about step one—the Idea. We will now move into the action steps two through four. They include the following: Proof of concept, Pilot, Proliferation. They really are a formal way to test, test, and test again. Ideas that survive the testing will be empowering to your team.
We discussed the Idea phase last time, so we can move into the next step quickly. Taking the output of the idea refinement process and selecting a really good candidate, we now want to find out if the idea has any merit in reality.
Step Two − Proof of Concept
In this step, you see if you can make the idea work at least once in the real world. It is the step that proves the achievability of the idea. Let’s say you have a desire to see if you can eliminate the end user need for hunting down and inserting blocks from a standard library. Many users have no idea where the library of parts is located, they do not remember what was used in prior projects, and they often redraw items that are readily available. This may be a programming effort that includes creating LISP routines, menus updates, CUI files, and more. Before you start down the path too far you have to outline and repeat the steps needed to pull and insert the block. Can I pull blocks from a library? Can I set the proper insertion parameters? Can it be programmed? Can it be automated? Will it change the workflow? How will everyone embrace this new process?
Write down the steps you think it will take to do it manually and then review them to see if any or all can be replaced by some customization work. Most on the list may be readily defined and easy to create. Others may take a little effort to “prove” that it can be done. This is when you prove it. Create little routines and menu bits that automate the process. Once you think you have the incremental steps down, then move to the entire process. Program it and have others try it out. Listen to their concerns and refinement ideas and put them in place.
Enlist a few users to help out. They may be the ones that helped nurture the idea or some that have no clue what you are trying to achieve. By running it past a small team, you get a quick feedback loop going and can adjust quickly to bumps and stalls along the road.
You may find that your idea is not achievable and the proving grounds have uncovered this. While I have chosen a fairly straightforward idea of pulling and inserting blocks, many of your ideas may be ahead of their time and not achievable yet. Or there may be troubles trying to adjust the current data formats, or versions, or naming or…. The things that might derail an idea can be fleshed out in the proof of concept phase with a smaller team and a little measured effort. The end of this step is triggered by a working model or a failed attempt.
The output of this step is a viable process that achieves the results desired. It may be clunky, but it works. It is not fully ready for everyone to start using, but you have proven that the goal is achievable. The other portion of a proof of concept process is buy-in from a larger group. My example here is not really time or money intensive, but some of your efforts may take a good amount of time and budget. By having a proving process, you can go to management with confidence that the idea is achievable and within reach with a little time and money.
This will lead us into the next step with the following questions still to be contemplated. What are people doing now? Will this change the workflow? How will everyone embrace this new process? How can we encourage use?
Step Three − Pilot
The next step is to pilot the concept to a larger group of users. This may be a project team or an office location. It should be selected from staff that are near you so you can monitor their success or troubles. The pilot staff should know that they are involved in a process. The staff should include not only those who are adventurous in testing new tools, but also some who may resist change. A wide variety of users that reflects your overall staff is what you are looking for—not just the cream of the crop who love every new trick.
Some confuse Pilot with Proof of Concept. They differ widely. While the proof of concept phase does involve a portion of piloting, the arena of the conceptual phase is too small to get a good enough shake down run at the idea. Will it withstand more scrutiny? Can it do what is needed by more users? Is it easy enough to understand and use? Proof of concept usually has such a tight feedback loop that everyone knows what the goal is and what the nuances are in getting the tool to work. Piloting takes us into the unknown.
You pilot a project by taking it to a wider, but still controlled, group. You want to observe the use of a tool or process and see what people do with it. Does it need refinement? Is it too limited in scope and not embracing the needs of a wider group? Does anyone care about using it? Is there any excitement in its unveiling?
The pilot step usually lasts about a week or two. Give it enough time for people to embrace or reject the idea. Give them time for feedback. Give yourself time to make adjustments. The signal that the pilot is done is enthusiasm to use the tool more or a casting aside of it. The pilot fleshes out the viability of this effort gaining ground and becoming the new standard.
The output of the pilot is a stable tool or process that is embraced by the majority of users in the group. The sentiment should be a willingness to embrace and not reject the change. Excitement would be great, but sometimes just a lack of negativity is a positive.
Next time we will look at the final step—Proliferation. How to get the entire firm to embrace the change.
