My father used to complain about people that read a magazine article and then based on the ideas presented, thought they had a PhD on the subject. With that in mind, this is my way of saying that you should read this article and know that subsequent work must follow, but I will suggest more of this at the end.
So what is this article about? It’s about the scary statement that 80 percent of M2M implementations are considered failures, or put another way, the best implementation is most often the prototype.
Here are some guidelines that should be considered when implementing or even contemplating an M2M implementation.
Start Simple: There should be a simple understanding of the implementation to increase measurable value. If the strategy does not start with a direct impact on something that impacts the bottom line then the data is bound to be caught in vague platitudes of use that will never materialize. I recommend making the system Web-based for the simple reason that all too often when incorporated in the corporate systems, the value gets lost. As a new system, it is highly unlikely you are going to change the user interface of the systems you are being attached to and as such your system is bound to lose its impact. Worse yet, it may put your system in the hands of employees that have no business using it. This can only lead to complaints that it does not do what they want, or worse requirements you do not need. We should all remember Dr. Frankenfurter’s reply to Janet, “I didn’t build him for you.”
Stay Discplined: The tendency for feature creep is gigantic here. We live in an age where analytics are so exalted that every piece of data is considered a gem to be explored. My advice is to not be driven by this hope. A few years back we were trying to help a green field carrier implement their OSS/BSS strategy. They became in love with the idea of the Network Element Resource Database (NERD). It featured upper management speaking in grand gestures about the value they were going to find in parsing and using the data for network simulation and other lofty goals. The problem was that it was not an element manager, so the data was doing nothing to help with the immediate goals of managing and monitoring the network. If you are blessed with unlimited network capacity then go ahead and stream it, but only listen to what you have agreed as value. However, in most cases the network is cost and not an asset so remember to treat the data coming out as a potential for inefficiency and waste. I am not saying you can’t decide to use the data later, but for now its value is at best null. Keep the resources focused on the added value of what made you implement M2M in the first place.
Stand Alone Success: If you do succeed, remember that success has many fathers, while failure is an orphan. If you have managed to impact where you intended and not let feature creep ruin the project. The system will be recognized for its value and you will find yourself being attached to all sorts of tweaks that are now being asked for from top, bottom and sideways in the organization. My advice is its time to train them on the principles and keep your system safely away from 2.0 dreams.
Which brings me to the principles.
Fundamentally what we are talking about in this article is the subject known as “Lean.” Lean software development and lean management are all off shoots of lean manufacturing developed in Toyota.
I recommend joining some of the meetups that occur near you focused on Lean principles to find like-minded implementers who can help you stay the course.
I also recommend you apply Lean, Agile and Scrum to the software side of the development. This will be really hard in the large corporations where they have probably declared themselves agile already and want to manage you. There are meetup groups here as well.
I do not recommend that you end your study with this article. If you do I will have to start referring to you as Doctor. :<)
Edited by
Stefanie Mosca
