Tuesday-Friday May 11-14, 2004
Walt Disney World, Orlando,FL

Present:

Regional ADSIC presentations were given by representatives from ARAZPA, AZA, EAZA, FUNPZA and JAZA. 

EADISC had a mid-year meeting, with 19 representatives. Members were brought up to speed via various documents. They talked about timeline for the rollout of ZIMS. Discussions about institutions that have pledged funds towards ZIMS should maybe receive some sort of special privileges. Emphasized data cleanup campaign via regional list-serves. Acknowledged Ross Snipp’s direct input into the institutional data cleanup process, with improved transaction link rates being seen. Discussions are taking place between ZSL’s invertebrate staff and NAIB/Denver Zoo about merging the group management software developments and the TRACKS system. Also mentioned concerns about SMEs traveling to various workshops with very short notice. There are 47 SMEs and 28 ADISC members from the European region.

JAZA has about 160 institutions; 10-12 of these are ISIS members. Many are managed by regional governments that use simple databases rather than ISIS software. A Regional Coordinator has been appointed. Several SMEs have joined the vet and taxonomy list-serves., but they do not necessarily know the background of the ZIMS development. Some are experiencing language difficulties, and are not necessarily able to reply to emails. Kazu will give a 30-minute presentation about ZIMS and ISIS at the annual conference next week. JAZA zoos and aquariums are creating a regional web-based animal and administration database system, but development has been halted so it can be interfaced with the ZIMS system. Many institutions don’t want to join ISIS or a global database system, so they plan to use their system as an interface to ZIMS. All zoos in JAZA will participate.

Kevin gave a quick update on the situation in SEAZA – Kit Tan has taken a retirement package and is leaving Singapore Zoo. A SEAZA ADISC has been established, and has about 20 members, but no one seems to be really driving it. Bruce suggested that we include the SEAZA list-serve in general communications. Syed suggested that institutions which have programs running in South-East Asian institutions promote ZIMS when they can. Opportunities exist at the Taipei meetings to promote ZIMS – some presentations have already been scheduled. ARAZPA and SEAZA are having a joint conference in Melbourne in May 2005 – good opportunity for presentations/workshops.

ISIS has signed a contract with the successful vendor – CGI. 
The help desk infrastructure is being improved to provide 24 x 7 coverage.
VoIP phones have been tested in Europe and Australia and are working well, but only with high speed internet access.
RFPs for ZIMS deployment and hosting will be developed.
Global and regional data standards development processes have been developed.
A communication plan has been developed and will continue to evolve when a communications staff member is appointed at ISIS.
The Technical Working Group spent several months developing a Discovery document which contains a beginning draft of some of the functional and nonfunctional requirements based on existing systems.
Two workshops were held in the past six months – water quality in Lisbon and a vet workshop in San Diego.
A number of IADISC members were involved in the vendor selection process. IADISC members felt that this should be written in a format suitable for publication, and then forwarded to regional associations, with the recommendation that it be distributed more widely (eg via newsletters).

Project Timeline - the group developed a timeline of workshops, training requirements, and testing requirements.

Dates for five JAD sessions were decided. The fifth workshop may be a "mega JAD" session, and will be held at either Miami or Orlando. (Note: to avoid potential confusion, the dates shown below reflect the confirmed dates for the meetings – some changes were made to the dates after the IADIASC meeting).

18-22 July – Minneapolis – This will be a high level review of what we have now in the way of use cases and supporting documentation, so we can identify any missing and/or any duplicate detail. It will include an overview of CGI’s view of a complete detailed use case and associated documentation, and how they would like to see all of our use cases populated. It will cover core and vet components.

It would be very useful to have participants at the first JAD session who are able to come to additional JAD sessions. This will mean less start up time in each session. There will be 50/50 blend of vet/core content.

This session will include 26 people (20 SMEs, 2 IT experts and 4 core team/ZTWG people). Initial thoughts are that we would do high-level explanations and planning on the first day. On the second and third days we will split into two groups – core and vet, and then join together as one big group for the last day.

9-12 Aug – Sydney – More detail of the use cases. A number of these (maybe 20) will be selected and will likely be focused on a particular area (vet, core). Each session will be a blend of each domain, but this workshop will be 80% core and 20%vet content. This session may include some data issues such as rules and mapping data for the migration path. Also need to know how clean each component of the existing data is. It will also include a session on user interface design, and CGI could present several options for how the interface may look. There will be a presentation and demonstration of the latest prototype for feedback.

