Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to use IBM Connections to manage a product build


Published on

Learn how to manage projects such as redesigns, product builds and more with this white paper on "How to use IBM Connections to manage a product build." One of Sherpa Software's resident IBM experts, Denny Russell, takes the reader through his process and helps them to understand how to "work smart and not hard" by using a social collaboration tool.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

How to use IBM Connections to manage a product build

  1. 1. How I used IBM Connections to manage a product build by Denny Russell, Sherpa Software 1.800.255.5155 | @sherpasoftware
  2. 2. How I used IBM Connections to manage a product build When I took over as product manager of a social business compliance tool, there were many things going on; keeping it all straight was tedious. As I was still completing duties pertaining to my old job, I found that both managing and driving the direction of a new platform required constant attention. I had to find a way to balance all my new tasks while not forgetting about any previous work. Too many emails, meetings and loose documents were being sent and received –maintaining it all was a daunting task. Why IBM Connections? For the most part, the group I was working with was already telecommuting (on an almost daily basis) and collaborating was a big key to our new project. Along with meeting face-to-face on occasion or holding phone conferences to catch up, we utilized the IBM Notes databases and email for many of these tasks. I looked at the current methods in place and decided to try a Social Enterprise tool, like IBM Connections, to organize our various tasks. After all, it was the first platform we were building our new solution for, so it was a no-brainer. The needs we had included: • • • • No data silos (in emails, loose files, individual Domino databases, etc.) Ability to get new team members up to speed (quick access to all information that led to decisions that were made) Files stored in a central location (no emailing of files back-and-forth) Web/mobile presence (computer, phone or tablet access) IBM Connections was already up and running in a test environment, thanks to an IBM Business Partner. Instead of building a new environment for production use, which would be a bigger cost in both time and money, we looked into using IBM Smart Cloud. Early evaluation proved it would fit all of our needs and would require little handson work to maintain. As we continue to implement Connections, IBM is adding new features and making it a more robust tool which only enhances our use. How we implemented IBM Connections The social platform was fairly easy to implement into our system. First, a community was created, and we started adding each key member of the team. As we started filling in content, we realized that we needed to segregate some of that data to make it easier to follow and read - we didn't want it to become a dumping ground of forum topics and files with no structure. We knew we would need some social champions to lead the cause and drive the adoption to make this a success. Then, we decided subcommunities would have with this goal. The following subcommunities helped organize this content the best way by keeping each key piece of information in its own location. • Customers & Business Partners: This was used to document each and every call we had with a potential customer of our product. It was also Sherpa Software • • Page 2
  3. 3. How I used IBM Connections to manage a product build used with Business Partners who were currently working with IBM Connections customers of their own. We wanted to know the what/why/how of IBM Connections in their environment; it would spark product ideas and provide real-world case studies of IBM Connections. • Competition: The goal was to understand who our competitors were, what they offered and where they were going. This became a critical subcommunity as we moved forward. • Market Direction & Trends: This was designed mostly with upper management in mind. We wanted for them to be able to understand the current Enterprise Social Network landscape and also to see how and why we were making specific decisions. Whitepapers, IDC reports, etc. were all stored in the Files application, and comments/further discussions detailed the topic at hand. • Marketing: This was designed to give marketing and sales all the ammunition they needed once the product is released. Ideas could be tossed around for advertisement content and videos. What’s more, activities could be assigned to make sure they had all they needed in a timely matter. Within each community, we followed some simple rules of how each Application would be used. • Forums were used to discuss ideas. Each topic should be in its own new post (with a link to a relevant topic that spurred the conversation). This would ensure that we didn’t hijack another topic, making that particular discussion unclear. We found these were used most often to prepare for a face-to-face meeting. Within the Forums community, topics were thought about and discussed prior to each meeting, and everyone was prepared to make decisions when it came time. • Wikis would be used for documentation. As our development team progressed, they would create wiki documents of studies and findings. XML Schemas, authentication models, and more were all documented and updated as needed. That way, if a new developer was added, they could easily find this information. • Files were uploaded and tagged so they would be easily found at a later time. The product roadmap was probably the most updated file in the system because it was built using a Mind map and shared with the team each time it was updated. • Ideation Blogs were a perfect way for us to throw new ideas out for discussion. Whether they were our own, or we got them from one of the subcommunities (above), we could easily get a handle on what people thought about it and how we could build it into a full feature. Ideas were voted up or down and decisions were made more efficiently. Challenges we faced Utilizing IBM Connections was a bit of a learning curve at times. People had to forget about “traditional” methods of communication and remember to post in their designated community in Connections. For example, a few emails were sent that should have been posted in the community – shortly thereafter, a Sherpa Software • • Page 3
  4. 4. How I used IBM Connections to manage a product build response much like “This would probably be best suited in this forum in the ‘product’ community” would be sent back, and the link was sent out to the original sender with the topic that was created for them. Sometimes, a responder might hijack another topic with an idea or question of their own. Again, the same type of response was given and a link to the new topic was included. This way, we were helping them understand where and how to use the system. It took some time, but people realized the benefits of collaborating in IBM Connections, and started using it for all product-related topics. Final Thoughts Overall, the team found IBM Connections to be the perfect blend of what we needed to keep the product build going. Because of the mobile app, we also found participation after hours via their phone or tablet. As they were catching up on the day’s happenings while watching TV, or waiting to pick their kids up after a practice, they were responding and adding insight. We were collaborating from all over the place, at all hours of the day. Work was happening at different times and places but all for the completion of a task. We were reinventing the way our work was being done, and that’s what I consider to be progress. Denny Russell is the product manager of social business solutions at Sherpa Software. Find him on Twitter @DennyRussell. Sherpa Software • • Page 4