Zoological Information Management System (ZIMS) Project mission and charter

mission The mission of the ZIMS project is to develop, deploy and maintain a comprehensive information system that supports a wide range of animal management and conservation activities associated with zoological institutions (aquariums and zoos) and the zoological community.

introduction The Zoological Information Management System (ZIMS) refers to an integrated information system that includes the application modules, a global information database and technical infrastructure that together support the project mission and charter. 

The "ZIMS Project" refers to the project governed by the International Animal Data Information Systems Committee (IADISC) to develop, deploy and maintain ZIMS.

The scope of the project has evolved from the initial vision of creating a central repository or database of zoological data to a system that also supports the information needs of many animal care and management activities of zoological institutions.

The primary goal of this document is to provide IADISC with an objective basis for planning, budgeting, and managing the ZIMS project. It assists in establishing the initial expectations of the project stakeholders regarding system scope and functionality, budget, timing and participant commitment. It also forms the basis for moving forward from this initial planning phase into the developmental phases (analysis, design and construction) and then on to the implementation and support phases of the ZIMS.

A secondary goal is to provide IADISC with the foundation to abstract and create related documents as appropriate for specialized audiences and/or general circulation.

The charter contains the following sections:

• Project goals and objectives
• Project stakeholders
• Project scope
• Project technical architecture
• Project risk assessment
• Project assumptions
• Project constraints
• Project open issues

project goals and objectives A project goal is a qualitative statement of direction regarding a benefit to a stakeholder as a result of developing the system. One of the criteria in evaluating the success of a project is the degree to which the project achieves its goals and objectives. Other success criteria include the degree to which a project meets it scope (business requirements), development schedule, and development budget.

The goals of the ZIMS include:

• Establish standards for zoological data
• Identify best practices for zoological information management and associated work processes
• Develop an integrated, comprehensive information system to support zoological work processes
• Develop a centralized data repository to support and facilitate animal and collection management, scientific research and the sharing of information among zoological institutions
• Design a scalable solution to accommodate a wide range of users and work processes
• Design an extensible system architecture that will accommodate changes and additions to user requirements over time
• Create a support infrastructure to ensure the on-going support, including help desk and installation, of the ZIMS
• Create a management infrastructure to manage the data and provide for future development priorities of the ZIMS
• Assist participating institutions in successfully implementing and maintaining the ZIMS

A project objective is a quantitatively measurable indicator of progress related to a goal. There are two categories of objectives with respect to the ZIMS Project: reduction oriented objectives and improvement oriented objectives.

Reduction-oriented objectives include:

• Reduce lost, missing, erroneous and incomplete data. For example, information regarding animal identity
• Reduce redundant data entry (e.g. Studbooks – keepers vs. registrars)
• Reduce the time required for system modifications – new business requirements and changes to existing requirements and functionality
• Reduce the time required to produce information from the system
• Reduce the need to manually develop reports, spreadsheets, etc.

Improvement-oriented objectives include:

• Increase the scope of data collected across zoological institutions (e.g. expanded taxonomic coverage)
• Improve the integration of data across disciplines (e.g. contraception/veterinary, husbandry, environmental quality indicators)
• Improve the ability of users to access the data in the system
• Improve the quality (accuracy and integrity) of the data maintained in the system. Accuracy means that the data captured from user input, system interfaces or external data feeds is properly validated. Integrity means that subsequent calculations and other data manipulation are performed correctly and consistently
• Improve security to meet local as well a global needs
• Improve the level of system satisfaction among users
• Improve the ability to extract data to make better informed decisions

One of the initial activities of IADISC in the business system analysis phase of the project will be to select the set of objectives from the above list that will be used to evaluate the success of the project. For each of the objectives selected, IADISC should define a set of measurements to serve as indicators regarding progress in achieving the objective. IADISC will also need to establish the current or "baseline" value for each of the measurements. The baseline values are necessary to provide the basis for determining the degree to which the project achieved its stated objectives.

project stakeholders A stakeholder in this project is any person or constituency that is affected by the ZIMS and/or the outcome of the project to a sufficient degree that their needs and expectations relative to the project have a bearing on the planning and execution of the project. Also see the "open issue" section of this document for additional comments regarding project stakeholders.

ZIMS stakeholders include:

Tactical stakeholders. A tactical stakeholder is a person or constituency for which the ZIMS will have a direct and material effect on their day-to-day activities. Tactical stakeholders are typically hands-on system users that utilize the system frequently to perform their day-to-day work related activities. The primary tactical stakeholders include operational and analytical personnel associated with zoological institutions.

Operational stakeholders include directors, animal collection managers, veterinarians, registrars, husbandry staff, keepers and others that manage or interact with the animals on an on-going basis. Analytical stakeholders include the population managers, collection managers, exhibit designers, researchers, zoo directors and other knowledge workers that use the information in the database to support research, planning and various analytical and decision making activities.

