VIVO projects often cross institutional boundaries. To help make decisions and set direction, you'll need a project sponsor and one or more advisory groups, preferably including stakeholders such as researchers. These Outreach Contacts are likely roles to serve on advisory committees. <do we need a page with examples of advisory groups?>

The size and makeup of VIVO teams depends on the VIVO implementation. See Hiring for VIVO projects for the types of resources typically needed. Additional resources are needed after the initial launch to maintain and possibly expand the system.

VIVO can be used to answer questions or generate reports about research. You may want to define those needs in the form of a use case. See: use case.

Generally institutional office which are interested in using and contributing to a VIVO are those that collect or that use research information. This can be review committees, grants management offices, institutional repository managers, public affairs, fundraising bodies and others who need to find out about the research being conducted at the institution. See a sample project plan for a university.

From spreadsheets to external data repositories, there are a variety of potential data sources that can feed into your VIVO instance.  See VIVO Data - what and from where.  You’ll need to identify which data types and data sources are best aligned with the overall goals for your implementation. See Policy and planning question for VIVO data.  It can take some time to evaluate the data content and quality in order to forecast your ingest strategy.  See Data source specifications for implementation and Design of PubmedFetch.

Become familiar with the top level aspects of the VIVO system. It helps to start with Installing VIVO release 1.8. You may also appreciate the information in the Software Architecture Overview.

• You can estimate how much computer power you will need by comparing to other VIVO installations, in VIVO hardware and software requirements.
• What about additional software? Most VIVO sites use only open-source software. The installation guide provides a list in A simple installation.
• Some sites modify the VIVO software stack, either because they have special needs, or simply because they have expertise with different tools. A list of configuration options is available in VIVO 1.8 Installation options.

Every site makes changes to VIVO. Some are as simple as changing the styling and the logo. Others add data types and properties to the ontology. Some add new pages to the application, or new functionality to existing pages. VIVO is made to be customized, but some changes are easier to accomplish than others, and you will need to take that into account. Many stylistic changes are easily done, as described in Changing the appearance of VIVO. Changes to the ontology are described in the Ontology Editor's Guide.

Your VIVO can be customized using your institution's colors, logos, and other identity elements. See Branding Your VIVO to learn more. Also check out other implementations for examples.  

 VIVO can do many things.  Which things will be used at your institution?  What will you deliver?  To whom?  When?  See What VIVO Is and What It's Not, Sample One-Page VIVO Project Summary for a University. It may be helpful to show decision-makers a list of other research organizations which have implemented VIVO.

 With scope defined, you'll know which data your VIVO will display. You'll need to identify the owners of the data you want to feed into VIVO. And you'll need to meet with them to ask for their data. Which data do you want? How will it look in VIVO? How often will you feed data into VIVO, and what are the options for obtaining the data? <Do we need a page/section that discusses how to engage with data owners?>

In addition to installing a test VIVO and inviting users to edit profiles, another way to demonstrate the value and impact of having a VIVO is to show other organizations with a fully populated site. See: Sites implementing VIVO.

The value of the semantic web lies within the ability to define data using widely accepted ontologies.  See How to plan data ingest for VIVO. Understanding your data in order to accurately map to the VIVO-ISF ontology is an important step.  See VIVO-ISF Ontology. Mapping to an ontology begins as a conceptual design process on a piece of paper or using a diagramming tool such as Vue.  Your final data mapping will occur using a tool such as Karma.  Your mapping strategy will not only affect the searchability of your data, but also how easily it can be aggregated and reused by other systems.

Because linked data has a greater potential to be shared and aggregated, data consistency is crucial.  Depending on the quality and variability in your data sources, you may need to plan for data cleanup and/or data “munging” prior to loading into VIVO.  See How to manage data cleanup in VIVO. It is also important to standardize and document your data cleanup strategy. Cleanup can be done manually or semi-automated.  For a list of suggested cleanup tools see Name disambiguation and entity resolution.

For most VIVO sites, the biggest challenge of a VIVO system is not VIVO itself. Instead, the challenge comes in populating VIVO with data from your institutional systems. Many pages in the VIVO wiki are concerned with data issues. Start with VIVO Data - what and from where (Example), and the pages linked to it. Data challenges are often particular to the individual institution, ranging from the practical (Data source specifications for implementation) to the political (Policy and planning questions for VIVO data).

  <Can we change this to "Develop Processes" ?> - You may need to develop your own programs and scripts for ingesting data, or you may be able to configure a more general tool to your own needs. In the VIVO community, the two favorite tools are the VIVO Harvester and Karma. You can view some tutorials on YouTube to learn more about using Karma with VIVO.

Create Launch Strategy

Identify Power Users

Data contributors or other stakeholders may be able to help identify those users who are likely to be active participants and who edit and update their profiles regularly. These might be people who have easily adopted other systems in the recent past. The Site Admin==>User Accounts link can be sorted by the number of logins, which might also help identify power users.

Develop Training Materials

See examples of training materials at Duke University's Scholars@Duke

