Why use Jive for project management?
Jive combines web-based documentation accessible from anywhere with powerful collaborative discussions. It provides a fantastic search tool that makes finding content and conversations incredibly simple. User profiles contain rich information about skills, experiences, and involvement. All of these powerful tools make Jive a project manager's best friend. Your team can create, share, collaborate, and take action on the project in a single, unified project hub.
At my last company, project collateral was posted in network folders, SharePoint sites, bounced back and forth in OneNote, or kept on people's hard drives, and things were emailed so wildly and blindly that you never really knew how current or accurate any of your documentation was.
On Jive, there is no question about what is the true version because there is only one place to look for the source of truth, and you can easily lookup the version history for any document. Being able to keep all project collateral in a single place where it can quickly and easily be created, modified and referenced, is a huge advantage. Having all of your project discussions and collateral open and accessible to the team, e-mail lists and 'reply alls' vanish because your team is connected to what's important.
Jive content is lightweight, easy to author and modify with advanced styling as needed, and is easier to digest than 8.5" x 11" formatted Word documents or verbose e-mail 'reply-all' threads. The content itself becomes collaborative, with the power to comment, reply, like, and mark with a structured outcome, and share. With the introduction of Responsive Mobile Web in the Jive Fall 2014 Cloud Release, the same rich documentation and discussion content you view on desktop can be seen on our most personal computers: our smartphones.
With all of these factors in play, Jive doesn't just connect people to content from anywhere; it connects them to each other. The alignment and clarity teams get by using Jive enables them to work better together.
Setting up your project
Checkout this description of Jive Projects from Jive Places Overview:
Projects can have unique page layouts just as Groups and Spaces can, but the similarities stop there. Projects are required to be nested within a Space or a Group, cannot have unique permissions associated with them, and have no management console. They inherit all permissions and visibility from whatever Space or Group they are attached to. These are best used for short, time-based projects, or helping increase focus of certain discussions; e.g. Marketing Ops has a specific Campaign with multiple types of documents and discussions and calendars. This allows a neater level of drill-down than keeping content and discussions at the space level.
Where should I create my project?
The simplest thing to do is to create a Jive Group as the parent Place for your Project. The Group should have a descriptive name that clearly identifies what the Project(s) within that Group are all about. The Group has it's own landing page and content separate from the content that will live in the child Project. I typically layout these Groups as a simple landing page for the various Projects that fall into that program, and I encourage people not to post Project-related content in the parent Group. The parent Group could serve an over-arching purpose, such as the master container for an entire program of projects, or for a particular team that work together executing projects; It's up to you to determine an information hierarchy that makes the most sense. Just remember that your project doesn't have it's owner permissions -- it inherits the permissioning of the parent Place.
The more accessible a Project is, the easier it is for me to solicit help cross-functionally, as well as keep my colleagues informed about the day-to-day happenings of the project and share the deliverables and lessons learned with others. That's why I generally advise to start with an open project, on only make the Project private or secret when it's necessary to do so.
If you're using a Space as the parent container for your Project, choose one that is accessible to all of the users that will need access to the project discussions and content (you may need to work with your Community Manager to determine where the best place to put your Project will be if you are in need of tight, system admin-controlled permissioning). If the Space you're using has already been provisioned and the layouts for that Space are already serving another specific purpose, consult with your Community Manager or the owner of that Space to determine how best your project could be displayed on that Space landing page.
Activity vs. Overview page
Beginning with the advent of Purposeful Places, Jive offers Place owners the choice of using lighter-weight Activity-driven landing pages for their Place pages, or using more elaborate widgetized Overview pages.
Two factors weigh in on whether I use and Activity page or an Overview page: 1) Team size, and 2) Content complexity.
I prefer to err on the side of Activity pages, since they're lighter and available on Responsive Mobile Web, and I only use an Overview page when I know that my project needs a more curated presentation. If I'm working with a team of a dozen or less, and I only need to provide some links to a few important docs, events, featured content, or trackers, then I use and Activity page. If I'm working with a larger team, or if I need to present lots of information on the landing page, Overview is more suited to the task.
Along with permissions, Projects also inherit the content types that are configured on the parent Place. Determining what kind of content types to have available in your Project is all about deciding what 'Work am I going to do within Jive?' Here's how I use the following content types within my projects:
Jive Docs are the repositories for some of my most important project collateral. These could be anything you would use a Doc for, from meeting notes to configuration guides or technical walkthroughs to project charters or resource trackers and everything else in between. They're collaborative, meaning by default anybody within the Project can author and update Docs, comment on Docs, and take Action or apply Structured Outcomes to Docs.
Discussions become the replacement for e-mail lists in team communication. They're used to discuss open issues, provide updates to the team, and solicit help from others.
By marking a Discussion as a Question, then the conversation transforms and it's purpose becomes finding a resolution. People who participate in the discussion can indicate when other people's replies are helpful towards achieving and answer, and once that answer has been posted to the discussion, either the Project owner or the person who started the discussion can mark their answer as Correct. Once marked, the Correct Answer is displayed immediately following the original Question. This means that somebody else navigating to this thread to learn about the issue doesn't have to dig through a miles-long reply-all jumble of e-mail land alphabet soup to try to piece together the context of what happened and what the answer is-- They can just look at the answer, right there in front of them.
Whether or not your Project has a Blog depends on two things: 1) Are Blogs enabled on the parent Place, and 2) Are Blogs enabled in the Project settings? Once both of those are true, you get a Blog container that displays all of your Project Blog posts at company.community.com/myprojecturl/blog.
I use Blog posts for regular status reports. Why use a Blog Post for a status report? Couldn't I just use a Doc? Well, yes, I could. But there is something much more organic about a 'Blog.' Docs store information, but Blogs tell stories. While a status report requires important information be passed along to the customer, it's also a chance to remind everybody that there are human beings on the other end of the phone, telling the story of their work.
There are functional advantages to using a Blog, too. In Jive, it's possible to follow just a Place's Blog without following the entire Place. This is extremely useful for stakeholders and executives who want to receive regular updates about projects, but don't necessarily need updates on every piece of project collateral. They can follow just the status report Blog in order to focus only on what matters to them: the story of the project unfolding.
Lots of teams use personal calendars for finding the time to collaborate. Adding Events in Jive shouldn't be thought of as a replacement for personal calendars, but a way to augment the personal calendar with key events that take on a visible identity within the context of a project. For example, when running software projects, I don't create an Event for every single meeting the team has, but I do create Events for key activities like a major due date or a production deployment. Creating the Event in Jive allows people to add it to their personal calendars, as well as participate in the collaborative discussion within the Project, where it is visible to everybody and on the forefront of everybody's minds, which can maintain alignment amongst team members.
Categories are useful in projects that may contain a lot of content. If you have discussions, open issues, technical documentation, meeting notes, slide decks, contracts, and many other sorts of content in the same Project, then it can be especially helpful for those trying to look up that content later to have an extra tool to look for that content. Categories, however, require a great deal of discipline. You cannot just create categories willy-nilly and expect everybody to always use them, or always categorize things correctly. Categories require ongoing curation by the Project Manager to ensure all of the content in a Project is organized properly.
Thanks for checking out this post! I'll be following up with a post that dives into using Activity and Overview pages to lay out your project.
Read the next post in this series: Jive for Project Managers II: Setting up the Project landing page