Operational stakeholders need and expect the system to respond rapidly to data entry and query transactions. System response time cannot impede their ability to perform their work activities. Analytical stakeholders typically extract large data sets from the system on a periodic basis to be loaded into tools such as Excel for further analysis. Therefore, analytical users typically expect ad-hoc access to a wide range of historical data. While response time is important to analytical users as well, it is not as critical as it is to operational users.

Strategic stakeholders. A strategic stakeholder is a person or constituency for which the ZIMS and/or the outcome of the project has a material long-term effect from a managerial, administrative, policy or political perspective. The primary strategic stakeholders in this project are IADISC and participating zoological institutions and associations. 

Strategic stakeholders include ISIS, conservation organizations such as IUCN, CBSG and governmental agencies such as USDA and US Fish and Wildlife Service. Strategic stakeholders also include other associations such as WAZA. While individuals and member institutions may be seen as Tactical Stakeholders, the associations themselves are viewed as strategic stakeholders.

Indirect stakeholders. An indirect stakeholder is a person or constituency for which the outcome of the project does not necessarily have a material or direct affect, but whose opinions and perceptions are worthy of consideration in developing and promoting a project mission and charter. This could include regional association benefactors, zoo and aquarium benefactors, zoo and aquarium members, conservation and academic organizations and educators.

project scope The scope of the ZIMS project includes the development and deployment of a comprehensive information system that supports a wide range of animal management and conservation activities associated with zoological institutions and the zoological community. The scope of the ZIMS project also includes the creation of data standards, standardization of data oriented business rules and the identification of process best practices across the zoological community.

The main architectural components of ZIMS include application modules to provide:

Transaction processing capability to support zoological related functions and processes.

An operational database to capture and maintain transactional data.

An integrated central data repository (data warehouse) to capture information across zoological institutions to support analysis and information delivery.

A number of zoological functions and functions were identified and aggregated into functional modules during the planning phase of the project. A module comprises a set of system functions/business requirements that have a high degree of data and process affinity (interaction) among the functions. The notion of a "module" will enable ZIMS to be analyzed, designed and constructed in manageable logical units of work.

The planning project resulted in the identification of five modules that are considered by IADISC as candidates for the subsequent analysis, design and development phases of the project. These modules include: inventory/core, veterinary/medical, husbandry, management and global data warehouse.

The scope of each module is based on the data and process characteristics that ZIMS will be designed to support. The data characteristics associated with ZIMS are depicted in the ZIMS conceptual data model. The processes characteristics associated with ZIMS are summarized as bullet-points in the descriptions below of the various modules.

The ZIMS conceptual data model provides a baseline view of the scope of ZIMS from a data perspective. The conceptual data model developed during the planning phase resulted in approximately 350 entity types. The conceptual data model integrates the data characteristics across the ZIMS modules to ensure the compatibility and extensibility of each module.

The conceptual data model was developed as a result of four facilitated sessions that involved over fifty-five subject matter experts from a diverse set of zoos and aquariums. Based on the depth and complexity of the conceptual data model resulting from the four facilitated sessions, a reasonable expectation is that the conceptual model could evolve into 800 -1200 normalized entity types during the business systems analysis phase of the project.

Listed below is a summary of the functional characteristics of each module:

core module The focus of the core module is to accurately and efficiently manage an institution’s inventory of animals and enclosures. The core module will essentially maintain and manage information regarding the animals associated with an institution such as location, quantity and movement. It will also maintain animal demographic information such as weight, gender and taxonomy. The functionality of the core module is critical to many diverse users of thZIMS and will serve as the foundation for the other ZIMS modules.

The key data related characteristics associated with the core module include:

• Inventory of individual animals and group animals
• Animal demographics such as age, gender, life stage, etc.
• Weights and measurements
• Animal identifiers like tags, transponders and visual identifiers
• Management status of an animal that may include quarantine, medical, surplus, reproduction, etc.
• Animal relationships such as parental and family lineage, reproductive opportunities
• Taxonomic determination for an animal and maintenance including changes in accepted taxonomy
• Locations and enclosures in which the animals live/reside or are maintained
• Organizational and personnel data that are used in conjunction with the system
• Transactions associated with the purchase, transfer, trade or loan of an animal
• Media items that represent still images or video that is used for visual identification of an animal or enclosure

The key process related characteristics associated with the core module include:

• Animal inventory that will track animals including pre-birth/hatch (e.g., eggs) as appropriate on a periodic basis and support audits that can adjust inventory due to birth/death, acquisition/disposition or accession/de-accession
• Enclosure management that will support the configuration and maintenance of enclosures that house animals for exhibit, medical care, training, quarantine, reproduction, etc. and the systems of which they may be a part
• Animal movements that will maintain the internal transfers of animals (i.e., enclosure to enclosure) and the external transfer of animals (i.e., institution to institution)
• Reproduction management that will support documenting changes and results in reproductive conditions or competency including fertility, contraception, sterilization, courtship and copulation

