16
2015
Cómo convertirse en un excelente CEO para IT. Fase tres: Sé uno con el departamento de IT
Léelo aprox. en 9:27 minutos.
En este tercer artículo pretendo tratar temas importantes para IT que todo CEO debería tener muy en cuenta: la inversión en material y software y el sistema de información (no el de IT únicamente, el de la empresa entera).
Temas muy importantes para los CEO con empresas tecnológicas o con alta influencia/necesidad de IT.
Para los que no hayan leído mis artículos anteriores, decir que para nada es una crítica gratuita y satírica o una ridiculización de un rol muy importante en toda empresa. Mi pretensión es aclarar o hacer llegar mensajes muy importantes que espero calen hondo y creen pedagogía al respecto.
En esta ocasión sólo aporto dos puntos globales y dos organizativos pero con ellos se han llenado libros enteros y los que están por venir.
En muchas ocasiones, el personal de IT necesita herramientas con las que realizar su trabajo de manera efectiva, llámense:
- programa de ticketing
- entornos diferenciados
- gestor documental
- wiki
- sistemas integración continua
- calidad
- control de versiones
- control de código
- y un largo etc.
- “El alcance del proyecto no está claro ni definido al inicio”. Imagina que lo haces predictivo, la posible desviación resultante da miedito.
- “Es que si el Analista o Product Owner no es bueno nada va a salir bien”, como de igual manera si un análisis funcional en predictivo es malo, tampoco vas a hacer un buen papel.
- “No sabes el tiempo ya que no puedes saber las iteraciones que necesitas”. En una planificación predictiva acaba siendo desviación e incumplimiento de plazos con lo que la perspectiva sigue siendo mala.
- “Es un descontrol y una anarquía porque no hay un responsable”. Yo creo que las metodologías tienen su propósito y conceptos bien establecidos, de manera que no es anarquía, eso sí, es un sistema donde el equipo se implica y se compromete a cumplir, somos todos mayores y profesionales, creo que sobran más explicaciones. El responsable es todo el equipo, por eso van todos a una.
Muchas de estas herramientas no son gratuitas pero son necesarias y el personal de IT las solicita. El trabajo rutinario no es muy gratificante y quieren ser lo más productivos posible y enfocarse a lo importante.
El no entender la naturaleza de las peticiones ni la necesidad para mejorar la productividad, hace decantar el NO en la mayoría de peticiones.
¿Quieres llevar tus Proyectos a otro nivel?
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
El argumento esgrimido es que si es software para producir llámese .NET, Cloudera, Sharepoint,… se aborda, en caso contrario rara vez se consigue dicho software sin una insistencia tenaz y constante. Lo habitual es que quede relegado, olvidada la petición o descartada directamente.
El software de soporte sirve para mejorar rendimiento y ahorrar en personal y hay que tenerlo muy presente.
Con el hardware pasa menos, debe ser que al ser más tangible la percepción es diferente pero ahora que estamos en Clouds y Virtualización…
Disponer de varios sistemas de información inconexos, uno para facturar, otro para proyectos, otro para actividad comercial… es una fuente de conflictos, de duplicidad de trabajo, de dudas en responsabilidades y acaba siendo un problema grave y una inversión de tiempo desmesurada.
No estoy diciendo que todo pase a ser SAP pero sites independientes de sharepoint, un navision y un project server, varias bases de datos y 50 excels no constituyen un sistema de información integrado, sobre todo, si no están interconectados y contienen información n-plicada.
Hasta la fecha no me he encontrado con un CEO que cumpliera absolutamente todo lo citado en estos tres artículos, espero no tener tal desatino.
Admito que el último CEO con el que he trabajado cumple 12 de estos 16 patrones, con lo que se acerca bastante (mis compañeros asienten con la cabeza al leerlo) y creo que esto ha supuesto cierta motivación para redactar estos artículos.
Espero que progrese y elimine algunos de estos hábitos, todos sé que es imposible, o bien que no tengáis la desdicha de tenerlo como CEO.
No obstante, debo afirmar que me he cruzado con varios CEO excepcionales, en mi etapa en el Departamento de Salud y Desigual, ambos unos visionarios y claros ejemplos de la antítesis de estos patrones.
No os equivoquéis que ambos eran muy exigentes.
Recuerdo en Desigual que si no estaba el dash board (cuadro de mandos para los amigos) actualizado a diario, recibíamos rayos y centellas ya que era una información valiosísima para la toma de decisiones, por tanto comprensible la fiabilidad requerida.
A parte de su pericia como CEO, aportaba valor con Haikus, curiosamente como hace este blog,.
Por ejemplo un relativo al factor diferencial que me he apropiado para explicar implantaciones de metodologías:
“No sólo importa lo que haces, ya que en la mayoría de ocasiones no es algo único, importa mucho cómo lo haces”
Quiero hacer especial mención a dos puntos más para mí esenciales.
Los CEO actuales no entienden la importancia de disponer de una PMO (Project Management Office), al igual que no ven la necesidad de establecer distribuciones en portfolios, programas y proyectos, para ellos IT son todo proyectos.
Los riesgos, las interacciones y relaciones entre recursos y proyectos son conceptos duros de digerir sobre todo sin alguien que se encargue de implementarlos y controlarlos.
Esto es un grave error y mi recomendación (de nuevo) es que se dejen asesorar que para eso contratan perfiles profesionales que entienden sobre IT.
En el caso de las PMO, el compromiso e implicación es aún mayor, ya que el CEO debe otorgar poderes a la PMO que en ocasiones pueden parecerle un lastre, como pactar portfolio, roadmap, adquisiciones, recursos y lo debe pactar porque todo esto genera gastos e implica otros profesionales de la empresa (RRHH, Marketing, Finanzas…).
Existen multitud de PMO así como existen múltiples tipos de distribuciones en organizaciones o empresas, así como niveles de madurez.
Nada se transforma de la noche al día, se concibe como un proyecto más llamado PMO que a mi entender debe tener prioridad máxima para ir perfeccionando y alcanzando el nivel que la empresa requiere al evolucionar.
El capítulo de la PMO es complejo y no me quiero extender, es un tema apasionante bajo mi punto de vista, claro que al ser mi campo de juego no soy imparcial.
De todos modos todo CEO que quiera ser uno con IT debe saber qué es una PMO y asesorarse de su necesidad y viabilidad.
El tema PMO da para muchísimos artículos, lo dejo en el tintero…
No obstante, es muy importante que el CEO tenga en cuenta que la dirección o jefatura de proyectos no es un rol, es una profesión para la que no cualquier técnico está a priori preparado y que lleva su tiempo dominarla, de ahí que se hable de efecto halo ya que se malinterpreta que si es un buen técnico ergo será un buen director de proyectos, esto rara vez se da en la realidad y distraer o importunar a un especialista técnico con tareas de dirección de proyectos suele acabar mermando su rendimiento a largo plazo aunque sea por el simple hecho de que muchas veces las posiciones entre estos roles han de ser totalmente opuestas (ejemplo técnico que necesita buenos servidores vs jefe de proyectos que tiene que cumplir presupuesto y tiempos).
Por tanto, escatimar en cuanto a jefes de proyecto (juniors en lugar de seniors) o creer que un especialista técnico puede llevar los proyectos es un juego muy peligroso.
Os remito de nuevo al Chaos Manifest para que evaluéis la diferencia en porcentaje de éxito entre estas opciones y que valoréis el riesgo en consecuencia.
El otro punto es el miedo pavoroso que se tiene al concepto Agile. Vistos los patrones anteriores y que con Agile muchos de ellos quedan diluidos o no tienen cabida, esa pérdida de control, posesión y autoritarismo hace que tanto los CEO, como algún CIO, incluso algún Project Manager critique en demasía ya que no entienden qué es, cómo funciona y cómo se implanta, ni quieren adaptarse a algo que les saque de su zona de confort.
Muchos se escudan en frases como:
Y en cuanto a documentación, no es para nada cierto que en Agile (Scrum, XP, lean…) no se documente, el que no lo hace es por dinámica de trabajo propia, en mi caso en mis implementaciones la documentación era una tarea tan importante como cualquiera de desarrollo de código.
Me hace especial gracia cuando les explico TDD (Test Driven Development) y BDD (Behavior Driven Development).
En el primero extrapolan que es demasiado concreto y cada vez que hacemos un cambio hay que modificar los comentarios.
En el segundo que al ser más generalista, y para evitar el mismo problema de TDD, se pierde nivel de detalle.
Si hay tests unitarios porque consumen tiempo en desarrollo, si no los hay es que aparecen muchos bugs.
Por tanto CEO, y en su extensión CIO, que desconfíen de estas metodologías y herramientas, por favor, echadle un ojo a los chaos manifest de los últimos años que las estadísticas no engañan, no os montéis películas.
Estos miedos son infundados, ahora bien, contratad un buen profesional para implantar, esa es la clave.
De leer un agile manifest o algún manual de scrum a implantar alguna metodología hay un gran salto, y lo realmente complicado de ellas no es entenderlas, sino implantarlas ya que la casuística es muy grande, recordad el ejemplo del mecánico del primer artículo.
No hagamos experimentos, no compensa y acaba siendo frustrante.
Ya para concluir, plantear la necesidad de un cambio en el tejido y concepción empresarial, que permita romper estas dinámicas y ayude a la unión y harmonía entre los CEO que conocen el negocio como nadie y el equipo de IT, que son su fuerza para tener una empresa rentable, eficiente y con trabajadores motivados.
A fin de cuentas las PMO, EPMO, Agile, Management, Software todo tiene sus correspondientes métricas, indicadores, KPI, si es un servicio SLA, se puede cuantificar y demostrar la eficacia de las implementaciones, proyectos, la competencia de la gente y un largo etc. que permite valorar a nuestros profesionales de manera objetiva, por sus logros, su consecución de objetivos, en lugar de por las horas que pasan en la empresa delante de la pantalla, ya que más horas no implica mayor productividad.
Este concepto constato que se acentúa en España así como el del teletrabajo, que están mal vistos y acaba siendo el motivo de que el talento acabe partiendo a empresas en otros países por su diferente filosofía empresarial. Me abstengo de entrar en el tema salarial, eso es otra lucha.
Agradezceros vuestra atención.
Espero haber servido de nexo y haber logrado un cambio, por pequeño que sea, en vosotros y/o en alguno de vuestros CEO.
Recomendadles los artículos como lectura entretenida.
Puedes consultar el resto de los artículos de esta serie que también te pueden interesar.
Consigue Más de 100 Libros gratis
Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo
Miguel Jurado
Últimos artículos de Miguel Jurado (ver todos)
Otros artículos que te pueden interesar
1 Comentario+ Escribir Comentario
¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
Teniendo un buen contenido clave de marketing bolg McDonalds webde Pamper utilizaria palabras claves que buscan clientes.Realizaría buena búsqueda en linking. Y por último optimizaría estos tres puntos. Un saludo.