Page tree
Skip to end of metadata
Go to start of metadata
Table of Contents

Purpose of this page

This page is meant to document the risks of the TSR project. This page will evolve with the project. In the "Probability" columns, please note the likelihood of a particular risk occurring, on a scale of 1-10; 1 being low. In the "Impact" columns, please note the impact that a particular risk would have were it to take place, on a scale of 1-10; 1 being low.

When identifying risks please assume the following:

  • that the TSR is fully community-sourced by students, staff, and faculty
  • immediate notifications will be sent to service providers given change to definitional data
    • when thinking through impact values, base this on the worse case scenario of 24 hours to respond to a notification
    • when thinking through probability and/or impact values, identify a baseline of hits your service page might get in 24 hours.
  • page versioning is in place and a service provider will have the ability to apply a rollback of former pages

Identified Project Risks

 

Risk

Category

Probability
(1-10)

Impact
(1-10)

Total

Mitigation
Options

1.

IST service provider teams become annoyed and angry because they are pushed beyond
capacity with an additional set of items/notifications to watch re: definitional data changes
on the TSR related to their services

Annoyance

10

5

50

1. Lock definitional data to service provider team
2. Allow temporary locking 5 of definitional data to service provider team
3. Add support staff 1

2.

IST service provider teams get pushed beyond capacity during migration of information
from existing locations to the TSR for 3 months

Capacity

10

10

100

1. Don't migrate data
2. Extend migration time (4-6 months)
3. Phase migration by service families
4. Have someone else migrate the data
5. Add support staff 1

3.

A customer or service provider team is unable find data while migrating information
from existing locations to the TSR

Can't find data

2

8

16

1. Add bi-directional links to/from migration points
2. Add contact info in case of questions
3. Disable sites once data has been migrated

4.

A customer gets inaccurate data related to a services for 24 hours b/c of inaccurate
entry by a contributor including pricing

Inaccurate data

2

8

16

1. Lock definitional data to service provider team
2. Allow temporary locking of definitional data to service provider team
3. Migrate everything before cutover; temporarily run parallel repositories

5.

A service provider team loses control of its service data for 24 hours b/c of a
malicious contributor

Malicious contributor

1

10

10

1. Lock definitional data to service provider team
2. Allow temporary locking of definitional data to service provider team

6.

Service provider team does not adopt the TSR and / or provide regular updates to
their pages

Low IST staff participation

8

10

80

1. Add update alarms
2. Get reprimanded by supervisor
3. Mark "as deprecated" unrevised/approved entries after 3 months
4. Remove unrevised/approved entries after 3 months
5. Add support staff 1

7.

The campus community does not adopt the TSR

See Campus Participation

 

 

 

1. Identify a functional and operational owner
2. Develop a communication and community organization plan
3. Identify and develop a community cheerleader

8

The service provider who gets feedback from the customer can not make
requested changes given resource constraints or the capacity of the service

Overwhelming feedback,
Service constraints

9

10

90

1. Disable feedback 2
2. Enable feedback to be turned on/off by service provider team
3. Provide a section to address common misconceptions about service capabilities

9.

Service providers teams lose morale based on negative reviews or ratings

Bad reviews

8

9

72

1. Disable opinions and ratings


Other/Inherited Risks

 

Risk

Categories

Probability
(1-10)

Impact
(1-10)

Total

Mitigation
Options

1.

The branding ability/capacity of IST-related services will be critically
reduced by shrinking the scope of the IST presence

 

 

 

 

 

2.

IST web presence, TSR, and Knowledge Base will continue to house a substantive amount
of stale data; this can cause the data to be untrustworthy

Capacity and User distrust

10

10

100

1. Develop a Technical documentation team with editorial and integration responsibilities 
2. Provide technical writing support 
3. Develop editorial workflows through documentation team 
4. Set up notification systems with consequences re: out-of-date data


Notes

  1. A consistent theme throughout this risk assessment process was that service teams were at or over workload capacity and that this effort would overstretch them further. Having additional support staff or a team that could monitor notifications, contribution review, writing changes, and/or rollbacks was noted as an extremely desirable. Support staff would need to be knowledgeable about the various services as well as have strong technical writing skills.
  2. Feedback in this context refers to requested enhancements and other things related to the service that is desired/requested by the end user. It is not the same as reviews or ratings.
  3. With our current editorial workflows and publishing process a substantive portion of data on our web sites is considered stale. Migrating the data a new location will not change these workflows or processes; it will simply transfer the risk to the TSR. If trustworthy data is a key benefit to visiting the TSR, addressing these workflows, processes, and staffing roles is critical.
  4. In the current proposal, formally submitted knowledge base articles could be supplemented with user-submitted articles; however, in a community sourced model, no editorial process can be enforced for user-submitted articles.
  5. A temporary lock indicates a functionality similar to that in Wikipedia where heavy contribution with strongly differing views are presented over the course of a short time period, i.e. Conflict in Egypt, definition of political parties during a campaign. During these seasons, an identified moderator has the ability to lock down a page for a period time. e.g. three days, until things settle down or invested parties can talk. It has been noted that some of the more time-consuming responses to address might come from well-intended campus experts from Micronet or other places. They may wish to contribute inaccurate definitional data stemming from a misconception about a service or product. Addressing this may require more time than just a version rollback.