veterinary/medical module The focus of the veterinary/medical module is to provide the functionality to support the management of the healthcare of an animal. This module will maintain medical records regarding treatments, tests and diagnoses of an animal’s physical condition. It will also help manage healthcare cases and clinical notes.

The key data related characteristics associated with the veterinary/medical module include:

• Transactions associated with testing requirements for pre/post shipment
• Healthcare transactions for the areas of microbiology, parasitology, treatments, immobilization, quarantine, pathology, necropsy, and surgery including healthcare journals and medical cases
• Observation actions for animal physiology, morphology and injuries
• Biomaterials tracking that includes the request for and disposition of biomaterials

The key processes related characteristics of the veterinary/medical module include:

• Case management that will track the initiation and management of the veterinary care of an animal that includes actions taken and diagnoses/conclusions reached
• Routine medical procedures that will support preventive healthcare like vaccination, routine physical exams, lab work, etc.
• Non-routine procedures that will support corrective healthcare involving the diagnosis and treatment of animals through exams, diagnostic tests, delivery of treatments, etc.
• Quarantine that will support isolating an animal from others following distinct protocols and specifying environmental conditions and sign-off for an animal’s release from quarantine
• Sample banking that will assist in the usage, storage and disposition of animal and enclosure samples (e.g., blood, urine, gamete, venom, etc.)

husbandry module The focus of the husbandry module is to provide the functionality to support the general daily care of an animal. This module will maintain standards-based information an animal’s feeding, enrichment, training, reproduction, contraception, etc. It will also help manage training and enrichment plans and diets.

The key data characteristics associated with the husbandry module include:

• Training and enrichment plans
• Diets and feeding
• Animal group management
• Management actions including treatment, quarantine, contraception, enrichment, incubation, training, feeding and maintenance of enclosures
• Observation actions including feeding results, injury, reproduction, behavior and morphology

The key processes characteristics associated with the husbandry module include:

• Routine husbandry procedures that will support the regular observations and care of animals including information on an animal’s physical, behavioral and medical well being that will vary through an animals progressing life stages
• Diet and feeding procedures that will support the routine preparation and delivery of food for nutrition/sustenance and training/enrichment including the formulation of diet and the monitoring of its effectiveness
• Husbandry plan management that will track the development, review, approval and actual success of training and enrichment plans
• Behavior management that will help standardize and measure the result of an animal’s behavior in common situations (e.g., introduction into a new group)

management module The focus of the management module is to provide the functionality to support the management of specific components of the support infrastructure of zoological institutions. This module will maintain pertinent information on staff and related scheduling, collection plans and environmental monitoring parameters. It will also help manage necessary animal-related permits.

The key data characteristics associated with the management module include:

• Collection plans
• Business transactions
• Institutional staff including skills, related certifications and section assignments
• Environmental monitoring
• Permits

The key processes characteristics associated with the management module include:

• Population management that will track the development, review, approval and key elements of population management plans (e.g., ICP, RCP, SSP, PMP, etc.)
• Environmental monitoring that will track specified environmental parameters and compare to threshold values based on an assigned rating
• Regulatory compliance that will support maintaining appropriate institution, taxonomy or animal permits that are required by regulatory organizations to maintain and/or ship animals or biomaterials
• Research request management that will help track the proposal, review, approval and fulfillment of requests for biomaterials
• Staffing assignments that will support the scheduling of management actions and observations for animals and enclosures by role/section and the completion by specific institution personnel

global data warehouse module A data warehouse is a database that aggregates detailed transaction data, typically from disparate data sources, into a single data structure that is designed to facilitate access to the data by non-technical end-users. The Global Data Warehouse module will integrate detailed transaction data across the ZIMS user base into a central database that will be designed to provide the users of ZIMS with access to information for analysis and ad-hoc reporting.

The goal of the Global Data Warehouse is to provide ZIMS users with accurate and consistent information for research, population management, animal history analysis, etc. to facilitate the development of collection plans, training plans, diets, enclosure configurations, research, etc.

functions/activities outside of scope The ZIMS is an integrated system designed to support a wide range of zoological activities. However, a number of activities typically associated with zoological institutions are classified by IADISC as outside the scope of the ZIMS. The functionality associated with out-of-scope activities will not be included in the subsequent analysis, design and development phases of the ZIMS project.

The activities that are outside the scope currently include, but are not limited to:

• Facilities maintenance and management of the actual physical plant and equipment (e.g., HVAC, elevators, building core and shell, etc.)
• Financial accounting systems including general ledger, accounts payable, accounts receivable, payroll, human resources, etc.
• Inventory control and management of animal food commissary and pharmacy
• Animal show development, execution and analysis
• Retail merchandizing of gift shop, vending, food services, etc.
• Ticketing
• Membership accounting/management
• Guest programs, education programs

scope summary The level of detail associated with the ZIMS functionality summarized in the various modules above and further supported by the conceptual data model, was targeted for the purpose of preliminary project planning, scoping and budgeting.

