Objeto

Permitir la gestión de los proyectos de cualquier área de la STIC (sea provincial o centralizada), entendiendo como proyecto el conjunto de actividades que se hacen para, en un tiempo definido, conseguir un objetivo. Dentro de estas actividades se engloban tanto las propias tareas de ejecución del proyecto como todas las de gestión para controlar que se siguen unos objetivos de calidad, de esfuerzo y de tiempo.

Alcance

Este proceso tiene como alcance cualquier proyecto gestionado por un área de la STIC y ejecutado tanto por integrantes del propio área como de proveedores externos.

Actividades del proceso

Alta del proyecto

El primer paso es proceder al alta del proyecto, identificando aquellos datos que van a ser necesarios para gestionarlo correctamente. Para dar de alta un proyecto en la herramienta de gestión corporativa, debe solicitarse creando una solicitud aquí indicando el nombre y la clave del mismo. La clave debe tener una serie de restricciones impuestas por la propia herramienta, aunque se recomienda que sea lo más descriptiva posible para poder identificar fácilmente las tareas del proyecto. Las restricciones referidas son:

Debe tener como máximo 9 caracteres
No debe empezar por un número
Todo deben ser mayúsculas
No debe contener caracteres raros ni guiones

El peticionario deberá indicar el área de SSCC o el nodo provincial para el que solicita el proyecto. Este dato es fundamental porque indicará la categoría que tiene el proyecto en la herramienta corporativa. Además, es también importante que indique si el proveedor del proyecto debe tener usuario en la herramienta.

Completar propiedades del proyecto

Una vez que el proyecto está dado de alta en la herramienta, es necesario seguir informando todos los datos que aun son necesarios. Esta actividad es llevada a cabo por los Coordinadores (pueden ser más de uno, se incluirán en el grupo gestores-propiedades) de cada área, y esos datos en la herramienta son llamados "propiedades" del proyecto

Descripción: breve indicación del objetivo principal del proyecto.

Promotor del proyecto: opcionalmente puede indicarse quién promociona el proyecto. Puede ser o no miembro del equipo provincial o de la propia STIC.

Responsable del proyecto: idem a la propiedad anterior. Es fundamental que esté informado en el caso en que se creen tareas con validación, ya que será el encargado de validar el trabajo

Área TIC: las áreas TIC definidas son:

Desarrollo
Sistemas
Puesto usuario
I+D+i
Gestión
Seguridad

Cada área centralizada o nodo provincial podrá decidir si quiere o no usar todas las áreas TIC definidas. Además, podrán establecer una diferentes grupo de proyectos para cada una de esas áreas. Por ejemplo, podrían considerarse dentro del área de desarrollo los proyectos .net, los de explotación de datos, etc.

Grupos de proyectos

Centros de gestión: desplegable en el que aparecen los centros de gestión de cada área o nodo provincial. Al igual que las áreas TIC y los grupos de proyectos se configuran para cada categoría, es decir, son definidos por cada área centralizada/nodo provincial.

Prioridad

Estado

Usuarios de terceros que participan en el proyecto: usuarios con licencia en la herramienta que van a tener permiso para interactuar en el proyecto. Es importante tener en cuenta que:

todos los usuarios que se muestran como terceros visualizan el proyecto, pero sólo aquellos que son seleccionados son los posibles asignados de las tareas.
si la empresa de soporte provincial participa como proveedor, hay que indicar si tiene o no visibilidad en otras tareas que no sean de soporte provincial.

Nombre empresa proveedora

Nombre persona de referencia proveedor

Teléfono proveedor

Correo electrónico proveedor

Prioritario Subdirección: Indicar si el proyecto es o no prioritario para la Subdirección

Tipo de plantilla: indica la posibilidad de la plantilla que se crea para gestionar la documentación y el conocimiento asociado al proyecto, Hay dos posibilidades: simple y compleja

Creación de espacio para el proyecto

