April 2015
EDUCAUSE Coffee Shop-Life in the Wiki Wild West Notes
April 14, 2015
Presenters:
· Rick Lesniak, SUNY University of Buffalo
· Carlyn Chatfield, Rice University
Facilitators: Karen O’Hara and Cathy McVey, Miami University (Ohio)
Technical Hosts: Rurik Spence and Stan North Martin
Notes taken by: Kerri Testement, University of Georgia
Background on this Topic:
· Miami University is reviewing internal and external documentation
· Miami first did an internal audit where documents are stored
· Then, decided on a tool to maintain order of documents within their IT
· Recommendation was Confluence wiki; update was needed at the time
· One team was charged with developing standards and procedures on documentation
· Karen asked if other colleges are doing the same, thus this Coffee Shop today!
SUNY, University of Buffalo, Rick
· Has been using Confluence for more than 10 years; so long ago, it was almost like a grassroots adoption
· Today, we will talk about pitfalls to avoid: Total of 5 pitfalls/warnings
· Can’t identify the successes, but will talk about pitfalls
· Pitfall #1:
o Myth: Wikis are self-organizing that’s a collaboration tool and will reflect common organization culture
o Reality: Like any other web project, design your Confluence site like other major projects
§ Consider stakeholders’ functional needs
§ Design appropriate information architecture, such as:
· Projects and services
· IT organization hierarchy
§ Design common navigation system
· Enforce for ALL pages
· Still confusing to this day
· Almost like a content management system design
· Pitfall #2
o Myth: Wikis encourage people to do their own thing
§ Express their own style
§ Freely organize materials
o Reality: Organize style
§ Set up templates
§ Tags: Develop a tagging strategy that fits your architecture
· People search a lot; so, tags are important
· Pitfall #3
o Myth: Wiki content is authorative
· Content is the most current info
· Automatically updated
· Serves as an archive
o Reality: Editorial policy need in order to manage
· Assign an editor role
· Get a review schedule to keep up to date
· Develop a deprecation process
· Archive policy
o Build a policy of how to move older content to an archive
· Pitfall #4
o Myth: Wikis encourage open communication
o Can be referenced by any stakeholder
o Reflects organizational culture to stakeholders
o Reality: Authors must know their audiences
o Internal IT only?
o Can distributed IT access?
o Is there public access?
o All authors from day one need to know about openness
§ Define key terms (acronyms)
§ Position frames for reference
· Pitfall #5
o Myth: IT people will figure it out
· Like “power users”
· Process will be apparent
· No training needed
o Reality: No, you need to give people good training, how-to documents
· How-to videos
· You need a “guru” in your organization to give tips, guide training, adhere to rules
o The solution person or team for managing your wiki
Rice University, Carlyn
· Similar story, like Rick
· How to wrangle content among your teams
· Rice has 40 spaces in IT wiki
o Space for individual projects
o Outdated content still lives in our wiki
· IT DIY: IT Do it Yourself
o New Help Desk manager organized documents
o Shaped topic categories
· No template requirements on how to write documents
o Committee at the time wanted to encourage teams to participate, so no “police” monitoring content.
o Still trying to figure out how to manage
· Good how-to instructions
o Our Confluence site is not mobile friendly for viewing
· Old content with good information
o Need to review now that it’s been 10 years
· Internal OIT pages
o Good: Teams can see pages across teams, unless security concerns
o Most people can see, but can’t edit pages
o Good job starting this project, but not finishing
o IT Security Office does a good job embracing the wiki for sharing info with other teams
§ Incident Response via RTIR
§ Verbiage on how to handle incidents
§ Flow charts on how to handle incidents
o You can set up forms in Confluence
§ Forms submitted to their ticketing system
· Search function is very robust
o We’re not using tags/labels
o Initially had very elaborate labels/tags
§ Once set up, if plans change, you have to change your tags
§ Use as dashboard for critical systems
o New OIT All Staff Home page
§ New space for new organization
§ New logos, town hall meeting
§ Thinking about templates, ownership and labels
Questions from the Audience:
· Did you set your pages to auto expire or move to archive?
o No -Rick
o Auto expiration can be problem because that doesn’t mean the info is no longer valid-Rick
· Has anyone used accessibility standards (508 standards) to ensure people with disabilities can view?
o No
o We think about our external pages, but we haven’t for internal pages
o Need an accessibility policy at our university
· How did you get buy-in and encourage your staff to post documents?
o We were using other systems to collect documentation; each area already had some sort of practice to record their documentation—Rick
o One manager sent reminders to his staff every day to tell people to post-Rick
o Then, decided to make it a standard for the organization; then, sent message to entire organization to adopt-Rick
§ If you’re going to collaborate, pick one tool
§ So, you need some leadership initiative/support to pick one tool
· Anyone recently implement a new wiki with standards and templates?
o Nope.
· New Confluence, new projects would start in our new Confluence environment-Rick
· Why collect documentation in one place?
o We’re struggling with cross training, break out of silos; we’ve got four different repositories (Confluence, Google Docs, Google Sites, etc.)
§ How do we share standards?
§ We haven’t had time to devote to establishing standards for all organization-Stan
§ Not just our IT department, but other IT offices across campus (distributed IT) how we can share info
o People are using the tools they are comfortable with, but staff turnover affects documentation
§ We want a single system to live beyond particular individuals-Cathy
§ Maintain your institutional knowledge somewhere
§ We had a had of cross team collaborations, so one place helps-Rick
§ From a management standpoint, it needs to be shared with everyone; tied to your authentication system-Rick
§ We use Confluence for training, especially for the teams with high turnover
§ Challenge for organizations to commit time to organize Confluence.
§ With Google Docs or Sites, we have generic accounts not tied to one individual; but, that’s a lot to manage-Stan
§ Using Box for entire institution?
§ Google Docs: More casual, limited scope; Box used for temporary space
§ Stronger solution is Confluence because content still lives if the people who created the content leave the university.
o Watch out for collaborative storage systems
§ Box is not searchable if it’s not shared with you
§ Confluence shares with everyone
§ Box: Sharing externally; we could give external units access to share
o Does Confluence notify content creators when content becomes stagnant?
§ Don’t know-Rick
§ It would have taken resources to manage-Carlyn
§ >>>CARLYN TO PROVIDE MORE INFO<<<
§ Possibly as an add-on expense-Karen
o How did you select Confluence?
§ Three teams worked on internal documentation to review; already familiar with Confluence-Karen
§ Our Confluence is based off our organizational chart
§ But, we wanted to post info for new employees or people who are not familiar with those services
o Why put everything in one place?
§ Need to ensure you can access during a major incident (power outage)-Rick
· First system to bring back online is Confluence, since procedures for everything else is outlined there
· First priority system to be recovered
· Think about your disaster recovery plan
· In our state, copy is off site for disaster recovery
o But, must also be kept current
§ Are you comfortable putting secure documents in the cloud, like Google?
· Something to consider for Google
o What is the scope of IT at Rice and Buffalo?
§ We conducted an internal audit of all IT at Rice; about 4,000 undergrads
§ Buffalo: Our VP/CIO sits at the presidential level; 30+ units manage their IT
· Enterprise level: Responsible for most workstations on campus
· Distributed IT: Spread across colleges, units; we work well together
§ Rice developed a list with names and photos of all individuals in IT, so we know who everyone is in a meeting
End of Coffee Shop
###