Enterprise was designed to enable seamless data flows between project-level instances of DevResults and headquarters instances of DevResults. "Enterprise" is our name for that set of linked DevResults sites. What does Enterprise offer, and how is it different than a single DevResults site?
First, let's look at a schematic of a single DevResults site.
The central organizing feature of DevResults is an Activity. An Activity in DevResults is generally an award, grant, project, etc. An Activity usually represents a contract that provides funds to a managing organization to achieve some end, and these contracts frequently require reporting on indicators in return. Conceptually, DevResults allows unlimited "Activities" to report any indicators needed (wherever the Activity operates, for any relevant periods of time). Have a look at our Data Structures page to see Activity structure in more detail.
An Enterprise site is just like a normal DevResults site, but one or more of its Activities is itself another DevResults site.
We call the Enterprise site the "parent" site, which can have any number of "child" sites. To the Enterprise site, these child sites are simply more Activities. The difference is that the Activity has its own DevResults site for managing its own partners, sub-awards, sub-grants, and sub-projects, etc.
Why choose DevResults Enterprise?
Whether to use DevResults Enterprise hinges on a primary question. Is your goal to provide data management and analysis tools to:
- One central body that gathers information from disparate sources, or
- Many entities that gather information from their own disparate sources?
Pros and Cons of Enterprise
|All management tools in each DevResults site are available to site owners for their own needs||Requires training in site configuration and administration for not just one group of site owners, but for each entity with its own DevResults site|
|Hierarchical data relationships are captured, i.e., data for partners (sub-awards, sub-grants, and sub-projects) aggregates to child sites. Then, child site data aggregates to the Enterprise site.||Higher cost|
|Offers both centralized and decentralized management of indicator reporting, i.e., child sites might be required to report on indicators from a standard indicator library, or the could have the ability to report their own custom indicators (or both)|
|Configuration options like permissions and tags can be specific to each site|
Pros and Cons of Single Sites
|Offers centralized management of all indicator reporting||Those reporting data to a single site do not have their own platform for collecting indicator data from sub-entities|
|Training in site configuration and administration for single set of owners, not many sets||Configuration options are shared by all users|
|Lower cost||Data is attributed to one set of Activities and cannot be subdivided by sub-Activities|
A global NGO, company, or donor wants to collect indicator data from projects operating in many different places. We'll call them DevOrg. They want to be able to see and analyze indicator results from each of their projects.
The case for Enterprise: DevOrg's projects need a tool for collecting, storing, and analyzing data from their partners or sub-grantees. The project managers have authority over the indicators they use. These managers need to make changes to their data collection plans in response to altered requirements or strategy. The projects work with data that is more specific than is needed by DevOrg; perhaps DevOrg is interested in national totals for indicator results while the project keeps records of all beneficiaries. However, DevOrg would like to have easy access to this information for auditing and data quality assessment purposes. Projects might need to report to a separate donor as well. DevOrg's projects might or might not share indicators, but projects do not need access to one another's data. Most people who need access to data for all projects work for DevOrg headquarters.
One case for Single Site: A single DevResults site is the system that DevOrg project managers use to manage their work and report data. Project managers have access to edit program information for all projects, but typically only edit information for their own projects (or they collaborate with other project managers on shared information, like shared indicators, frameworks, and tags). These projects are responsible for reporting results to DevOrg and potentially to one or more donors as well. A project in DevOrg typically does not have contributing partners, sub-awards, sub-grants, etc., or if they do, those partners can easily report combined indicator results. Projects might or might not share indicators. DevOrg needs both to gather indicator results from their projects and to give project managers the tools for entering and organizing data.
A second case for Single Site: DevOrg's projects have their own systems for collecting and storing data, whether purpose-built data management systems, mobile collection tools and apps, or Excel. These projects are responsible for reporting some results of their work to DevOrg and potentially to one or more donors as well. DevOrg does not need to assess the contributions of various sub-awards to each project, but it is interested in all or some of the indicators used by the projects. Projects might or might not share indicators, and projects might or might not need access to one another's data. DevOrg is primarily interested in a way to gather indicator results from their projects.
Features of Enterprise
- Data publication from child sites to the Enterprise site with two clicks of a button
- Indicator library from which child sites can select indicators
- Site-specific access and permissions
Can a DevResults site have multiple 'parents'?
Yes. For example, a project or award with their own DevResults site could be linked to both the donor who funded it (like a USAID DevResults site) as well as that of the NGO that received the award.
Didn't answer your question? Please email us at firstname.lastname@example.org.