Cuántas veces hemos leído, estudiado y hasta aplicado las “mejores prácticas”, los “10 pasos para implementar proyectos de tecnología”; o hemos recibido numerosos consejos, técnicas, herramientas y hasta metodologías para que el proceso de implementación de todo proyecto sea exitoso?
Sabemos que todo proyecto es muy particular, que no existen proyectos iguales, haciendo una analogía: un proyecto es como una persona, muy distinto el uno del otro. Inclusive el PMI (Project Management Institute) no tiene la “receta original” o la “bola de cristal” para llevar adelante y culminar con éxito proyectos de implementación de sistemas, desarrollo de software, migración de aplicaciones, instalación de redes e infraestructura o cualquier otro que involucre tecnología.
Siendo así, simplemente tenemos un conjunto de normas, reglas, prácticas o pasos a seguir para culminar nuestro objetivo; las mismas que podemos adaptarlas a la realidad del proyecto y usarlas de acuerdo a nuestra conveniencia.
Basado en mi experiencia de aproximadamente 6 años en el área de tecnología, luego de haber participando en varios proyectos, algunos exitosos y otros no tanto; y cumpliendo casi todos los roles dentro del equipo de un proyecto, les comparto algunas de las mejores prácticas para asegurar el fracaso de un proyecto, y si por cualquier milagro no fracasa, al menos les va a generar un montón de stress, problemas mentales y conflictos con la gente.
1. Organice un equipo de proyecto con el personal más joven, con menos experiencia pero que sea muy creativo para solicitar requerimientos.a. Los jóvenes sin experiencia, pero con un montón de ideas frescas y nuevas, sobre todo relacionadas a la tecnología, siempre aportarán al negocio y enriquecerán cualquier aplicación solicitando automatizarlo todo y solicitando miles de reportes y ventanitas nuevas… después de un tiempo nadie las usa!b. Evite juntar gente de experiencia y que domine el negocio, con el personal nuevo; de esta manera no hay inútiles confrontaciones con los jóvenes. A quien le importa todo lo que una persona aprende en 10 o 15 años?? Jóvenes recién graduados con bajos sueldos son siempre la mejor opción.
2. Permita que el equipo de proyecto redacte los requerimientos y los pase directamente al área de desarrollo. a. Elimine puestos claves del área de IT, los Analistas de Sistemas son caros y normalmente entorpecen el proceso de desarrollo. Para qué tomar el punto de vista técnico de lo que el usuario pide? Eso es perder el tiempo!!! Déjelo todo a la imaginación de los desarrolladores, ellos pueden hacer “magia” escribiendo millones de líneas de código.
3. Diga SI a toda iniciativa de la Alta Gerencia, y si es una multinacional permita que decidan por Ud.a. Si la solución tecnológica funciona perfectamente en países tan similares a los nuestros como Malasia, Filipinas e Indonesia, simplemente impleméntela sin objeciones; total todo se puede “personalizar”.b. No se tome la molestia de analizar alternativas locales, regionales, casos de éxito de soluciones similares. Siempre es mejor evitar dolores de cabeza haciendo análisis de costo/beneficio; además las presentaciones de negocio son muy aburridas y las experiencias de otras empresas nunca aplican para lo que nuestra organización necesita.c. Nunca tome en cuenta las opiniones del personal local de IT y de los usuarios sobre lo que es mejor para la organización. Siempre una decisión que viene de “afuera” es mejor. Está comprobado que el extranjero tiene una mejor visión del negocio y sabe lo que se necesita justamente porque ve las cosas desde lejos y no conoce el detalle.
4. Ponga toda la infraestructura de sus aplicaciones de misión critica lo más lejos posible.a. Si se “cae” la aplicación, el negocio puede esperar días enteros sin operar hasta que se ponga en marcha el “Plan de Contingencia/Continuidad”. A quién le importan las 14 horas de diferencia horaria? Pobrecitos han de estar durmiendo, ojalá mañana puedan conectarse en nuestro horario.
5. Para el desarrollo de las personalizaciones de su aplicación de misión crítica contrate a una empresa que se ubique lo más lejos geográficamente, que hable otro idioma y que no tenga la más minima idea de su negocio.
6. Contrate personal tercerizado solamente por el tiempo que dure el proyecto.
7. Despida al personal de TI que tuvo exitosas implementaciones en proyectos anteriores.a. Después de todo, a quien le importa desperdiciar la experiencia anterior para ponerla en práctica en nuevas implementaciones?
8. Permita que el equipo de desarrollo y soporte se disuelva inmediatamente después de terminar la implementación.a. Para qué desperdiciar tiempo y recursos capacitando al personal que va a “estabilizar” la aplicación.
9. Acepte que la organización premie con ascensos solamente a miembros del proyecto que son parte del negocio, igual el personal de sistemas deberá hacerse cargo de todos los procesos mal automatizados y entregar soluciones… total el negocio no puede parar porque la aplicación no funciona!!
10. Permita que el departamento de Tecnología se haga responsable de todo: del análisis de requerimientos, del desarrollo, de las pruebas, del control de calidad, de la decisión de pasar o no a producción cambios críticos de la aplicación. Finalmente, en todo lado siempre la culpa es de “sistemas”.
