How to manage a project with RESISTANCE of your business partner

How should you manage a project and cope with an unstructured business partner with high level of resistance on project itself,  who has been nominated by the management or customer to lead functionally the project and to promote the change in order to obtain the business outcomes. This person might be a trusted expert in his area and leads possibly a department or division of corporate / centralized functions.

 

What kind of characteristics you might find.....

• The person doesn't like to talk to anybody about the project goals and activities, doesn't see any necessity for team meetings, workshops or communication.
• Takes decisions, without listening to anybody and will not share them.
• Believes he can manage alone the project without the participation of anyone else.
• knows every detail, he is the expert, but he is unabe to express in a structured way the scope and content to others, or to synthesize a whole picture of the scope.
• expresses often his disagreement with the hierarchical bosses of the team members of their decsicions affecting the project.
• In his opinion the project is not necessary, only some detailled actions from his part
• simplifies every topic, stating to be able to finish in short time.
• talks like a waterfall, jumping from one topic to another, losing the red line in 2 minutes and feels absolutly surprised when people doesnt understand him, judging them as stupid and uninterested.
• Isn't able to concentrate on more than one topic at same time
• stops abrupty the meetings.
• Bad relationships to everybody around (project and other stakeholders).

This kind of behaviour is not acceptable for a project where an output will be delivered by a team and not by individuals working separately. The pieces worked out will not match and so the requiered outcomes will not be delivered.

The most dangerous aspect is that this person in charge is supposed to be the leader of the change, normally in an environment of resistance for change.

 

People who try to use a project to profile themselves in front of peers and bosses will not follow the project objectives, but their own personal ones. They won't try to manage the project agenda, but their own ones. The hardest fact is that this behaviour on project responsible will not get the things done, but generates hundreds of excuses why the targets couldn't be met, putting the fault on others, always.

 

In some occasions where I have experienced this kind of behaviour in a project, the person in question doesn't have problems with the executive management, but is suffering blocking from the peers. The only way out he sees, is to attack peers and project members and stakeholders, instead of Putting all his efforts to onsolidate and negotiate. Unfortunately the executive management normally notice the situatuon, once it is too late to correct the situation, and so extra costs, extra efforts and time delay already has been caused. But the most negative impact is the missing of a working project team to get the project done.

 

My recommendations for this case:

Give the person in question his responsability, require his actions and progress in each follow up and steering committee. Give him a lot of visibility on all levels, which challanges him and makes his behaviour also visible for everybody. Then ...

• Take the step and talk to project sponsors and steering committee members. If they do not react and correct the situation you can only focus to manage the project as professional as possible, but knowing that you won't get the project done as planned. Document each step of yours, each decision and change, you might need this log book later on.
• Focus your actions to organize and structure the project, communicate to all project team members and stakeholders, negociate with all business peers. Integrate everyone to the project. Integrate what he/she was separating. Create trust on you and try to take the lead on the project fulfill the given goals.
• Orientate the project on objectives, targets, deliverables dates and responsibles.
• The team needs to see and notice a new leading person. Make them follow you and show how the project can be mastered together. The power of a team is always stronger than individuals.
• Express your opinion clearly and execute the project management accoding to it.
• Document everything so good that everybody in business (from management to admnisration) can understand it. Use documentation to make things and facts understandable.
• Take the emotions out of the project.

 

The situation normally tends to disappear from the project, although in beginning it is making your life as PM impossible. Be patient but perseverant, solve instead of fight. Just focus in your project, not on the person.

Nevertheless, any company which is aiming targets and productivity, would immediatly remove these kind of person from the project and focus on the results directly.

Wish everybody luck with the Change Management in the Projects !!!

Outi

Sourcing en TI

La palabra Sourcing en las TIC se asocia habitualmente con "externalización", "outsourcing", "subcontratación", "contratación". Generalmente siempre relacionado con aprovisionamiento de recursos desde fuera (infraestructuras, comunicaciones, proyectos, conocimiento, consultoría, aplicaciones etc.). 

