Cliente y Proveedor de Software, pulso de expectativas, Peritaje de Gestión o Management

Contrato y desacuerdo

En las relaciones mercantiles entre los Clientes y sus Proveedores de Software se establecen los términos del proyecto o servicio por medio del contrato o/y del pedido inicial que, normalmente, suelen dejar con mediana claridad definidos tanto el coste como  las fechas de necesidad.

Sin embargo,  ya no se puede decir lo mismo en relación con el alcance o el objeto del contrato, que si bien, por supuesto se define, en ocasiones se realiza a groso modo o de forma generalista siendo necesario, a posteriori, acotar en su propia definición y límites para conocer qué se espera como entregable y hasta dónde llegan los compromisos contractuales de cada una de las partes.

En muchas ocasiones, este efecto de falta de definición es debido a que, tanto el tiempo como el coste suelen estar delimitados por parámetros externos y exógenos al producto que giran en función de los intereses, objetivos y presupuestos asignados. No obstante, éste no es el caso del alcance que siempre está definido por parámetros internos o endógenos que vienen definido por factores tales como: las prestaciones, las necesidades o funcionalidades, los procesos, el escenario, la infraestructura, la organización, la información a gestionar, etc., todos ellos elementos de alta complejidad que son necesarios analizar de modo profundo y exhaustivo.

El alcance no se suele delimitar claramente en la fase inicial por simple conveniencia de ambos actores, cliente y proveedor, el cliente porque en ocasiones no ha tenido suficiente tiempo como para poder definir en toda su extensión las funcionalidades o prestaciones que necesita del software que está encargando en el proyecto, por parte del proveedor, porque lo importante es conseguir el contrato y, más adelante, ya se verá cómo gestionar el alcance si éste finalmente se encontrase fuera de los parámetros utilizados como premisa en la estimación inicial que ha llevado a cabo el equipo del proveedor.

Propuesta y Contrato

Ante esta situación de indeterminación del alcance es normal que se produzca a lo largo del proceso, al menos, dos niveles de degradación del alcance del proyecto y que a continuación se exponen.

Primera Degradación

La dificultad de definir el alcance correctamente en su extensión o bien la definición tardía del mismo cuando ya se han aceptado tanto el coste como las fechas de liberación del producto software acarrean dos problemas principales:

1) Que el concepto del alcance no esté bien acotado en el contrato o en los documentos auxiliares con lo que el cliente y el proveedor poseen una visión totalmente diferenciada del propio alcance.

2) Que aún cuando el alcance se encuentre bien acotado, no esté lo suficientemente definido o, estándolo, se preste a la interpretación, en ambos casos, las expectativas de hasta dónde se ha de llegar en la solución a entregar es diferente para el cliente y el proveedor.

Es evidente que dada la situación, tarde o temprano, surgirá la controversia evidenciándose el conflicto presentándose uno de los siguientes síntomas o situaciones dependiendo únicamente del punto de vista del actor desde el cual se analice el conflicto:

a) Visión Proveedor: El proveedor está en la creencia que ya ha terminado, que ha cumplido con lo comprometido y, por ello, no cree necesario continuar destinando recursos o medios porque el trabajo está finalizado, en todo caso, las pretensiones del cliente son debidas a una situación en la que aparentemente se está pidiendo cosas fuera del alcance.

b) Visión Cliente: Lo entregado por el proveedor no se ajusta a las necesidades que el cliente piensa que ha definido claramente y que el proveedor entiende que ha interpretado incorrectamente o bien está incumpliendo intencionadamente lo comprometido, por lo que se genera una situación en la que el cliente posee la sensación de que se le está entregando un producto pobre, que no cumple con lo esperado y que el proveedor está escatimando parte del proyecto o de los trabajos para generar un ahorro en base a la reducción de sus costes.

Ciclo de Expectativas coche amarillo

Segunda Degradación

La segunda degradación se produce cuando el proveedor del software a lo largo del proyecto ha visto que se ha sobrepasado su umbral presupuestario o está apreciando que la marcha del proyecto no se corresponde con las expectativas de beneficio esperado y es necesario comenzar a corregir las desviaciones que se están produciendo.

