Get it in Writing?
April 26, 2011
I recently attended the RFID Journal Live 2011 trade show and conference in Orlando, FL. I really like this event because it brings together a diverse group of vendors, academics and customers in a setting that promotes open, honest discussions. These discussions are about not only technology, but also the state of the markets RFID serves, including aerospace, medical/heath care, defense, supply chain/retail and manufacturing, the process of RFID, like developing your ROI and even the “how to” parts of it all.
I would highly recommend attending this event to anyone seriously looking to implement RFID, especially at an organizational level. You will gain insight into the advantages of the RFID value proposition and the visibility capability all in one place, at one time. (For future events and to take advantage of RFID Journals offering, go to www.rfidjournal.com)
While attending one of the great conference sessions on how to develop your ROI case, I heard a gentleman make a very insightful inquiry about how others control the responsibilities of multiple vendors involved in a single project. Frankly, as a manufacturer, I found myself sympathizing with his suggested plight. After the session, I had the pleasure to meet Robert Morrison, Principal at Creative Technology and Management Services, LLC. (www.creativetechmgt.com) We then discussed this issue a little further. The point he raised was a great point when working with several partners on a RFID or any large-scale implementation for that matter. Unfortunately when working at this scale and a problem arises, people can tend to point the finger at someone else. (I don’t personally believe it is out of any malicious intent, but simply because of the nature of so many being involved, we all like to think it’s not our fault, “we did such a great job on our part, it must be the other organizations issue”.) I found it interesting that as a manufacturer, many times when this happens we are the recipient of the finger-pointing. (And frankly in some rare cases, it can be deserved, no one is perfect.) But many times we find ourselves defending our products to the point where we will even provide an engineering resource just to show our products are working to specification and that it is a software or implementation shortcoming. As a manufacturer, we accept and even want to provide this as a point of service when possible. But in the end, the customer can sometimes pay the price in delays or substandard performance trying to resolve the issue.
So how do you handle the “blame game” as Robert and I discussed? Must everything be in writing down to the minutia? Probably not realistic. And frankly, I don’t know that I have a single answer to this, but I would make a few suggestions: Start with making sure the roles and responsibilities are clearly defined, especially in who will be taking the lead role between the project partners (a consultant or external project manager for example). I would also suggest that you keep a strong internal champion on the project from beginning to end, and not necessarily someone who is a technical expert, but a good project manager. Also, be very careful of project creep! This is something that needs to be controlled with a project “lock”. Once this milestone hits, the scope should be fixed. This way everyone can clearly understand what’s expected.
Finally, as with all larger projects involving multiple partners, I would suggest considering setting the scope up with the “stick AND the carrot”. (Many only use the stick or threats.) If the scope and responsibilities are clear and an incentive toward cooperation exists, I hope you’ll see a successful outcome from the very beginning and never have to worry about a conversation like we had.