The functional characteristics associated with each module will evolve into the functional requirements and system specifications during the Business Systems Analysis (BSA) phase. The BSA phase will also include defining data standards, defining consistent processes across different functional areas of zoological institutions, and extending the level of consensus already achieved in the planning phase.

project technical architecture The development and deployment of an integrated system such as ZIMS requires the design team to make numerous decisions regarding the types of system software (operating systems, middle ware, etc.), development and deployment software tools, infrastructure technology (servers, connectivity, etc.), deployment options, etc. to utilize in developing and deploying the system. Collectively, these decisions represent the system technical architecture.

The ZIMS technical architecture will be developed in conjunction with a rigorous business systems analysis initiative. This section of the project mission document describes several key components of the ZIMS technical architecture based on the preliminary findings of the project team at this early stage of the project life cycle. The purpose of this preliminary discussion is to provide ADISC with an early look at potential deployment alternatives in order to facilitate early discussion among ADISC members and to provide the project team with the basis for a preliminary project estimate.

One of the goals of ZIMS is to provide a wide range of project stakeholders with the ability to utilize ZIMS. As part of the planning project the AZA ADISC steering committee, in conjunction with the ADISC members, identified key characteristics that distinguish zoological intuitions from an information technology perspective.

After analyzing these characteristics across many institutions, the ADISC steering committee identified four basic profiles. Each profile represents a type zoological institution from an information technology perspective. This means that the institution already has, or could attain, the characteristics of the profile. The profiles overlap and an institution could have characteristics of several profiles.

The four profiles are listed below in ascending order by level of information technology sophistication.

zoological institution profile 1 

current system environment	Non-networked stand alone PC running ARKS and possibly Medarks. Basic static Web site or no Web site
IT staff	None. IT support provided by a zoological professional such as a curator, registrar or veterinarian. ISIS technical support provided as needed via phone. Webs ite maintained by outside party
Internet access	Typically a dial-up connection as needed via a 28-56 Kbps modem. However some institutions may have, or have access to, a full-time broadband connection such as a DSL line, cable model or T1 line
profile base	Approximately 25% of zoological institutions

zoological institution profile 2 

current system environment	Non-networked PC(s) or small local area network (LAN) running ARKS and possibly Medarks. Static public Web site
IT staff	Small PC support oriented IT department. IT department provides infrastructure support (PCs, LAN, etc.), but not technical (application maintenance) support, for the application software. Zoological professionals such as registrars, curators, and veterinarians manage the data and application software. Website maintained by outside party. ISIS technical support provided as needed via phone
Internet access	Typically a dial-up connection as needed via a 28-56 Kbps modem. However some institutions may have, or have access to, a full-time broadband connection such as a DSL line, cable modem or T1 line
profile base	Approximately 40% of zoological institutions

zoological institution profile 3 

current system environment	Server based local area network or multiple networks running ARKS, possibly Medarks and possibly some informal in-house applications. Public website with simple interactivity
IT staff	Small application oriented IT department. IT department provides infrastructure support (PCs, LAN, etc.), help-desk type support for of-the-shelf applications and develops and supports small informal applications utilizing a desktop tool such as Excel or Access. Website maintained internally by IT department. IT could provide infrastructure support to host ZIMS locally. ISIS technical support provided as needed via phone
Internet access	Typically a full-time broadband connection such as a DSL line, cable modem or T1 line
profile base	Approximately 30% of zoological institutions

zoological institution profile 4 

current system environment	Server based local area network or multiple networks running sophisticated in-house developed applications. Interactive public website and local Intranet
IT staff	Large application oriented IT department. IT department provides infrastructure support (PCs, LAN, etc.), help-desk type support for of-the-shelf applications, develops and supports small informal applications utilizing a desktop tool such as Excel or Access. IT may also develop and maintain sophisticated transactional systems. Website maintained internally by IT department. IT could provide infrastructure support to host ZIMS locally and could also provide programming support to interface the institution’s custom applications with ZIMS. ISIS technical support provided as needed via phone
Internet access	Full-time broadband connection such as a DSL line, cable modem or T1 line
profile base	Approximately 5% of zoological institutions

The current assumption at this early stage of the project life cycle is that ZIMS needs to be designed such that the system can be deployed to operate within the technical environment of each of the four profiles. The premise is that if the system can operate within these technical environments, then ZIMS is a viable solution for the vast majority of zoological institutions.

The project team developed four deployment options for ZIMS. Each institution can choose the deployment option that is the best fit for their specific needs, requirements and technical environment. Most institutions will be able to choose one of several options.

Additionally, the ZIMS will be designed to be scalable and modular. This means that an institution is not locked-in to the option that they initially choose. As an institution changes and evolves over time, the institution will be able to migrate from one deployment option to another. The migration and conversion effort among deployment options, while not seamless, will be substantially easier than a migration and conversion effort from or to a system that is not designed to be scalable and modular.

