Cómo evitar situaciones sin salida en proyectos de consultoría

Evitando las Situaciones Sin Ganador en los Proyectos de Consultoría: Un Caso Real

El Consultor

Recientemente, Doug, un amigo y consultor independiente, me contó acerca de un proyecto que se convirtió en una situación sin ganador. Le habían pedido que realizara un estudio de viabilidad comparando un paquete de software seleccionado por el cliente con varias alternativas.

El proyecto parecía sencillo. El cliente había comprado un paquete de software en el que Doug era experto. Sin embargo, el gerente del proyecto a cargo de la evaluación se fue, y el nuevo vicepresidente contrató a George en su lugar. El nuevo gerente del proyecto cuestionó algunas de las decisiones tomadas por el equipo de evaluación. Pensaba que las siete interfaces del paquete podrían ser desarrolladas internamente a un costo mucho menor que el establecido por el proveedor de software.

El proyecto comenzó a salir mal casi de inmediato. Cuando Doug recibió el contrato, el contratista principal le pidió que no lo llevara a su abogado. En palabras del contratista principal, "los abogados solo estorban; tienen que hacer cambios para justificar sus honorarios". Doug se preguntó qué estaba ocultando el contratista principal. Para asegurarse de que sus intereses fueran atendidos, Doug decidió consultarlo con un abogado de todas formas. Cuando llegaron los comentarios del abogado, el contratista principal aceptó los cambios sin negociación. Esto sorprendió a Doug, ya que varios de los puntos deberían haber sido objeto de al menos alguna negociación.

Mientras tanto, el nuevo gerente de proyecto, George, descubrió que no tenía la autoridad para contratar a Doug durante seis meses. Así que le informó a Doug que el contrato tendría que dividirse en dos partes. Durante el período de desarrollo de la viabilidad (aproximadamente dos semanas), Doug realizaría las entrevistas necesarias para finalizar el contrato para el período posterior a sus vacaciones. El tiempo restante del contrato, aproximadamente cinco meses y medio, debería ser aprobado más adelante.

Consulta a los expertos en construcción AU

Sabiendo que dos semanas no serían suficientes, Doug decidió que necesitaría más tiempo. Aunque se había desarrollado un proyecto charter profesionalmente, no se incluyó información clave sobre el proceso de toma de decisiones. Y ninguno de los documentos de análisis detallados del proceso de selección de software estaba disponible. Realizar el estudio de viabilidad, por lo tanto, requeriría entrevistas con cualquier persona que tuviera conocimiento sobre el entorno y el proceso de selección. Pero dado que el primer proyecto no había guardado el material de respaldo, no había forma de entender qué tenía en mente el primer gerente de proyecto al elegir el paquete de software.

Varios jugadores clave se encontraban de vacaciones. Además, comenzaron a surgir problemas técnicos. Doug se dio cuenta de que la interfaz que el proveedor había vendido era un middleware generalizado que se conectaba a una edición más compleja del paquete. Luego, el proveedor desarrollaría conexiones a medida para la versión que se vendió al cliente, y este conectaría el middleware a su data mart. En efecto, el cliente estaría pagando un precio adicional para que el proveedor desarrolle su software.

Para empeorar las cosas, el cliente ya tenía un data mart que cumplía la misma función que el middleware. ¿Cómo pudo la gerencia pasarlo por alto durante la debida diligencia?

Aparición de la política

Dado que el gerente del proyecto, George, no pudo proporcionar un formato para el estudio de viabilidad, Doug utilizó uno propio basado en una matriz de decisión. Dado que el formato había sido desarrollado para este cliente en particular, Doug pensó que funcionaría. Ya estaba comenzando a darse cuenta de que este era un proyecto sumamente político, por lo que consideró que comunicar claramente el razonamiento detrás de sus recomendaciones era importante.

Doug entrevistó al representante del usuario final del cliente para desarrollar los criterios para la matriz de decisión. Estos criterios y las calificaciones relativas se utilizarían para determinar la mejor opción entre la organización y las alternativas. Resultó ser más difícil de lo habitual obtener comentarios significativos del representante del usuario final. (He descubierto que a menudo los ejecutivos se sienten incómodos al definir lo que es importante para su gente y clasificar esos criterios, ya que ellos mismos están dictando esas prioridades). Sin embargo, Doug logró determinar que al cliente le interesaba principalmente reducir el riesgo y los costos. Durante este proceso, Doug mantuvo un contacto cercano con el gerente del proyecto y el equipo directivo.

Aporta tu granito de arena a la comunidad Builder AU

La siguiente reunión con el representante del usuario final fue impactante. Durante la reunión, el representante manipuló los criterios y la matriz, sobre enfatizando el análisis de riesgos. Era casi como si estuviera tratando de encontrar alguna forma de demostrar que la decisión del proveedor era la mejor. Además de esto, Doug comenzó a recibir comentarios de otros consultores: el proveedor sugirió falsamente que Doug estaba preparándose para conseguir un contrato permanente.

La recomendación final fue que el personal interno desarrolle las conexiones directamente con el data mart sin utilizar el paquete middleware. Los consultores locales proporcionarían capacitación en la plataforma y el paquete durante el proyecto inicial. Usar el middleware y hacer que el proveedor lo conectara personalizadamente al data mart resultaba ser la opción más arriesgada, más costosa y peor. El gerente del proyecto, George, tenía razón al cuestionar la solución original.

Doug se sentía satisfecho con su trabajo. Varios ejecutivos habían afirmado que les había dado "algo en qué pensar". Y parecía que Doug iba a ahorrarle al cliente entre $500,000 y $1,000,000. En este punto, Doug se tomó un descanso y se llevó algunos trabajos sin terminar. Logró finalizarlos y esperaba con ansias sus primeras vacaciones en muchos años.

