¿Qué es la obligación de gestión de proyectos en el desarrollo de sistemas?

El desarrollo de sistemas es un proceso que solo puede avanzar mediante la cooperación mutua entre el usuario que encarga el trabajo y el proveedor que lo acepta.

Los proyectos para desarrollar sistemas de TI utilizados en las empresas rara vez avanzan exactamente según lo planeado o previsto. Más bien, es más común que se enfrenten a una serie de problemas y desafíos, grandes o pequeños, y que avancen superándolos uno por uno. En este contexto, es importante no solo hacer esfuerzos para coordinar el ritmo entre el usuario y el proveedor, sino también gestionar las crisis anticipando situaciones de conflicto.

Desde un punto de vista legal, el primer paso en la gestión de crisis es aclarar qué obligaciones tiene cada parte y qué derechos puede reclamar a la otra. En este artículo, explicaremos principalmente las obligaciones legales que tiene el proveedor en relación con una serie de proyectos, centrándonos en la obligación de gestión de proyectos.

¿Qué es la obligación de gestión de proyectos del proveedor?

Primero, veamos qué implica la obligación de gestión de proyectos del proveedor.

Según los casos judiciales, el contenido de la obligación de gestión de proyectos es el siguiente:

– La obligación de avanzar en el trabajo de desarrollo de acuerdo con el acuerdo, gestionar constantemente el progreso y esforzarse por descubrir factores que obstaculicen el trabajo de desarrollo y tratarlos adecuadamente.

– La obligación de gestionar adecuadamente la participación del usuario en el desarrollo y trabajar con el usuario para asegurar que no se realicen acciones que obstaculicen el trabajo de desarrollo por parte de usuarios que no tienen conocimientos especializados en desarrollo de sistemas.

Esto se refiere a mostrar al usuario los problemas y plazos para los asuntos que requieren toma de decisiones y preocupaciones que deben resolverse, indicar los problemas que surgen cuando la toma de decisiones del usuario se retrasa, aconsejar al usuario para fomentar la toma de decisiones, y si hay solicitudes que no se pueden aceptar debido al progreso del desarrollo, explicar completamente las razones y rechazar las solicitudes del usuario.

De esta manera, el proveedor tiene la obligación de avanzar en el trabajo de desarrollo mientras fomenta la toma de decisiones del usuario y se esfuerza por asegurar el éxito del desarrollo del sistema.

Obligación de cooperación del usuario

Por supuesto, en el desarrollo de sistemas, no es el caso de que el proveedor asuma unilateralmente todas las obligaciones. Después de todo, dado que es un sistema de TI que se utilizará en la empresa del cliente, el proyecto de desarrollo del sistema no debería ser “asunto de otros” para el cliente.

Aunque se utilicen expertos externos confiando en su capacidad técnica y organizativa para desarrollar sistemas, la gobernanza interna debería ser aplicable. Sin esfuerzo para aprovechar la habilidad de los expertos externos, es imposible entregar el trabajo necesario como si fuera asunto de otros. En este sentido, el usuario también tiene la obligación de cooperar en el desarrollo del sistema.

Las obligaciones de cooperación que el usuario debe cumplir incluyen lo siguiente:

　① El usuario realiza un análisis de riesgos de manera proactiva, coordina adecuadamente las opiniones internas y unifica las opiniones antes de transmitir las solicitudes al proveedor.

　② Verificar los productos entregables.

　③ Responder a las solicitudes de cooperación del proveedor.

Se espera que el usuario comunique claramente al proveedor las funciones que requiere el sistema y coopere activamente en el desarrollo.

La gestión de proyectos no es fácil

El hecho de que los sistemas de TI estén compuestos por la combinación de pequeños componentes puede ser difícil de percibir para los usuarios que solo ven la pantalla. Sin embargo, es muy importante al considerar la dificultad de gestionar un proyecto de desarrollo de sistemas. Precisamente porque los sistemas de TI son así, se requiere del proveedor una atención meticulosa y, al mismo tiempo, la capacidad de organizar la imagen general de manera concisa y la capacidad de tener una visión general.

La dificultad del trabajo se encuentra en lugares que no se pueden imaginar solo mirando la pantalla, y también es la razón por la que los proyectos “se incendian” si se cambia el punto de vista. Primero, es importante entender estos puntos y saber que “gestionar un proyecto para desarrollar un sistema de TI no es una tarea fácil” será la premisa básica para aprender sobre la gestión de riesgos del proyecto.

Lo que puede suceder en caso de incumplimiento de las obligaciones de gestión de proyectos

Entonces, ¿qué sucede específicamente cuando hay una violación de las obligaciones de gestión de proyectos?