The four deployment options are described below.

Application Service Provider (ASP) option User institutions that choose this option will have full access to the functionality of the system. The users will interact with the system through a secure browser-based interface. The browser based interface will be connected via the Web to an off-site centralized server.

ZIMS application programs, data and technical environment will be hosted off-site within a centralized, secure infrastructure maintained and managed by a dedicated and specialized technical team. The local institution is not responsible for physically maintaining the database, application programs and will not have to perform other system support functions such as backup and recovery, network connections, database support, upgrade and revision installation, etc.

User institutions will not be able to customize the application program code. However, the system will be designed to support many configuration options that enable the local institution to "fit" the system to their local business practices and preferences.

The ASP option is depicted below:

ASP option characteristics

locally-hosted option User institutions that choose this option will have full access to the functionality of the system. The users will interact with the system through a secure browser-based interface. The browser-based interface will be connected via the institutions LAN to the intuition’s server.

The ZIMS application programs, data and technical environment will be hosted on-site at the local institution. The local institution will be required provide system support functions such as system backup and recovery, network connections, database support, upgrade and release installation, etc.

The original application code and database structure will be maintained off-site within a centralized, secure infrastructure maintained and managed by a dedicated and specialized technical team. The local ZIMS will synchronize with the central ZIMS on a periodic basis to exchange data and provide releases and revisions.

The local system will be designed to support many configuration options that enable the local institution to "fit" the system to their local business practices and preferences. The option could also be designed to enable the institution to customize the application program code locally. However, if the application code is locally customized, then the user institution will be responsible for manually integrating the system upgrades into their customized version.

The locally-hosted option is depicted below:

locally-hosted option characteristics

local interdependent option This option is an extension to the ASP model. This option consists of a centrally developed and maintained application and database as in the ASP option above, however, the functionality can be independently distributed, in-whole or in-part, among the user institution’s stand-alone desktops and laptops. This option allows a user to work off-line independent of the centralized system and connect periodically to synchronize data receive application upgrades and enhancements. The users will operate the system through a secure browser-based interface

Users will not be able to customize the application program code. However, the system will be designed to support many configuration options that enable the local institutional user to "fit" the system to their local business practices and preferences.

ZIMS application programs, data and technical environment will be hosted on individual user laptop and desktop computers. The individual user will be required provide system support functions such as system backup and recovery and network connection.

The original application code and database structure will be maintained off-site within a centralized, secure infrastructure maintained and managed by a dedicated and specialized technical team.

The local interdependent option is depicted below:

local interdependent option characteristics 

target profiles	1 & 2
Internet connection requirements	A broadband connection such as DSL, cable modem, or a T1line is the preferred connection for this option. However, a dial-up would work with a minimum connection speed of 28 Kbps. The data and application synchronization of ZIMS is directly affected by the speed and reliability of the internet connection. Therefore, this deployment option is based on the fastest and most reliable internet connection
ad-hoc data access	User institutions will be able to download their source data from the central system to a local PC via predefined queries built into ZIMS. Access to data sets that are not part of the predefined queries will be available to the user institutions via an Application Programming Interface (API) through messaging technology to the central system
data warehouse  access	Global data warehouse data is centrally maintained and managed. Access to the warehouse is via a browser-based interface. The data available to the user will be based on predefined classes of queries with user-selectable parameters
system maintenance requirements	While application components are locally stored, customization of the program code would not be allowed. Therefore, maintenance would be limited to the synchronization, storage, and execution of centrally developed and maintained application components
integration with other existing systems of user institution	Supported only through messaging technology to the central system

local independent system option This option assumes that an institution has an existing information system that provides the institution with sufficient functionality such that the institution chooses not to implement and utilize ZIMS. However the institution would like to provide transactional data to ZIMS and be able to receive data via the data warehouse features of ZIMS.

The user institution will be provided with the data exchange schema, messaging architecture and interface specifications. The user institution will be responsible for developing and maintaining the interface from the user side of the transaction.

The local independent option is depicted below:

local independent option characteristics: 

target profiles	4
Internet connection requirements	A broadband connection such as DSL, cable modem, or a T1 line is the preferred connection for this option. However, a dial-up would work with a minimum connection speed of 28 Kbps. The data synchronization is directly affected by the speed and reliability of the internet connection
ad-hoc data access	Low to the central ZIMS system data unless the user institution decides to maintain a local copy of central ZIMS data
Data warehouse access	Global data warehouse data is centrally maintained and managed. Access to the warehouse is via a browser-based interface. The data available to the user will be based on predefined classes of queries with user-selectable parameters
system maintenance requirements	The user institution is responsible for maintaining the technical infrastructure/environment to support their existing system and the interfaces that they have developed to ZIMS
integration with other existing systems of user institution	Integration is supported through Application Programming Interfaces (API’s) to ZIMS via messaging technology with the central system

