 |
||
  |
||
| It’s Not Just Technology | ||
| Some
time ago, I attended a conference where the
departing keynote address was entitled “It’s
Not the Technology, Dude!” given by Jon
Seidel.**
The
point behind his talk was that it’s not
really the technology that makes or breaks a
project. Those of you who have contracted with
me for your projects have probably heard me
say exactly this same thing at one time or another.
Where Jon focused on the reasons that projects
fail, I’d like to focus on why technology
is not actually the purpose of our projects.
Let’s identify a few of those reasons: Solutions Starting a project tends to be about creating a new or better solution in order to update your work processes. It’s an opportunity to revisit all the things that got slipped-in just because a process was quickly needed, but are sometimes poor ways of doing things. One day, someone insists that this way is the way it must be done because that is the way it was always done, even though the originator of the process probably just needed to enable it to actually get done. Any LIMS is a software package, not a solution. Some solutions might be more easily achieved using a software package, but the software package is just a portion of the solution. Until it solves something, that is to say, until it is implemented in a way that solves whatever problems you experience, that software package has not contributed to the solution. Reducing the Pain Multitudes of different applications to do the work. Other times, it’s that the work process requires unnatural or unnecessary steps. Looking at a company from a wider view, there are almost always forms and bits of information that are scattered throughout the organization but are needed often by one particular work process. Even within the localized view, this is sometimes the case within one laboratory, where their data is scattered across many forms and applications. Part of the goal of a new project should be to reduce this scattered state of information and data. Think of it this way, by reducing the pain, that is to say, by getting rid of some of the clumsy or unnecessary steps, there will be more time to do the things that are most important. In other words, productivity will go up. Efficiency In high-throughput laboratories, a new project should have a goal of increasing efficiency. For example, automatically loading results from instruments into a LIMS is one area where most high-throughput labs see an easy efficiency gain. However, even low-throughput labs tend to see efficiency gains by doing things like this as one result is usually less manual rechecking of data. Regardless of the type of project, there are usually efficiency gains achieved somewhere in the process. Finally As you can see, I suggest that the focal points of the project should encompass the entire work process. Solutions, reducing the pain, and efficiency are just a few factors that our projects are actually about. I’m sure you can think of a few more. ** If any of you happen to be at a conference where Jon Seidel is giving this particular talk, it’s worth attending. |
||
| If you are not on the distribution list for "Out on a LIMS" but are reading this newsletter, you have probably stumbled across it via an Internet search. To join the list of this free, monthly newsletter, see the Newsletter page. For more information on GeoMetrick Enterprises, see the Home page. | ||
| Production
of This Newsletter Assistance in the production of this newsletter was provided by Teich Technical and Marketing Communications, which can help you find your new clients through marketing communications, technical writing, editing, indexing, and Web content services, along with training and educational materials development. Thea Teich, owner and principal, is currently the immediate past president of the Society for Technical Communication. Contact: Thea@TeichTMC.com |
||
| © GeoMetrick Enterprises 2006 | ||