Una vez que se han indicado las propiedades necesarias para comenzar la gestión del proyecto, es necesario crear el espacio en la herramienta de gestión del conocimiento donde muchos de los datos se informarán directamente con lo registrado anteriormente y podrán completar información importante para la gestión del proyecto. Como hemos indicado en las propiedades del proyecto, las plantillas pueden ser simples o complejas.

La estructura creada para cada espacio de un proyecto si se elige la plantilla compleja contiene:

Hoja de ruta: Incluye el horizonte temporal estimado del proyecto y posteriormente se podrá registrar el real, así como una planificación a alto nivel que debe ir actualizándose a lo largo del ciclo de vida del proyecto

Descripción del proyecto: consiste en incluir una breve descripción en la que se indique para qué sirve el proyecto y la justificación que lleva a su creación.

Objetivos y alcance

Estado del proyecto: se definen cuatro posibles estados:

En estudio: el proyecto aún no ha comenzado y puede ser que nunca llegue a ejecutarse
En cartera: el proyecto está ya aprobado pero aún no ha comenzado a ejecutarse
En ejecución: como su nombre indica, el proyecto se está ejecutando
Paralizado: el proyecto se ha paralizado por alguna razón bloqueante y se reanudará, es decir, pasará de nuevo a ejecución una vez que se haya solventado el motivo de bloqueo
Cerrado: el proyecto ha llegado a su fin porque o bien porque ha acabado su ejecución o porque desde la fase de estudio se decidió no abordarlo

Estimaciones: pueden ir registrándose las estimaciones de recursos, esfuerzo y costes e ir cambiándolas si es necesario a lo largo del ciclo de vida del proyecto.

Información relevante: en esta sección hay un apartado, Datos básicos, que siempre va a estar actualizado de forma automática con los datos que se hayan registrado en la herramienta de gestión. Cualquier modificación de los mismos debe hacerse desde esa herramienta y no mediante edición de la página.

El resto de la plantilla lo explicaremos a la hora de ver cómo se hace el seguimiento y control del proyecto.

En el caso de que se elija la plantilla simple, la estructura será la siguiente:

Hoja de ruta: Incluye el horizonte temporal estimado del proyecto y posteriormente se podrá registrar el real, así como una planificación a alto nivel que debe ir actualizándose a lo largo del ciclo de vida del proyecto

Descripción del proyecto: consiste en incluir una breve descripción en la que se indique para qué sirve el proyecto y la justificación que lleva a su creación.

Información relevante: en esta sección hay un apartado, Datos básicos, que siempre va a estar actualizado de forma automática con los datos que se hayan registrado en la herramienta de gestión. Cualquier modificación de los mismos debe hacerse desde esa herramienta y no mediante edición de la página.

El resto de la plantilla lo explicaremos a la hora de ver cómo se hace el seguimiento y control del proyecto.

Cada espacio correspondiente a un proyecto tiene un enlace con un espacio "padre" que se configurará dependiendo del área centralizada o nodo provincial que gestione el proyecto.

Ejecución del proyecto

Sea cual sea el estado del proyecto, se podrán crear tareas del mismo que serán asignadas o bien a uno de los miembros del área centralizada/nodo provincial que gestiona el proyecto o bien a uno de los usuarios terceros que se hayan incluido como usuarios del proyecto. Si el proveedor o proveedores del proyecto no tienen usuario, la ejecución y gestión de sus tareas deberá asumirlas un integrante del área centralizad/nodo provincial.

Cualquier tarea (excepto las tareas de soporte provincial) puede ser dividida en subtareas con el mismo ciclo de vida que las tareas de las que se originan. Tanto en tareas como en subtareas pueden ir registrándose trabajo, de manera que si para cada una de ella se tiene una estimación de trabajo, puede controlarse la evolución de lo estimado frente a lo incurrido.

