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

###