project risk assessment A project risk is an event, action (or inaction) or circumstance that, without management or intervention, could contribute to the failure to achieve a project goal and/or stated objectives. The purpose of this section of the Mission/Charter is to identify relevant risk factors and to discuss potential mitigation of those risks, to the extent practical, at this early stage in the project life cycle.

Risks associated the ZIMS Project include, but are not limited to:

Insufficient access to knowledgeable Subject Matter Experts (SMEs) The access to highly knowledgeable and enthusiastic subject matter experts for the facilitated sessions in the planning phase was excellent. However, there will be a substantially higher commitment required as the project moves into analysis, design, construction, testing and deployment.

Great analysis cannot overcome insufficient access to business knowledge via business subject matter experts. The project will require continued access to the very best subject matter experts on a timely basis. The risk is that the participating institutions will reduce or restrict the level of access/availability to their very best subject matter experts either from lack of interest or lack of resources. Insufficient access to knowledgeable subject matter experts will have a direct impact on the quality and completeness of the business system analyses and construction deliverables.

In order to set expectations, the project team will require 3-5 highly knowledgeable subject matter experts for each of the approximately 20 in-scope functional areas identified in the Project Scope section of this document. Each of the subject matter experts will need to participate on a close to full-time basis for 6-12 weeks during the business system analysis phase of the project with additional part-time follow-up. A similar level of commitment will also be required during the construction/testing phase of the project.

Disparity between project budget and stakeholder expectations. Fredrick Brooks in the classic book on software project management "The Mythical Man Month" makes an important distinction between a software "program" and a software "product". To highly simplify his discussion, a software program is the thing that a programmer or small programming team produces and runs in a garage/workshop environment. A software product is a software program that is transformed to run as part of an integrated application in a real-world day-to-day work environment.

A tremendous amount of work is required to transform a software program into a software product including generalization, interfacing, integration, component and user testing, documentation, security, etc. Brooks contends that the level of effort required to transform a software program into a software product is nine (9) times the level of effort required to create the software program. In other words, if the software program requires 80 hours of effort to create, then the production version of the program will require another 720 hours of effort of transformation work, for a total level of effort of 800 hours. A number of studies over the years have validated this rule of thumb.

Historically, many software development projects have either greatly exceeded their budget or have met their budget at a greatly reduced level of functionality. Regardless, the resulting systems fail to meet the expectations of the stakeholders. The primary cause for not delivering the proposed functionality within budget is that the original project budget was not realistic for the expected functionality.

In many cases, a programmer or small group of programmers that have traditionally worked on developing small desktop or departmental applications is tasked with estimating an integrated cross-enterprise application. The estimate metrics that this group uses are typically based on developing desktop and/or departmental software programs and not cross-enterprise software products. The result is a budget that is far too low to produce a production quality system that meets stakeholder expectations.

The ZIMS is a sophisticated and complex development initiative. The current expectation of IADISC is to develop a commercial quality product that supports a wide range of activities for a wide variety of zoological institutions and other project stakeholders. The level of effort estimate developed as part of the planning phase was based on developing a software product.

Many of the institutions participating in the ZIMS project have a programmer or a small programming team on staff and/or even sophisticated users and administrators that can create desktop and departmental solutions with desktop databases such as Access, 4GL development languages such as Foxpro, and productivity tools and utilities such as Excel. It is also possible that some of the project benefactors and their advisors have exposure to information technology primarily from a desktop perspective.

It is likely that some of the stakeholders described above will, while meaning well, extrapolate their desktop experience into expectations (time, budget, skills, etc.) on the ZIMS project. This could result in some of the stakeholders placing pressure on IADISC to scale the project to a level of effort budget that is closer to a software program than a software product.

If the ZIMS level of effort budget is reduced below the level necessary to create a software project without a commensurate reduction in scope and functionality, then the result will be a system that fails to meet the expectations (quality, functionality, scope, extensibility, maintainability, etc.) of the stakeholders.

This risk can be mitigated by proactively educating the stakeholders from the participating institutions, including programmers, users and administrators regarding the complexities of developing software products and the steps required to evolve a software program into a software product.

As a point of clarification, the above discussion does not imply that stakeholders should not be allowed to challenge the IADISC project plan and budget. The project plan and budget should be completely transparent (all relevant factors in deriving the plan and budget are disclosed and defined) and defensible to the participating institutions and stakeholders. The message is that the ZIMS is a complex project and the objective evaluation of the project plan and budget requires an appropriate frame of reference.

Passive sponsorship. The term "sponsor" with respect to an information system development project means the specific individual in an organization who manages the organizational unit (department, division, business unit, etc.) that funds/owns the project, is accountable for the results, and receives the benefits from the system. For example, the Vice President of Manufacturing of an industrial company would typically be the sponsor of an Inventory Control System.