Existe la posibilidad de que se gestionen tareas que el proveedor ejecuta normalmente en una entidad de otro tipo de proyecto (de aplicación, de plataforma). Por ejemplo, un proyecto del área de Sistemas en el que una tarea es la construcción de una plataforma. En estos casos, la tarea podrá enlazarse con la entidad en la que el proveedor hace el trabajo mediante un tipo de enlace especial,

Desde la entidad del proyecto a una entidad de proyectos de tipo aplicación, plataforma o soporte provincial: "Se desarrolla en"
Desde la tarea del proyecto de aplicación, plataforma o soporte provincial a la entidad del proyecto: "Se gestiona en".

Tipos de tareas del proyecto

Los proyectos de un área centralizada o nodo provincial se gestionan en base a tareas que, como hemos comentado anteriormente, pueden ser creadas y ejecutadas por integrantes del equipo del área/nodo o bien por el o los proveedores que se hayan definido para el proyecto concreto. Hay cuatro tipo de tareas:

Tarea general

En este tipo de tareas puede especificarse:

- Qué se quiere hacer
- Quién debe hacerlo
- Fechas orientativas de comienzo y fin de la tarea
- Área TIC por si no coincide con la del proyecto
- Centros de gestión, por si no coinciden con los del proyecto
- Esfuerzo requerido
- Fecha de compromiso de la tarea
- Con quién está comprometida
- Si es o no prioritaria para la Subdirección
- Posibles solicitudes de NWT con las que la tarea pudiera estar relacionada

Una vez creada y asignada a su responsable, éste la ejecutará y resolverá, pudiendo solicitar información al creador de la tarea. Existe la posibilidad de que en cualquier momento la tarea quede bloqueada, reanudándose una vez se haya resuelto el motivo que la bloqueó.

Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose.

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

Tarea con validación

Los campos en la creación son exactamente iguales que en la tarea general. En cuanto al flujo, la única diferencia es que una vez que se resuelve la tarea, el Responsable del proyecto será el encargado de validar si la resolución de la misma es o no correcta. En el caso de que lo sea, la tarea se cerrará. Si por el contrario la resolución no es correcta, volverá a estar en resolución para que su asignado la corrija. Una vez resuelta de nuevo, volverá a ser validada por el Responsable del proyecto.

Tarea MCMI

son tareas específicas del modelo corporativo del marco de implantaciones (marco normativo para la ejecución de cualquier proceso de implantación en el ámbito del SAS, independientemente del producto implantado). Si quieres conocer el MCMI, pincha aquí.
En este tipo de tareas debe especificarse

- Qué se quiere hacer
- Quién debe hacerlo
- Fechas orientativas de comienzo y fin de la tarea
- Área TIC por si no coincide con la del proyecto
- Centros de gestión, por si no coinciden con los del proyecto
- Esfuerzo requerido
- Fecha de compromiso de la tarea
- Con quién está comprometida
- Si es o no prioritaria para la Subdirección
- Posibles solicitudes de NWT con las que la tarea pudiera estar relacionada
- Fase MCMI: son las fases que cubren todo el ciclo de vida de la implantación. Es un desplegable con los valores:
  - APS: Fase de obtención de información sobre la situación de partida
  - RP: Reingeniería de procesos
  - PRE: Preimplantación
  - IMP: Implantación
  - ARR: Arranque
  - CON: Consolidación
  - EXT: Extensión
  - PN3: Transferencia del soporte a los proveedores del servicio N3

- Área MCMI: son las áreas de conocimiento en las que se categorizan las actividades de una determinada fase de la implantación. Es un desplegable con los valores
  - FUNC: Área de conocimiento Funcional
  - FORM: Área de conocimiento de Formación
  - MIGR: Área de conocimiento de Migración
  - INTE: Área de conocimiento de Integración
  - SIST: Área de conocimiento de Sistemas e Infraestructura
  - AYED: Área de Análisis y Explotación de Datos
  - GEST: Área de Gestión