De mal en peor

A su regreso, Doug se encontró con que la situación había cambiado una vez más. El gerente del proyecto no estaba, pero dejó un mensaje diciendo que aún contrataría a Doug por los cinco meses y medio restantes del contrato. Sin embargo, durante dos semanas, nadie avanzó en la contratación de Doug.

Finalmente, se le informó a Doug que tendría que realizar una entrevista telefónica. Cuando llamó, la entrevistadora no se dio cuenta de que la entrevista se realizaría por teléfono y que ella había preparado una entrevista para un nivel de personal incorrecto. A pesar de esto, el gerente del proyecto continuó diciendo que contratarían a Doug. O al menos eso hizo hasta que dejó de responder las llamadas de Doug.

Cómo transformar el departamento de IT en un centro de valor

Un mes después de su regreso de vacaciones, Doug abandonó la idea de trabajar para ese cliente y comenzó a buscar otros proyectos. Desde entonces, se ha enterado de que uno de sus competidores de otra ciudad fue contratado antes de que él se fuera. Este consultor fue muy recomendado por el proveedor. También se ha enterado de que el 90 por ciento del personal del cliente fue despedido, un proceso que había comenzado antes de que él fuera contratado. Parece que el nuevo vicepresidente estaba reestructurando en torno a paquetes de software, externalización y proveedores externos. Había decidido que los programadores internos no eran tan competentes como los externos. Doug estaba especialmente molesto con esto, ya que la plataforma de desarrollo tenía una oficina de consultoría local. Esta oficina podría haber brindado fácilmente ahorros similares y reducir el riesgo.

También ha descubierto que los otros consultores independientes locales contratados para el proyecto abandonaron disgustados, a pesar de las contraofertas. Parecía que la política interna, los conflictos y las prácticas de baja calidad eran demasiado para ellos.

Hace algunas semanas, Doug se enteró de que el cliente había prohibido al contratista principal seguir trabajando debido a que supuestamente proporcionaba personal incompetente. Como el propio Doug es un proveedor de servicios, teme que esto recaiga sobre él, aunque las personas que se lo dijeron automáticamente supusieron que él también había caído en la política interna. Doug siente que sus habilidades fueron subestimadas por razones políticas y que el proveedor ha engañado al cliente.

Aunque Doug puede aceptar que sus opiniones fueron desestimadas por razones políticas, está preocupado de que el cliente arruine su reputación al contarle a los reclutadores y a otras personas que es incompetente. Dada la magnitud del mercado de Doug y la situación económica actual, está preocupado por el efecto que esto puede tener en su negocio.

Para aumentar su frustración y miedo, Doug ha estado recibiendo informes regulares sobre el proyecto. Sus predicciones sobre los planes del proveedor y sus riesgos fueron acertados; el proyecto está $500,000 por encima del presupuesto y más de seis meses retrasado. El consultor recomendado por el proveedor ha estado allí durante más de un año y evita capacitar a su reemplazo interno. George ha sido trasladado y varios miembros del personal se han ido o han sido despedidos. Doug también ha escuchado que el personal restante del departamento no ha podido mantener los demás sistemas a su cargo.

Ahora, Doug se pregunta qué podría haber hecho para evitar quedar atrapado en esta situación.

El genio de Flash que revoluciona la reproducción de videos

Lecciones aprendidas

Incluso para un proyecto de corta duración, trata de aprender tanto como puedas sobre tu cliente. Si Doug hubiera preguntado en su red de contactos, se habría enterado de la situación política de antemano. Por ejemplo, uno de los consultores de su red había trabajado para el cliente antes de que comenzara el ciclo de reducción de personal. Sus opiniones y consejos habrían revelado la agenda oculta del departamento de externalización. Su opinión negativa y las advertencias sobre el cliente y el entorno laboral le habrían permitido a Doug evitar completamente el proyecto. El estudio de viabilidad fácilmente podría haberse adaptado a la agenda del departamento.

Hay varias formas de obtener información sobre un cliente:

• Pregunta a tu red de contactos sobre el cliente.
• Pregunta a tu red de contactos quién conoce a alguien que haya trabajado para el cliente.
• Solicita referencias y contacta a los contratistas que han trabajado para ellos antes.
• Habla con el recepcionista mientras esperas para la entrevista.
• Habla con el secretario/a o asistente ejecutivo/a.
• Haz un recorrido y escucha las interacciones entre las personas.
• Pregunta a un reclutador de confianza sobre el cliente.
• Pregunta a un reclutador de confianza si conocen a alguien que haya trabajado para el cliente.

Aunque debes evitar la política interna, es obligatorio estar políticamente consciente. La tarea consiste en evitar contribuir a cualquier pantano político, pero estar al tanto de las "agendas ocultas" y las relaciones y personalidades involucradas. Recuerda que si bien tienes una responsabilidad fiduciaria hacia tu cliente, tu primera responsabilidad es contigo mismo. Si te haces conocido por jugar a la política por tu propio beneficio, dañarás tu reputación. Sin embargo, tu reputación se beneficiará de negociar situaciones políticas difíciles en beneficio del proyecto.

Entonces, ¿qué opinas? ¿Había algo que Doug debía haber hecho mejor? ¿Cuál fue su gran error? ¿Qué habrías hecho tú? Únete a la discusión a continuación y danos tu consejo.

IBM pide una regulación más estricta de las patentes en el desarrollo colaborativo de software

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre CXO, allí encontraras muchos artículos similares a Cómo evitar situaciones sin salida en proyectos de consultoría , tenemos lo ultimo en tecnología 2023.