GEOSS Banner

Managing expectations of users

Table of contents
No headers
Subject area/Theme

User Engagement/Communication

Best Practice:

Current and future specifications of services or data products should be made transparent while these products are being developed, so that the respective users at all times have realistic expectations.

Clear messages should be provided to the users about what could be realistically achieved in a project context with regard to the fact that services/products are developed not only trying to satisfy one respective user but a broad range of users with different expectations. If a user knows about this already in advance or at the beginning of the project the user can better accept that his expectations/requirements will only be fullfilled up to 80%.

Explain why is there a need for this Best Practice?

During product development in GMES* projects, future capabilities of the resulting services  were anticipated in quite different ways. When the respective data providers  gave a realistic description of product specifications that can currently be achieved, and of the time spans needed for product development, users knew ahead of both benefits and limitations of the respective data products. In those cases, when data providers oversold the future products and services, users had, accordingly, very high expectations, which later caused disillusion. The former case is a prerequisite for a lasting working relationship built on trust, whereas the latter may impede future engagement of these users.

)* Global Monitoring for Environment and Security, the European contribution to GEO.

Provide an example application(s):

To provide examples, particular service providers would have to be named which would not be adequate in this frame. 

How widely deployed is this practice(if applicable)

Several service providers act according to this practice, but not all of them.

Owner (Originator) Contact Information:


Submitter Contact Information:



Editor's comments:

The sentence under "Provide an example application(s)" is not clear. Is it meant that the space is not adequate to name particular service providers? You might consider naming a few examples - no need to be exhaustive.

It would be useful to provide specific contact information so that one can send an e-mail to the submitter, if necessary. The GNU web site is nice in providing information about the project, but it is not possible to contact any individual from that web site (as far as I could see).


-- H. K. Ramapriyan.

Files (0)

You must login to post a comment.