Andares de un proyecto

Aceptando el reto

Recientemente iniciamos un proyecto para un cliente estadounidense. Nuestro cliente quería un sitio web en el que se incluyera un componente de donaciones para una asociación civil sin fines de lucro, por lo que el presupuesto era muy ajustado. Adicional a esto, el cliente necesitaba que el sitio estuviera operando para inicios del año, lo que nos dejaba un calendario muy ajustado para terminar. La fecha de entrega no era negociable porque ya se había publicado la fecha del inicio del concurso que recaudaría los fondos y cada día que fuera entregado tarde el sitio representaba una pérdida en el potencial de recaudación.

shutterstock_7861366.jpg

Previo al proyecto

El cliente en EUA de primera instancia buscó compañías en ese país para que le hicieran el trabajo, pero con el presupuesto reducido y, sobre todo con el calendario tan apretado, tres compañías le rechazaron el proyecto. Posteriormente encontró un par de compañías basadas en India que accedieron a hacer el sitio por el presupuesto ofrecido, pero ninguna de las dos compañías ofrecieron terminarlo a tiempo, de hecho, ambas coincidieron en que lo podrían hacer en el doble del tiempo presupuestado.

Finalmente buscaron en México y siendo nosotros socios comerciales en proyectos pasados nos solicitaron la implementación. Revisamos la factibilidad y decidimos abordar el proyecto pero con una metodología ágil en la cual redujéramos algunos costos. La propuesta fue aceptada e iniciamos el proyecto.

Factores de riesgo

Adicional a la metodología ágil, otra estrategia que implementamos para reducir el costo fue conseguir personal externo a nuestra compañía que hiciera el trabajo con un precio por debajo de nuestro propio costo y buscamos personal en entidades socioeconómicas de menor nivel (fuera de la ciudad de Monterrey) y con los conocimientos técnicos para hacer la tarea.

Entrevistamos a algunos individuos y finalmente contratamos a dos de ellos en una ciudad a más de 2,000 kilómetros de distancia.

shutterstock_98130041.jpg

El proyecto involucraba el desarrollo sobre un Sistema Administrador de Contenido (Content Management System o CMS ó por sus siglas en inglés) que nuestro equipo nunca había utilizado y también involucraba la interacción con una entidad para la recepción de donaciones de manera segura, cosa que tampoco habíamos implementado antes.

Todo esto preparaba una atmósfera de riesgo adicional en el proyecto sin embargo decidimos tomar el reto con el afán de dar el servicio y con la expectativa de hacer algo que otros no habían querido hacer.

Las fiestas decembrinas, el fin de año, el equipo de trabajo a distancia, la metodología ágil, el presupuesto cerrado del proyecto, la fecha agresiva de entrega del proyecto y la tecnología que nuestro equipo no dominaba eran riesgos evaluados pero no poco considerables.

La ejecución del proyecto

En las primeras fases todo parecía ir bien hasta que solicité ver físicamente los entregables, empezamos a notar que no estaba todo lo que los externos decían que iban a completar. El líder de los externos empezó a postergar entregables de un sprint a otros posteriores y lo que fuimos recibiendo eran entregables incompletos.

Hicimos la primer presentación del avance al cliente de manera exitosa indicando que postergaríamos algunos de los entregables para una presentación posterior y el cliente aceptó.

Llegaron las festividades decembrinas y por un tiempo no recibimos avances considerables. El equipo externo estaba localizable, pero los entregables no se completaban. Establecimos una estructura de revisiones más cercanas que el equipo externo no pudo cumplir ya que no tenían siquiera una estructura de trabajo formal.

shutterstock_20302609.jpg

En subsecuentes revisiones con el cliente, éste se mostró preocupado por el escaso avance y empezó a cuestionar nuestra capacidad de entrega del producto a tiempo, por lo que me vi forzado a tomar por completo el control del equipo externo aún cuando su líder se resistía a ser administrado.

Iniciamos juntas diarias con el equipo remoto y establecimos metas claras diariamente para ir concluyendo cada uno de los entregables. También concentré al equipo en pocas actividades de alto valor, esto nos permitió ir acabando lo más importante aún que fueran pocos entregables y evitar tener muchos medios avances.

Agregué un equipo de pruebas que no era de ingenieros de pruebas (QA Testers), sino un equipo de desarrolladores de sistemas que empezaron a probar cada uno de los entregables que a su vez el equipo de externos iba produciendo. Esta decisión tenía tres objetivos: 1) reducir el tiempo del ciclo entrega-testing-documentación-remediación-entrega, 2) involucrar a nuestro personal técnico en la solución desarrollada, para que pudiera hacerse cargo de algunas partes del desarrollo del sitio en un momento dado, y 3) para que nuestro equipo apoyara en la remediación de algunos defectos, de tal forma que redujéramos la cantidad de trabajo enviada a los externos para remediación.

Continuamos con las revisiones diarias que a la vuelta de las semanas se volvieron muy cansadas ya que no permitíamos que el equipo se fuera a descansar sin concluir las metas propuestas por ellos mismos en el día. Debido a algunos problemas de actitud que el equipo de externos tenía, las revisiones se volvieron tortuosas, sin embargo para mediados del mes de enero, muy cerca ya de la fecha de entrega, declaramos como terminado todo el sitio y solo quedaron algunas actividades de pruebas y remediación de errores.

Las pruebas finales

shutterstock_56950768.jpgHacia el fin del proyecto invitamos al cliente a entrar al sitio para que validara toda la funcionalidad, el accedió e invitó a tres integrantes de su empresa para probar el sistema. Nosotros les compartimos el acceso a una herramienta para el reporte y seguimiento de los errores encontrados y en ese sistema ellos fueron capturando cada problema encontrado. Nuestro equipo revisaba la lista de problemas encontrados y priorizaba  su atención, asignaba cada problema a un responsable de desarrollo e iba remediando cada problema y probando que hubiera quedando resuelto. De esta manera proporcionamos un entorno muy visual y transparente del avance en la resolución de problemas encontrados.

La entrega

El sitio lo terminamos dos semanas antes de la fecha final de entrega y esas dos últimas semanas el cliente estuvo revisando y reportando problemas mientras nuestro equipo los resolvía. El día previo a la fecha final de entrega, alrededor de las 7:30pm terminamos de corregir todos los problemas y el sitio pudo ser anunciado en la prensa local y las donaciones empezaron a entrar al día siguiente.

Hubo algunos cambios que nos solicitó el cliente conforme iba probando el sistema y conforme veía su desempeño, pero gracias a que involucramos a nuestro equipo pudimos hacer internamente lo solicitado sin recurrir a los externos, a quienes ya habíamos liberado con la intención de no volver a contratarlos más.

Conclusión

Nos quedamos con muchas lecciones aprendidas de este proyecto, pero una de las principales es que necesitamos tomar los retos que se nos presentan, pero con una evaluación adecuada de los riesgos y de nuestra capacidad para afrontarlos. Desde luego aprendimos que debemos combinar el menor número de riesgos, por ejemplo, pudimos experimentar con un grupo de externos con los que no habíamos trabajado antes, pero en un proyecto más holgado.

Nuestro cliente quedó sorprendido por nuestra entrega a tiempo con fechas tan agresivas y un presupuesto tan recortado y gracias a eso ya estamos firmando nuevos proyectos con ellos, pero más holgados y en mejores condiciones presupuestales.

Creo que podemos hablar mucho de lo que hacemos, pero cuando nos dan la oportunidad de demostrarlo eso se convierte en el mejor argumento de ventas para nuestro equipo de trabajo. 

shutterstock_76411899.jpg

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.