Proceso: Gestión de Proyectos


Objetivo

Permitir la gestión de los proyectos de cualquier área de la DGSIC (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 DGSIC 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.

Así mismo, es fundamental indicar quién va a ser el Responsable del proyecto. Tendrá un papel fundamental a la hora de indicar las propiedades y la estructura tanto del proyecto como de su espacio asociado.

Otros datos imprescindibles en el alta de un proyecto son:

  • Si es provincial, el área STIC (SISTEMAS, PUESTO USUARIO, IMPLANTACIÓN/PROYECTOS, GESTIÓN, SEGURIDAD, I+d+i) y el grupo de proyectos dentro de cada área STIC. Cada provincia tiene clasificados los grupos de proyectos dentro de sus diferentes áreas TIC. En los espacios provinciales puede verse la clasificación que tiene cada una.
  • Si es centralizado, y pertenece al área SCSD, hay que indicar el área de negocio a la que pertenece y la línea de proyectos. Cada área de negocio tiene definidas líneas de proyecto.
  • Usuarios que participan en el proyecto. Hay que tener en cuenta:
    • Los usuarios que participan lo hacen siempre como proveedores, ya que todo el personal perteneciente a la DGSIC y a la oficina técnica de proyectos ya participan por defecto. En el caso de que se trate de proyectos provinciales de las áreas Implantación/proyectos o I+D+i interviene siempre el proveedor de la Oficina de Interoperabilidad, ya que serán los encargados de acometer las tareas de integración. Hay que tener en cuenta que los proveedores acceden a las herramientas de gestión de proyectos y de conocimiento con usuarios genéricos, no nominales.
    • 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. En el caso de tener visibilidad, la tendrá también en el espacio asociado al proyecto.

Completar propiedades del proyecto. Responsable de 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 el Responsable de 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.


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

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. En el momento en que se crea el esapcio de CONFLUENCE, quedará enlazado al proyecto medinate la misma clave.

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.

Además, existen páginas dentro de esa sección para las lecciones aprendidas, los resúmenes ejecutivos y las actas del proyecto. Cabe mencionar los aparatados de Sistemas e Infraestructura y de Gestión del proyecto que contienen páginas donde debe incluirse la información oportuna del proyecto

Sistemas e infraestructura

  • 00.- Instalación y Configuración
  • 01.- Documentación Infraestructura
  • 02.- Usuarios Administradores
  • 03.- Seguridad: VPN, Firewall, Antivirus y Sonda
  • 04.- Sistema de Respaldo y Monitorización
  • 05.- Redes y Comunicaciones
  • 06.- Contactos y Soporte
  • 10.- Correos y Notas


Gestión del proyecto

  • 00.- Check list de Gestión Proyecto
  • 01.- Informe Seguridad USTIC
  • 02.- Integración
  • 03.- Manuales instalación y usuario
  • 04.- Plan de Contingencias
  • 05.- Correos


Contratos y expedientes

Se define a continuación los contratos y expedientes asociados al proyecto, si están disponibles y sus documentos.

Puesta en marcha del proyecto

El Responsable del proyecto tendrá que hacer las labores propias de puesta en marcha del proyecto:


  • Establecer estructura para el proyecto/espacio:

Es importante saber cómo van a clasificarse  las tareas:

    • Mediante componentes: bloques temáticos o funcionales en los que puede descomponerse el proyecto. Deben ser definido y creados por el Responsable de proyecto, de manera que cada tarea debe pertenecer a uno o a n bloques. Las posibles subtareas de esa tarea heredarán por defecto los de la padre, auqnue pueden cambiarse.
    • Mediante etiquetas: las etiquetas, si bien son útiles y fáciles de manejar, son comunes a todo el sistema. Es buena práctica establecer las etiquetas que van a usarse en el proyecto por todos los participantes en el mismo.
    • Mediante tipos de tareas: lo mismo que las tareas de soporte provincial tienen establecisos tipos y subtipos de tareas en base a la naturaleza de las mismaa, pueden establecerse tipos de tareas para cada proyecto. Por ejemplo, en el caso de los proyectos de áreas centralizadas, todos los proyectos tiene tareas/subtareas generales y con validación de tipo hito, riesgo, problema o decisión.
    • Establecer temáticas grandes en el proyecto que conllevarán tareas. Estas temáticas deberán ser definidas como épicas.
  • Hacer el primer resumen ejecutivo para explicar porqué la necesidad de acometer el proyecto:
    • Business case preliminar que lo origina
    • Alcance
    • Recursos necesarios
    • Motivos por los que e acomete el proyecto
    • Valor que aportará a la STIC
    • Plazo de ejecución estimado.

Ejecución del proyecto

Una vez que se pone en marcha el proyecto, se comenzarán a crear tareas que irán asociadas con páginas en ele spacio correspondiente. Hya que tener en cuenta que si el proveedor de un determinado proyecto no va a entrar en la herramienta, las tareas deberán estar asignadas a algún integrante del proyecto que se encargue de actualizarlas.

Cualquier tarea puede ser dividida en subtareas con el mismo ciclo de vida o no 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". 


Es importante establecer enlaces entre las diferentes tareas del proyecto, Caben destacar:

  • Enlace de bloqueo, lo que impedirá que la tarea bloqueada camie de estado hasrta que no finalice la bloquente.
  • Enlace de dependencia. Tiene dos ventajas:
    • Todas las tareas dependientes de una se informan en el campo Dependencias.
    • Cuiando acaba una tarea dependiente, aparece un mensaje de alerrta indicando que es posible tener que actualizar la original.


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.

Loading...




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 usuario que la resuelve decidirá quién debe 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, el validador deberá decidir el motivo por el que no acepta la tarea. Puede elegir entre estos tres motivos:

    • No aceptar la tarea porque la solución técnica que se ha llevado a cabo al resolver no es correcta.
    • No aceptar la tarea porque el trabajo o coste incurridos en la mism acon son correctos.
    • No aceptar la tarea tanto porque la solución técnica como los costes no son correctos.

 Además, el validador debe decidir si debe incurirse más trabajo o no tras la no aceptación.

Las tareas que no son aceptadas por el validador pasan a estado NO ACEPTADA.



Si una tarea general o con validación se descompone en subtareas, su estado pasa a ser PDTE. SUBTAREAS, se manera que hasta que dichas subtareas no se cierren, la tarea padre no volverá al estado en el que se habían creado las 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.


Loading...




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 aparecen en proyectos en los que participa el proveedor de Soporte Provincial.
  • No es posible crearle subtareas, aunque pueden ser creadas como subtareas de tareas generales o con validación.
  • Sólo pueden ser creadas por usuarios que pertenezcan al equipo provincial, por el proveedor de Soporte Provincial y por cualquier proveedor que participe en el proyecto (con aprobación previa de alguien del equipo provincial). El proveedor de Soporte Provincial podrá además crear tareas en los proyectos para actividades en horario extendido.


En este tipo de tareas debe especificarse 

    • Quién debe ser el revisor técnico
    • Qué se quiere hacer
    • Fechas orientativas de comienzo y fin de la tarea:
      • Si la tarea se crea por parte del equipo provincial, deberá informar las fechas de inicio y fin deseadas. 
      • Si la tarea se crea por parte del proveedor de soporte provincial, deberá informar las fechas de inicio y fin según la planificación de sus recursos.
    • Área TIC por si no coincide con la del proyecto
    • Centros de gestión, por si no coinciden con los del proyecto
    • Esfuerzo requerido
    • 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, a menos que haya sido creada por un proveedor que participe en el proeycto, caso en el que deberá pasar primero por aprobación por parte del Equipo Provincial antes de pasar a ser calendarizada.

En ese estado, el proveedor podrá solicitar aprobación, sea quien sea el creador de la tarea, asignando la tarea al usuario del equipo provincial que considere, que será normalmente el Responsable de Sistemas, el de Puesto Usuario o el del proyecto concreto en el que se ha creado la tarea.

En el caso en que la tarea la haya creado el equipo provincial, el proveedor revisará las fechas deseadas e informará las fechas de inicio y fin. En caso de que esas fechas no coincidieran con las deseadas se enviará una notificación al solicitante de la tarea indicando este hecho.

  • Si la tarificación es basal, tras poner fechas, la tarea pasa al estado PDTE. COMENZAR RESOLUCIÓN. 
  • Si la tarificación es Valor añadido, al hacer esa acción la tarea pasa a estado CALENDARIZADA donde el Responsable del Contrato aprobará o no la estimación de la tarea. Si no aprueba la estimación, la tarea deberá ser de nuevo estimada por el Proveedor. Una vez aprobada, pasará a estado PDTE. COMENZAR RESOLUCIÓN.

Cuando la tarea está en en ese estado está planificada en fechas y en teoría no deberían modificarse éstas. Ahora bien, en ese estado el Responsable de Sistemas, el de Puesto Usuario o el del proyecto concreto podrán modificar esas fechas consensuándolas con el Proveedor, fundamentalmente porque puede haber cambio en las prioridades y sea necesario una replanificación del trabajo pendiente.

Cuando el Proveedor comienza a resolver la tarea,  puede indicar el técnico o los técnicos que van a hacerse cargo del trabajo. La lista de técnicos del proveedor se configura en la opción "Miembros del proyecto". Es importante indicar los técnico fundamentalmente porque de esta forma garantizamos que si la tarea tiene alguna modificación (se cambia algún campo, se pone un comentario, se edita un comentario, se adjunta un archivo, etc. ) el técnico indicado recibirá una notificación en su correo electrónico.

Cuando el proveedor está resolviendo la tarea pueden darse varios casos:

  • Que el proveedor necesite información de cualquier usuario que participe en el proyecto, con lo que podrá solicitar esa información requerida, quedando la tarea en estado PDTE. INFORMACION asignada al usuario que debe proporcionarla. Una vez proporcionada (accediendo a Completar información), la tarea pasaría de nuevo a estado EN RESOLUCION asignada al Proveedor de Soporte Provincial.
  • Que la tarea se desarrolle como se había planificado. El proveedor incurre el esfuerzo (si es de tarificación basal) o el coste (si es de tarificación valor añadido) y resuelve la tarea. Puede ocurrir que exista una desviación (positiva o negativa) respecto a la fecha fin indicada. El proveedor al resolver debería justificar esa desviación.
  • Que la tarea se bloquee y no pueda seguir su curso hasta que ese motivo que la bloquea desaparezca. En ese caso, la tarea deberá paralizarse e informarse una fecha prevista de reanudación de la misma.
  • Que la tarea cambie las condiciones en las que se había planificado, bien porque pueda haber un cambio de prioridades y que haya algo más urgente o bien porque la tarea se haya complicado más de los previsto. En cualquier caso, el proveedor sabe que no va a poder cumplir con la fecha fin indicada. En estos casos accediendo a la acción Seguimiento podrá indicar en el momento en el que la planificación de la tarea cambia, cuál es la Fecha Fin Actualizada y el grado de avance técnico que lleva n la tarea en ese momento. A partir de ahí será esa fecha la que marque la posible desviación respecto a la fecha real en la que el proveedor resuelva la tarea.
  • Que la tarea tenga que cancelarse por cualquier motivo. Siempre será cancelada por el Responsable del proyecto. En estos casos la tarea 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 asignada al usuario que se ha indicado que sea el revisor técnico, quien 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. Cunado comience a hacerlo pasará de nuevo a EN RESOLUCION, se habrá incrementado un contador de rechazos y, una vez que la haya acabado pase a PDTE. REVISIÓN TÉCNICA de nuevo. Destacar que la fecha que se marca como de resolución de la tarea por parte del proveedor es la fecha en la que ha hecho las correcciones que se le han indicado al no aceptar la solución técnica.
  • Si el revisor técnico acepta la solución, la tarea pasará a estado CERRADA si su tarificación es basal. Si la tarificación es valor añadido pasará a la revisión de costes, donde el Responsable del contrato deberá comparar los costes en HBS incurridos con los registrados en la estimación aprobada de la tarea. En el caso en que no aprobara los costes, la tarea volvería a NO ACEPTADA para que el Proveedor corrigiera los costes. Una vez corregidos, pasaría  de nuevo directamente a que se revisaran los costes por parte del Responsable del contrato.





  • Tareas de seguridad


Las tareas de seguridad se detallan en el proceso de evaluación de seguridad.

Hay que indicar que hay veces en las que ciertas implantaciones no tienen entidad suficiente ni recorrido para ser un proyectos. En estos casos se crean tareas generales o con validación para la implantación y subtareas de seguridad que funcionan como una especie de asesoría para estos casos.


  • 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.



  • Épicas

Son tareas muy grandes que pueden ser descompuestas en otras tareas del mismo o de otro proyecto. Tienen un uso importante en aquellos proyectos que se gestionan de forma ágil porque permiten descomponer esa gran cantidad de trabajo en historias de usuario.



Creación de tareas por lotes

Es posible la creación de tareas generales y tareas de soporte provincial por lotes, especificando en un archivo Excel los datos de las mismas. Puedes ver una guía accediendo  aquí.

Creación de tareas programadas

Para la gestión de proyectos es posible la creación de tareas repetitivas programadas en el tiempo. Puedes ver una guía accediendo  aquí. 

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 relacionada: