Welcome back! This is the third and final post in my series about using Jive Projects as a communication and collateral hub for project managers. In my first post, I discussed the value of using Jive for project management, the information architecture of projects, and the content types available. In post #2 I talked about laying out the Project landing page using Overview, Activity, or Place Pages.
In this post, I'll discuss running the Project; the processes I as a project manager use to rev the engine and bring the Project to life.
Following your project
By default, when you create a Group or Project within Jive, you 'follow' it in your Connections Stream. I find, however, that as the manager of a project, it's critical for me to be constantly tracking the conversations happening in the Project in order to understand the issues and blockers and be able to succinctly articulate the status of everybody's efforts to project stakeholders. For that reason, I follow all of my projects in my Inbox. I do not, however, have e-mail notifications turned on for everything in my Inbox; only for direct replies and mentions (this is just my personal preference to cut down on the amount of e-mail I get). Every morning when I open my Jive Inbox, I have a list of updates to catch up on and acknowledge via my Inbox, and for the ones that I need to address discretely, I open them into new tabs to address one-by-one once I've finished my morning review.
If the flood of notifications becomes too much to bear, or if one Project in particularly is noisier than others, I find it helpful to use Custom Streams. I can either create a stream for all of my Projects, or one stream dedicated for a particularly noisy project.
Discussions, questions, and answers
As the Project Manager, I ensure that all issues, inquiries, or actions are entered into the project as Discussions marked as Questions. One of the key benefits of using Jive instead of email is that everybody on the team works out loud. Our conversations are open for everybody on the team, and as a result everybody on the team benefits from the reduced friction and the transparency. That value is only realized, however, when our teammates buy into that philosophy by posting to Jive instead of writing an email. This can take some gentle 'reminding.' I will often use Jive Anywhere OWA cartridge to convert e-mails to discussions to encourage the sender to collaborate on Jive to find answers.
I also ensure that all Questions get answered. I use the Unanswered Questions widget to keep track of open items, and I place it front and center so that those hot topics are the first things anybody sees when they navigate to the Project. I can answer Questions myself if I have the expertise to do so, or I can @mention a subject matter expert to address the question for me. Replies that are Helpful or Correct should always be marked, and if the Discussion author doesn't do it, then I as the Project owner can do it as well. Once Questions are answered, they no longer appear in the Unanswered Questions widget-- Checking them off of our to-do list, but retaining the information for the record of the Project.
Publishing important documentation
A project isn't just about the conversations, but also the project collateral and documentation that is published. Jive Docs can be used to publish a project charter, project plan or WBS, tracker documents, requirements documentation, meeting notes, configuration guides, rosters, procedural lists -- or just about any other kind of documentation you can dream of. Anything that you would otherwise publish with a word processor and email out to people or post in a network drive, you can publish natively in Jive to give quick access of that information to everybody in your project.
Other people in the project will by default have editor rights on all of the documentation you publish, giving them the ability to contribute to the final product. Versioning helps users understand what's changed in a Doc over time, and revert to older versions as required. Structured Outcomes gives the team the power to designate content as 'Official,' increasing its search ranking, 'Outdated' to decrease its search ranking, as well as drive a variety of other actions.
The advantages of documenting this way goes back to our philosophy of working out loud. By making all of the information about the project easily accessible to all team members, on any desktop or mobile device of their choosing, people can collaborate more effectively because the barriers between people and information are broken down.
The Project Blog
My Project Blog is critical for me. As I mentioned before, the Blog is where I post regular status reports. Just like any Blog on the web, it needs regular updates to stay useful, fresh, and curate a following. I recommend posting at least one new Blog Post every week for the duration of the project.
One really great thing about using Blogs instead of just regular native Docs is that Blogs can be followed discretely without following the entire project. If I navigate to mycommunity.mycompany.com/groups/mygroup/blog I am presented with a page that contains the full text of all of the Blog Posts published in that Place. In the right-hand menu, I can 'Follow' just as I would any other Jive Place, but when I follow a Place's Blog, I only get updates when there are new Blog Posts. This is extremely valuable for project stakeholders, executives, or teams working tangentially to my project, who only want to follow the regular status reports without following the rest of the content in the project; it allows them to follow only what's important-- the updates that the project manager provides through Blog Posts.
With the introduction of News in the latest release of Jive Cloud, subscription streams can be setup to point at Blogs. News provides a vehicle for high-profile projects to be showcased for users across the organization via the project manager's blog posts.
Beyond the functional advantages, Blog Posts *feel* different from Documents. It's not just about recording details in a report-- it's about telling the story of your project as it unfolds.
Finishing your project
Two things signify to others that I've closed out a Project; publishing a retrospective, and archiving the project.
I typically conduct a retrospective meeting with all of the project stakeholders and personnel. This is a pretty common practice, but publishing the notes from that meeting gives others an opportunity to include their own feedback to be documented as outcomes in that same retrospective doc. I also link out to any key reports, discussions, or deliverables that were key, and I ensure that all open Questions are marked answered. The final leave-behind for the project is a single Doc that has a summary of everything that happened, what went right and lessons learned, and an index of all of the useful or important project collateral.
The last to-do for closing out my project is archiving it. By archiving a Project, the content in the Project goes into a 'read-only' state. It will still be indexed and discoverable by search, but users can no longer modify or reply to the content inside of that project.
I've really enjoyed walking through the use of Jive for Project Managers. I look forward to your feedback on this series, and I encourage everybody to share your thoughts, ideas and best practices here in the Jive Community. Thanks for reading!