No hay ninguna disposición clara que diga “Estas son las obligaciones de gestión de proyectos”.

Sin embargo, a partir de los precedentes judiciales, podemos deducir una postura bastante consistente sobre lo que puede hacer un usuario si el proveedor ha incumplido sus obligaciones.

Si el proveedor ha incumplido sus obligaciones, el usuario puede reclamar al proveedor indemnización por daños y perjuicios o la rescisión del contrato. Sin embargo, si el usuario también tiene un problema, se puede determinar que el proveedor no es responsable, o se puede compensar la negligencia, lo que puede reducir la cantidad de indemnización por daños y perjuicios.

Por otro lado, si el usuario ha incumplido su obligación de cooperar, el proveedor puede reclamar al usuario una cantidad equivalente a la remuneración, basándose en el riesgo asumido (Artículo 536, párrafo 2, del Código Civil japonés) o el incumplimiento de la obligación, si el trabajo no se ha completado como resultado.

Ejemplos de casos judiciales que demuestran la obligación de la gestión de proyectos

Existen varios casos judiciales representativos que explican la obligación de la gestión de proyectos.

El caso que se detalla a continuación se desarrolló hasta llegar a juicio debido a retrasos en la fecha de entrega y a que el proveedor solicitó un aumento en la estimación inicial en el desarrollo de sistemas. Podría ser un ejemplo típico de un “proyecto en llamas”, donde la disputa se prolonga hasta llegar a juicio sobre cómo dividir la responsabilidad entre el usuario y el proveedor.

El acusado, como especialista en desarrollo de sistemas, tenía la obligación de completar el sistema informático del caso en cuestión antes de la fecha de entrega acordada, de acuerdo con el contrato de desarrollo del sistema informático y la propuesta del sistema informático, basándose en su alto nivel de conocimiento y experiencia especializada. Por lo tanto, el acusado debería entender que tiene la obligación de avanzar en el trabajo de desarrollo de acuerdo con los procedimientos de desarrollo, métodos de desarrollo, procesos de trabajo, etc., presentados en el contrato de desarrollo del sistema informático y la propuesta del sistema informático, gestionar constantemente el progreso, esforzarse por descubrir factores que obstaculicen el trabajo de desarrollo y tratar adecuadamente con ellos. Además, dado que el desarrollo del sistema se lleva a cabo en consulta con el cliente, el acusado debería haber tenido la obligación de gestionar adecuadamente la participación del demandante, la Asociación Nacional de Seguros de Salud, en el desarrollo del sistema y de influir en el demandante, que no tiene conocimientos especializados en desarrollo de sistemas, para evitar cualquier acción que obstaculice el trabajo de desarrollo (en adelante, estas obligaciones se denominarán “tareas de gestión de proyectos”).

Sentencia del Tribunal de Distrito de Tokio, 10 de marzo de 2004 (Año 16 de Heisei)

No es importante interpretar el lenguaje detallado o la complicada secuencia de eventos del caso a partir del resumen de la sentencia anterior. Lo más importante es que se utiliza la frase “obligación de gestión de proyectos”. Aunque no hay una disposición explícita, se puede ver la actitud de establecer una guía para dividir la responsabilidad legal bajo la dirección del tribunal.

Resumamos y organicemos el contenido de la sentencia anterior de manera sencilla. La “obligación de gestión de proyectos” mencionada aquí es:

• Avanzar en el trabajo real de acuerdo con el plan previo (procedimientos de desarrollo, métodos, procesos, etc.)
• Realizar la gestión del progreso para ver si el trabajo real está avanzando sin problemas
• Si hay algún “factor de obstrucción” que impide que el trabajo real avance sin problemas, descubrirlo y tomar medidas adecuadas a medida que surja

Además, en relación con los tres puntos anteriores,

• No se trata solo de esfuerzos de autoayuda por parte del proveedor, sino también de esfuerzos de comunicación, como solicitar la cooperación necesaria del usuario cuando sea necesario

Podemos organizarlo como un término general para estos.

Además, el desarrollo del sistema es en la mayoría de los casos un contrato de mandato o un contrato de obra. Y el contrato de mandato es, en términos simples, un contrato para “realizar un trabajo con la precisión correspondiente a la remuneración obtenida”, por lo que la obligación de gestión de proyectos también puede ser considerada como un concepto que se absorbe en la “precisión, etc.” que se debe lograr.

Aunque es un tema de debate, se cree que la obligación de gestión de proyectos también puede surgir en el caso de un contrato de obra, que es un contrato para “hacer lo que se pide”. La razón es, como ya se mencionó, que la gestión del proyecto es importante en el desarrollo del sistema, ya sea un contrato de mandato o un contrato de obra, y se cree que el proveedor debe hacerlo.