Yo también le añadiría el análisis y la decisión que hacer internamente y con que recursos desde la propia organización - todo relacionado con lo que se pretende externalizar. Los objetivos estratégicos y operativos a final son los mismos, y deberían influir en ambos.

Si tomamos como ejemplo las cadenas de suministro (supply chain) de las empresas, estamos ya habituando ver que el producto final o servicio al "usuario" está suministrado por varios agentes - internos y externos - como una única cadena.  El factor importante para el éxito de las cadenas de suministro es, como fluye la información en tiempo real, y quien debe actuar y como según la información recibida y que realmente ocurre como previsto/prometido.

Lo mismo no siempre funciona en TI, faltando fluidez (flowless), transparencia de los procesos y compartición de la información independiente a quien pertenece. En modelos de sourcing TI,  cada proveedor suele crear su caja negra de operación, reportando a posterior unos pocos datos de rendimiento a la compañía cliente, quien tampoco pide mucho más. Porque esto ocurre justo en Sourcing TI puede tener varios razones : 

• el uso de los modelos de operación estándar para TI no se ha generalizado, ni mucho menos industrializado (p.ej. ITIL),
• falta de definición de datos maestros y variables, así como deben ser intercambiados entre los diferentes agentes internos e externos. http://outinystrom.blogspot.com/2010/10/que-podemos-aprender-del-sector.html
• el enfoque hacia servicios en TI, ha hecho de olvidar de los procesos end-to-end trasversales, viendo desde punto de vista del cliente,
• falta de aplicaciones de operación transversales en TI con posibilidad de ser utilizados por varios agentes a la vez (p.ej. en cloud),
• razones de externalizar servicios TI, en lugar de procesos completos ( Business Platforms),
• razones de externalizar TI para quitar complejidad, entendiendo que no haga falta controles sobre ello.
• complejos contratos enfocados a definir las responsabilidades de cada proveedor contratada, sin tomar en cuenta el proceso completo del servicio.

Esta lista podría ser mucho más larga y seguramente contradictorio, según a quien preguntaríamos. Os invito compartir vuestros opiniones. 

Definitivamente sería mucho más ventajosa para el cliente poder adaptar las modalidades de outsourcing en alcance, modelo y proceso. Pero hoy en día mayoría de los Proveedores de TI ofrecen servicios estandarizados para tener su propia economía de escala y optimizacíón en la operativa. Cualquier intento cambiar los modelos estandarizados de los Proveedores TI llevaría automaticamente a precios más altos - ya muy comparables con el hecho de hacerlo uno mismo. ¿ Dilema ?  Hay que volver a los objetivos iniciales de Sourcing, a la estrategía que persigue la compañía con ello.  

Gestión y Gobierno de Proyectos - parte II

Una de las actividades importantes del Gobierno de Proyectos es definir las prácticas y metodologías cuales deberían ser usadas uniformemente en la gestión y ejecución de los proyectos, con el objetivo de garantizar la calidad y resultado de los proyectos.

Actualmente en el mercado existen diferentes metodologías o mejores prácticas para Gestión de Proyectos (PMI, Prince2, etc.), pero estos no incluyen actividades de Desarrollo / Implementación de Sistemas de Información o Gestión de Cambios organizativos. Por otro lado existen una multitud de metodologías para desarrollo / implementación de Sistemas TI, pero excluyen las tareas de gestión de proyectos. Ambos no incluyen las actividades relacionadas con cambios organizativos. Realmente una dilema para los departamentos de TI, habitualmente responsables de coordinar estos tres áreas de actividad.



En los proyectos llevados a cabo por las empresas consultoras del sector TI, cada uno suele traer consigo una diferente metodología de gestión de proyectos TI - Negocio, con el consiguiente impacto de tener heterogeneos métodos en la compañía, cuales no incluyen los procedimientos, normas y practicas de la propia compañía, ni tomando en cuenta las especialidades del negocio de la compañía. A final esto causa confusión y desorganización en la implementación e intergración de los proyectos en la empresa.

Para apoyar las organizaciones en la gestión de los Proyectos TI para el Negocio, he desarrollado una fusión de las siguientes metodologías:

• Gestión de Proyectos basado a PMI (Project Management Institute) y
• Desarrollo/Implementación de Sistemas TI basado a la métodos tipo cascada como p.ej. SDLC (System Development Lifecycle),
• Gestión de Cambio basado a modelos y mejores prácticas del mercado (7S de McKinsey, Kotter 8 pasos, Lewin).

El objetivo de esta fusión es facilitar una ejecución y control simultáneo y sincronizado de ambos por un único Jefe de Proyecto, evitando organizaciones complejas y costosas de los proyectos.  La metodología ya está muy probada en diferentes entornes de negocios y empresas y permite en una manera eficiente y simple controlar hasta proyectos muy complejas.

Adicionalmente esta metodología añade actividades de preparación del proyecto hasta su aprobación interna, como en las actividades de Gestión de Cambios organizativos y su puesta en marcha en las organizaciones sincronizándolo con las actividades puramente ligados a sistemas informáticos.

En el siguiente diagrama podrá ver el proceso completo, incluyendo los hitos principales y los auditorías de calidad.  Este proceso se compone de 5 ases consecutivas, aunque podrán solaparse también en tiempo, siempre dependiendo del tipo de proyecto.

Esta metodología de Gestión de Proyectos se adapta a todo tipo de proyectos para implementar nuevos sistemas de información o infraestructuras informáticos en las organizaciones. Para despliegues repetitivos de la solución solamente hace falta de repetir algunos de los fases y actividades, sin tener que asumir otra metodología específica para ello.  Esta metodología permite controlar en los despliegues repetitivos las actividades de gestión de cambio organizativo y las de TI.

Esta metodología de Gestión de Proyectos debe ofrecer una ayuda a los Jefes de proyecto de las divisiones o departamentos de negocio para controlar toda la envergadura del proyecto, ayudarles a recolectar todos los datos necesarios y coordinar todos los procesos necesarios en diferentes unidades y/o proveedores para cumplir el objetivo final del proyecto. Más que una lista de actividades a acometer, representa un método controlado y secuencial para gestionar el proyecto – Guía rápida del proyecto. En la guía rápida de gestión de proyectos se puede distinguir entre proyectos importantes y complejas y en proyectos más pequeños con menos riesgos. Según la clasificación las tareas son más o menos completas. La guía rápida incluye también el primer control de seguimiento y calidad con controles de estado de las actividades y cumplimiento de fases, facilitando así el labor de control.

En este documento se escriben las fases, sub-fases y actividades cuales serán el base para la “Guía rápida” , cual se podrá utilizar diariamente en controlar los proyectos. Se especifican las tareas concretas a llevar a cabo, indicando la información necesaria para llevar a cabo la tarea, y el resultado (Resultado) de la tarea, así como los formularios estándares cuales pueden ser utilizados como documentación del proyecto. Se recomiendo crear un repositorio por cada proyecto en los sistemas existentes de de la organización. Todos los formularios y herramientas están creados en el entorno Microsoft Office y Microsoft Project.

Esta metodología incluye :

• Descripción de la metodología en fases, sub-fases y actividades.
• Guía Rápida para herramienta de control en los proyectos, incluyendo gestión de calidad y riesgos.
• Más de 100 formularios como herramienta unificada con Guía rápida para gestionar proyectos.

permitiendo una fácil y rápida implementación, así como adaptación a las necesidades de cada empresa, colaboración eficaz entre las diferentes unidades/grupos.

¿Por qué fallan los proyectos de IT?

¿Por qué no es suficiente aplicar metodologías de Gestión de Proyectos para mejorar los resultados de los proyectos?

Cuando una organización tiene problemas en la ejecución de sus proyectos, y sobre todo en lograr los beneficios esperados de ellos, mayoritariamente busca solucionarlo con un responsable de área de proyectos experimentado y con metodologías estándares del mercado. Pero no es suficiente. Una de las problemas habituales es falta de cultura de proyectos en las organizaciones, y falta de un marco de actuación en relación con los proyectos de la organización - Project Governance o Gobierno de Proyectos.

