Skip to end of metadata
Go to start of metadata

Definition


Knowledge management (KM) comprises a range of strategies and practices used in an organization to identify, create, represent, distribute, and enable the understanding and adoption of insights and experiences. Such insights and experiences comprise knowledge (captured and distributed as artifacts), either embodied in individuals or embedded in organizations as processes, practices or policies. Knowledge management efforts typically include organizational objectives such as operational understanding/alignment, improved performance, competitive advantage, innovation, the sharing of lessons learned, integration and continuous improvement of the organization.

Stakeholders

BO: Kevin O'Brien
PO: Kevin O'Brien
TO: Kevin O'Brien
SM:
Others:

Background

UMOL traditionally kept organizational and operational information related to practices, processes and policy on various "shared drives," local desktops, as paper documents files in office file cabinets, emails, or even solely in the memory of key staff/individuals. In order to provide access, collaboration and distribution an toward Knowledge Management was developed and implemented.

Systems Supporting Knowledge Management

Service

Cost (Initial year)

Cost (yearly maintenance fees)Product

Notes

Knowledge Management

$2,000 Academic License

$1,000Atlassian Confluence

Our software licenses entitle you to perpetual use, and include 12 months of maintenance (updates/support) commencing from the date of purchase. Renewing maintenance is entirely optional.

Knowledge Management

$2,000 Academic License

$1,000Atlassian JIRA

Our software licenses entitle you to perpetual use, and include 12 months of maintenance (updates/support) commencing from the date of purchase. Renewing maintenance is entirely optional.

Hosting

$9,899.40

N/AContegix Hosting

per Year

Plugins for Knowledge Management Systems

$1,200

$300K15t

ScrollOffice

$1,000$500AtlassianTeam Calendars
$1,000$500StepstoneStepstone Zen Theming
Free$0LucidChartLucidChart
$50$25Artemis SoftwareMulti-Excerpt Plugin
Staffing    

TOTAL

$17,149.40

$3,325 

 

Utilization

UMassOnline currently utilizes multiple systems as a way to manage their knowledge and to track tasks related to the systems and services that they support.

Community

UMassOnline's community includes all UMass campuses (5), our Hosted partners (7), and a wide community of peers and others who are interested in online education. The visitors to our Knowledge Management resources account for about 50,000 visits each year.

Licensing

Licensing for Knowledge Management is current based on the system that the KM is provided for. Please see the Associated Systems and Services for the proper licensing documentation. 

Error rendering macro 'excerpt-include'

null

 

Support

General Technical Support for all Systems and Services can be found here.

Training

Much of the training needed can be found right on the sites themselves. A user has the ability to access the Knowledgebase within Confluence to learn how the system works. There are many tips, tricks and tutorials to get the users started using these systems as quickly as possible. 1 on 1 training is also available. Please contact the Confluence Administrator if you would like to schedule training.

Best Practices

UMassOnline's Tech Team is striving towards Agile Project Management (APM). While APM has been very effective at reducing the need for extensive, ponderous documentation, this methodology has not done away with the need for documentation (Knowledge Management) entirely. It has simply moved documentation from a foundational role to a supportive role. Jason Tee, of TheServerSide.com, in his article, Project Documentation and Agile Development offers seven ways a team can use documentation to enhance Agile methods rather than slowing things down. These tips both reinforce UMassOnline's goals in Knowledge Management and provide a rationale for such an approach.

Asociated Systems & Services


 

Current Status


 
 

4 Comments

  1. All,

    Tim sent me a JIRA ticket to get my input on basic information on data retention. I think this highlights some of the ambiguity we are feeling about when to use JIRA and when to use JIRA. My first thought is in this example, we would use Confluence (please do not think I am singling out Tim, I have had the same discussions with Kevin and Stef. But as I have had these one on ones with each of you, I thought it might be good to use this to start a group discussion).

    At this point it might be good to go back and look at why we (I) wanted to use Confluence. Many of the what, why, how, who questions about UMassOnline was locked up in individual's heads, or contested between folks who relied on their own experience, needs as a reference point. The goal was to create an authoritative reference that not only described UMassOnline, teh Tech Team and what we supported, but a platform for continuous improvement as new or enhanced services emerged. The approach was to simply say what we thought was true (anyone could start a page on any topic), so that all could see it, and then refine our understanding as more folks found, reviewed and contributed to the information describing a service or system. If no one added anything, the initial description must be right, if others did add information, it would help us understand other perspectives, needs, ideas, etc.

    JIRA was put in place as a reporting and task management tool for requesting, monitoring and resolving issues. JIRA requests are made to address a specific, currently operational activity that has two (maybe more) qualities, 1. Someone specifically (the assignee) is responsible for completing the task, and 2. there is a solution (e.g. service level/expectation, normal/expected functionality, etc.).

    I think the confusion comes down to two things: requests and communications. Why not put a request in JIRA to review a discussion/policy in Confluence? and Why not discuss an idea or potential solution to an issue in JIRA. Confluence is for discussions around the development of policies/practices. Perhaps a way to differentiate the two is: JIRA is for discussions about the application of those policies and practices. Using a the Recent ticket from Tim might provide an example.

    "Do you have anything to add to my questions for CF?"

    • What is your campus policy on how long students who are granted an In-progress/Incomplete grade given to complete their work once a course is over.
    • Are they given access to the online material to complete this work?
    • What is your campus policy on how much time a student has to challenge a grade?
    • Please describe your process for setting up new semesters. Specifically, do you copy content from the prior semester's course (e.g. Fall to Spring),
      a semester specific course (e.g. Spring to Spring), or some other method? Or do you reset your courses?
    • What mechanisms do you currently have in place for maintaining the data in your current Bb Institution?

    I think the motivation was to put a ticket in to me to make sure I was aware of the issue and get feedback before putting it up for public comment, perhaps anticipating a bit of controversy as each campus offered different expectations. But looking at the workflow, after reviewing the JIRA ticket, I might simply close it and say, "These look good" or I might begin a discussion asking for clarification about one of the issues, offering another with some discussions about its relevance, etc. However, all of that conversation, should be transparent so others outside of Tim and me can add to our knowledge, perspective, etc.

    So in this case, as well as the other examples I discussed with Stef and Kevin, I would just put it up in Confluence. Find a place you think the topic makes sense (with this it might be under Bb Vista, or under the "Archiving" section of the service catalog, etc.). Then share the page with folks you might think would (should) be interested and even add them as watchers. Then let the discussions begin.

    Indeed this discussion, taking place in Confluence about how/why to use Confluence is an example. I know there are gray areas where Confluence and JIRA bleed together, but I think it is healthy to constantly reflect on our practices to continuously inform and hopefully improve them.

    1. I see your general perspective, but to further add to the discussion, I opened that ticket as a "task" I have set for myself, or maybe even a reminder that it needs to be done. The only reason I assigned it to you was to get the feedback which was probably my error. Perhaps I should simply have added you as a watcher of the ticket so you could provide feedback if you chose to do so. 

      1. And, as the reporter of said ticket, shouldn't you just reassign pointing out your perspective so I could close it?

        1. I see your first point: assign myself a ticket so I do not forget to create the Confluence page. I too do this. On the second point, yeah, you're right. I should have included my comments, and reassigned to you to close. I'm learning too!