A esta situación se puede llegar por multitud de factores y, en ocasiones, concurren varios de ellos en mayor o menor medida en la situación conflictiva en concreto, sin ánimo de ser exhaustivos ni completos a continuación se enumeran los factores más comunes que se suelen presentar:

– Deficiente o incorrecta estimación inicial de los costes, esfuerzos o medios. Falta de presupuesto para afrontar los compromisos, desviación económica del proyecto.

– Exceso de errores, ineficiencias, trabajos desempeñados de forma incorrecta o deficiente. Creciente número de incidencias técnicas y/o funcionales.

– Prolongación de las actividades en el tiempo, tiempos muertos, falta de cierres o aprobaciones parciales, excesivos puntos o frentes  abiertos.

– Mala coordinación y planificación de las actividades, solape de etapas,  sobrepasado de las fechas previstas, falta de medios y recursos en los momentos necesarios, falta de toma de decisiones.

– Continuadas modificaciones del alcance o definición (concreción, matización o especialización) del alcance realizándose sobre la marcha conforme avanza el proyecto.  

– Etc.

Esta segunda degradación hace que el proveedor entregue un producto totalmente diferente al esperado por el cliente e incluso al concebido por el propio proveedor inicialmente pero en este último caso es consciente de todo aquello que no está cubriendo o entregando pero se ve forzado por la situación del proyecto.

En definitiva, tras los dos niveles de degradación planteados, al cliente final se le presenta un producto que no se ajusta a lo inicialmente previsto y esperado por él, es decir, por lo que el cliente supone que está pagando, aunque en algunos casos sí fuera este producto el concebido inicialmente por el proveedor.

Alcanzado este punto, tanto para plantear una situación de negociación y de acuerdo entre las dos partes, cliente y proveedor, como para prepararse para un posible litigio en caso de desacuerdo entre los mismos, es necesario la intervención de un perito y la realización de un Peritaje de Gestión o Management que refuerce el contenido con los resultados que se han llevado a cabo, a nivel de concepto (funcional), de realización (lo entregado o ejecutado) y a nivel técnico (la calidad).

Los letrados van a plantear la defensa de cada una de las partes y sus posturas desde el punto de vista de las obligaciones contractuales, entre ellas, lo comprometido según los parámetros de coste, plazos, alcance y algún otro factor adicional como pudieran ser la calidad, el cumplimiento de estándares, la seguridad, etc., en base al redactado del contrato, las especificaciones y/o las buenas prácticas.

No obstante, para poder discernir el grado de cumplimiento dentro de los cánones normales se ha de acudir al perito de Gestión o Management para determinar hasta qué grado se ha cumplido con lo comprometido, cuál ha sido el nivel de cambios sufrido del contrato y/o especificaciones a lo largo de la evolución del proyecto y cuál es el estado de lo entregado, así como determinar aquello que se ha realizado fuera del alcance o cuál es la parte faltante o deficiente.

Con toda esta información recopilada acerca de la vida y desarrollo del proyecto se podrá determinar, con la objetividad que debe proporcionar el perito como tercero ajeno al conflicto (aunque el mismo sea de parte), el grado de cumplimiento o de incumplimiento de las obligaciones contractuales de cada una de las partes y hasta qué punto puede ser reivindicable, reclamable o compensable la exigencia del pago de lo comprometido y entregado o la devolución de lo aportado.

En mi opinión, como perito de Gestión o Management considero que es una gran imprudencia y temeridad plantear un conflicto contractual de esta índole, sin realizar un análisis objetivo de la situación que proporcione la visión de los puntos fuertes y débiles así como, llegado el caso, muestre los argumentos que refuercen o debiliten la postura propia que permita establecer una estrategia clara de negociación o el propio procedimiento judicial.

Y finalmente, llegado el caso, la realización de un Informe Pericial de gestión, funcional, técnico y económico para reclamar aquello que se considere de justicia.

Acerca de Rafael_L_R

Perito Judicial Informático y Director de Organización, Proyectos y Servicios TICs
Esta entrada fue publicada en Buenas Prácticas, Divulgación, Gestión y Management, Opinión, Peritaje Informático o Tecnológico, Seguridad Informática, Todos y etiquetada , , , , , . Guarda el enlace permanente.