Identified Risks related to Migration of the Knowledge Base

Overview:  The IST knowledge base, also known as "the KB" sits at:  kb.berkeley.edu.  It currently serves as a repository for information on about 30 services, including:  Calagenda; CalMail; and CalNet, among others.  The risks of moving the contents of the KB over to TSR can be broken down into three categories---(1) the risk of crowdsourcing the information, (2) the risks of moving the kb from where it is to any other site or service, and (3) the risks of moving it to the TSR, specifically.

 

Risk

Category

Probability
(1-10)

Impact
(1-10)

Total

Mitigation Options

1.

Given that most of the information on the KB is technical support information on IST-owned
services, the single greatest risk is that erroneous or misleading information finds its way
onto what appears to be the authoritative source for such information, our TSR site, for an
extended time. 

Crowd-sourcing

9

2

18

Establish a documentation team to manage KB section.

2.

An editing/review team won't be in place to review, edit, and manage the user-submitted 4 articles

Crowd-sourcing

8

9

72

1. Distinguish between formal KB articles and user-submitted articles
2. Require user-submitted articles to follow and editorial review process (see inherited risks #2)

3.

Users try to link to non-existant KB articles

General Migration

10

2

20

1. Bi-directional links in the KB and TSR indicating where to find data

4.

Frustration in navigating information structure that is different from what was
expected.

General Migration

9

1

9

1. Identify key structural components of the KB and incorporate them into TSR

5.

Frustration and difficulty in locating information in unexpected format and location.

General Migration

9

2

18

1. Bi-directional links in the KB and TSR indicating where to find data
2. Identify key structural components of the KB and incorporate them into TSR

6.

Potential disconnect and loss of the editors who were previously maintaining their content.

General Migration

9

8

72

1. Maintain current process and request editors to publish in new venue
2. Maintain current process and have KB team / other staff migrate from KB to TSR

7.

Loss of control over a system we manage and know how to run.

General Migration

9

2

18

 

8.

Frustration and difficulty for authors and admins in having to learn and gain access to a
new system.

 

9

2

18

 

9.

An additional risk of making plans to move the KB right now is that there is a significant
likelihood that the contents of the KB will be absorbed into the Service Now system after
the test pilot phase of Service Now, which is just beginning, ends.  This would obviate, or
at least render as an unneeded duplicate, a TSR copy of the information.

General Migration

8

8

64

1. Mundrane is sponsor of both projects 
2. Assess with sponsor how these two projects overlap

10.

Insufficient KB staff for migration support.

General Migration

9

8

72

 

11.

The data taxonomy and the architecture of TSR is currently unknown so assessing
the risks of moving to an unknown service will be, of course, unknown.

Migration to TSR

 

 

 

 

12.

Insofar as we understand that the TSR will potentially resemble something along the lines of
Wikipedia, which is in an encyclopedia format, and the current KB is  in a document-under-a-topic
format, converting from one format to another would potentially involve a huge amount of work
for the writers and content maintainers.

Migration to TSR

9

8

72

Find the best approximate mapping between the relevant categories and fields in the KB and the TSR.

13.

Potential loss of documents due to difficulties with moving data.

Migration to TSR

6

6

36

Ascribe to professional data transfer protocols.

14.

Potential loss of documents due to eliminating bad data.

Migration to TSR

9

5

45

Do not attempt to eliminate bad data until all data good and bad has been transferred.

15.

Possible KB service interruption by a) locking into TSR option and b) waiting to Phase 3 to move KB to TSR.

Migration to TSR

4

10

40

Move migration of KB to phase 1.

Campus Participation

When addressing the risk of campus adoption, we chose to identify the likelihood of campus participation in various categories. They are listed below.

Participation

Probability
(1-10)

Impact
(1-10)

Total

Overall

5

5

25

Finding data

9

9

81

Providing opinions and feedback

10

10

100

Adding to existing contributions

8

4

32

Adding new services

2

1

2