Feb. 22, 2007—I spent a lot of time debating in my mind what the subject of this first interactive column should be. I considered writing about how to construct an RFID lab, how to integrate RFID systems with material-handling devices or how to overcome warehouse inventory-management challenges. These are all important topics, and I'm sure I'll address them in the future. But for this first column, I decided to focus on some of the lessons learned over the years I've worked on RFID implementations. Here they are:
Focus your efforts: Deciding on the exact focus of your RFID project is paramount to its success. Every project manager on the planet will tell you about the hazards of scope creep. RFID technology is a natural way to automate many problematic processes throughout your organization, so it is particularly prone to scope creep. When you decide to pilot or implement, carefully define what is—and is not—in scope, then live and die by that scope. If you lose your focus, you will find yourself behind schedule and quickly exceeding your budget, without solving the original problem that led you to deploy RFID in the first place.
Deal with real-world environments: Today, many RFID interrogators are being installed in rough environments. This can be a real challenge, because no matter how tough your interrogators are, improperly mounting them will put them in harm's way. The result would be similar to what you see in the before and after photos below. Ouch!
When going into battle, a smart general will secure the ground already claimed before trying to advance farther into enemy territory. In the same manner, make sure the first interrogator you install can function properly in the environment before installing additional units in similar locations.
Pace yourself: Trying to reach too far too fast will quickly demonstrate to senior management that the technology is "not ready for prime time." How many times have we heard this about RFID? Many times, it wasn't the technology that was at fault—it was the people running the projects, responding to pressure to deliver a system within unrealistic timelines. The technology will achieve the objectives if the proper time and attention are given to getting it right before extending to production.
Keep it simple: Carefully design your solution, using the least amount of components required. Complexity in design will result in a great science project, but not a realistically supportable solution. Remember: You build this once, but you will support it forever.
Start managing your data at the reader level: The less data you have to push across the network, the better. EPCglobal's application level events (ALE) specification can be used to reduce the data from RFID interrogators, but the flexibility it offers on where and how to implement it sometimes creates problems for the over-zealous integrator or middleware designer. If you can, implement this at the reader level, or as closely as possible, so simple reports can be used for activity up the chain instead of complex data streams that will cause traffic bottlenecks and slow responses.
Plan for failure during the design phase of your solution: Risk assessments and response planning will dramatically help reduce the amount of downtime you will experience when a failure occurs. And, yes, a failure will occur somewhere. Which would you prefer: a planned response or a knee-jerk reaction?
Don't design in a bubble: When you are working through a design that will help make other people's jobs easier or faster, ask for their help to make sure the solution fits the problem. Too many solutions start and finish in a lab or on paper. Then the solution is designed and delivered to production, and the people who have to use the device are left to accommodate its shortcomings. When they try to tell the design team about issues with the solution, they're perceived as malcontents stuck in their ways. After all, this solution came backed by management; it has to do the job, right?
In reality, if their feedback had been requested during design, critical flaws in the design might have been fixed before they became an expensive and embarrassing problem to resolve. Bottom line: Ask the people walking the concrete how the proposed solution looks to them, then listen to what they say. It could save your project a lot of time and money.
Be creative and imaginative: This technology will do many things, but following the crowd will net you exactly what everyone else is getting. As with any technology, RFID can create solutions to "impossible" problems, but only if you are willing to find a way to solve them. Impossible is a word for people without creativity or determination, who are willing to accept failure. In my world, failure is simply an incremental success. When it doesn't work, I know what path not to try next round, and I am determined enough to try them all until I find the one that does.
There you have it—eight lessons I've learned. I'll be sharing more in the coming months. Since this Expert Forum is designed to be interactive, I encourage you to post your lessons learned, or to post a question. I'll do my best to answer it, and I'm sure other experts will chime in with their own view, as well.
Mark Brown is VP of professional services at RFID4U, a global provider of RFID education and advisory services with RFID design, construction and integration projects throughout the United States, Europe and Asia. Mark is leading cutting-edge RFID deployments. He and the team of experienced consultants he leads are industry recognized and trusted subject-matter experts known for their participation in major industry initiatives, such as Auto-ID Labs and EPCglobal workgroups. They have authored well-publicized white papers and three bestselling RFID certification books, and they speak at major trade shows and industry events. RFID4U partners with the best RFID manufacturers, service providers and laboratories throughout the world, demonstrating cutting-edge technology to solve challenges throughout diverse organizations in all industry verticals.