Una vez creada y asignada a su responsable, éste la ejecutará y resolverá, pudiendo solicitar información al creador de la tarea. Existe la posibilidad de que en cualquier momento la tarea quede bloqueada, reanudándose una vez se haya resuelto el motivo que la bloqueó.

Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose.

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

Historia de usuario

son tareas destinadas a desglosar requisitos de proyectos de desarrollo cuando la gestión de los mismo se hace con metodología ágil. La información que debe especificarse en este tipo de tareas es:

Qué se quiere hacer
Quién debe hacerlo
Narrativa: consiste en especificar qué es lo que se tiene que hacer usando el formato "Como______ quiero____para"
Criterios de aceptación de la historia de usuario.

Una vez creada y asignada a su responsable, pasará a estar en desarrollo y en testing para pasar a ser validada por quien haya pedido esa funcionalidad.
Mientras la tarea esté resolviéndose, su responsable podrá registrar trabajo en ella. El responsable del proyecto determinará "las unidades" del trabajo que se realiza, horas, HBS, etc.

En cualquier estado será posible descomponer una tarea en subtareas a las que se podrá poner fechas orientativas y hacer una estimación del esfuerzo. Al igual que en las tareas, podrá registrarse trabajo mientras estén resolviéndose.

Una tarea no podrá darse por resuelta mientras no lo están todas sus subtareas.

Tarea de soporte provincial

Estas tareas tienen las siguientes condiciones:

Sólo deben aparecer en proyectos en los que se haya dado de alta como proveedor al proveedor de Soporte Provincial
No es posible crearle subtareas
Sólo pueden ser creadas por usuarios que pertenezcan al equipo provincial. Al proveedor de Soporte Provincial se les deja crear tareas que no sean de este tipo pero que nunca deberían ser asignadas a ellos mismos.

En este tipo de tareas debe especificarse

- Qué se quiere hacer
- Fechas orientativas de comienzo y fin de la tarea
- Área TIC por si no coincide con la del proyecto
- Centros de gestión, por si no coinciden con los del proyecto
- Esfuerzo requerido
- Item de catálogo:
  - Puesto de usuario:
    - Instalación de más de un puesto de usuario
    - Configuración de más de un puesto de usuario
    - Verificación de más de un puesto de usuario
    - Actualización de más de un puesto de usuario
    - Reparación en taller de impresora
    - Reparación en taller de PC/Terminal
    - Reparación en taller de otros
    - Testeo o piloto
    - Telefonía fija
    - Otros
  - Infraestructura TI y Software
    - Mantenimiento
    - Revisión CPD
    - Instalación y mantenimiento equipamiento HW
    - Instalación y mantenimiento entorno virtualizado
    - Configuración de almacenamiento
    - Instalación y/o configuración de backup
    - Creación y/o configuración de BBDD
    - Instalación de software de servidores
    - Soporte puesta en producción
    - Testeo o piloto
    - Soporte a terceros
    - Otros
  - Redes e Interconexiones
    - Conectividad local
    - Conectividad entre centros SAS
    - Adecentamiento de armario
    - Diseño de solución de comunicaciones
    - Gestión de VLAN y reglas
    - Revisión de logs y conectividad
    - Testeo o piloto
    - Soporte migración de datos
    - Otros
  - Seguridad TI
    - Antivirus y navegación segura
    - Testeo o piloto
    - Otros
- Tarificación:
  - Basal: actividades que entran dentro del horario normal
  - Valor añadido: actividades que se hacen en horario extendido o con recursos que exceden el soporte basal del contrato y que necesitan la aprobación del Responsable del Contrato.

Una vez creada la tarea, se asigna automáticamente al Proveedor de Soporte Provincial del nodo correspondiente en estado PDTE. CALENDARIZAR.

El proveedor marca unas fechas de inicio y fin estimadas teniendo en cuenta las que se le han sugerido y dependiendo sobre todo de la planificación de sus recursos.