8 – 12 September – Toronto – Similar to previous session except 80% vet and 20% core. (Note: at the time of the IADISC meeting, this meeting was originally scheduled for 30 Aug – 2 Sep).

4-7 Oct – Bristol – Similar to previous session except will include administration, management, taxonomy, population management.

8-11 Nov -Florida – a more generalized session, including a wrap-up. We will have our quality assurance SMEs identified before this time.

Deliverables from the JAD sessions: completed templates of use cases, definitions of reports, data rules, data inclusion/exclusion, how to handle localization and translation, workflow processes etc.

It is our understanding that each of these JAD sessions will be business process-driven rather than domain-driven, so a mix of SMEs will be required at each session. There will be about 16 SMEs at each workshop, as well as two facilitators. Ideally, we should have eight core and eight vet SMEs and additionally, two IT people. Fifty percent of the people should be from the host region, and 40-50% should have been to at least one other meeting. The ISIS BSA should attend four or all of the JAD sessions.

We are now in a position to identify the SMEs that would be appropriate for each of the JAD sessions. IADISC will contact the regional ADISCs asking them to select the appropriate SMEs. Preference will be given to SMEs whose institutions will fund them, and SMEs who are able to attend at least two sessions.

Regional representatives to forward recommendations of SME participants at JAD sessions to Robert Erhardt by May 27.

Number of JAD sessions - will probably continue after 5 - as the product is being created, we will want to present results and get feedback:

Example- will want to have a final deployment plan workshop

Example- will want to have an architecture workshop- may not be a JAD or a focus group – may be a WebEx session or two.

The regional breakdown of participants for each of the workshops is described in this table.

We will also need to verify the data mapping from ARKS, MedARKS, SPARKS and Eggs. We might have a session where we get all of the data rules, including how clean the data is. Syed suggested that this should be done with the ISIS staff.

Things to be included in JAD workshops:

Completed templates of use cases
How we are filling in bad or missing data
Templates for reports - definitions
Present the data models
Data aggregation
Bad and missing data rules - what is needed what isn’t needed

Sessions on each individual component- how to handle translation, localization, user group management, security, deployment, workflow, super-service, (many sessions per workshop).

Workflow - will talk through an initial design, identified requirements (identified some through use cases), will build a tool to perform workflow and walk through this design and how it maps to different things. May do requirements, design review and final, or capture from the use cases.

Workshop participants will have review to do prior to and after the workshop. Deliverables to look at before the workshop and thereafter that will need to be reviewed by the participants.

December/January is usually registrar end of year cleanup, and so a busy time for registrars.

UAT testers ~ 20 people, multi-region, multi-domain

Syed to draft a position description for Quality Manager

Someone on the ZIMS Core Team (ZCT) with previous test plan development experience should take on the ZCT Quality Manager position

People who attend the JAD sessions should be involved in UAT. Should it be compulsory? Should there be some UA testers who’ve had no involvement in the design?

We discussed how organizations other than regional zoo association (AAZV, ZRA WDA etc.) could participate in IADISC. We decided that these organizations should be represented via their regional ADISCs, with or without representatives on IADISC. It was thought that we should be attempting to increase the level of participation at the ADISC level, rather than having representation of these organizations on IADISC. Each ADISC could have a vet representative and a registrar/core representative on IADISC.

After discussion with Nadine Lamberski from AAZV, it was decided that the most appropriate avenue for participation from AAZV is via AZA’s ADISC.

It was felt that some of the ADISCs might not be able to assign individuals to each of the regional facilitator positions. It should be the role of the ADISC Chairs to ensure that the various tasks get done by allocating single or multiple people on an as-needs basis.

Robert gave an outline of the Standards Management Workshop that was held in San Diego in April. This was well-attended with around 20 participants. Goals for the meeting were to understand the systems development life cycle, understanding why standards are important, how to document standards, and developing a communication plan.

We need to learn from this workshop and develop a set of guidelines than cane be used in future standards workshops.

Our standards process has a lot of requirements:

World-wide constituency

No current world-wide standards body

Must allow for broad review

"Straw models" (a model of a solution to a particular business problem that can be used to stimulate conversation and discussion to re-model a final solution) will play a critical role

Some standards may be important, but they are out of the scope of the current project

Will include business process standards (the way people actually use the system) as well as data standards.

Time and cost are both critical

The more we develop standards internally the easier it will be for the vendor to make a product that meets our needs.

Identify potential problem standards early, to allow SMEs to discuss these at length "go ugly early". We may need to develop an interim standards process so that design can continue while the concern is adjudicated.