Muchos proyectos en las organizaciones se quedan estancados causando retrasos a otros proyectos por falta de definiciones, falta de decisiones o falta de recursos. Quizás se lanzan una multitud de proyectos una vez los presupuestos del año hayan sido aprobados, pero no han sido evaluados según criterios de prioridad e importancia para la organización, y serán eliminados poco a poco, después de haber invertido tiempo y dinero en ellos. Ya podemos implementar las mejores metodologías de gestión de proyectos del mundo, pero mientras el marco de actuación o Gobierno de Proyecto no ha sido establecido en toda la compañía, no aportará mejoras significativas.

Gestión de Proyectos es una competencia clave para muchas organizaciones, si no a todas. Especialmente para los fabricantes y desarrolladores de software, es más que clave, es fundamental para existir  -  una competencia estratégica. Para estas empresas la falta de competencias de gestión de proyectos tendrá un impacto a su capacidad competitiva y tiene una especial atención por la dirección en sus organizaciones.

Gobierno de Proyectos es una parte importante de Gobierno de TI, ofreciendo un marco de gestión, liderazgo,  y de estructuras y procesos organizativas, de estándares y normas de comportamiento para garantizar que  la unidad de TI soporte los objetivos de negocio de la compañía. El objetivo principal del Gobierno de Proyectos es alinear proyectos tecnológicos con objetivos estratégicos de la organización, asegurando el resultado prometido.

Hoy en día, casi todas las compañías están utilizando TI en sus modelos de negocio y en sus procesos de negocio. Las organizaciones están inmersos en continuas mejoras de sus sistemas informáticos o desplegando nuevos para mejorar diversas áreas de la organización como por ejemplo: servicio al cliente, reducción de costes, mejoras en producto o calidad de servicio, lanzamiento de nuevos productos, servicios y modelos de negocio.  Estos nuevos despliegues de sistemas de información también representan un riesgo importante para la organización, así a nivel estratégico, como operacional. El Gestión de Riesgos es un parte importante de Gobierno de Proyectos.

Como ya conocemos todos de nuestras experiencias, los proyectos de TI no se entregan siempre con éxito, de hecho muchos fallan en la entrega de los beneficios prometidos, y los que llegan a entregar el producto final con éxito, tienen retrasos importantes o exceden sus presupuestos.

Cuando empezamos a definir el Gobierno de Proyectos en las organizaciones, hay componentes importantes de organización, procedimientos y políticas, cuáles deberían ser clarificados desde el inicio.

Gobierno de Proyectos tiene 6 principales objetivos, interconectados ente sí:

1. Asegurar consecución de beneficios con resultados de los proyectos.
2. Controlar costes
• gestión de proyectos centralizado con gestión de recursos financieros y humanos facilita la monitorización y control de costes, así como presupuestación y planificación.
3. Optimizar Recursos
• recursos internos y externos pueden ser asignados según prioridades de la dirección a los diferentes proyectos. 
4. Gestionar el riesgo balanceando el portafolio de proyectos:
• con la vista de todos los proyectos, con sus requerimientos de recursos y costes, sus limitaciones en tiempo etc, ayuda balancear el riesgo global de la compañía (ver dibujo 2)
5. Aplicar metodologías uniformes a todos los proyectos de la organización.
6. Coherencia organizativa
• la organización puede asegurar que todos los proyectos se llevan a cabo según los estándares, políticas y procedimientos acordados, sean de TI o generales de la compañía.

Para poder dotar los proyectos de TI de la importancia que tienen, es importante verlos como proyectos de negocio, lo que realmente son. 

Si pensamos que un proyecto con un peso importante en TI es un proyecto de TI, podría causar fallos graves en la ejecución del mismo, o como mínimo retrasos, faltas en cobertura y costes adicionales, etc., por falta de participación y compromiso de las áreas receptoras y afectadas del resultado de proyecto.  Los proyectos de TI solo involucran, afectan y benefician la unidad de TI.  Por otro lado, los proyectos de negocio generan valor al negocio de la compañía, involucran varias áreas de la compañía.  Los proyectos de negocio serán priorizados e integrados a la organización, se les controla y monitoriza como a cualquier otro iniciativa en la compañía.

