Firstly, what is an MIS? It’s a wonderful computer-industry acronym that stands for Management Information System – which is about as unclear and meaningless as many other such acronyms. In short, the basic concept is that by utilizing properly designed software programs you can achieve wonderful improvements in productivity and reduced overheads, while also gaining the benefits of access to historic data for business analysis purposes. Any one of those facets might justify an investment in an MIS by itself, but package them all together and it’s a no-brainer… right? Well, maybe so – but like many great concepts, the benefit is directly proportional to the amount of effort applied during implementation.
The first step in any such project is to identify the chosen solution. There are really only two options here – you’ll need to decide whether to build it yourself (i.e. “custom” development) or identify a “package” that has been commercially developed for your specific industry niche. Both approaches have different challenges and benefits, as follows:
I’ll be honest here and suggest that this is by far the best approach if the desire is for unlimited modification in response to changing needs, or if your internal processes are simply unable to fit into a standard packaged solution. The system will be built specifically for your needs, and you can (relatively) easily change it whenever your business changes or in response to market adjustments. The other up-side is that if you do need to make changes, you have complete control – whereas asking a package vendor to change their software to meet your unique needs is both optimistic and unrealistic. More on that topic later.
However, custom development is also a minefield for the unwary. It’s expensive, time-consuming, and typically relies on you having ongoing access to the same IT folks who wrote the system. Handing a system to a new programmer who wasn’t involved in the initial development is like handing War and Peace to another novelist and asking for a couple of additional chapters to be inserted so the outcome is changed to your particular preference(s). Certainly not impossible, but even more time and expense will be incurred if the original creator is no longer available.
I used the word “creator” advisedly in that last sentence, because it’s vitally important to understand that computer programming is typically more art than science, even though the reverse might appear to be the case. It’s similar to the analogy about asking 10 graphic designers to produce a brochure, and receiving 10 different designs. Systems development is very often like that – if you give the same “task” to 10 different programmers, I can almost guarantee you’ll get 10 different approaches. Programmers are by nature “creative” types – so if you lose access to the creator, it can take another programmer quite some time to work out how the task was attacked in the first place; not to mention that they’ll likely feel honor-bound to “fix” it while they’re under the hood.
Having said that, if you have a good, well-managed, relatively stable IT team at your disposal (whether internal or external), and deep pockets as well, I will go out on a limb and state that custom development will usually achieve better results – because it’s built to your own specifications.
This is where the vast majority of converters will end up – for all the contrary reasons mentioned above. After all, it’s akin to having a programmer write a word processing program, an accounting program, or a spreadsheet program when there are excellent solutions already available. Other than time and cost, there are other benefits to be gained from selecting a package, as follows:
Packages are available “off the shelf,” so the time delay in getting a workable solution is much less than building it yourself.
Costs are usually much less – particularly when compared to the need for IT staff to continually maintain and support your own custom system.
Packaged solutions are usually the result of many years of development and enhancement in response to requests from other converters just like you – so you automatically get access to useful features and functions that you may not even have thought about yet.
Packages are produced and maintained by professional software companies – who have teams of staff under careful management control to produce programs to a reasonably “standard standard.” Accordingly, losing a key developer is less likely to bring development to a grinding halt, as other team members have been deliberately trained in a single methodology and are firmly discouraged from adding their own personal touches.
Support and training are also functions provided by packaged software companies (at additional cost of course), and these tasks are usually not well performed by internal staff. If we accept that programmers are creative types, asking them to train users in the everyday usage of the system is (to be frank) asking for trouble. Their personality profiles are typically extremely averse to sitting patiently with a new employee explaining how to do a basic function or responding to requests for help – so commercial software companies have specialist training teams whose entire “raison d’être” is to assist with the learning process. These are very different individuals, whose skillset is a good “working knowledge” of the system in everyday use, rather than the detailed functionality of how it actually does it.
Regardless of which approach you take, the next critical step (and often the least appreciated) is the actual implementation. So, assuming you now have a shiny new “solution” available to you – how to attack it such that the results come even close to your lofty expectations?
The critical word in the last sentence is “expectations.” Setting reasonable expectations in an MIS implementation is no less important than what you should normally be doing with your customers (i.e. under-promise and over-deliver). After many years in the IT industry, particularly engaged in large system implementations, I can assure you that the two biggest factors that need to be attacked head-on are expectation-setting and leadership commitment. Let’s explore each of these in more detail:
Plain Fact Number One: A broad-based MIS implementation (or indeed a change from one MIS to another) is guaranteed to be more of a challenge than you could possibly imagine – so it’s important to recognize that up front. If done properly, the benefits are usually well worth the effort, but it’s vital to understand that the pain will be substantial. Why? Well, there are numerous reasons, but most often it’s the people issues. Be prepared for significant “push-back” from your employees – each of them has different personalities and even the best workers will find good reasons to continue doing it “the same way we’ve always done it.”
Some will resist more openly than others, which can make it even more difficult to spot trouble areas. Some passive-aggressive types will undermine everything you do by simply “appearing” to be supportive while behind the scenes they’re doing everything in their power to stem the flow away from what they know and understand. So, be prepared to monitor progress very closely, and also be prepared to remove the old processes that allow resistors to make a choice.
So, the importance of setting the right expectations cannot be overstated. Pretending that this project is going to be a walk in the park in order to gain “acceptance” is simply setting yourself up for (valid) criticism when the going gets tough – which it will. I’m not suggesting you tell your staff that their lives are about to become totally miserable and they’ll be working 70-hour weeks for the next six months, but it is important to set the scene in a realistic way. There will be challenges and fear of the unknown. There will be unexpected issues that pop up mid-project, but be realistic and at least your folks should respect your integrity. Should…
Okay, it’s time for some brutal honesty. Plain Fact Number Two: Unless the leadership of the organization is totally committed to the project, and also very public about their commitment, the whole shebang is academic and will fail. Unless you demonstrate a firm, visible dedication to having the implementation completed and successful within a defined time-frame, it is VERY unlikely to achieve the goals you hoped for when embarking on the project. Sure, things can always go wrong to affect the project plan – but without a goal there is not enough “drive” to achieve anything useful. As leaders, you must demonstrate continued personal involvement or your staff will automatically assume it’s not important to you – which makes it unimportant to them too.
Oh, by the way, also understand that it’s not unknown for some staff to fall by the wayside when a major change (of any kind) takes place. Some folks just cannot absorb the way that a new MIS impacts their daily lives – this is human nature after all. So don’t be completely blind-sided if one or more employees just decides to move on – it may not happen, but it’s not unheard of so be prepared for it. And some others may actually threaten to quit unless you pull back and allow them to continue in their old ways – in such cases I shouldn’t need to tell you the answer. Any employee holding you to ransom is both unwelcome and counter-productive to your future, so deal with them appropriately.
The last piece of critical understanding you must have is primarily related to the “Packaged Solution” approach (although it still applies to a lesser degree when designing custom systems). That is – if you expect the chosen MIS to fit into your organization without affecting a myriad of established processes, you need to think again. The whole purpose of a new MIS is to improve the way you operate – to increase your profitability, to give you better understanding of your business, and to make for better customer interaction.
Therefore, to expect the chosen system to adapt to your old (inefficient) ways is to minimize the benefits you could achieve – so why bother? If you aren’t firmly focused on making productive changes throughout your organization, you’re better off spending the money and time on a beach somewhere. At least then you’ll (hopefully) have some fun and trust that the business will still be around in 5 years to support the umbrella-drinks and sunscreen.
If this sounds brutal, consider that a very large proportion of IT projects (of any kind) fail to achieve the goals set in the beginning – and the reason is almost invariably that the leadership lacked the personal drive and commitment to push the hard yards. If you leave an IT project to its own devices you can absolutely expect it to fail. Do not delegate and ignore – stay involved and you’ll have a reasonable chance of delivering dramatic benefits to your organization. Even if you don’t understand what the heck this technology stuff is all about (which is a very common scenario and nothing to be ashamed of), you must continue to demonstrate leadership. After all, isn’t that what you’re there for?
Steve Smith was President and Co-Owner of Lightning Labels until its acquisition in 2008 by Cenveo. Lightning Labels is a Denver-based label converter and was the first all-digital and internet-focused shop in the industry. Prior to his involvement in the label industry, Steve had an extensive career in Information Technology, including the establishment of several internet-based businesses, and was one of the early proponents of online marketing. He continues to be semi-active in the label industry as a speaker and consultant. Steve can be reached via email at firstname.lastname@example.org.