Are professional associations the right forum for the decisions on standards? Professional associations could suggest one or two representatives to the regional ADISCs for inclusion on ADISC.

The group discussed whether there was a need for a communication coordinator at IADISC level. ISIS is about to hire a fulltime communications expert. Once this new person has worked with the Communication Manager to complete the communications plan, it was thought that it might make sense not to have the Communication Manager position at the core team level, but rather to have this person at the IADISC level.

It was agreed that most communication between CGI and ISIS should go through the Project Managers, but that various ISIS/ZIMS team members and CGI tem members should be able to communicate directly with each other if required. These communications should be copied to the Project Manager(s). CGI will produce a list of key contact points (core, vet etc.) and ISIS to provide CGI with a list of appropriate contacts on the various teams and committees.

When we receive deliverables from CGI, we will have deadlines and will have to perform specific tasks in a set timeframe. ISIS will contact the correct user group to perform these tasks. We will need fast communication between ISIS and IADISC down to ADISCs.

Listserves have been developed as a collaboration tool to enhance communication in a cost-effective and speedy way. Document-sharing and collaboration enhance the usefulness of the listserves. Moderators will document all discussions about each standard, and then document the proposed standard. Proposed standards will then be communicated to other stakeholders. Standards must be consistent. Workshops will be held for resolving contested standards.

There is concern that the core and vet listserves will have many threads that are only of interest to a subgroup. The suggestion is that the listserve moderator should use keywords in the subject heading that will key the reader to the topic. Keywords should be defined and used in all listserves to help with the volume of emails. Sue and Kevin to discus with the listserve moderators and develop keywords with the moderators’ listserve by May 27.

A draft ZIMS Change Control Process has been prepared by Becky Bryning from San Diego Zoo. Becky is the Change Control Manager at the Core Team level. We need a change control coordinator at the IADISC level – we need to write up a description and recruit a suitable person. This person will interface with the ISIS BSA.

Any community member or stakeholder can request a change. These requests go through the regional ADISCs for filtering. The requests for change are then forwarded to IADISC. If IADISC consider the request needs to be made, it is then forwarded to the ZIMS Core Team. The impact of this change will then be considered by the core team and the vendor.

The request for change, and the implications of the change will then be published so it can be considered by the entire community and then the priority for then change will be then set. Very high priority changes will be forwarded to the PSG for consideration (if there is a high cost to time implication), or be accepted for change (if there is no significant implications). Once the final decision and documentation has been reviewed, the decision will then be forwarded to the initiator of the request.

The Discovery Document will evolve into a requirements document after getting SME input during the JAD sessions and published in about six months. After that, any changes to the functionality will need to follow the change control process. This process has begun now. 

We need to ensure that when the Discovery Document is distributed more widely throughout the community that sufficient explanation of the process that lead to this document is carefully explained.

It was suggested that the draft Discovery Document be distributed to the participants in the first JAD session, for comment and modification. After that session, the document should then be more widely distributed to the broader community.

The ZIMS Core team has asked IADISC to look at the format of the draft ZIMS Data Standards document and review its content. The content of this document is in an Access database. The committee felt that apart from the few ISO standards, all other standards should be passed onto the listserv moderators to be discussed via the listserves and standards workshops and be evaluated via the agreed data standards process.

The ZIMS position descriptions were discussed. IADISC should work on filling the volunteer positions of coordinators (International level) and encouraging regional ADISCs to fill the facilitator positions.  

Regional ADISCS are to take charge of disseminating communications within their region. Each ADISC should send the name of the appropriate person in each region that is the main contact for communication to the ISIS Communication Liaison (Ivan Rea) and to Bruce (temporary communications coordinator). Regional ADISCs will then distribute communications amongst the appropriate regional listserves.

Each regional representative on IADISC should provide a list of existing regional listserves, their moderators, and the numbers of participants on each list to Bruce (temporary communications coordinator) so that a global picture of our audience can be determined.

Each ADISC to determine appropriate methods of distribution of ZIMS monthly updates

Kevin will take on the IADISC Quality Coordinator position. This leaves a vacancy for the ZIMS Core Team Quality Manager. Kevin to draft a position description for the Quality Manager and the Quality Coordinator, and Quality Facilitators. Kevin to develop profiles for UAT and pilot testers by June 15. Each region will have quality facilitators who will get right people together to do the testing.