Many projects fail to achieve their stated objectives due to the lack of an active project sponsor. An active project sponsor provides the necessary buffer between the user constituency and the project team. An active project sponsor is empowered to and is willing to make difficult decisions on a timely basis. A passive sponsor that primarily acts as a figurehead typically abdicates the difficult decisions to "others" and places the project manager and project team in the position of accepting and interpreting directives from multiple and often conflicting decision makers.

The types of decisions that the ZIMS sponsor will be required to make will include scope (in-scope, out-of-scope) issues, standards issues, conflicting business rules, selection of "best" best practices, budget tradeoffs, etc. The majority of the sponsorship related issues and intervention will occur during the business systems analysis phase of the project. The sponsor must be willing to and empowered to make difficult project decisions on a timely basis. Furthermore, IADISC must be willing to support the sponsor by making decisions as a committee on a timely basis that are perceived by the various project stakeholders as fair and reasonable.

As the project moves from planning into business system analysis, IADISC and the regional associations need to appoint a project sponsor. The sponsor should be an individual that is perceived by the greater stakeholder constituency as objective and unbiased, has a demonstrated ability to make decisions, is a good communicator and has a balanced blend of subject matter and technical knowledge. Ideally, the sponsor should be able to participate on this project on close to a full time basis early in the project life cycle and also have the time and budget to attend meetings in various, including international, locations.

Due to the scale and complexity of the ZIMS project, the project sponsor should consider appointing delegates for specific types of decisions such as project plan, scope and budget, business rules and practices, system architecture, etc. In order for the delegate approach to be effective, the delegates will need to be "active" as defined above, possesses the same type of characteristics as discussed above for the sponsor and be empowered by the sponsor to make binding decisions on behalf of the sponsor. The delegates must also have substantial time to dedicate to this project and have the ability and budget for travel.

Project management. Many projects fail due to weak, ineffective or inexperienced project management. Most project management related failures are due to project managers that lack of people, communication and administrative skills.

ZIMS will require an experienced, proactive, responsive, engaged, professional project manager. The project manager must have a working knowledge of the underlying technical issues, but more importantly, the project manager must have project, people, communication and managerial skills.

Insufficient consensus and compromise. There are a wide variety of terms, concepts and business practices across zoological institutions. One of the challenges of the project team is to reach consensuses among the project participants regarding the definition of a business rule, requirement or practice in the ZIMS design specification. However, there will be a number of occurrences when a consensus cannot be reached among participating institutions. In these occurrences, the project sponsor will be required to make a final decision.

An occasional result of a non-consensus occurrence is a disgruntled participant. The creation of disgruntled participants cannot be eliminated. However, reasonable attempts should be made to minimize the number of disgruntled participants and to identify and soothe them. Too many disgruntled participants can lead to loss of interest among institutions which could lead to a lack of participation ultimately causing the project to fail.

IADISC and the project team must foster the sprit of compromise among the project participants to achieve high levels of consensus. The key to mitigating participant discontent is to identify, objectively analyze and clearly communicate definitions, interpretations and options regarding the rules, requirements and practices

Furthermore, IADISC will need to strongly support the project sponsor’s decision regarding a non-consensus occurrence. Otherwise, various disgruntled participants may sense weakness in the veracity of the decision and attempt to build a business case and re-introduce their alternative interpretation of the rule, requirement or best practice. Once a few decisions are reversed and revised by the project sponsor, the veracity of future decisions will be severely compromised.

As a point of clarification to the above statement, the veracity of the decision does not imply an inflexible autocratic approach to decision making. The vast majority of decisions will be reached through consensus. A final decision that is made by a project sponsor regarding a rule, requirement or practice that cannot be reached through consensus is made only after a thorough analysis and discussion among the parties. However, once the sponsor makes a final decision, it should stick unless substantial, material and compelling new information is discovered subsequent to the final decision.

Diminished stakeholder interest. In many organizations, system users and other stakeholders have been conditioned through experience to expect sponsor and management commitment to wane after an initial period of interest in a project. Currently, regional association members and other stakeholders appear to be actively engaged and highly enthusiastic about the ZIMS project.

If the ZIMS users and other stakeholders sense (rightly or wrongly) a lack of follow-through on the project from IADISC, then momentum and interest could be diminished or even lost and difficult to rebuild.

Typically, institutional stakeholders either withdraw or reduce their participation in the project when they lose interest or confidence. Reduced participation typically results in an institution placing their newest and therefore least knowledgeable people on the project so that the knowledgeable subject matter expects can attend to normal work duties or focus on internal or even competing projects.

In order to maintain the interest of the stakeholders, IADISC should regularly communicate the project status to the stakeholders and seek opportunities to promote the project among the stakeholders and to celebrate project milestones.

Failure to adequately address change management issues. Change management is the process of moving from the "as-is" work process activities and practices based on an existing information system to the new work process activities and practices enabled by a new information system. Change management typically includes changing the existing work process activities and practices, training users to utilize the new system and changing organizational structure and reporting relationships as appropriate.

