Andares de un proyecto

El outsourcing en los proyectos… ¡Hay que atreverse!

Publicado el Agosto 31st, 2011 en Planeación, Adquisiciones, Costos por admin

outsourcing.jpgEn las experiencias que día a día recordamos, abundan aquellas en las que el alcance o el tiempo eran el actor principal. Platicamos como nos debatíamos para lograr cerrar la lista de requerimientos o cómo el tiempo era un factor clave para alcanzar los objetivos. En muchas ocasiones también recordamos experiencias valiosas donde el riesgo fue el factor que nos dio más problemas.

Sin embargo hay otras áreas de la administración de proyectos que también han dejado lecciones aprendidas muy valiosas y que no es común que recordemos porque se trata de temas poco ejercitados. Por ejemplo, normalmente no hablamos de contratos dentro de nuestros proyectos y es natural porque no es un área que, como el alcance, el tiempo, la calidad o el riesgo, todos los proyectos involucren.

Muchas empresas se valen de sus propios recursos (humanos, materiales, etc.) para ejecutar sus proyectos y pocos hacen uso de entidades externas que apoyen a la consecución de sus objetivos. Claro, existen algunos países y algunas empresas que si han desarrollado un habito y hasta una preferencia por subcontratar otras compañías para elaborar algunos de los entregables del proyecto.

Pero vamos desde lo mas básico: cuando un proyecto tiene riesgos (lo cual todos tienen en un cierto grado), nosotros podemos aceptarlos, mitigarlos o transferirlos. Cuando hablamos de transferirlos nos referimos a que le pagamos a otra compañía para que ellos adopten el riesgo y nosotros librarnos de esa carga (elaborar un plan de contingencia, hacer una reserva en el presupuesto para afrontar los gastos en los que incurramos en caso de que el riesgo se convierta en una realidad, etc.). Por ejemplo, un seguro de daños implica contratar una compañía aseguradora para que se haga cargo de las reparaciones en caso de un desastre. Esto implica un contrato.

Por otro lado, supongamos que nos han asignado a un proyecto de construcción y que nos encontramos en la etapa de elaboración de detalles, y dentro del plan de trabajo se requiere elaborar algunos acabados que requieren un material que nuestro equipo no esta acostumbrado a trabajar y que requiere cierto nivel de experiencia para su manejo y tallado, como por ejemplo el mármol. Podemos intentar involucrar a miembros de nuestro equipo para que hagan el trabajo, pero corremos el riesgo de echar a perder el material y/o que el cliente quede insatisfecho. Por otro lado, podemos recurrir a una compañía de gente que se encargue de trabajar profesionalmente el mármol y establecer un contrato especificando el nivel de calidad, el tiempo de entrega, etc. Esto se puede administrar como un sub-entregable del proyecto completo. Cuando la compañía especialista termine de hacer el trabajo, simplemente salen del ‘escenario’ y se concluye dicho contrato.

En una ocasión fui invitado a liderar un proyecto de alto nivel, el sponsor del proyecto era el hijo del dueño de la compañía y el producto que deseaba elaborar era un portal de Internet con características muy similares a otros que ya ofrecían el mismo servicio (ya había un estándar en el mercado).

Dado que la orden vino “de arriba” tuvimos que atender el requerimiento como urgente, pero todos nuestros recursos humanos estaban asignados a proyectos con prioridades establecidas, de tal forma que no teníamos a nadie para desarrollar el portal, y fue así que me estrené en la búsqueda de proveedores de desarrollo de sistemas que ofrecieran el mayor valor en su propuesta. Hice una matriz con la funcionalidad que requeríamos y la anexé a un documento RFP (request for proposal) para distribuirlo entre cuatro consultorías locales de prestigio.

Las consultorías tomaron el documento que estaba disponible en formato impreso y en formato electrónico y empezaron a evaluar nuestras necesidades. Yo establecí un marco de tiempo de dos semanas para que ellos revisaran la funcionalidad que solicitábamos y que hicieran su propuesta tecnológica, de tiempo y de costo. Durante las dos semanas siguientes invité a los proveedores a dos sesiones de preguntas y respuestas en las que nos pudieran hacer preguntas de cualquier detalle que consideraran relevante. Nunca nos reunimos a solas con una compañía, siempre hicimos todo público para evitar cualquier sospecha de preferencia de alguno de los proveedores y para que las preguntas de unos sirvieran para que otros tuvieran mas información. Al cabo de las dos semanas recibimos tres propuestas y una carta de abandono del proyecto.

Con las tres propuestas en mano hicimos una sesión para que cada uno de ellos explicara su solución mostrándonos las razones por las que ellos representaban la mejor opción. Después de estas sesiones y las retroalimentaciones que les dimos durante su presentación, les dimos la oportunidad de hacer una ultima revisión a su propuesta y entregarnos la que sería su versión definitiva de la solución.

Posteriormente y junto con otro colega elabore un documento que presentaría a la dirección general para la evaluación del proyecto. En dicho documento anexe las tres propuestas evaluadas desde la misma perspectiva (comparando manzanas con manzanas, para eliminar debilidades y ventajas a ese nivel) y después en la sección de recomendaciones anexé el detalle de las ventajas de cada proveedor y las desventajas. Mi colega agregó información muy importante relativa a la inversión que necesitaríamos en equipo para albergar el portal (servidores, cableado, racks, etc.) y completó su información con un par de cotizaciones.

En la sección de inversión monetaria elaboré un cuadro resumiendo los costos por concepto de desarrollo de sistemas, costos de equipo, mantenimiento anual y otros costos relacionados, así como el plan de pagos de cada una de las compañías proveedoras. Finalmente, en la última sección, agregamos nuestra recomendación sobre cual de los proveedores deberíamos escoger desde la perspectiva tecnológica (que era el departamento al que nosotros representábamos).

El documento lo entregué al director general, al director de ventas de ese proyecto y al hijo del dueño de la empresa, posteriormente hicimos una junta en la que explicamos el contenido del documento y dimos detalles que no venían en el documento, pero que teníamos gracias a nuestras continuas entrevistas con los proveedores.

Finalmente la dirección general optó por una cuarta opción: no implementar el proyecto.

Desafortunadamente no tuvimos la oportunidad de ejecutar el plan que construimos en un par de meses, pero nos quedó la experiencia de haber elaborado un ejercicio que dejó precedente. En ese momento nuestra organización entendió que era posible implementar proyectos mas allá de la capacidad instalada en el departamento. Aprendimos que podemos salirnos del molde y aventurarnos a administrar proyectos con recursos externos.

Esta experiencia puede parecer básica para muchos de nuestros experimentados lectores, sin embargo en su momento fue una experiencia que nos dejo un aprendizaje de algo a lo que no estábamos acostumbrados. Normalmente abordábamos los proyectos con la gente que teníamos y el arranque de proyectos se postergaba hasta que tuviéramos disponibilidad; con este nuevo esquema nos atrevimos a subcontratar los servicios de desarrollo mientras nosotros administrábamos el proyecto y lográbamos las metas de negocio.

Mas adelante la compañía pudo vivir la experiencia de implementar proyectos completos con personal externo de acuerdo a las necesidades de las diferentes áreas de la compañía. En otras ocasiones se contrató personal externo a largo plazo y no sólo por proyectos.

La compañía experimentó con una serie de contratos cuya negociación normalmente quedaba a criterio del administrador del proyecto obligando a éste a ejercitar esa área tan importante de la administración y liderazgo de proyectos que a veces dejamos de lado.

Por Fernando Valdez

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