Ecosystem Approach Community of Practice Overview: Clusters

This page is dedicated to document the services and resources expected to be made available, grouped by EA-CoPCommunity of Practice. cluster.

Each clusters is described in its own page:

• the Statistical cluster page;
• the Biodiversity cluster page;
• the Geospatial cluster page;
• the Semantic technologies cluster page;

The cluster pages describes EA-CoPCommunity of Practice. desiderata grouped in terms of a composition of services and resources, delivered as a single unit to the CoPCommunity of Practice.. Such a single unit may be a service, a resource, a VREVirtual Research Environment., a consolidated report or other object, etc. One cluster may contain many of such units. This approach is taken to facilitiate the discussion in the CoPCommunity of Practice.. The requirements collection is completely separated from the implementation discussion, and the CoPCommunity of Practice. retains all freedom to structure its desiderata.

The Requirements page describes how the CoPCommunity of Practice. organizes the requirements collection and discussion on high-level topics in a set of organic, but also technological clusters; geospatial, biodiversity, statistics, and semantic technologies all are supported by technologies that overlap in functionality with other clusters, yet are still easily identifiable as falling within one of the clusters. The cluster pages are the result of that collection and discussion process.

Workplan

What are iMarine Work Plans

In the iMarine project Deliverable D3.1, EA-CoPCommunity of Practice. Operation, WP3 documents the functioning of the EA-CoPCommunity of Practice.. The deliverable is this wiki articulated with a web based tool for managing the meetings, their reports and progress reports, recommendations and conclusions; the imarine Board channel. Deliverable chapters are Work plans, iMarine Board meetings, and Supported Business Cases. The chapters are implemented as section of the wiki.

This section, on work plans, describes the 2 main activities related to work plans over a given period of time. They first cover the activities needed to convince decision makers such as the iMarine Board for its approval, then as a guiding document for the activities to be carried out during that time period, and how to validate the results.

The iMarine Board meeting section contains the documented response of the Board individual members or the body as a whole on the presented work plans.

The last wiki section will cover the rationale behind the decision process that will govern the selection of the business cases to support and it will illustrate the features of the third and unselected business case that could be addressed in the remaining selected business cases. Part of this rationale will relate to the feasibility of the implementation through work plans.

Work Plans in iMarine

The main purpose of the work plans are to provide the iMarine Board with a planning and management instrument (tool) that provides a framework for planning activities, and that can serve as a guide for carrying out that work. The scope is the interface between Board and project activities; they aim to implement a iMarine Board objective.

They contribute to project transparency, as the plans are accessible to those persons or organizations who have a need or a right to know what will happen, when, and why, during the project.

The work plans relate to objectives specified in the DoW. They are orthogonal to the Work Packages (WP), as their implementation typically requires effort from several WP's. They are also agnostic of Business Cases (BC's), as these relate to a CoPCommunity of Practice. vision that may have little or nothing to do with the tools and resources needed to achieve it. Work Plan specify a strategy to operate in a specific time segment with effort from one or more WP’s. They identify (as goals) the problems to be solved, make them finite, precise and verifiable as objectives, indicate the resources needed and constraints to be overcome, outline a strategy, and identifies the actions to be taken in order to reach the objectives and complete and validate the outputs.

In order to efficiently plan the resources, work plans can cut across the Business Cases. It makes little sense to implement solutions for e.g. geospatial data management separately for each business case. This necessitated the definition of clusters, as described in the DoW. So rather than Business Case Work Plans, this wiki contains Cluster Work Plans for technology related objectives, and mediation and governance work plans that cover the Board other activities.

The goals and objectives (when accomplished) are the output of the project. They must therefore be formulated thus that they are measurable. The outputs are validated, and thus need to be enriched with information on their required quality with regards to performance, completeness and coverage.

Period Covered by Work Plans

The optimum length for a work plan is between six and twelve months. A three month work plan is too short, considering the amount of time and effort needed to prepare the plan. A twenty four month work plan might be too long, because conditions change during a whole year, and by the end of the year the objectives and priorities may have have all become different. They should align with the general project reviews and / or iMarine Board meetings.

The Structure and Content of the Work Plans

An iMarine work plan includes the following parts:

• Abstract or Executive Summary;
• Introduction and Background (The Problems);
• Goals and Objectives (The Outputs);
• Resources and Constraints (The Inputs);
• Strategy and Actions (from Inputs to Outputs);
• Appendices (Budget, Resources, Documents, Schedule and Others).

The Overall Flow of the Work Plan

The work plan consists of a main text and appendices. The appendices may include budgets, agreements, external resources, data formats, etc. They are put into appendices at the end of the work plan, as they do not form part of the argument.

iMarine takes an Agile approach to programming, and the work plans do not need contain details at the start of any activity. Where these are known, or where there are expected dependencies on tools, services or other resources, these need to be described first.

Work plans are initiated in WP3 and identified and aligned with the content of the DoW. This ensures that they provide a relevant progress towards the realization of one or more business cases and that the project as a whole benefits from their services. After drafting, they work plan needs approval in the iMarine Board, following Board procedures. If an agreement has been reached, the work plan is forwarded to the Project Executive Board, from where implementation effort from the technical work packages will be identified. WP3 will collaborate with WP6 and representatives of the iMarine Board to monitor implementation.