Andares de un proyecto

El valor de los entregables intermedios

Posted on Septiembre 14th, 2012 in General by admin

En la administración de proyectos nos encontramos con diferentes situaciones que nos llevan a tomar decisiones muy relevantes. Mas allá de las decisiones tradicionales a las que nos enfrentamos, como lo son la elección de la metodología que usaremos para administrar el proyecto, la cantidad adecuada de recursos a dedicar en la construcción de entregables y la frecuencia de revisiones de calidad que haremos, existen algunas decisiones no tan comunes que también tenemos que hacer.

En algunos casos los proyectos son complejos y requieren la adquisición o renta de artefactos que  harán posible la construcción de los entregables finales del proyecto. En estos casos necesitamos planear concienzudamente para determinar qué se necesita construir o adquirir aún cuando el cliente no lo haya solicitado, y aún lograr que el proyecto resulte rentable dentro de un plazo razonable.

En una ocasión administré un proyecto en el que el cliente tenía una base de datos con información de direcciones postales de sus propios clientes, pero que no estaba estandarizada, es decir, algunos clientes que vivían en la misma colonia tenían capturados sus datos, por ejemplo, como colonia ‘Santa Martha’ mientras otros clientes de la misma colonia tenían capturado ‘Sta. Martha’ (abreviado) y otros ’Santa Marta’ (sin ‘h’ intermedia), etc.

El cliente decidió que estandarizaría su información basándose en el sistema nacional de direcciones, definiendo el nombre de la colonia tal como el Servicio Postal Mexicano (Sepomex) lo definiera. Sepomex nos envió su base de datos de colonias y nosotros iniciamos el proyecto.

aprietos.jpgDurante la planeación no tardamos en darnos cuenta que más que un proyecto, estaríamos realizando un trabajo operacional (repetitivo) que requeriría varias personas capturando información y homologando las colonias de toda la base de datos d  e los clientes. Pensamos en facilitar esta tarea desarrollando un sistema que identificara patrones encontrando la mejor opción para ese nombre de colonia, por ejemplo, si algún cliente tuviera la colonia ‘Sta. Martha’, que el sistema lo sustituyera por ‘Santa Martha’. Esta idea, aunque buena, estaba incompleta porque tendríamos que estar alimentando al sistema con todas las posibles opciones para cada colonia. Además la información contenía errores tipográficos (mejor conocidos como ‘error de dedo’ al momento de capturar), como por ejemplo: ‘Santa Narta’ (’N’ en lugar de ‘M’) o ‘Sta Marta’ (sin punto en la abreviatura y sin ‘h’). la cantidad de opciones era ilimitada y, si bien nuestro sistema cubriría la mayoría de los casos, existía la necesidad de dar una segunda y probablemente una tercera revisión general a todos los datos para asegurarnos de que todos estuvieran bien clasificados.

Otra idea que se nos ocurrió fue el hacer un sistema que mostrara del lado izquierdo de la pantalla el dato original proveniente de la base de datos del cliente y del lado derecho de la pantalla la información proveniente de Sepomex. El interfaz de usuario cargaría la información del cliente y realizaría la búsqueda dentro de la base de datos de Sepomex encontrando las mejores opciones dentro de esta base de datos y desplegándolas del lado derecho. El usuario elegiría manualmente la opción que mejor se adaptara y almacenaría el registro con la información elegida.

Realizamos el sistema e hicimos pruebas y determinamos que una combinación de las dos propuestas anteriores era la mejor opción (un proceso automático para aquellos patrones más comunes de error (como ‘Sta. Martha’) y el proceso semi-manual en el que el usuario elegiría la mejor opción de las que se le presentaran).

Hasta este punto he explicado mucho acerca del proyecto, pero desglosando, ¿cual era el entregable real para el cliente? Al cliente no le interesaba lo que hiciéramos para alcanzar el objetivo para el que nos contrató, que era el ‘limpiar’ su base de datos y tener consolidada toda su información.

Así que dentro de nuestra planeación tuvimos que considerar la elaboración de un par de sistemas intermedios para alcanzar el objetivo con mayor rapidez y precisión. Este sistema fue cotizado, pero eventualmente nosotros fuimos los usuarios u operarios del mismo y no el cliente.

¿Es ético cobrar por esto? Definitivamente. El cliente nos contrató por nuestra habilidad para resolver los problemas… sus problemas, y si esto implica viajar, construir, rentar, destruir o cualquier otra actividad ética, entonces es válido.

En una ocasión vi un programa de televisión en que para la construcción de un mega puente se requirió el uso de una grúa que no existía en el mundo. El Líder del Proyecto buscó en los diferentes países y nunca encontró una grúa con las dimensiones que el necesitaba, así que tuvieron que construir una versión muy básica de grúa con los materiales que tenían y finalmente la utilizaron para la construcción del puente. ¿Qué pasó con la grúa después de terminado el proyecto? La desmontaron y vendieron por partes (como material).

PMOEn lo personal creo que podrían haber vendido el prototipo a una empresa dedicada a la construcción de grúas y satisfacer esa necesidad del mercado, pero supongo que no sería demasiado rentable dado que no todos los fines de semana se construye un mega puente en el mundo, pero el tema aquí es que es necesario considerar el potencial de los entregables intermedios y, finalmente, considerar su costo.

En muchas ocasiones no cotizamos los entregables intermedios y salimos perdiendo. Hay que prever estos gastos y planear un destino para ellos, como en el ejemplo anterior, si se requiere de construir una grúa muy específica, se deberá planear su venta ya sea completa o por piezas una vez que se haya dejado de utilizar.

A veces los materiales usados en los entregables intermedios pueden ser rematados o vendidos para recuperar algo de capital. La basura de unos es el tesoro de otros.

En ocasiones la construcción de objetos, herramientas o entregables intermedios causa un ahorro para el proyecto, porque si bien elaborarlas tiene un costo relacionado, su uso ahorra tiempo, aumenta la productividad de los integrantes o aumenta la calidad de los entregables finales del proyecto. Esto representa ahorro que a todas luces impacta positivamente al presupuesto.

Si un entregable intermedio no representa un ahorro, muchas veces justifica su construcción el hecho de que no es posible elaborar los entregables finales sin el.

La construcción de un entregable intermedio definitivamente deberá estar en el plan del proyecto, aún que algunos miembros del consejo de aprobaciones del proyecto no estén de acuerdo con su construcción. Aquí debe ponerse en uso las habilidades del administrador de proyectos para “vender” la necesidad al consejo.

El objetivo final de cualquier proyecto en el sentido más práctico, es resolver un problema, pero este objetivo se tiene que alcanzar resolviendo todos los aspectos relevantes del proyecto.

One Response to 'El valor de los entregables intermedios'

Subscribe to comments with RSS

  1. FHR said,

    on Octubre 16th, 2012 at 1:08 pm

    Muy buen artículo y con puntos que nos pasan a los que desarrollamos proyectos. Saludos

Post a comment

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.