Si la tarificación es basal, al hacer esa acción, la tarea pasa al estado PDTE. COMENZAR RESOLUCIÓN. En este estado es factible por parte del Responsable de proyecto poder modificar esas fechas una vez que se tenga una foto de todo el trabajo a planificar.
Si la tarificación es Valor añadido, al hacer esa acción la tarea pasa a estado CALENDARIZADA donde tendrá que ser aprobada por el Responsable del Contrato. Una vez aprobada, pasará a estado PDTE. COMENZAR RESOLUCIÓN.

Cuando el Proveedor comienza a resolver la petición y puede asignar un técnico que será visible (selección a través de un desplegable con los miembros del proyecto que el Proveedor hayan configurado), la tarea pasa al estado EN RESOLUCIÓN. En este estado, el Proveedor podrá incurrir esfuerzo, indicando el restante. Si durante este estado, hay algún motivo que bloquee la tarea pasará a estado PARALIZADA.

Si una tarea que se está ejecutando tiene que ser cancelada por parte del Responsable del proyecto, entra en un circuito en el que se intenta que el Proveedor liquide el esfuerzo que llevara hasta ese momento y el grado de avance técnico (estado PDTE. CANCELACIÓN). Esta liquidación que hace el Proveedor debe ser validada por el Responsable del proyecto. Dicha acción se realiza cuando la tarea está en estado PDTE. REVISIÓN CANCELACIÓN

Una vez que el Proveedor ha terminado su trabajo, la tarea pasa al estado PDTE. REVISIÓN TÉCNICA donde el peticionario de la misma debe aceptar o no la solución

Si el peticionario no acepta la solución, la tarea pasará al estado NO ACEPTADA con objeto de que el Proveedor vuelva a trabajar en ella y, una vez que la haya acabado pase a PDTE. REVISIÓN TÉCNICA de nuevo

Si el peticionario acepta la solución, la tarea pasará a estado CERRADA

Tareas de seguridad

Estas tareas se definen como la Evaluación de un proyecto, por parte de la USTIC, previo a su aceptación y puesta en servicio. No se consideran bloqueantes para el desarrollo del proyecto. En principio todos los proyectos, independientemente del área TIC al que pertenecen deben tener al menos una tarea de seguridad. Los proyectos van a tener una nueva propiedad, denominada Revisión seguridad que se informará a "Sí" cuando se cree la primera tarea de seguridad .

Este tipo de tarea podrán ser creadas por los integrantes del equipo provincial o del área centralizada a la que pertenezca el proyecto. En la misma creación se informa de aquella documentación que puede ser requerida por la USTIC así como enlace a su espacio donde pueden descargarse plantillas y formularios que pudieran ser requeridos. En la creación aparecen los mismos campos que en una tarea general con tres diferencias:

- - No aparece el campo área Tic que es informado automáticamente con el valor "Seguridad"
  - Aparecen una serie de preguntas y, en función de su respuesta, el comportamiento del flujo de la tarea es diferente. Las detallamos a continuación
  - Si la tarea de seguridad viene con la aprobación de alguien, pierde cualquier prioridad y será atendida por la USTIC cuando queden recursos disponibles para la misma. Si una tarea se crea y sigue su curso habitual pero en cualquier momento se registra que está autorizada, pasará a ese estado "latente" denominado "Pdte. revisión" y será atendida cuando sea posible.

Las preguntas que se hacen en la creación son:

¿Proyecto de nueva implantación?

- Respuesta Sí

Se solicita contestar otras dos preguntas y aportar la documentación pertinente:

¿Dispone de acuerdo de encargado de tratamiento de datos en el contrato?

¿Dispone de certificación de seguridad del sistema?

Independientemente de estas respuestas, la tarea se creará y cualquier miembro de la USTIC podrá asignársela. Podrá pedir información y documentación al responsable del proyecto. Una vez finalizada la evaluación del proyecto, será el responsable del mismo quien indique si acepta o no el resultado de la misma.

- Respuesta No