Dentro de la metodología de gestión de proyectos en la empresa, las reglas, normas y procedimientos internos debería quedar incluidas en la misma metodología, garantizando los objetivos de la compañía, así como la transformación de los procesos de negocio y el gestión del cambio. Las buenas practicas como PMI o PRINCE son base para ello, pero sin adaptarlos a la situación de cada compañía no logran a asegurar el éxito de la ejecución de los proyectos.

En esto Nyström & Partners os puede ayudar ! 

¿Existen realmente metodologías para apoyar en el Gobierno TI?

 Seguramente una pregunta provocativa - sobre todo a todos los que se dedican a las buenas prácticas y metodologías de Gobierno TI, pero legitimado desde punto de vista de las empresas usuarias de las TI y de los Directores de Sistemas.

Después de meses de trabajo en campo, analizando modelos de Gobierno TI, y lectura de varios estudios sobre el tema, he llegado a la conclusión que no existe un metodología unificada e integrada para Gobierno TI, ni existe un entendimiento común de que se trata. No existen herramientas para Gobierno TI, si no herramientas por un lado a la definición de la área TI (estratégicos) y por otro lado para la operación de las TI (operativas).

El rol del CIO o de los Directores de Sistemas de Información - es orquestar e integrar de forma óptima para su compañía la utilización o no-utilización de todos ellos.

Sobretodo hay que mantener la perspectiva amplia y nivel alto, para no perderse en demasiados detalles. La importancia de todos los estándares y mejoras prácticas del mercado es indiscutible, ayudan a crear una gestión de TI profesionalizada (menos improvisado) y procedimientos de gestión en el TI. Sin ellos no sería posible Gobernar TI adecuadamente. En el siguiente gráfico verá las áreas que alguna manera están cubiertas por un estándar o metodología o herramienta en la gestión del Gobierno TI:
 


*) Fuente propia


 Las áreas marcadas con color verde son las estratégicas, y donde menos metodologías y herramientas se utilizan hoy en día. Estas áreas son los más importantes para la razón de ser del área de TI en la compañía y su convergencia con las áreas de negocio. Por otro lado las metodologías y herramientas no son accesibles o necesarias para la mayoría de las compañías. En una compañía mediana es totalmente factible manejar la creación de un modelo de TI y arquitectura empresarial con herramientas convencionales de análisis y definición. Lo importante es hacerlo, y mantenerlo actualizado y es responsabilidad del CIO y su equipo de primer nivel.

Las áreas marcadas con color azul son las operativas, donde la aplicación de metodologías, mejores prácticas y herramientas está ampliamente entendida en el mercado. También representan la base de toda la operativa de Sistemas de Información, aportando datos necesarios para las decisiones más estratégicas. Es responsabilidad del CIO y su equipo de primer nivel definir las normas y políticas de seguir, pero las tareas se llevan a cabo por el personal de TI, de todas las niveles.

Cada vez más la dirección general de las compañías está más interesado como se gobiernan las TTII en la compañía. Como dijo Alan Calder en su libro IT Governance: "IT is far too important to be left to the IT department!"

Es algo muy normal que en las compañías se responsabilizan de gran parte del Gobierno TI a los Directores Financieros, como Gestión de Riesgos, Compliance y Gestión financiera y controlling del área de TI. Por otro lado al Comité de Dirección o Comité de Inversiones juega un papel decisivo en inversiones en TI, impactando así en el portafolio de soluciones y servicios de TI. Esto no significa que el CIO no tendría un papel decisivo en cada uno de las áreas, su papel está en influenciar, convencer, justificar y vender sus ideas y convicciones a los de más directores de la compañía, así como alertar de los posibles riesgos en hacer o no-hacer las cosas. Resumido, así es como lo hacen el resto de los directores de la compañía cuando compiten de los escasos recursos financieros y humanos.


Libros interesantes sobre el tema :

Añadir leyenda

Añadir leyenda

Añadir leyenda



Añadir leyenda




 