Ejemplos de casos judiciales que demuestran la obligación de gestión de proyectos incluso antes de la firma del contrato

Además, se considera que la obligación de gestión de proyectos puede ser impuesta incluso en las etapas previas a la firma del contrato. El caso judicial citado a continuación demuestra que el proveedor tiene una obligación de gestión de proyectos incluso en la etapa previa al contrato, es decir, cuando se están presentando diversas propuestas y planes.

El caso a continuación se refiere a un proyecto que se estancó a mitad de camino, y se discutió si se podía reconocer la obligación de gestión de proyectos debido a deficiencias en la planificación y las propuestas en la etapa previa a la firma del contrato, y en las estimaciones y explicaciones al usuario en la etapa de propuesta. En general, dado que las tareas de planificación y propuesta son previas a la firma del contrato, se planteó la cuestión de si es legalmente posible reconocer tales obligaciones, pero el tribunal las reconoció.

La forma de pensar sobre la obligación de gestión de proyectos en el caso judicial citado anteriormente también se aplica a las etapas previas a la formación del contrato, como se puede ver a continuación.

En la etapa de planificación y propuesta, se definen los grandes lineamientos de los asuntos relacionados con la concepción del proyecto y su viabilidad, como la definición de los objetivos del proyecto, los costos de desarrollo, el alcance del desarrollo y la duración del desarrollo, y también se determinan los riesgos asociados con el proyecto. Por lo tanto, la planificación y análisis de riesgos del proyecto que se requiere del proveedor en la etapa de planificación y propuesta es esencial para llevar a cabo el desarrollo del sistema. Por lo tanto, el proveedor debe considerar y verificar la funcionalidad del sistema que propone, el grado de satisfacción de las necesidades del usuario, el método de desarrollo del sistema, la estructura de desarrollo después de recibir el pedido, etc., incluso en la etapa de planificación y propuesta, y debe explicar al usuario los riesgos previstos. Esta obligación del proveedor de verificar y explicar se puede considerar como una obligación bajo la ley de delitos civiles basada en el principio de buena fe en el proceso de negociación hacia la firma del contrato, y se puede decir que el apelante, como proveedor, tiene tal obligación (la obligación de gestión de proyectos en esta etapa).

Sentencia del Tribunal Superior de Tokio, 26 de septiembre de 2013 (Año 25 de la era Heisei)

Además, la idea de que hay ciertas obligaciones legales hacia la otra parte incluso en las etapas previas a la firma del contrato no se limita a los proyectos de TI, sino que ha existido desde siempre en todas las transacciones comerciales y negociaciones en las que intervienen las leyes.

Por lo general, cuanto más grande es la transacción, más largo es el proceso de “acercamiento” hasta llegar a la meta del contrato. Incluso en ese proceso, es bien sabido, al menos moralmente, que se debe ser honesto con la otra parte. En pocas palabras, este tipo de historia no se limita a meros sentimientos morales emocionales, sino que también tiene un significado legal. (Se cita el texto de la ley a continuación. El subrayado ha sido añadido por el autor.)

Artículo 1, párrafo 2 del Código Civil japonés
El ejercicio de los derechos y el cumplimiento de las obligaciones deben realizarse con buena fe y honestidad.

La palabra clave “principio de buena fe” en la sentencia resume el contenido anterior de manera concisa.

Además, los casos judiciales que hemos presentado en este artículo también tienen un aspecto de “guía para trazar la línea entre la obligación de cooperación del usuario y la obligación de gestión de proyectos del proveedor”.

Resumen: Consulta a un abogado en caso de problemas relacionados con el incumplimiento de las obligaciones de gestión de proyectos

En este artículo, hemos intentado organizar de manera general lo que se entiende por obligaciones de gestión de proyectos en el desarrollo de sistemas. El desarrollo de sistemas viene con varios desafíos y problemas, pero lo que parece ser crucial cuando te enfrentas a tales situaciones es la ‘base’ que subyace en cualquier escenario de conflicto. Sin duda, habrá infinitas variaciones en la forma en que se presentan las situaciones irregulares individuales.

Sin embargo, la importancia de preguntar “¿Quién asumió cuánto de la obligación legal en primer lugar?” frente a tales situaciones tiene una cierta universalidad que trasciende la individualidad del caso en sí.

En lugar de limitarse a la resolución de problemas ad hoc, parece que las pistas para buscar soluciones a través de la segmentación constructiva de los desafíos también se encuentran en la ley y en los precedentes judiciales.

Si surge un problema relacionado con el incumplimiento de las obligaciones de gestión de proyectos, consulta a un abogado de inmediato.