Se solicita contestar una serie de cuatro preguntas, de manera que si la contestación de alguna de ellas es Sí, el proceso será el mismo que en el caso anterior.

Si todas las preguntas tienen como respuesta No, la tarea de seguridad de cerrará directamente y el proyecto quedará registrado con la Revisión seguridad informada a Sí

Expedientes

Son tareas que tienen el mismo flujo que una tarea general con la diferencia de que cuando se crean se asignan a un grupo, constituido por usuarios que forman la unidad de contratación de la provincia correspondiente. Cada uno de los miembros de ese grupo puede asignarse la tarea hasta completarla.

La información necesaria para poder crear una tarea de este tipo es la misma que para una tarea general a la que se añade la posibilidad de indicar dentro del equipo provincial quién es el técnico redactor del expediente

Tabla de estados y acciones

Para acceder al manual JIRA que detalla los estados, acciones y roles que pueden actuar en cada punto del flujo de estos tipos de tareas, pulsa aquí.

Control y seguimiento del proyecto

El seguimiento y control del proyecto se realiza en base al control de las tareas del mismo. A su vez, el espacio del proyecto sirve como punto de control tanto de la documentación como del seguimiento que puede hacerse a través del mismo, independientemente del tipo de plantilla que se use:

Hoja de ruta: puede actualizarse para tener un roadmap a alto nivel de la planificación del proyecto a corto-medio plazo.
Sección central en la que pueden distinguirse tres subsecciones:
- Miscelánea: donde puede recogerse cualquier documentación que sea necesaria para el proyecto
- Información relevante donde se distinguen:
  - Datos básicos: donde se recogen todos los datos identificativos del proyecto y que como hemos comentado no deben cambiarse por edición de esa página
  - Resumen ejecutivo o Informes de seguimiento, donde podrá crearse una entrada cada vez que se quiera recoger el avance del proyecto
  - Actas del proyecto, donde podrán recogerse las actas y tener siempre un informe de las tareas de las diferentes actas que continúan abiertas
Actividad en vuelo: aparecerá una relación de aquellas tareas que están aún sin cerrar
Repositorio documental, por si fuera necesario adjuntar algún archivo

De esta forma, teniendo enlazados el espacio y el proyecto se puede hacer un control y seguimiento del proyecto. Hay que tener en cuenta que todo lo relacionado con un proyecto sólo lo verán los proveedores que hayan sido incluidos en el mismo.

Ayuda

Accede al espacio de Ayuda Jira/Confluence aquí.

Objeto

Permitir la gestión de los proyectos de cualquier área de la STIC (sea provincial o centralizada), entendiendo como proyecto el conjunto de actividades que se hacen para, en un tiempo definido, conseguir un objetivo. Dentro de estas actividades se engloban tanto las propias tareas de ejecución del proyecto como todas las de gestión para controlar que se siguen unos objetivos de calidad, de esfuerzo y de tiempo.

Alcance

Este proceso tiene como alcance cualquier proyecto gestionado por un área de la STIC y ejecutado tanto por integrantes del propio área como de proveedores externos.

Actividades del proceso

Alta del proyecto

El primer paso es proceder al alta del proyecto, identificando aquellos datos que van a ser necesarios para gestionarlo correctamente. Para dar de alta un proyecto en la herramienta de gestión corporativa, debe solicitarse creando una solicitud aquí indicando el nombre y la clave del mismo. La clave debe tener una serie de restricciones impuestas por la propia herramienta, aunque se recomienda que sea lo más descriptiva posible para poder identificar fácilmente las tareas del proyecto. Las restricciones referidas son:

Debe tener como máximo 9 caracteres
No debe empezar por un número
Todo deben ser mayúsculas
No debe contener caracteres raros ni guiones

El peticionario deberá indicar el área de SSCC o el nodo provincial para el que solicita el proyecto. Este dato es fundamental porque indicará la categoría que tiene el proyecto en la herramienta corporativa. Además, es también importante que indique si el proveedor del proyecto debe tener usuario en la herramienta.

