Projects Scenario

From LiquidPubWiki

Jump to: navigation, search

Contents

Introduction

The Projects scenario is composed of those projects funded by an organization (e.g. the European Union) under a specific program. The program and percentage of the fund depends on the nature of the project. However, the project needs a counterpart from the participating entities. The “How”, “When” and “Who” questions about the use of the fund, are information that most projects maintains in order to provide some required reports. The project has a group of companies that conforms the so-called Project Consortium. Each company has active participation in the project playing different roles that are basically a coordinating or participating role. In particular, the coordinating role belongs to the head company and the participating role to the other partners. Moreover, there are people who belong to these companies playing different roles within the company organization. Thus, there are a coordinator per company and an overall coordinating person: the Project manager.

Although it is not always the case, very often the project life cycle is organized in three main phases: the preparation, negotiation and execution phases. Therefore, a project since its conception is in any of these phases.

During the preparation phase, there are people working on documents in a collaborative way, discussing in forums, mailing lists and meetings (real or virtual) from which they gather information. In this work in progress, the people keep versions of their documents and define visibility levels to share them with other people. At some point a version of the document is submitted to the organization (European Union) and afterwards the reviews come back. Then, the negotiation phase starts and a new entity join the process: The Project Officer. The project officer replies with reviews which can be of any kind: modification of the document, comments over certain points of the document, etc. Once processed this info, the document get approved and becomes an official document. From here on, the process execution starts and the project is organized and executed to meet the proposed goals. An important issue for the people, who participate in this process, constitutes the version tracking. They keep the submitted versions and attach to them the review results. In general, they tag important versions (e.g. approved version, first draft, official document, etc.).

Key entities of the Project scenario
Key entities of the Project scenario

The work is structured by means of these key entities:

  • Lines of work: Groups several work packages.
  • Work packages: Is a sub-part of the project that groups smaller work entities under the same concept (tasks, deliverables and milestones).
  • Tasks: Is a specific unit of work that requires an effort to be performed.
  • Deliverables: A deliverable is the outcome produced by performing a task or in general an activity within the project scope.
  • Milestones: A milestone is a terminal element that marks the completion of a work package .

All these entities have 1) a responsible party, 2) one or more participating parties. The work packages and tasks also have a start and end time, expressed as relative to the start of the project (e.g., month 1 to month 25). Deliverables and milestones are instead characterized by the date when they are due. Also, work packages, deliverables, and tasks (and maybe) milestones are also characterized by the effort foreseen to achieve/perform them.

Roles

In the project scenario the stakeholders can play the following roles:

  • Project Member: This role belongs to all users who participate in a project. It allows the members to access to project-level information.
  • Project Owner: This is a specialized role that belongs to the user who creates the project. As such, this user is in charge of the administrative tasks related to the project: members management, project configuration and project organization.
  • Project Manager: This is a specialized role for a project member whose job is to perform project-related management tasks.
  • Unit Coordinator: This is a specialized role for a project member whose job is to perform coordinating tasks within a unit/company scope.
  • Internal Reviewer: This is a specialized role for a project member whose job is to review and contribute with feedback on a work.
  • External Reviewer: This is a specialized role for a user who does not participate directly in the project but has the job of reviewing and assessing a given result.
  • Project Officer: This is a specialized role for an External Reviewer whose job is to assess a deliverable.
  • Accountant: This role belongs to the user who is in charge of the accounting and funds management.

Artifacts

In this scenario, artifacts are developed by a team subject to certain time constraints. In the following subsections we briefly describe each one of them.

Project proposal

The project proposal is a document developed with the intention of requesting support (e.g. financial, infrastructure, human resources) from a organization. It contains general information about the project such as: background, objectives, timelines, organization, feasibility analysis and budget draft. Therefore, there are a lot of information that evolves to produce the final result. This artifact can be subject to different processes:

  1. Elaboration process: The elaboration process covers the preparation and evolution of the project proposal. It comprises the phases of elaboration, reviewing, submission and publication. The artifact evolves in the phases of elaboration and reviewing. In the submission phase it is solidified while in the publication phase it is published as official version.
  2. Evaluation process: The evaluation process covers the phases in which the project proposal is either accepted or rejected.

Deliverable

The deliverables are complex artifacts composed of heterogeneous components. For example, deliverables may contain documents, code, data; that evolve over the time and at some point need to be delivered. Deliverables can be subject of two processes:

  1. Elaboration process: The elaboration process covers the collaborative elaboration of the deliverable. It comprises the phases of planning, elaboration, reviewing and submission. The artifact evolves during its life cycle and at some point, when is internally approved, it is solidified and submitted. Afterwards, the artifact can be published (visibility changed).
  2. Evaluation process: The evaluation process covers the external evaluation mechanism that assures the quality of the deliverable and provides feedback.

Report

Reports can be viewed as a variation of a deliverable. However, it is unidirectional and not as flexible as other kind of artifacts. Its elaboration process covers preparation of the report, internal review, and submission.

Budget

The budget is an estimation of all costs related to the project. This is developed independently by each consortium participant but at some point the different estimations converge to a global budget. Therefore, we could say that this artifact has a two-levels elaboration process.

Code

In many projects, specially in the research projects, it is expected write some code. This artifact is subject to the software development process.

The project

The whole project is at the same time a complex artifact. It has its own lifecycle and its execution is subject to evaluation. This artifact is subject to the following processes:

  1. Execution process: This process covers the project since its conception until the final release. The phases of this project are: preparation, negotiation, execution and release.
  2. Evaluation process: This process could be very complex depending on the organization in charge. We can see this process as a black box.

Data model

Functional requirements

Use cases

Test cases

See also

Personal tools