Prepare Data Loads

Depending on how your technical roles are defined, this task will be shared between your data staff/domain experts and your developers.  This is when ontology mapping goes from conceptual diagrams to actual RDF generation.  Preparation of the data loads involves:

• executing the data cleanup strategy
• physically mapping the data to the ontology
• verifying the RDF generated.

See XSLT Ingest Example and Using a different data store

Document Data Provenance

Maintenance of the data in your VIVO instance requires thorough documentation of your data flow.  Some of this information may be documented internally, while some of it will make sense to load in VIVO as part of the metadata. See Provenance Ontology.

Build Customized System

Add your customizations to VIVO. If you are only making small changes, mostly to appearance, you might add your changes directly to the VIVO distribution files. For larger customizations, you should learn Building VIVO in 3 tiers. This helps to organize your installation, and will make it easier to implement system upgrades when the time comes.

Test Performance

Before announcing your VIVO system to the public, you should test to be sure that it performs acceptably. If not, you might consider Use HTTP caching to improve performance, or the methods in Troubleshooting VIVO's Performance. <This needs work.>

Oversee Publicity Campaign

Communication is an important part of the launch strategy.  It's important to let the community know that VIVO's coming. Different audiences may need different messages, and different ways to engage with the project. See <Communication Strategies> for more information.

Implement Assessment Plan

How will you know when your VIVO implementation is successful? Consider a set of goals or a mission statement, endorsed by the VIVO governance groups. These goals should be tied to your assessment plan. See <Assessing the Impact of VIVO at Your Institution> to learn more about how to demonstrate the value of your VIVO.

Publicize VIVO

In addition to regular meetings with primary stakeholders, materials can be posted or mailed to those with potential interest. An example of a poster for that purpose is here.

Hold Trainings

Route Data Cleanup Requests

From the cleanup strategy identified for the initial ingest, you will need to determine which are ongoing tasks and what the frequency will be going forward.  Once your VIVO instance is established, you will want to work with management and to identify the resources and workflow by which data maintenance requests will be addressed.  See Data Maintenance. You may have noticed inconsistencies or missing data during your initial ingest that could not be addressed in batch.  It is good to be aware of potential cleanup requests and have an established method for correcting the data.  See Monitoring for quality.

Support Data Provisioning

One of the fun parts of getting your data into VIVO is finding out all of the creative ways it can be reused in other systems.  See Finding VIVO Data with the University of Florida Public SPARQL Endpoint. Setting up a SPARQL endpoint is one way to write customized queries for data consumers.  See Setting up a VIVO SPARQL Endpoint. SPARQL query results can be run periodically and exported in several common formats such as .csv and .xml.  For example queries see Rich export SPARQL queries. Web developers may find the VIVO widgets to be a useful way to consume VIVO data as JSON.

Provide System Support

As with any IT project, you should expect VIVO to require ongoing support. This includes things like backups, security checks, upgrades to operating systems, etc.

Contribute to VIVO community

Once the dust settles, you'll want to share your experiences and best practices with the VIVO community. Follow other VIVO sites on social media, and create your own accounts to share your news. Join a VIVO task force to create or improve something. We need your help to make the VIVO community stronger!

Find New Collaborators

Engaging a research organization's community will depend on identifying new collaborators who might either contribute to or use the VIVO (or both). 

Hold User Meetings

Manage Ontology Updates

Ontologies can be updated to add or remove terms as a domain becomes better defined.  Ontology changes can be initialized from within your institution (ex. an identifier specific to your institution) or externally (ex. a deprecated term identified by an international standards organization).  The ontology change can be adopted at the level of the the VIVO ontology, or it can be a change done locally within your institution, aka a “local extension”.  For an example, see Ontology Extensions -- Duke.  Local extensions can easily become duplicate ways of defining the same type of information, so it can be helpful to collaborate with the VIVO ontology community when deciding whether or not you need to create a local extension. To the extent that it is relevant to the broader VIVO community, it is important that over time, local ontology extensions get incorporated into the VIVO core ontology.  See Proposed ontology development workflow.

Add New Data & Sources

Data curation is an ongoing task and including new data types or new data sources will most likely be an aspect of maintaining your VIVO instance.  You may find that your initial implementation draws more interest from owners of data repositories you hadn’t considered.  You may want to prioritize new data sources based on the data quality and volume, as well as the number of new ontology mappings required.  As an example, see Activating the ORCID integration.

Implement System Upgrades

The VIVO team issues a new release about every year, with occasional extra releases to fix problems. For the most part, upgrading is straightforward. If there is a change in the VIVO ontology, the new release will include an automatic script to translate your existing data. Again, it is not unusual to find that the largest task is making changes in your data ingest processes. Most VIVO sites try to adopt new releases as soon as possible, to take advantage of new features or improved performance.

Develop New Features

You should also plan to develop new customizations for your VIVO installation. As your users gain experience, they will likely request new data and new displays. In the best case, these changes may be something that you can contribute to the VIVO community, so others may benefit from your work.