Completar propiedades del proyecto

Una vez que el proyecto está dado de alta en la herramienta, es necesario seguir informando todos los datos que aun son necesarios. Esta actividad es llevada a cabo por los Coordinadores (pueden ser más de uno, se incluirán en el grupo gestores-propiedades) de cada área, y esos datos en la herramienta son llamados "propiedades" del proyecto

Descripción: breve indicación del objetivo principal del proyecto.

Promotor del proyecto: opcionalmente puede indicarse quién promociona el proyecto. Puede ser o no miembro del equipo provincial o de la propia STIC.

Responsable del proyecto: idem a la propiedad anterior. Es fundamental que esté informado en el caso en que se creen tareas con validación, ya que será el encargado de validar el trabajo

Área TIC: las áreas TIC definidas son:

Desarrollo
Sistemas
Puesto usuario
I+D+i
Gestión
Seguridad

Cada área centralizada o nodo provincial podrá decidir si quiere o no usar todas las áreas TIC definidas. Además, podrán establecer una diferentes grupo de proyectos para cada una de esas áreas. Por ejemplo, podrían considerarse dentro del área de desarrollo los proyectos .net, los de explotación de datos, etc.

Grupos de proyectos

Centros de gestión: desplegable en el que aparecen los centros de gestión de cada área o nodo provincial. Al igual que las áreas TIC y los grupos de proyectos se configuran para cada categoría, es decir, son definidos por cada área centralizada/nodo provincial.

Prioridad

Estado

Usuarios de terceros que participan en el proyecto: usuarios con licencia en la herramienta que van a tener permiso para interactuar en el proyecto. Es importante tener en cuenta que:

todos los usuarios que se muestran como terceros visualizan el proyecto, pero sólo aquellos que son seleccionados son los posibles asignados de las tareas.
si la empresa de soporte provincial participa como proveedor, hay que indicar si tiene o no visibilidad en otras tareas que no sean de soporte provincial.

Nombre empresa proveedora

Nombre persona de referencia proveedor

Teléfono proveedor

Correo electrónico proveedor

Prioritario Subdirección: Indicar si el proyecto es o no prioritario para la Subdirección

Tipo de plantilla: indica la posibilidad de la plantilla que se crea para gestionar la documentación y el conocimiento asociado al proyecto, Hay dos posibilidades: simple y compleja

Creación de espacio para el proyecto

Una vez que se han indicado las propiedades necesarias para comenzar la gestión del proyecto, es necesario crear el espacio en la herramienta de gestión del conocimiento donde muchos de los datos se informarán directamente con lo registrado anteriormente y podrán completar información importante para la gestión del proyecto. Como hemos indicado en las propiedades del proyecto, las plantillas pueden ser simples o complejas.

La estructura creada para cada espacio de un proyecto si se elige la plantilla compleja contiene:

Hoja de ruta: Incluye el horizonte temporal estimado del proyecto y posteriormente se podrá registrar el real, así como una planificación a alto nivel que debe ir actualizándose a lo largo del ciclo de vida del proyecto

Descripción del proyecto: consiste en incluir una breve descripción en la que se indique para qué sirve el proyecto y la justificación que lleva a su creación.

Objetivos y alcance

Estado del proyecto: se definen cuatro posibles estados:

En estudio: el proyecto aún no ha comenzado y puede ser que nunca llegue a ejecutarse
En cartera: el proyecto está ya aprobado pero aún no ha comenzado a ejecutarse
En ejecución: como su nombre indica, el proyecto se está ejecutando
Paralizado: el proyecto se ha paralizado por alguna razón bloqueante y se reanudará, es decir, pasará de nuevo a ejecución una vez que se haya solventado el motivo de bloqueo
Cerrado: el proyecto ha llegado a su fin porque o bien porque ha acabado su ejecución o porque desde la fase de estudio se decidió no abordarlo