I’m an odd mix of preferences when it comes to technology. There are people who are always bleeding edge, where money is no object to always have the current tech. There are also people who fear change, who in their perfect world would still carry a beeper and run DOS. I don’t fall into either of these camps.
On one hand, I bought my Droid 2 the day they came out. On the other, I have implemented the same trouble ticketing system with 4 different companies. I’m on my 3rd MacBook Pro in 3 years, but I built my current PC workstation in 2007.
I like to think of myself as being a person who uses the best possible tool for the job (given constraints like cost, time, and ability to support it). I keep abreast of new technologies, but I don’t rush to adopt them for no other reason than because they are new. New, while appealing, (and an excellent marketing point) is not a valid reason for change. Business need is an excellent reason for change.
Using my wife as an example: about 4 years or so ago, she decided that she didn’t like our popcorn maker. It was 10 years old, it was loud, and it didn’t even have a power switch (you needed to unplug it to turn it off). Obviously the state of the art had improved since then, so it needed to be replaced. One evening I came home from work to the popcorn maker having been thrown away, and being told we were on a mission to get a new popcorn maker.
When I got home the next night a new popcorn maker was in the house. The first batch of popcorn was a hot burning mess. There were moving parts that would get stuck on the kernels, and overall it just did a poor job. The next night revealed another unit. It was a lot of work, and messy as well. It had the additional issue of filling the kitchen with smoke. The next attempt looked pretty, but the popcorn was very heavy (not fluffy), with a ton of uncooked kernels, as well as having a plastic-y smell.
After nearly a week of trials, she purchased the popcorn popper that we still have today. Funny about that.
So, just like you should never be the one to point out a flaw in someone else’s plan if you can’t offer a fix, it isn’t always good to scrap what you have until you have defined what you want that would be better.
Where I currently work, we have three different trouble ticket systems for various departments. The sales department has three different contact management systems in use as well. That sounds bad on the face of it, but this isn’t a unique situation. My previous job, IT Workshop, has 4 different customer data repositories. All in use, (some only holding older data), although only two being updated with new data (but not the same new data). The entire time I was with Wright Medical, they were implementing a new ticket system there as well. It had been selected to overcome all the shortcomings identified with the system it replaced, but the only opinion the entire userbase had in common about it was that they hated it more than the one that came before. (Admittedly, this is not uncommon. There is almost always user pushback with a new system, but it usually dies out quickly after a smooth implementation to a system that better meets user needs than the one it replaced.) Unfortunately, 10 months later, it was still hated because it didn’t do what it was expected to do.
What do these situations have in common? Well, the first two had identified issues with an existing system that seemed like they would be fixed with a replacement system. Then, either due to incompletely evaluating the scope of the issue, or just through poor planning and implementation, the decision was made to jump to a new system AGAIN before even completely migrating off the first system. The final situation was due to people over promising about a system to do things it was never designed to do, customizing it to perform every task that was described by the userbase (no matter how seldom a feature may be used) and then forcing the person who had to perform the implementation to do it as a “side job” around their full time set of responsibilities.
As we scope out a new ticketing and CRM project at work, these cases are what I am working actively to prevent. Many of the conversations have to be pushed beyond the “we don’t like what we have” statements. Some of the systems in place were the result of “we’d rather have this other system” as opposed to “This is the business problem we’re trying to solve, and we need a system that adequately performs A, B, and C, HAS to do X, and while Y and Z would be nice, we don’t need them.” Once we have an explicit needs assessment, we get buyoff from all the stakeholders, and then create a detailed scope of work. Once the resources have been allocated, we make sure the project plan has appropriate decision points to make changes or even abandon the project if that’s the right thing to do.
One thing I’ve learned – never be afraid to pull the plug and walk away. There’s enough to do without trying to force a system on your users that will only make their jobs harder.