1 person found this helpful
We did evaluate both - as well as a couple of others. I would suggest that you to a formal evaluation that is very specific in terms of your requirements from both a functional and technical perspective, including how you envision administering your community (i.e. centralized or delegated). I would also highly recommend that you include a usability test as part of your evaluation, as it is critical that you select the solution that your community members like using. Each product has its strengths and weaknesses, so it's important that you do an objective, side-by-side comparison and let the results speak for themselves.
Hi Claire, thanks for your reply, your point about administering your community was really interesting as I hadn't thought about that before.
We did a series of surveys and one to one interviews with various communities and asked them about the features they cared about the most, we were thinking of bringing in an external company to carry out usability tests with our users - do you think that's a good idea, would we get results we couldn't get ourselves?
We're running formal evaluations at the moment, but heavily weighted towards Connections, did you have to go through the same process or were you able to choose from 'best in breed'?
If your evaluation process is weighted in IBM's favor, then there's not much point in going through the motions of doing one. To Claire F.'s point, your users are already telling you what they like, and someone's not listening. If that's truly the case, I would recommend meeting with your manager or the sponsor of the project to make them aware of your preliminary findings and your concerns about the evaluation process. Given the costs, you don't want to implement something that's not going to be used. First impressions are everything - if people don't like what they see, they won't come back.
We did go through a formal process, but did not structure it so that it favored one vendor over the other, even though we are a big IBM shop. We sent out an RFP that had extensive functional and technical requirements. It's important that the larger business community own the functional requirements and the selection, not IT. From an IT perspective, we would have been comfortable going with either solution, but the team had an overall preference for Jive because of it's structure, usability and its configuration and administration capabilities.
As far as usability tests, if you haven't done this before then it would be a good idea to get outside help. They will be able to help you structure it in a way that ensures that it's an apples-to-apples comparison.
I second Claire Lash's suggestion.
That's exactly what we did. We had a lot of IBM technology in our company.
If you follow what Claire suggests, your evaluation and your users will tell you what's best. That worked for us. The story was so compelling - on the requirements, usability, TCO and innovation front that our evaluation made the case for us.
We evaluated several options - and for many reasons we were hoping for the integration we hoped Connections would bring. Obviously we are now a Jive SBS implementation (publicly known now). But we went into the process with a clear set of requirements so that it was not weighted in favor of any solution, but ultimately what we thought a system should do from a complete, holistic perspective.
Yes, usability was a major factor. I can't "second" Claire Lash's comments enough. She is right on the money. If the system isn't usable, complete, simple and easily navigated from various perspectives (as a user I want my view of all my content, as a group or community member I want a view of all that content, and as a member I want to customize my dashboard across the entire system and use my dashboard as my activity updates for the people and groups or communities I care about) then it simply will not take off virally.
I can tell you, we, too, had requirements around integrate with Sametime, Quickr, Lotus Notes, etc - because we were an IBM shop for many other applications. But at the end of the day, if we were honest about our core "enterprise 2.0 way of working requirements" - the integration with IBM products were less important.
In our evaluation process, not only did we send out an RFI, but we also installed a proof of concept. This allowed us to get at things like cost of ownership (skills required to install, admin and update) and usability (we had a team of users evaluate our finalists along requirements and usability factors).
Finally, when we decided the approach, we still opted to 'pilot' rather than move forward with a full enterprise contract. For us a pilot meant - limit duration (fix number of months) but do not limit the audience (meaning all 90K+ employees had access to the site if they wanted). Within 12 weeks we had tremendous viral adoption measured in user registrations, groups and weekly activities. This is the topic of several JiveWorld sessions I'm talking about (so I won't reveal too many more details here until those sessions are completed).
I came across this post, and would love to chat about being an IBM shop and your users choosing Jive. My client is in the RFP process, yet as a global project, some feel it may be a more seamless implementation to stick with an IBM solution since they are an IBM shop.
User experience is huge and the requirements are specific enough, it just appears to be going in na direction of what's comfortable as opposed to what's preferred.
Any feedback on the adoption experience since your decision to go with Jive?
I can't respond directly to the adoption experience, but check out Gartner's Magic Quadrant of Social Software in the Workplace doc from 2011. Gartner provides an unbiased view of whatever they are evaluating.
The doc states that IBM's interface is 'difficult to get used to', that 'integration is more difficult than expected' and that 'implementations can become complex' as you try to install all components' (p 18)
They also state that Jive's user interface is much better than SharePoint. Having used SharePoint and Jive, and many IBM products (mainly Lotus Notes but not Connections), Jive is highly intuitive. Mind you my background is in technology. A proper introduction / education course on Jive will have people doing all kinds of functions quickly and with confidence. SharePoint, even though it has a high adoption rate, has a clunky interface and very old school with many drill downs and many tree structured approaches. As Connections is an old Lotus product, I can imagine it has the same old school interface, which is comfortable, but complex.
You can create a few everyday tasks that a person would do in the course of a business day (ie "A day in the life") and have a focus group run the tasks. make sure the focus groups have people from a few business areas and of diverse ages so you get a 'level' playing field. Have the people score, on a scale, the key features you want to evaluate.
Connections is an old Lotus product
Just one? - no, about 4 or 5 products and it even included Jive at the start I'm pretty sure I've responded privately to Tammie on this subject (?). We work with both products so I can't go on record with a comparison. However Connections 4.0 is coming soon, lost count of how late it is, and it might have partially caught up with 4.5 or even 5.0, but hey look Jive is now on 6.0 so the bar is even higher
Connections 4 was released yesterday. I will take a look at it and report back.
1 person found this helpful
We had exactly the same situation, a lot of IBM products inhouse like Lotus Notes, and we saw that SBS is much better than Lotus Connections. We did a formal evaluation stressing our needs which are
- very intuitive, easy to use
- consistent approach to all functionality
- low cost
- low infrastructure footprint, low technical complexity (and with that short implementation time).
As mentioned in the other response you should including test users to get objective values for the first two points.
What we did as well, what proved to be very successful, was to run a pilot for 3 months with a limited number of users. We set the limit to 1'000 users to ensure we get some traffic. The goal was to prove, next to ease of use, the business value.
You mention you have a successful confluence community. How do you plan to include them? Will they co-exist or not?
Hi Wolfgang, thanks for your post, it was really helpful. I don't feel quite so alone in this anymore.
We certainly plan to bring the confluence users with us, for a couple of reasons really, firstly the cost and also as the platform is difficult to use and isn't really used as a wiki (more an expensive blogging platform for us), basically our users have no-where else to do this sort of thing so they use it with gritted teeth.
I think we share your goals, we're looking for something that will bring our people together, communities and expertise location is also big for us, as is the difference between showing what's a formal working community and what's more a social or adhoc community. We also need to incorporate other solutions such as microblogging.
Did you get a lot of push back from your IT divisions, were they pushing you to adopt connections? How did you get to the dual pilot situation?
thanks for your time,
What we did during the evaluation on the technical side was to ensure we had the "right" people looking into it. This means that the technical complexity of Connections - and the simplicity of Jive SBS - was confirmed by recoignised experts. This helped to avoid too many discussions and push back from IT colleagues.
To avoid a dual pilot we decided for a two step approach. First do the pilot with the preferred solution (SBS) and in case the technical assumptions would not prove do a second one with the alternative one. So we splitted the pilot in two phases, first a technical feasibility with very few people (less than 50) and afterwards for 3 months the next phase with ca. 1'000 business users.
The third element was cost. Due to the technical complexity total cost of ownership for 5 years was significantly higher for Connections than for SBS.
Will you attend JiveWorld? If so we can meet there to discuss more details.
It is also very important to determine the functional and technical requirements that you will have beyond the native functionality, when you will want to build functional solutions in the future -- maybe in the first year after deployment. To get the full business value from any of these platforms, you will need to build functional solutions on top of the platform, so you need to figure out which platform will best support those longer-term needs, beyond the native functionality of the platform.
Too often, organizations deploy a social platform, with only the native features, then feel like they are not getting the full value from the platform, which really comes when you implement functional solutions on top of the platform (e.g., functionality for the salesforce, or specifically for customer service, or specifically for a global PMO team).
So, make sure that you define your high-priority functional use cases, and include associated requirements in the RFP.
My team has instances running of Jive 5 (hosted an on-prem) and Jive 6, and we also have folks who have evaluated these platforms for clients in the past.
I am speaking in a couple of sessions at JiveWorld, and would be happy to discuss in person.