Gobierno TI alineado con el Gobierno Corporativo (parte I)

Gobierno TI - igual como el Gobierno Corporativo en general - es sobre la especificación de los derechos de decisión y el marco de responsabilidades para garantizar un comportamiento deseable en el uso de las Tecnologías de Información en la empresa. El objetivo principal del CIO es alinear su gobierno de las TI al gobierno corporativo garantizando así los controles generales y fomentando la confianza de los accionistas e inversores en la gestión de la compañía.

Cuando definamos el Gobierno de TI, el CIO o Director responsable de TI, debe buscar las respuestas a las siguientes preguntas :

• ¿Mejoran las capacidades de TI la competitividad de la compañía?
• ¿Reconocen los directivos de la compañía sus responsabilidades en la gestión eficaz del uso de las TI o asumen estos directivos que el departamento de TI se encarga de la gestión de TI?
• ¿Aportan las inversiones en TI a los objetivos estratégicos de la compañía y representan las prioridades de la compañía?
• ¿Estamos obteniendo un valor aceptable de las inversiones en TI?
• ¿Quiénes son nuestros clientes y qué productos y servicios les ofrecemos a ellos?

Las respuestas pueden ser diferentes en cada caso, pero lo que importa más es cómo, desde la posición de dirección de TI, logramos dirigir y gestionar el uso de las TI en la compañía sin perder de vista la estrategia de la compañía y la confianza en la gestión de la compañía. Seria mucho más fácil ejecutar las peticiones múltiples de los clientes internos, que tener que evaluar la viabilidad, los beneficios y la prioridad de las peticiones y luego defender su posición.  Claramente responsabilidad de un director de nivel C (CIO, COO, CFO, CxO) y no externalizable.

El Gobierno de TI tiene las siguientes áreas cuales deben ser definidos en la estrategia de TI de la empresa y a continuación organizadas, gestionadas, planificadas y controladas por los responsables de TI :

En todas estas áreas de Gobierno TI existen a su vez activos a controlar. Estos activos claves deben estar alineados con el Gobierno corporativo y operativo del negocio. En caso que la estrategia de TI no haya sido definida con claridad para todas las áreas de control, incluyendo el modelo de gobierno, existirán áreas de TI sin mecanismos de control y con confusión organizativa. 

El Gobierno de TI define las políticas y los objetivos fundamentales, y establece el marco organizativo para TI, así como los mecanismo de control del área de TI.

¿Cómo se diferencia entonces el Gobierno TI de Gestión (Management) de TI?

Simplemente en lo que los Managers de TI deben controlar y ejecutar de acuerdo con las definiciones de Gobierno de TI y Gobierno Corporativo. A eso le llamo yo "modelo de gobierno", porque ya viene dado por la dirección de la compañía y se trata de ejecutarlo en ese modo. 
A veces las definiciones del modelo de gobierno en las compañías no permiten establecer un Gobierno de TI facilmente, y hay que establecer un proyecto complejo involucrando la dirección de compañía. Esto ocurre normalmente en casos como:

• fusiones & adquisiciones o desprender de un parte de negocio
• crecimiento o disminución del negocio / mercado
• internacionalización
• salida a bolsa
• nueva estrategia de la compañía

Si se pretende enfocar un proyecto de Gobierno de TI independientemente del resto de la compañía, no lograremos la alineación con gobierno corporativo, o la convergencia con la unidades de negocio. El hecho de implementar buenas prácticas en la gestión de TI, como ITIL o COBIT, no nos garantiza un Gobierno de TI necesaria para nuestra compañía.

En el Gobierno de TI,  la vinculación con el Gobierno Corporativo de la empresa y las Unidades de Negocio es importante para alcanzar las decisiones correctas en el uso de las TI para cumplir con la estrategia y los objetivos de la empresa.  Normalmente, si una empresa tiene integrado en su gobierno corporativo todos los controles internos, no será necesario crear mecanismos de control independientes para TI en otras áreas clave como las de activos de TI, pero aún así todos los elementos incluidos deben ser gestionados y controlados en las operaciones de TI y organizados para la toma de decisiones:

