Sneaking Web 2.0 in the Back Door
This is my site Written by Alora on February 6, 2009 – 1:32 am

This post was originally written for and published on Social Computing Magazine.

Those of us in the Web 2.0 space who come from a technology background are often a little stunned when we discover that it is frequently our IT cohorts who pose some of the biggest obstacles to prospective enterprise implementations.

After all, wouldn’t it be better to use (for example) a SaaS or cloud computing solution for something, rather than bring yet one more department-specific application inside the firewall, for an already over-stretched staff to have to support?

Of course, in a totally rational universe, this wouldn’t be in question, but when it comes to change, ration is frequently shouted down by emotion. So in that spirit, I present five recommendations to employ when attempting to introduce the advantages of Web 2.0 to your reluctant enterprise, including (potentially) your IT Department.

  1. Start with the lowest of the low-hanging fruit

    This is, without a doubt, the most important thing to remember when trying to get your organization on-board with the value of Web 2.0 capabilities. Every single organization has something, somewhere that can be made much easier – you just need to look for it.

    I was working in the IT Department of an industry-leading organization which had virtually no standardized project management tool set or methodology. And yet, being a project-centric organization required that each Friday everyone provide status reports. For years, each person put the information in their own format – a bullet list in Outlook, a template in Word, an Excel spreadsheet, a PowerPoint presentation, whatever worked best for them. Team members would provide status updates to project and functional managers, who would roll up their view to their director. And then the Directors of each group would consolidate everything, and hand it off to the department admin, who would spent a whole (long and tedious) day manually pulling everything together into a single, semi-cohesive document for the CIO and the rest of the executives. Not only was it a nightmare for all involved, but it was bad enough to make people actually dread Fridays.

    While I would love to balk about how rare that type of thing is, I would be lying if I said that. Endless time wasters like this are commonplace, and any objective observer would be quick to point out that they are an insane and expensive waste of time. So, our goal was to find a way to make this onerous, tedious and thoroughly unpleasant task easier for everyone. The “selling point” was not about how much greater information it would provide; it was not about how we would be able to track trends week-over-week; it wasn’t about gains in leadership oversight. There was nothing altruistic or theoretical about the goal. It was 100% tactical and immediate: “Look at how much easier we can make your life!”

    After some very quick-and-dirty SaaS tool comparison, we selected the extremely flexible and ridiculously affordable Intuit product, QuickBase. Literally, in less than 30 minutes, we had created an app, defined the fields we wanted people to fill in, and started adding users to invite in and use the system.

  2. Start small

    Sure, there are tons of things that might fall in the “low hanging fruit” category, but find a small one – like status reports, time cards, or a team calendar – something that can be localized and does not require cross-departmental coordination. Limit the scope of what you are trying to do with the first iteration.

    What proved so profoundly valuable for our QuickBase implementation was that, once people realized how much simpler it was to fill out three fields of information instead of sitting in front of their computer for an entire morning worrying about formatting and what details matter and what details can be omitted, it streamlined the whole process. Additionally, once it became clear that the reports the system could generate were just as valuable and ready-to-go out to the stakeholders in other departments as they were for IT Leadership, then it offered each person the chance to even further cut back on the amount of time they spent writing status reports each week.

    Because we started small, and with something that had previously been such an on-going source of pain and frustration, our user base became the biggest advocates for the tool, pushing to use it more and more. And because of the degree to which it also offloaded work from the management team – and provided the much needed visibility for business units and executives – the internal department leadership became our core champions.

  3. Pick the most non-threatening tool you can find

    There are two sides to this point.

    First, when you select a tool to implement, go with something that is not intimidating. Obviously different groups are used to different levels of UI sophistication, so you might have more leeway with a group of developers or engineers (as an example) than you would with call center agents, but whatever it is, it needs to be very accessible. Again, an SaaS solution lends itself to this very, very nicely because it’s browser-based, which is essentially native to your users. A product with a strong brand behind it can also help as well. While that might seem a bit dumb to someone looking purely at functionality, don’t underestimate the ability of a reputable brand name to put people at ease when you are taking them out of their comfort zone.

    Second, part of what it takes for a tool to be ‘non-threatening’ is that it can’t be usurping the tool (a.k.a. “territory”) of someone else. The fastest way to bring organizational change to a halt is to bring an outside solution in, when someone else owns the current solution. If you can get them onboard as an evangelist, that’s great. But, if possible, start with a problem that does not currently have an established tool set designed to fix it, and you will encounter far less resistance from people who feel possessive and threatened by a new solution.

  4. Use a beta group

    This is another one that seems obvious, but I am constantly surprised to hear about attempted roll-outs that were enterprise-wide right out of the gate — and then I’m even more surprised to hear that people are shocked when it encounters obstacles and resistance. There is great value to having a subset of your user base dry-run the system. For starters, getting their feedback gives you the chance to iron out any kinks and avoid the nay-sayers knee-jerk negativity the first time they see something they think is “wrong.”

    But secondly, if the beta group is experiencing success with the tool, word will spread. Fast. And it won’t be long before you are having to fight off other volunteers to get in and be allowed to use the system. This is not fakeable, though, and a lukewarm beta group doesn’t build anticipation among the general population. Your beta users have to have genuine excitement at how much of an improvement your tool provides in order to help fuel the fires of those waiting in the wings.

  5. Leverage momentum to iterate

    Build on success. Once you’ve got your users appreciating how much help your tool has provided, and once your leaders are on-board with how much better visibility/metrics they have, it’s easy to start branching out. If you started with status reports, then roll in project charters or time sheets. Pick whatever the next ‘lowest hanging fruit’ is and see how you can dovetail it together. Once your users are in the habit of going to a single tool for one thing, it is increasingly easy to add more capabilities in over time, because they get increasingly used to and fluent in the system. Whereas if you try to do it all at once, a perfectly good solution can be wasted on resistance and culture shock.

    This is where our use of a straight forward, flexible and highly customizable tool like QuickBase came in handy in my change-resistant organization, because it was easy to evolve it to include more and more capability with just an hour or two of administration. What started off as simple status reporting for projects within the IT Department turned into an enterprise-wide array of department-specific and inter-departmental communications and coordination applications revolving around projects, marketing campaigns, design collateral, calendars, strategic communications programs, training schedules, and call center support functions in less than a year – because the first time someone saw a report out of the system, they immediately wanted to know what it was and how they could leverage it, too.

Sure, there are things you need to do – making sure you are clear on the security standards and how you go about ensuring that no one is putting data in there that isn’t appropriate for the system. But the reality is, that is a risk with employee laptops as well. If you start with small, non-sensitive data and a straight-forward, unobtrusive tool, it is much easier to engage your leadership teams to help evolve your internal processes over time, as the capabilities of your tool set – and the organizational behaviors that go with it – also evolve.

A common danger in all change management is trying to push too hard, too fast and not stopping to recognize that the people need to be the focus, not the tool. Starting with something small and innocuous is the easiest way to start getting everyone used to the idea of leveraging new solutions that they may not have previously been willing to consider. Remember that your goal is to change attitudes first, so that future solutions will even be seriously considered.

Small changes may not be sexy or exciting, but they are the most reliable path to success, so don’t dismiss them simply because you think they are indicative of ‘thinking too small.’ When it comes to driving change, the turtle is always a safer bet than the hare.

(Note: Contrary to how it may sound, I have no actual formal affiliation with Intuit/QuickBase.)