Intranet Introspection: Starting on the Right Foot

At Digital Echidna, we have a long and successful history of working with enterprise-level clients, especially in the healthcare and educational markets, to develop dynamic and engaging Intranet solutions. These days an Intranet is more than just a document repository. The days of the enormous “Z Drive” with every document from the last 10 years are largely gone. And thank goodness for that.

Done correctly, an Intranet solution should improve your company's productivity, streamline your internal communications and add to your overall employee satisfaction. It should be a social hub for collaboration and employee engagement bridging gaps between roles, departments and geographic locations. But only if it's done correctly.

Over the next few weeks, I'll share some of the experiences that I've gained working with clients in planning, developing and deploying their mid to large-scale Intranet solutions. I'll cover topics from planning to execution, from content management to communication strategies for roll-out, and everything in between.

But let's start at the beginning -- the top mistakes companies make when choosing an Intranet solution and provider.

Dogma Shouldn't Drive Decisions

One of the biggest barriers to choosing the right Intranet solution comes from people being too focused on what they have, as opposed to what might be out there. I have a personal trainer friend that always tell me “If you do what you’ve always done, you’ll get what you’ve always had.” And that’s a solid statement across all aspects of life, including technology.

For example, if an organization is heavily invested in Microsoft solutions, which most are and that’s absolutely fine, there’s a feeling within these shops that all solutions should be built on Microsoft. After all, if they're a Microsoft shop then they clearly should create a Sharepoint solution, right?

Well, not really.

So many solutions out there integrate seamlessly with Microsoft products and platforms. Open-source, specifically Drupal, integrates seamlessly with a variety of Microsoft solutions that you may already be using. From Active Directory for user authentication or gathering employee information, to Sharepoint for document management, if there's an integration possible, Drupal has almost certainly done it.

By not letting your tech dogma limit your choices before the RFP or bid process, you will get a much better array of solutions to choose from.  

Budget Effectively

There’s one thing that I’ve seen across all different types of organizations: Budgets are shrinking and people are being asked to do more with less. So why spend the bulk of your budget on licensing fees? Don’t blow your budget on the cost of admission when that money should be allocated to meeting your organizational needs.

Open-source technology comes without those licensing fees, so you can work with your vendor to maximize your budget developing solutions and customizations that actually impact your business.

Share Your Budget

This one could be contentious for some people, but please hear me out: if you have a budget in mind, I strongly encourage you to share it.

Think of it this way, if you were in the market for a house, you wouldn’t go to a real estate agent and say, "I want a three-bedroom, two-bathroom home, but I'm not going to tell you what my budget is."

What would you expect to get back? You'd get a range of results that are all over the map, both figuratively and literally. You'd also waste a lot of time and resources eliminating the results which don’t fit into your budget. If you know what you want to spend, tell people, and evaluate the proposed solutions based on that. It will save everyone’s time -- the vendor’s and most importantly your bid evaluation committee's.

And once you've shared the budget, you've solved a pretty major obstacle of getting relevant bids for the project at hand - because ultimately price shouldn't be the defining factor in your solution choice.

Let me say that again. Price should not be the defining factor in your selection of vendor or technology.

You want to focus on

• Functionality: Does it do what you need it to do? Does it meet your organization's needs?
• Cost of supporting your solution: Are you required to pay licensing fees? What’s the total cost of ownership?
• Size of the development community: Is there a viable pool of developers that can help you with your future needs or expansion? Are you locked into one vendor? If so, do you have confidence that they'll have long-term capacity, can provide support, and will be reasonable in price and support?
• Company culture: This one may seem a bit odd, but it’s important. An Intranet project is a large undertaking and you’re going to be spending a lot of time with the vendor. Choose a vendor that is not only wise and experienced, but also a good cultural fit for your organization. You’re spending a lot of money. There’s no reason that it shouldn’t be an enjoyable experience.

Price is a factor, don't get me wrong. However you should know what you’re looking to spend ahead of time and share it, therefore making the price less of a differentiator and making the solution and the vendor the differentiators.

I can tell you unequivocally that if your staff are frustrated with their new Intranet, telling them that you saved $30,000 on it will not make their frustration go away. Quite the opposite.

Benefit from the Gift of Time

When you do go to bid, please make sure you give your vendors enough time to put together a quality response. After all, that gift of time is going to reap long-term benefits for you.

Why? Because the more time you give vendors to respond, the better your responses are going to be.

Guaranteed.

Any vendor that you're going to want to work with is going to be an expert in its field. And experts are busy. If they aren’t, well, they probably aren’t experts. So because your ideal vendor is a busy expert they are going to need time to thoroughly review your Request for Proposal (RFP), understand your requirements, and craft a specific and meaningful response.

And that takes time.

If you make the time frame too short, then you're either going to get people who aren't busy, or who rush through the process and possibly didn't give your requirements the attention they deserve. Generic, boilerplate responses aren’t helpful. You want to hear how a vendor is going to address your specific business needs with their solutions.

After all, in some cases you may be spending hundreds of thousands of dollars. You're going to want to make sure you don't rush the process and that you're evaluating the best of the best. In my experience, a minimum of two weeks from issue date to response will provide you with a good pool of options to review. Three to four weeks… even better.

Stakeholder Engagement

We're going to talk more about this in a subsequent post, but I want to make sure we touch on this here. Not knowing what your end-users need can lead you to selecting the wrong solution.

You may have a solid understanding of all your staff and its varied needs, but it never hurts to ask. Whether it's through focus groups, internal surveys, or one-on-one discussions, it's important to get the advice and suggestions from a variety of users. It's an investment in knowledge that pays off in a better-informed solution.

Next Up?

Next week, we're going to look at some of the key elements of starting a project, including the importance of ensuring that your time and resource budget is adequate and that you have the right people at the table at the right time.

And, as always, we'd love to hear your feedback!