• Recursos humanos (personal, habilidades, formación, información, competencias, etc.)
• Finanzas & Controlling (presupuestos, inversiones, cobros & pagos, proveedores, etc.)
• Físicos (inventarios de productos y servicios, mantenimiento, seguridad, utilización, etc.)
• Propiedad intelectual (conocimiento de procesos de negocio, servicio de TI o los productos creados, documentación, etc. )
• Relaciones (dentro de la empresa, con clientes y proveedores, competidores, etc.)

En la siguiente tabla puede encontrar ejemplos de los aspectos y activos a controlar dentro de Gobierno TI:

 seguirá..  en breve publicaré la segunda parte del tema, tratando cómo las buenas practicas y metodologías cubren las necesidades de los CIOs para el Gobierno de TI.

...

Porque tenemos problemas en los proyectos de TI

 Llevamos 30 años realizando proyectos desde el área de Tecnologías de la Información, y parece que aún no hemos aprendido a cubrir las expectativas de nuestros clientes.  Seguro que todos hemos visto ya esta viñeta y sin embargo todavía sigue estando de actualidad. Si alguien desea elaborarse su propia versión, lo puede hacer en la página http://www.projectcartoon.com/

¿Pero por qué nos pasa?

Llevo ya  más de 10 años luchando contra este mal. Independientemente del país, continente, tipo de compañía u organización, el problema se repite y repite.... No sabemos traducir las necesidades de negocio a los soluciones de las tecnologías de información. Y hay muchas razones que nos conducen a ello: falta de conocimiento,  falta de madurez de la tecnología, situaciones cambiantes en la compañía y poco compromiso del negocio, equipo de proyecto incapaz, falta de liderazgo, etc. La lista es tan larga como la cantidad de proyectos fracasados en su intento de entregar un producto en las condiciones acordadas.
Yo, definitivamente he llegado a la conclusión que el problema de fondo recae en varios aspectos:

• no somos capaces de ver claramente para qué  estamos haciendo el proyecto. No acabamos de entender cuál es el objetivo del negocio que se quiere lograr mediante la realización del mismo. Y aún si lo hiciéramos,  ¿seriamos capaces de defenderlo o poner en duda los objetivos definidos? Seguramente no tan fácilmente, así que necesitamos que un responsable de negocio defendiera y se responsabilizara de su proyecto de cambio o transformación. Si lográramos una cooperación y entendimiento con el líder de negocio del proyecto, es mucho más probable que seamos capaces de acertar con el producto.
• Las metodologías de gestión de proyecto se enfocan a la actividad de GESTIÓN, y dificilmente encontraremos en ellas métodos sobre cómo "entender al cliente", "cómo diseñar modelos de negocio", "cómo comunicar con el cliente", y así sucesivamente....
• Son muchas las capacidades que se le pide a un buen líder de proyecto, pero una de las más importantes es su conocimiento del negocio, de los procesos y del mercado, así como su capacidad para diseñar soluciones. Es difícil encontrar todas las capacidades en una sola persona, muchas veces se opta por una oficina de proyectos con varios especialistas. Lo más importante es conseguir un equilibrio entre las tres áreas de capacidades, sin que falte  ninguna de ellas. 
• En el peor de los casos, quien lleva la responsabilidad del proyecto TI no tan solo no está alineado con los objetivos de la compañía, sino que lucha por sus propios objetivos (maximizar la facturación del proyecto, estandarizar TI y sistemas, etc. ) lo que provoca que los objetivos principales del proyecto se desvíen o se quiebren.
• Por otra parte, no todo el peso del éxito del proyecto recae sobre el líder del mismo, también la elección del equipo y de los interlocutores es importante. El líder del proyecto debe actuar como un entrenador nacional seleccionando su equipo de proyecto. Si esta elección no está en sus manos, mejor no aceptar el reto por elevado riesgo de que el mismo acabe fracasando.  
• Si además, el encargo del proyecto no viene del responsable del área de negocio, otra razón más para rechazar un proyecto ya que estaría encaminado a no cubrir las expectativas del negocio, aunque culminase con un éxito.