Prototype testing will begin around early January 2005 after the first prototype has been delivered. We will have a sub-group of "power users" ready for testing. They should be focused on testing the major functions initially and the more cosmetic type of errors at a later stage. CGI recommended a 4-6 week time-frame for UAT of each prototype. It was recommended that we might hold a quality assurance workshop for training these power-users, and this may be as part of one of the data standard workshops. This would need to happen in the last quarter of 2004. Testing will take place at the users’ own sites, and will require broadband internet access, but will not require high-end computer infrastructure. It is very important that our testers can commit the time for testing. We need to have identified the power-users before the first JAD session so we can have some of them at this session.

It would be beneficial to the process if some of the prototype testers were bilingual.

During the development stages, prototype testing will be done predominantly by English-speaking testers, as the translations will not have been done at that time. All of the JAD sessions and other workshops will have been English, and since all of the testers should have been through the training sessions and other workshops, this will preclude non English-speaking people form participating in the prototype testing. Syed reported that 76% or ISIS members surveyed said that they are able to use the system in English, and it will be expensive to translate early prototypes into other languages.

CGI recommended that UAT testers should be people who have been closely associated with the project and have been testers of the earlier prototypes. They should participate in the use case process to familiarize themselves with this process. It would be ideal if they have undertaken some quality assurance training, and CGI could run a half-day training session and/or send them material about how to do the tests, how they should be thinking, what they should be looking for, how they should be reporting problems etc. The development of the user testing strategy is critical. Obviously the early prototypes will not be complete and CGI will outline what should be expected and tested with each of the prototypes. The ZIMS team will be writing the test scripts for UAT against the use cases.

The application will be deployed in four installation test sites at the end of the transition stage, and before the UAT period.

We need to be "selective" about who we have as UAT testers as we know at this stage we will run into problems with the prototypes.

UAT testers should have gone through at least one of the JAD sessions. The 90-day acceptance period will be after the UAT testing time, so it will be within our pilot testing period.

Pilot testers will be a larger group than the group who participated in the workshops.

At the end of the UAT, we have accepted the product, and this is the start of the 90-day warranty period and will include our pilot testing period. Before the UAT period, we will also be training the pilot testers.

Existing regional training processes could be utilized to assist with the development of training plans for ZIMS. This will include a UAT/pilot testers’ training plan. Training and deployment will likely take a considerable amount of time, and we need to set up an appropriate training needs assessment. We need to identifying various methods of deployment and training options at the regional level.

Train the trainer sessions ideally would be held in a face to face environment, but will also include recorded sessions and web-based sessions. Ideally this would happen about half-way through the development (approximately January 2005). We need to identify a core set of trainers who will help to develop the material, as well as the actual trainers. We will need trainers for each of the deployment methods. These trainers will likely be different group of people to the UAT testers. CGI will undertake the initial train the trainer sessions.

We will need prototype testers, UAT testers, administration trainers, deployment specialists. Language translation testers.

We need to work on the timeline – so that regions are aware of timeline and when users will need to be trained. Regions need then to draft their plans- targets based on which institutions to be deployed at which time.

Deployment of 620 institutions – estimated timeframe of 24 months following the completion of the product. The institutions providing financial support will be the first to get deployed. It is estimated that there might be two deployments per working day. In the first year, all of the big institutions will be deployed and the much smaller institutions, that have not contributed will come on in the second year. CGI will ask what the longest acceptable deployment time and over eight months have a plan which includes what is best for each region.

Deployment plan discussions should start in early 2005 – IADISC will need to be involved in the deployment planning to get regional input.  Discussed the  need for a deployment team now. Do we need a deployment coordinator? Syed needs to know from IADISC what the user needs for deployment will be and what an acceptable time period is. Should start thinking about deployment during the JAD session - what equipment, where, and what training. JAD products include a training and deployment sections.

ISIS is planning to circulate a ZIMS readiness survey to all institutions. This will help to provide CGI with the information they need to create their deployment plan.

We need to develop content and set aside time for training the trainers

CGI will have presentations and handouts

Can tape sessions for later use

Can do web-based and live training of trainers at the same time.

CGI will get together with the core trainers to develop the training materials. This starts when CGI starts production. Once materials developed then will have train the trainer workshops.

There will be 14 stand-alone meetings plus four opportunistic data standards workshops, held in the following regions:

North America – 7

Australasia – 2

Europe – 4

Other regions – 1