Change management is typically planned and executed at the local level. An individual institution’s implementation of the ZIMS can fail as a result of a poorly planned and executed change management program.

IADISC should anticipate a wide and disparate degree (proactive to passive) of responses to change management at the individual institution level. Therefore, as part of the development project, a change management standards guideline and template should be developed to assist the individual institutions in developing and executing their change management program.

Scope creep. Users in many organizations have been conditioned over time to believe that if any of their business requirements are not included in the initial release or roll-out of the system, then the requirement will probably never be implemented. Therefore, users have the tendency is to continually and aggressively push the scope envelope.

Time spent by the system analysis team analyzing out-of-scope requirements and/or by the construction team developing out-of-scope requirements in the initial release of the system can have a substantial negative impact on the project schedule and resource budget.

To mitigate scope creep, the scope statement associated with each phase of the project should be as comprehensive and complete as practical with respect to the information available for each phase of the project. Furthermore, the project budget should include funding for the second version/release of the system. The second version/release typically includes those items that were defined at the boundaries and classified as "out of scope" of the first version/release and new functionality desired by the users based on using the new system. Also see the "Project Estimate and Budget" section of this document for additional information regarding budgeting for project versions/releases.

Stakeholder representation. Large institutions v. small institutions and U.S. institutions v. international institutions. The risk associated with under representation of small and/or international institutions is similar to disgruntled participants discussed in "Consensuses" above – the project runs the risk of under-represented users losing interest in the project. This could result in some institutions not contributing time and talent to the analysis and test phase or not implementing the system and therefore not sharing data with the global community.

As part of the analysis and construction phase of the project IADISC needs to develop a mechanism for the small and international institutions to provide input either through direct participation in the analysis sessions or through a review and feedback process of the project deliverables.

Project constraints. Many projects fail due to inappropriate constraints placed on the project by the sponsoring organization and the acceptance of the inappropriate constraints by the development team. Project constraints could include development time, budget, scope, technical architecture, availability of knowledgeable subject matter experts, political considerations, etc.

Any one of these potential constraints, if inappropriately placed on the project, is sufficient to cause a project to fail. At this point in the project there are no stated constraints.

Project assumptions

Institutional participation. The project assumes that a sufficient number of zoological institutions will have the resources, time, money and interest, to support the development of the ZIMS. AZA ADISC is hopeful that approximately 95% of AZA members will implement one of the solution options.

External data sources. The vast majority of data associated with the animal database will be internally generated via user transactions. However some data such as lab results from outside veterinary diagnostic labs, environmental monitoring data, etc. could and probably will be imported from other systems and/or third party data sources. External data sources will be defined in detail in the analysis phase of the project.

Spiral development approach. Based on the Orlando planning meeting, the general consensus was to develop the ZIMS using a spiral rather than waterfall based development approach.

The spiral approach starts with the analysis phase of a core or baseline set of functionality. As this core or baseline set of functionality moves into the construction phase, additional modules (see definition of "module" in the Project Scope section of this document) are added to the analysis phase. This approach results in a number of modules being developed in a parallel rather than serial fashion. The waterfall approach implies that the entire system functionality is defined, developed and deployed as a single linear development effort.

The advantage of the spiral approach is that system architecture is validated earlier in the project lifecycle and baseline functionality is deployed to users much sooner than the waterfall approach.

Project constraints Constraints have not been placed on the project at this early phase of project planning.

Project open issues

Project stakeholders/participants. The AZA, ADISC and a number of AZA institutions actively participated in the planning phase of this project. These organizations contributed many hours of their employee’s time to participate in the analysis sessions, conference calls and documents reviews. Many of these organizations also incurred significant out-of-pocket travel related expenses for their employees in connection with the analysis sessions.

AZA and ADISC have developed this project with an understanding that the ZIMS must be global in scope and that stakeholders from regional and international zoological association such as EAZA, ARAZPA, LAAZGA and WAZA will need to participate in the project.

The open issues to be resolved by AZA and ADISC regarding participation of this wider group of stakeholders includes determining the scope and mechanism of participation (analysis sessions, requirements document reviews, user testing, acceptance testing, etc.) and the degree of commitment (financial, time, etc.) required of each additional stakeholder in order to participate. The earlier these issues are resolved, the easier it will be to successfully manage the roles and expectations of the wider group of project stakeholders.

Data conversion. Zoological data of varying types and quality is maintained at the institution level. It is too early in the project to determine how much of this data will be captured and converted into the database that supports the ZIMS. However, based on the ADISC data cleanup workshop in June 11-12, 2001, general consensus at this time is that inventory data from ISIS (via institutional ARKS databases) should be converted at some level.

In addition, there is also data in the MedARKS system. As part of the analysis phase of the project, the data from MedARKS will be mapped to the ZIMS database and analyzed for quality, consistency and integrity. Based on that analysis, the project team can develop a conversion level-of-effort estimate. Based on the estimate, ADISC can determine if the value of the data conversion is commensurate with the cost of conversion.