Four tentative workshops were scheduled. One will be held in Perth after the ARAZPA registrars’ workshop. Tentative dates are November 19-21 (Kevin to check with Perth Zoo and confirm with Sue). Additional workshops were suggested for Lisbon in March 2005, and Amsterdam in December, 2004. Frands and Duncan to confirm. Bruce also suggested a workshop in Seattle in January-March 2005. Kazu indicated that JAZA are keen to host one or two meetings, in Tokyo and Osaka.

The standards workshops will be held approximately monthly, starting January 2005, and will include approximately 20 people.

Sue introduced Mark Switzer (System Architect) and Victor Risinger (Project Manager) from CGI and impressed upon us how exciting this milestone is, to have signed up with a vendor. She then gave a brief outline of who and what IADISC is, and what we hope to achieve as representatives of the user community. The IADISC members introduced themselves. Robert gave a detailed overview of IADISC and its role in the ZIMS Project, and the history of how we have developed the various committees, teams, documentation and design processes that we have at this point. This presentation is available for the regions and various groups as a medium-level overview of the development process so far.

CGI detailed their reasons  why they think the data warehouse is so important to the discovery processes, ahead of the ZIMS transactional application. It will help to give them a better idea of the project, and the sorts of things we need from the system. Our needs of the data, and the way the data warehouse works will affect the overall database design, and so it is very important that the developers know this earlier rather than later.

CGI is using the document and the use case list to initially populate an inventory of use cases and reports, and producing an initial data model. They are using this to identify conflicts, and it is useful for them to understand the complexity of the system. They also believe we are missing some of the high level description. CGI will build a couple of documents that include the completed use cases, specify what gets done, what data is involved and what screens will be built. A second document will detail how the system works, how data will be synchronized etc.

CGI will produce a model Use Case Document (requirements document) of how a use case should look, and we will then get the appropriate details into the model, rather than continue to work on the Discovery Document. It will include references back to our documentation. This model will be available in two weeks’ time at the planning meeting.

The workflows we have are very useful, and we should continue to work on these.

CGI would like to determine the sorts of answers our community would like to obtain from the data warehouse, and therefore the sort of data that we need in the data warehouse. Syed suggested that we might have a separate workshop on the data warehouse including population managers, senior vets etc. who will have specific needs of the data warehouse. This will be useful to get people thinking about what they want from the data warehouse.

We need to go through the process of what the data warehouse will be - every time a question comes to mind throughout the JAD sessions it should be captured for the data warehouse.

Robert asked why the data warehouse is so important to the discovery process. Mark replied that the Conceptual Data Model (CDM) doesn’t tell you completely what the project is but frames what we are interested in and what we want to do. CGI will use the CDM to expand on the detail and the use cases will relate to the CDM. It is an underpinning that affects design. They will produce a Logical Data Model to create an Online Transaction Process OLTP (a transactional database vs. data warehouse) to build a transactional database. Knowing the needs of the data warehouse early will help create an appropriate OLTP.

This will start early on during development and will be based on use cases. Testing will include checking the prototypes against the appropriate use cases for functionality. The definition of individual use cases may expand at this point to include the required functionality.

Regional ADISCs to collect sample reports from non-ISIS applications as examples for CGI. These will be compiled along with the existing reports from ISIS software for CGI. These should be collected electronically before the first JAD session (before) July 19.

The group agreed that we will continue forward with the name ZIMS – Zoological Information Management System.

CGI will review the standards Access table and comment on its suitability, including details on any additional data and outcomes that we need to capture. Mark will do this by May 21.

After the initial planning session in two week’s time, CGI will be in a better position to inform us of the workshop schedule. We will try to always have at least six month’s worth of workshop dates scheduled at any one time.

CGI will set up a communication portal based on MS Share Point for document storage, document status, use case templates and status, work in progress, comments and feedback etc. This will be available to a somewhat limited audience. They may use the ISIS collaborative server, so that ISIS can take care of administrating user access. This will not have public access, and should not be used a communication tool. CGI would have administration rights to a partitioned area of the ISIS server.

Weekly updates will be scheduled. This may be face-to-face if they coincide with a previously scheduled meeting, or could be via WebEx. This will be discussed further at the initial planning session next week.

We should not invest in translation until after UAT, as the interface may continue to change during this period. The translation capabilities can be tested prior to this.

The next IADISC meeting will be held in Taipei October 26-27. Sue will check availability of venue. Kevin to ask Suzanne Gendron about people on the SEAZA ADISC who might be suitable to invite to this meeting. Kevin to send the contact details of the SEAZA President and forward them to Syed. We should check with CBSG about their registration list so we can also contact CBSG meeting participants about the meeting.