La Gestión Organizacional de Proyectos es la coordinación sistemática de estructuras, capacidades y prácticas para lograr la mejora continua en el desempeño de los procesos temporales (Proyectos, Programas y Portafolios).
Sobre la base de esta definición, los siguientes seis componentes son los bloques de construcción de OPM (ver figura a continuación)

​Antecedentes de OPM

El término Organizational Project Management (OPM) fue acuñado por John Schlichter en mayo de 1998 en una reunión del Comité de Normas del Project Management Institute. OPM se definió como la ejecución de las estrategias de una organización a través de proyectos mediante la combinación de los sistemas de gestión de portafolios, gestión de programas y gestión de proyectos. Esta definición fue aprobada por un equipo de cientos de profesionales de 35 países y se publicó como parte del estándar del Modelo de Madurez de Gestión de Proyectos Organizacionales de PMI en 2003 y se actualizó más tarde a una segunda edición en 2008, cuando también se convirtió en un estándar ANSI. El estándar se actualizó a una tercera edición en 2013. El término "Gestión Organizacional de Proyectos" debe estar en mayúsculas porque el término es una designación convencional para exactamente los sistemas de procesos elaborados en ANSI/PMI 08-004-2008, porque es un nombre propio para ese sistema y ese sistema es definitivo y reglamentado en su aplicación, y porque no denota genéricamente ninguna gestión de proyectos que se realice en las organizaciones.

​​Otras definiciones de gestión de proyectos organizacionales[3]

• Project Management Institute (PMI): OPM3 es la gestión sistemática de proyectos, programas y carteras en alineación con los objetivos estratégicos de la organización (PMI, 2008 p. 24)
• Asociación Japonesa de Gestión de Proyectos (P2M): P2M es "un marco que busca mejorar la capacidad de las organizaciones para responder a las fuerzas externas con el fin de lograr visiones y misiones" (Ohara, 2005 p. 16)
• Aubry et al.: "La gestión de proyectos organizacionales es una nueva esfera de gestión donde las estructuras dinámicas en la empresa se articulan como medios para implementar los objetivos corporativos a través de proyectos con el fin de maximizar el valor". (Aubry, Hobbs, & Thuillier, 2007 p. 4)

Estas definiciones existentes describen los tres paradigmas subyacentes de OPM:

• OPM como Estructura: La organización por proyectos fue vista como una respuesta al dinamismo en el entorno externo, creando nuevos desafíos para las empresas. Originalmente, las organizaciones jerárquicas se diseñaron en torno a procesos repetitivos a largo plazo. Por lo tanto, las empresas se configuraron en estructuras que apoyaban estas actividades. A medida que el entorno se hizo más competitivo, las empresas comenzaron a iniciar un número creciente de proyectos. Estos proyectos comenzaron a influir en las estructuras de las empresas, porque eran sistemas sociales distintos que abarcaban múltiples departamentos, clientes y proveedores. Comenzaron a surgir estructuras flexibles y orientadas a la red y el concepto de gestión de proyectos se aplicó al contexto organizacional en forma de "gestión por proyectos" (Gareis, 1989). En este paradigma, los proyectos, no los departamentos son las unidades de control, y el papel de la dirección es gestionar las relaciones entre los proyectos y sus entornos, tanto internos (dentro de la empresa) como externos (fuera de la empresa). La gestión de estas redes de proyectos requería dos tareas: integración y diferenciación. La integración es responsabilidad de la administración de la empresa e implica la incorporación de las entradas y salidas del proyecto en un marco de toda la empresa. La diferenciación es responsabilidad de los equipos de proyecto e implica la creación de nuevos proyectos para resolver problemas o acceder a oportunidades. En un argumento relacionado, OPM facilita el desarrollo del aprendizaje organizacional. El cambio incremental en un entorno estable o un cambio de primer orden necesita proyectos simples. Un cambio o reposicionamiento más radical y de segundo orden requiere programas y carteras. Las características de los proyectos ayudan a posibilitar iniciativas de cambio, ya que pueden formar un espacio de experimentación con nuevas estructuras y procesos. Los investigadores han argumentado que esta área sigue estando subdesarrollada a medida que la investigación existente analiza los proyectos desde la perspectiva de las operaciones. Como organizaciones temporales, pueden gestionar la incertidumbre de maneras que los departamentos tradicionales no pueden (Thiry y Deguire, 2007); sin embargo, el limitado trabajo teórico o empírico ha explorado estas vías.
• OPM como práctica: Además de la perspectiva estructural, OPM también se ha visto como una colección de prácticas. Utilizando un modelo de madurez, las organizaciones acceden a sus prácticas actuales e identifican sus posiciones relativas en una escala. Aunque el uso de modelos de madurez se ha establecido en el campo de las operaciones, son relativamente nuevos en la gestión de proyectos, habiendo surgido solo en los últimos 20 años (Andersen & Jessen, 2003). En el gráfico 1 que figura a continuación se ofrece un resumen de los principales modelos de madurez de proyectos actualmente en uso.
• OPM como capacidad de integración: Finalmente, OPM se ha propuesto como una competencia o capacidad integradora (Thomas & Mullaly, 2008). Esta perspectiva tiene sus raíces en la visión basada en recursos, una teoría que ve a las empresas individuales como una colección de recursos (Mahoney y Pandian, 1992). Estos recursos pueden entonces ser coordinados, formando la base de la capacidad de una empresa para competir contra sus rivales (Penrose, 1959). Los investigadores han sugerido características particulares de los recursos en la vista basada en recursos (RBV) de la que se puede derivar la ventaja competitiva (Barney, 1991): Valioso, Raro, Inimitable (difícil de imitar) y No sustituible (difícil de reemplazar), resumido con el acrónimo VRIN. Desde este punto de vista, los modelos de madurez de forma aislada no pueden considerarse estratégicos porque son recursos disponibles para todas las empresas. Sin embargo, los recursos basados en el conocimiento que se basan en la cultura y la historia de una empresa pueden exhibir características de VRIN (Wernerfelt, 1995) y respaldar la ventaja competitiva. Sin embargo, identificar tales competencias puede ser difícil, ya que existen pocas medidas estándar (Priem y Butler, 2001)

Entonces, ¿qué es ITOM, de todos modos?
En primer lugar, hay varias definiciones por ahí, dependiendo de la perspectiva del proveedor de definiciones porque, a diferencia de ITSM, no hay una definición aceptada en toda la industria. En segundo lugar, si bien las organizaciones desean "hacer" ITOM, la mayoría de las definiciones que encontrarán hablarán sobre cuáles son las herramientas de ITOM, no sobre cuál es la práctica de ITOM. Por ejemplo:
"El software ITOM es el conjunto de capacidades de administración de TI que las organizaciones necesitan para administrar
de manera efectiva la provisión, la capacidad, la disponibilidad y el rendimiento de la infraestructura de TI, que incluye
recursos informáticos, de red y de aplicaciones".
Esta definición es indicativa de los problemas al definir qué es ITOM y dónde se "sienta": que ITOM está comúnmente definido por la tecnología. Y cada proveedor de soluciones ITOM tiene su propia visión de lo que es ITOM en función de las capacidades de su solución. También parece similar en cobertura a ITSM que, desafortunadamente, hace que sea difícil definir ITOM y posicionarlo claramente contra ITSM.

¿Por qué necesitamos ITOM?
La forma más sencilla de describir el "¿por qué?" de ITOM es hablar sobre la dependencia cada vez mayor que las organizaciones tienen de la tecnología. Ya sea para entregar productos y servicios a los clientes, involucrar a esos clientes a lo largo del ciclo de vida del cliente o permitir que los empleados hagan el trabajo que necesitan hacer cuando lo necesitan. Además de esta mayor importancia, también hay un aumento de los volúmenes y la complejidad de TI, con servicios de TI que potencialmente aprovechan una combinación de capacidades locales, en la nube y otras capacidades proporcionadas por terceros. Las capacidades de ITOM ayudan a abordar esta complejidad y permiten a las organizaciones comprender qué tan bien funciona su infraestructura de TI, incluidas las aplicaciones, y solucionar problemas según sea necesario. Idealmente, antes de que los problemas afecten negativamente las operaciones y los resultados comerciales.

ITOM vs. ITSM
Al posicionar ITOM contra la gestión de servicios de TI, primero aprecie que no es una situación de uno u otro. Más allá de esto, es difícil decir si ITSM es un subconjunto de ITOM, ITOM es un subconjunto de ITSM (especialmente con la cobertura más amplia de ITIL 4), o si se sientan uno al lado del otro con un grado de superposición. Dependerá de la definición y comprensión de ITOM empleada.
La única certeza es que no son capacidades completamente dispares ni exactamente lo mismo: hay cierta superposición sin importar la perspectiva tomada. Esta situación se muestra cuando se consideran las soluciones tecnológicas relevantes:

• Algunos proveedores de herramientas ITOM pueden ofrecer capacidades básicas de ITSM, como la mesa de ayuda.
• Algunos proveedores de herramientas ITSM pueden ofrecer capacidades específicas de ITOM
• Y tanto los proveedores de herramientas ITOM como ITSM ofrecerán capacidades que beneficiarán a ambas disciplinas de gestión de TI, incluso si no las comercializan como tales.

Este desenfoque entre ITOM e ITSM se volvió más complicado cuando ITIL 4 se creó en un lienzo mucho más amplio y algunos profesionales de ITSM ahora podrían considerar que este nuevo cuerpo de orientación de mejores prácticas de ITSM alberga ITOM. Sin embargo, si desea mantener la perspectiva de disciplinas separadas, la afirmación de que "ITSM se centra en los servicios consumidos por los usuarios finales, mientras que ITOM se centra en la infraestructura de TI y sus componentes" es un diferenciador útil. Finalmente, otra perspectiva a considerar, que es ayudada por la definición anterior, es que ITOM no es una "cosa" distinta. En cambio, solo hay operaciones de TI y la tecnología que utilizan: el software ITOM.

Capacidades comunes de ITOM
A pesar de las dificultades para definir qué es y qué no es ITOM, podemos hablar de algunas de las capacidades típicas de ITOM que se ven en las herramientas ITOM e ITSM. Idealmente, deberíamos adoptar una perspectiva empresarial de estas capacidades de ITOM, mientras que con todos los aspectos de TI, existe la necesidad de ofrecer de manera consistente la habilitación tecnológica que una organización necesita. Pero la realidad es que la definición basada en la capacidad de ITOM está fuertemente influenciada por las funciones y características de la tecnología disponible, y esto difiere según un proveedor de tecnología.
Así que aquí hay una lista de lo que una herramienta ITOM podría incluir, no una lista de lo que ofrece cada herramienta ITOM (ni lo que cada proveedor de herramientas ITSM ha agregado para ayudar a sus clientes con sus necesidades ITOM):

• Gestión inteligente de alertas y eventos que ofrece "un único panel de vidrio" y habilitación de IA
• Capacidades de automatización y orquestación restaurativa, incluida la automatización inteligente
  o habilitada para IA
• Análisis de gestión del rendimiento para dispositivos, redes y aplicaciones, incluidas las capacidades de gestión de la experiencia digital
  (DEX)
• Capacidades de administración de dispositivos o clientes, incluida la administración de parches
• Capacidades de descubrimiento, incluida la base de datos de administración de configuración (CMDB), el descubrimiento en la nube y la
  asignación de servicios
• Capacidades de administración de recursos de personas, como la administración de guardia
• Soporte automatizado y predictivo para las prácticas de administración de cambio, implementación, lanzamiento, problemas,
  disponibilidad y capacidad de ITSM
• Capacidades de gestión de la nube enfocadas

Algunas herramientas ITOM también ofrecerán capacidades adicionales fuera de estas. Así que esa es una introducción rápida a lo que es ITOM. 

​Muchos proyectos en una amplia gama de organizaciones fracasan. Pero los expertos en gestión de proyectos recomiendan una serie de mejores prácticas que pueden ayudar a mantener los proyectos en movimiento y tener éxito.
Los expertos recomiendan 15 mejores prácticas en la gestión de proyectos
A continuación, hemos recopilado las 15 mejores prácticas en gestión de proyectos que los expertos dicen que son vitales :

1) Celebre una reunión de lanzamiento, o dos, con el equipo interno y los clientes
Es importante celebrar una reunión de inicio en la que explique los objetivos generales del proyecto y cómo el proyecto encaja con los objetivos estratégicos de la organización. También debe proporcionar una visión general del trabajo y el cronograma. Alan Zucker, consultor de gestión de proyectos y director fundador de Project Management Essentials, dice que debe hacer lo siguiente en la reunión de lanzamiento:

• Establecer reglas básicas sobre cómo avanzará el proyecto.
• Establecer expectativas claras con respecto a los roles y responsabilidades.
• Establecer los objetivos y metas del proyecto.

​
Algunos expertos dicen que es posible que desee celebrar dos reuniones de lanzamiento. La primera reunión debe incluir a cualquier cliente (s) para quien esté haciendo el trabajo, partes interesadas externas importantes y su personal. La segunda reunión puede ser para el personal interno asignado al proyecto.


Aún así, algunos expertos enfatizan la importancia de esa reunión de inicio con todas las manos con su personal, el cliente externo y las partes interesadas importantes. Eso permite a sus clientes o partes interesadas familiarizarse con el equipo del proyecto y permite al equipo obtener una perspectiva más completa de las necesidades y objetivos de un cliente." A veces es posible que necesites tener reuniones separadas. Pero animaría a los equipos a que, con la mayor frecuencia posible, tengan una reunión de equipo con todos los miembros del equipo y los ejecutivos de las partes interesadas presentes para que todos escuchen lo mismo", dice Saman Pourkermani, Director de Transformación Digital y Desarrollo de Productos de Inspirant Group, una consultora de gestión del área de Chicago.

"Es mucho más impactante cuando tengo un representante del cliente hablando con todo el equipo, incluidas las personas que hacen el trabajo diario. De esta manera, entienden: 'Este es mi problema'. Eso significa mucho más para el equipo. Y los motiva", continúa Pourkermani.
​
​
2) Enfatice el propósito general y estratégico del proyecto

No solo mueva a su equipo a un proyecto con una lista de tareas pendientes y una fecha límite. Es importante que cada miembro del equipo entienda cómo el proyecto se relaciona con los objetivos estratégicos generales de la organización.

"Enfatizar el propósito estratégico general de un proyecto, eso es enorme", dice Pourkermani. "Creo que eso es muy importante. Lo destacaría como uno de mis 10 mejores. Y asegúrese de que no solo el liderazgo y las partes interesadas estén en la misma página, sino que todos en el equipo también sepan cuál es el propósito del proyecto. Habrá decisiones que surgirán cuando los miembros del equipo estén trabajando día a día. Cuando tienen ese contexto muy claramente incrustado en su mente, les ayudará a tomar las decisiones correctas más rápido. Tendremos menos situaciones en las que necesito hacer una pausa y levantar una bandera y hacer preguntas para aclarar: '¿Es esto realmente lo que necesitas es esto?' Eso nos ralentiza. Tener ese propósito les ayudará obviamente a crear un producto mucho más significativo"."T ambién es importante ser lo suficientemente inteligente políticamente como para comprender los verdaderos objetivos y metas de la organización para cualquier proyecto y para su dirección estratégica general", dice Sergei Brovkin, consultor internacional de gestión de proyectos y fundador y director de Collectiver, Inc., con sede en Montreal. "Hay un dicho de un político estadounidense hace mucho tiempo que dice que siempre hay dos objetivos: el bueno y el real", dice Brovkin. Con un proyecto, hay dos propósitos: el bueno y el real".

3) Crear una carta de proyecto 

de proyecto es un documento que detalla algunos de los objetivos y requisitos básicos que cubrió en la reunión inicial. La carta del proyecto describe el proyecto e incluye a los participantes clave, el alcance, los objetivos y las metas generales. Las personas siempre pueden consultar el documento y comprender sus responsabilidades.

"[La carta del proyecto] es el certificado de nacimiento del proyecto", dice Brovkin. "Todavía no sabes nada sobre tu hijo, excepto que estos son los padres y este es el nombre. Entonces, tienes un objetivo: el proyecto tiene que lograr esto, esto y esto, y tiene que estar hecho para esta fecha. Este documento hace que su proyecto sea legítimo".


4) Consolide, realice un seguimiento e informe sobre la información del proyecto utilizando una base de datos

Que sea de fácil acceso Querrá monitorear y realizar un seguimiento continuo del progreso en una base de datos en línea a la que todos los miembros del equipo puedan acceder fácilmente." Las herramientas de colaboración son cada vez más complejas, porque terminas teniendo equipos más complejos y más grandes. Y tener esa única versión de la verdad es importante", dice Elizabeth Harrin, directora de Otobos Consultants Ltd, con sede en el Reino Unido, y autora, capacitadora y oradora sobre gestión de proyectos.

Las herramientas que proporcionan este tipo de seguimiento e informes cambian continuamente. Y algunos no se centran tanto en las palabras y los informes detallados como en las imágenes, dice Zucker. 

5) Entrenar a los empleados para dividir las tareas en trozos más pequeños 

Algunas tareas dentro de un proyecto pueden parecer abrumadoras al principio. Y cuando los miembros del equipo se enfrentan a una tarea abrumadora con una fecha límite lejana, a menudo no completan su trabajo antes de esa fecha límite. Los buenos gerentes de proyectos ayudan a enseñar a los miembros de su equipo a dividir las tareas grandes en pequeñas y alcanzables porciones de trabajo. Y luego establecen plazos para cada uno de esos trozos.

6) Mantenga bajo control la fluencia inútil del alcance

• Los clientes externos o los líderes ejecutivos dentro de su empresa a veces querrán sugerir un trabajo nuevo y diferente que el equipo no asumió al comienzo del proyecto o en la carta del proyecto. A veces, ese trabajo adicional no encaja con los objetivos del proyecto o tendrá un efecto importante en los plazos dentro del proyecto, o ambos.
  
  En este punto, los líderes del proyecto deben tratar de convencer a los clientes o ejecutivos de que el trabajo nuevo o ampliado no es apropiado para el proyecto."A veces encuentro que cuando trabajas para un cliente, la gente tiene miedo de retroceder cuando ven cosas que pueden exceder el costo y el cronograma. Así que tienen que tener el coraje de decirle al jefe que el bebé es feo", dice Cindy Young, consultora de gestión de proyectos y presidenta y directora ejecutiva de CJ Young Consulting.
  
  Muchos proyectos todavía siguen adecuadamente el método Waterfall, donde las tareas dependen de la finalización de otras tareas antes que ellos. El deslizamiento del alcance puede ser especialmente problemático en esos proyectos. "Puedes decirle al patrocinador todo lo que saldrá bien o mal con este proyecto si hacen ese cambio", dice Young. 

7) Espere un cambio y acéptelo

Si bien los líderes de proyectos deben luchar contra el deslizamiento del alcance en situaciones específicas, también deben comprender que los cambios son casi inevitables en los proyectos, y esos cambios pueden resultar en un mejor producto y un mejor resultado.

El método ágil de gestión de proyectos, al principio más común en el desarrollo de software, pero ahora utilizado en muchos otros proyectos, abarca los cambios en el proyecto. Incluso los gerentes de proyecto que lideran un método modificado de gestión de proyectos en cascada deben estar listos para los cambios en sus planes iniciales.

"A veces esa es la filosofía con la gestión de proyectos tradicional: minimizar los cambios que surgen porque pueden afectar la línea de tiempo", dice Pourkermani. "En cambio, reconozca el hecho de que el cambio va a ser una constante. Deberíamos esperarlo. Pregunte: '¿Cómo nos volvemos buenos para gestionar el cambio, adaptándonos rápidamente en función del cambio, y realmente tomándolo y usándolo a nuestro favor?'"

Harrin, de Otobos Consultants, pregunta: "¿Qué hay de malo en cambiar lo que está en el alcance? Si va a hacer que el producto sea más útil, debemos ser mucho más ágiles para lograr lo que nuestros grupos de interés quieren en un entorno en constante cambio".

Cuando surgen problemas relacionados con posibles cambios, puede ser útil reunir a su equipo para intercambiar una solución. Contar con las herramientas adecuadas para facilitar la colaboración y la comunicación acelerará este proceso y la eventual resolución. 

8) Verifique regularmente con los clientes y las partes interesadas

Es vital verificar regularmente con los clientes para los que está trabajando, así como con otras partes interesadas clave. Estos check-ins le permitirán dar una actualización y obtener sus opiniones.

"Busque comentarios regulares de los clientes y las partes interesadas clave", dice Zucker. "Muéstrales lo que estás desarrollando. Esto reduce las brechas en las expectativas de entrega".

Pourkermani también sugiere mantener reuniones periódicas con todo el equipo, incluidos los clientes y las partes interesadas importantes. Si el equipo completo incluye cientos de personas, esas reuniones pueden ocurrir solo una vez cada tres meses. Si el equipo incluye una docena de personas, celebre las reuniones cada dos semanas o meses.

"El propósito de [estas reuniones] es simplemente mantenerse alineado y sincronizado como un equipo de proyecto, con sus partes interesadas y clientes", dice.


9) Revise y realice continuamente los cambios necesarios en el proyecto y sus procesos

Debe hacer más que aceptar el cambio en los elementos de su proyecto a medida que realiza el trabajo, también debe estar dispuesto a realizar cambios en sus procesos.

"Debemos centrarnos en tener retrospectivas frecuentes a lo largo del proyecto", dice Pourkermani. "No se trata solo del producto o de lo que estamos construyendo o entregando, sino también de cómo estamos trabajando en el proceso que estamos utilizando. Por ejemplo, ¿el proceso de planificación que estamos haciendo es la forma más efectiva? Reevalúe con frecuencia a lo largo de su proyecto y tenga un mecanismo para mejorar continuamente la forma en que realmente está haciendo el trabajo".

"Agile tiene estas retrospectivas", dice Harrin, "por lo que estamos iterando en el rendimiento y el proceso al final de cada iteración".

Zucker es un defensor de Kaizen, una práctica nacida en Japón que se centra en la mejora continua de los procesos. La palabra japonesa se traduce en "cambio para mejor", y las organizaciones utilizan la práctica en la gestión de proyectos, la fabricación y otras áreas.

"Kaizen es un concepto que surgió de Toyota y el sistema de producción Lean de la compañía", dice Zucker. "Era la idea de que los equipos de trabajadores que estaban construyendo automóviles pudieran identificar formas de mejorar el proceso, y esos cambios se implementaron realmente. Toda esa idea de mejora continua, en Agile a escala lo llaman mejora implacable, es la idea de que al final de nuestros sprints, tenemos nuestra retrospectiva de sprint, donde identificamos formas de mejorar. Y en realidad implementamos esas mejoras, o algunas de esas mejoras, en nuestra próxima iteración o nuestro próximo sprint".

Para obtener más información sobre Lean y Kaizen, visite "The Definitive Guide to Lean Project Management".

10) Haga que su relación con su cliente sea una prioridad

Young dice que eso significa más que check-ins obligatorios. Eso significa que lees y respondes sus correos electrónicos, así como devuelves sus llamadas telefónicas, rápidamente.

"Su cliente se siente importante y más que solo dólares", dice. "Cuando tu cliente se dé cuenta de que lo estás priorizando, responderá a las preguntas necesarias para apoyarlo y no sentirá que solo estás trabajando para ellos, sino que también eres parte de su equipo".

11) Desarrollar un proceso para escalar problemas y problemas de manera apropiada

Los problemas y problemas a menudo se enconan en los niveles inferiores de un equipo de proyecto. Los trabajadores de nivel inferior no quieren informar a los líderes de proyectos senior, clientes y partes interesadas clave de los problemas por temor a la reprimenda o la censura.

Al principio del proyecto, cree una matriz de escalamiento de problemas que identifique el nivel de importancia de un problema y la ruta de escalamiento adecuada para los diferentes tipos de problemas.

Zucker también dice que la escalada puede ocurrir de manera menos formal, si tiene reuniones diarias de pie y reuniones de seguimiento que forman parte de Agile y otros métodos de gestión de proyectos.

"Crear procesos para que los problemas y cuestiones se resuelvan rápidamente", dice. "Identifique los problemas en la reunión diaria de pie y resuélvalos inmediatamente en la reunión posterior".

12) Asegúrese de que la documentación adecuada del trabajo, los cambios, la toma de decisiones y el progreso

Mantenga documentos detallados sobre los conceptos básicos de lo que está sucediendo con el proyecto. Esto significa documentar los objetivos y tareas del proyecto, los cuellos de botella, los cambios de alcance y las dependencias de las tareas. Esta documentación puede ayudar a los nuevos miembros del equipo a familiarizarse con el proyecto. También puede ayudarlo a tomar mejores decisiones y aprender de los problemas y problemas.

El software que su equipo utiliza para ayudar a monitorear y rastrear el proyecto debería ayudar a su documentación. 

13) Prepárese para matar un proyecto si es necesario

A veces es necesario reconocer que los objetivos de su proyecto ya no encajan con las realidades comerciales. Esas realidades comerciales (la demanda potencial de un producto o la utilidad de un producto en el mercado) pueden cambiar rápidamente."Ahora nos estamos encontrando con un tipo diferente de deslizamiento de alcance", dice Raman Attri, autor y orador sobre gestión de proyectos y competencia empresarial. "Porque lo que pasa es que cuando ejecutamos los proyectos, el peligro no es salirse del alcance. El peligro es que las tecnologías cambien mientras tanto, por lo que la solución que teníamos originalmente en mente puede que ni siquiera sea viable".

Cuando eso sucede, necesita líderes de proyecto lo suficientemente fuertes como para recomendar terminar todo el proyecto. Tienes que asegurarte de no desperdiciar más recursos organizativos en una mala idea de repente.

En esos casos, su organización debe tomar una decisión muy básica, dice Attri. "¿Deberíamos seguir haciendo este proyecto o deberíamos matarlo? Hay casos en los que la administración ha sido muy dura al matar el proyecto, porque saben que ya no es válido", dice.

14) Comprender la importancia del contexto

Cada organización y cada proyecto es diferente. Incluso un proyecto similar dentro de la misma organización es diferente cuando ocurre en un momento diferente.

La conclusión es que el entorno y el contexto en el que existe un proyecto son muy importantes. Tenga esto en cuenta al considerar qué mejores prácticas son esenciales seguir para su proyecto y cuáles puede dejar atrás.

"Una de las cosas de las que paso mucho tiempo hablando cuando estoy enseñando es la idea de que el contexto cuenta", dice Zucker, de Project Management Essentials. "Cada proyecto, cada organización y cada industria es algo diferente. Reconozca que los proyectos y la gestión de proyectos no son un esfuerzo único para todos. Cuando toma decisiones como gerentes de proyectos, debe comprender el entorno en el que está operando y luego tomar decisiones en consecuencia. Eso es muy valioso".

15) Las mejores prácticas no son solo una lista: es un proceso continuo con ajustes

Harrin, de Otobos Consultants, dice que no está haciendo una buena gestión de proyectos si solo sigue una lista de mejores prácticas. Debe hacer ajustes que tengan sentido, incluso si no están en una lista o incluso parecen diferentes de las mejores prácticas tradicionales.

"El término 'mejores prácticas' implica que hay un conjunto de cosas que tenemos que hacer y marcar cada casilla", dice. "Y debido a cómo la gestión de proyectos ahora se está alejando de Waterfall ... en una forma que es mucho más inclusiva, que cubre metodologías ágiles e híbridas, entonces no hay un solo conjunto de mejores prácticas. Así que lo que se te ocurre es una lista de cosas buenas que la gente debería hacer. Pero no estoy seguro de que me sentiría cómodo describiendo todo lo que hago como una "mejor práctica". Eso implica que cualquier cosa que se desvíe de eso es incorrecta, de alguna manera. O que podría no darte un resultado óptimo".

Una historia concisa de la gestión de proyectosHay una larga historia que ha dado forma a lo que la gestión de proyectos encarna hoy en día. Comenzando con los diagramas de Gantt que permiten a las personas trazar visualmente las dependencias, el estado del proyecto y los plazos a través del desarrollo final del Manifiesto para el Desarrollo Ágil de Software, la gestión de proyectos moderna sigue creciendo hoy en día. Varias metodologías son ampliamente utilizadas hoy en día; a continuación se muestra la línea de tiempo que narra los avances en la gestión de proyectos.

• 1917 - El diagrama de Gantt, con su combinación de tiempos y tareas, proporcionó un método formal para documentar y mostrar las etapas del ciclo de vida del proyecto (iniciar, planificar, ejecutar, monitorear, controlar y cerrar). Con la evolución del diagrama de Gantt, todos estos podrían describirse en un gráfico simple que permitiera a un gerente de proyecto ver el estado del proyecto. El diagrama de Gantt se utilizó en el desarrollo de la presa Hoover en 1931. Menos conocido que Henry Gantt fue Louis Fayol, cuyas funciones de gestión se convirtieron en el conjunto básico de funciones de gestión de proyectos que aún se observan hoy en día: planificación, organización, dotación de personal, dirección, coordinación y control.
  
  
• 1957 - Morgan R. Walker de DuPont y James E. Kelley, Jr. de Remington Rand desarrollaron el Método de Ruta Crítica (CPM), que predijo cuánto tiempo tomaría un proyecto al centrarse en las actividades menos flexibles. CPM demostró su valía en el primer año en que DuPont lo intentó al ahorrarle a la compañía un estimado de $ 1 millón.
  
  
• 1957 - Justo después de CPM fue la Técnica de Revisión de Evaluación de Programas (PERT), que se inventó para el proyecto submarino Polaris de la Armada de los Estados Unidos. PERT se centró en definir tanto las tareas como el tiempo de cada tarea necesaria para completar un proyecto. Un proyecto PERT determinó el tiempo total y mínimo requerido para la finalización del proyecto, y se utilizó principalmente para estimar el riesgo del cronograma del proyecto. Curiosamente, aunque PERT se hizo popular tras el éxito del proyecto Polaris, no se utilizó en la mayoría del proyecto.
  
  
• 1965 – Este año vio la formación de la Asociación Internacional de Gestión de Proyectos (IPMA), que comenzó en Viena como una asociación profesional de gerentes de proyectos. Actualmente es una federación de aproximadamente cincuenta asociaciones de gestión de proyectos en todo el mundo.
  
  
• 1969 - El Project Management Institute (PMI) es la organización de gestión de proyectos más conocida de los Estados Unidos. Fue fundada en 1969 como una organización sin fines de lucro dedicada a la práctica, la ciencia y la profesión de la gestión de proyectos. Celebró su primer simposio en 1969 y desde entonces ha estado promoviendo la gestión de proyectos como profesión. El Project Management Institute ofrece certificaciones para Certified Associate in Project Management (CAPM) y Project Management Professional (PMP). ® Además de sus otros servicios y actividades, PMI desarrolló y publicó el texto, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) como un libro blanco. Desde entonces, la guía ha crecido y se ha convertido en un trabajo seminal en la gestión de proyectos. El libro blanco se revisó en un libro en 1996 y se revisó de nuevo en 2000 y 2004. La Guía PMBOK define la gestión de proyectos como "la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del proyecto".
  
  
• 1975 - El Método PROMPTII se originó debido a una crisis en los proyectos informáticos, que se estaban ejecutando constantemente atrasados en el tiempo y el presupuesto. PROMPTII se centró en establecer directrices para el flujo de un proyecto de una fase a la siguiente y fue adoptado por la Agencia Central de Computación y Telecomunicaciones (CCTA) del Gobierno del Reino Unido en 1979.
  
  
• 1989 - PROMPTII condujo al desarrollo del Método PRINCE en 1989, que fue publicado por la misma Agencia Central de Computación y Telecomunicaciones. El Método PRINCE era demasiado engorroso para tener éxito, pero fue revisado en 1996 en PRINCE2 y tuvo mucho más éxito. Un comité compuesto por 150 organizaciones europeas contribuyó a su desarrollo. Si bien PRINCE tenía la intención de reducir los costos de TI y los excesos de tiempo, también se desarrolló como una metodología de gestión de proyectos para cualquier tipo de proyecto. PRINCE2 emitió una revisión importante en 2009 que simplificó el método e introdujo siete principios básicos del éxito del proyecto.
  
  
• 1984 - El Dr. Eliyahu M. Goldratt desarrolló la Teoría de las Restricciones (TOC) en la novela The Goal en 1984. El TOC estaba destinado a ayudar a las organizaciones a lograr un objetivo centrándose en eliminar las limitaciones que dificultan el logro. Goldratt más tarde redesarrolló TOC en Critical Chain Project Management (CCPM). Una red CCPM mantiene los recursos distribuidos a nivel, pero requiere tiempos de inicio flexibles para que puedan cambiar entre tareas y cadenas de tareas para mantener el proyecto a tiempo.
  
  
• 1986 - Se desarrolló Scrum, el modelo de desarrollo de software ágil basado en múltiples equipos pequeños que trabajan en un entorno colaborativo y de ritmo rápido. Takeuchi y Nonaka le dieron al método el nombre de "Scrum" en su artículo "The New New Product Development Game" (Harvard Business Review, 1986). Scrum ha sido adoptado y adaptado más allá del mundo del desarrollo de software y se utiliza en varios lugares.
  
  
• 2001 - En febrero de 2001, diecisiete líderes de pensamiento de desarrollo de software se reunieron en el resort The Lodge en Snowbird, Utah, para discutir sus frustraciones con las metodologías y marcos tradicionales de desarrollo de proyectos. De este encuentro surgió el Manifiesto para el Desarrollo Ágil de Software. Agile generalmente se conoce como un "movimiento" en lugar de una metodología y se encarna en Cuatro Valores y Doce Principios. Una variedad de metodologías han surgido del Manifiesto Ágil, incluyendo Scrum, Kanban, eXtreme Programming y más.

Marcos de gestión de proyectos
La Guía PMBOK describe un marco de gestión de proyectos como una estructura básica para comprender la gestión de proyectos. Hay varios marcos disponibles y los gerentes de proyecto elegirán el marco que funcione mejor para el proyecto o proyectos dentro de su negocio. Las organizaciones a menudo aprovechan múltiples marcos que son específicos de una unidad departamental o del tipo de proyecto.

• PRINCE2
  PRINCE2 combina el método PROMPTII original con la metodología MITP (Managing the Implementation of the Total Project) de IBM. PRINCE2 se centra en definir y entregar productos que cumplan con precisión los requisitos. Está menos centrado en dividir tareas que en producir el producto. Como tal, difiere notablemente de Agile. Por ejemplo, PRINCE2 está muy preocupado por la etapa de planificación del proyecto: los miembros del equipo se centran en definir los requisitos del producto por adelantado para limitar el cambio en el futuro. Por el contrario, Agile promueve la flexibilidad con la capacidad de responder al cambio a lo largo del proceso de desarrollo.
• Critical Chain Project Management (CCPM)
  CCPM está diseñado para hacer frente a las incertidumbres inherentes a la gestión de proyectos. CCPM se centra en la asignación de recursos, incluido el personal, las habilidades, la gestión y la capacidad durante el proyecto. El objetivo es mantener el nivel de carga para todos los recursos.
• Lean
  El concepto central de la gestión de proyectos Lean es ofrecer un alto valor con un desperdicio mínimo. Lean busca lograr esto a través de la estandarización, la compatibilidad maximizada, la seguridad, la repetibilidad, la interoperabilidad y la calidad. Lean a menudo emplea la metodología Six Sigma, que está orientada a mejoras de calidad a través de la eliminación de defectos. Los defectos se eliminan mediante la estandarización y formalización de los procesos. El método Kanban se considera un enfoque Lean. Kanban es una metodología de mantenimiento que comienza con el proceso existente y busca la mejora incremental a lo largo del tiempo. Las tareas se colocan en un tablero Kanban y se extraen del tablero a medida que los recursos están disponibles. Kanban no tiene una fecha de finalización del proyecto establecida; el proyecto simplemente continúa y los recursos realizan continuamente nuevas tareas.
• Extreme Project Management/Megaproject (XPM)
  Extreme Project Management (XPM) es un marco desarrollado para satisfacer las necesidades de proyectos muy complejos y, a menudo, altamente elásticos. XPM está más preocupado por la gestión de las partes interesadas que por los plazos y los diagramas de Gantt. En un proyecto tradicional, el entregable es mucho menos complejo, el cambio es costoso y, por lo tanto, se minimiza, se supone que la tecnología es relativamente inmutable y el proyecto está impulsado por el plan del proyecto. Esto no se escala bien en entornos de alta tecnología donde el cambio es una constante porque la tecnología en rápida evolución impulsa el mercado. XPM está destinado a emparejarse con eXtreme Programming (XP) y se caracteriza por períodos de desarrollo muy cortos (sprints) de dos semanas o menos, innovación y colaboración muy alta.
  Un gerente de proyecto XPM debe ser capaz de aceptar el cambio tanto como el equipo de desarrollo. El gerente de proyecto de XPM está involucrado en la negociación con las partes interesadas, la comunicación con los miembros del equipo, la eliminación de obstáculos para el éxito y ayudar a los miembros del equipo a mantener la mentalidad adecuada.
• Scrum
  Scrum es similar a XP en que se basa en sprints cortos, pero los sprints Scrum son más largos, generalmente de dos a cuatro semanas. Se dedica un solo día a la planificación, y luego comienza el desarrollo. Se lleva a cabo una reunión diaria para repasar lo que se ha completado, los obstáculos para completar y lo que aún está pendiente. Las tareas completadas se demuestran a las partes interesadas al final del ciclo de sprint, se realizan las pruebas y comienza un nuevo sprint.
• Cascada
  La metodología Waterfall es generalmente considerada como un enfoque tradicional para la gestión de proyectos. Waterfall se basó en la noción de que todo sucede en secuencia, con una fase de un proyecto que termina antes de que comience otra. Esto creó muchas dependencias y también resultó en algunas situaciones bastante desastrosas para el desarrollo de software: los proyectos a menudo estaban retrasados o por encima del presupuesto. Además, Waterfall no podía acomodar la tecnología que cambiaba rápidamente, por lo que los proyectos a menudo se cancelaban antes de que pudieran completarse porque ya estaban desactualizados mientras aún estaban en desarrollo.

¿Por qué hay tantos marcos de gestión de proyectos?
Cada marco tiene sus propias fortalezas y debilidades, pero lo que es más importante, los proyectos tienen sus propias necesidades y recursos. Algunos elementos que pueden determinar qué marco emplear son el tipo de negocio (grande vs. pequeño, fabricación vs. software), la naturaleza única de los proyectos (desarrollo de un producto versus mantenimiento), o los diferentes departamentos que utilizan el método.
Por ejemplo, el marco PRINCE2 podría utilizarse para controlar los costos en un entorno donde los sobrecostos han sido comunes y la administración está tratando de ralentizarlos. CCPM puede introducirse en un entorno donde hay muchos obstáculos para completar un proyecto a tiempo, como un cliente que quiere nuevas características o incluso desarrollar productos completos que están fuera del alcance inicial del proyecto. En ese escenario en particular, se podría introducir un marco ágil para adaptarse al cambio en lugar de un método para superar el cambio.

Roles de gestión de proyectos y áreas de conocimiento

Para comprender completamente los marcos de gestión de proyectos, es importante comprender los roles de gestión de proyectos y las áreas de conocimiento de gestión de proyectos.

Roles
Hay una variedad de roles que contribuyen a una gestión efectiva de proyectos, siendo cada persona responsable de sus tareas asignadas.

• El gerente de proyecto: el rol de gerente de proyecto es fundamental para el éxito general del proyecto y es responsable de la iniciación, ejecución y control general del proyecto. Además, son responsables de completar o cerrar el proyecto. El gerente de proyecto aplica las lecciones aprendidas de proyectos anteriores al proyecto actual, define los roles y trabajos del equipo, lidera la planificación y el monitoreo del proyecto, administra el riesgo, busca oportunidades para implementar las mejores prácticas, se comunica con el equipo y las partes interesadas, promueve la participación del cliente y realiza cualquier otra tarea requerida para mantener el proyecto dentro del presupuesto especificado y entregado a tiempo.
• Comité Directivo Ejecutivo: el Comité Directivo Ejecutivo generalmente comprende representantes de diferentes departamentos dentro de la organización más grande, todos los cuales son partes interesadas hasta cierto punto. El comité directivo es responsable de aprobar los entregables y las modificaciones en el alcance del proyecto, así como de proporcionar orientación general para adherirse a la estrategia. Otras actividades del comité directivo pueden incluir la obtención de recursos y la comunicación con altos ejecutivos. El papel del Comité Directivo Ejecutivo es razonablemente fluido en el sentido de que se pueden agregar tareas adicionales según sea necesario.
• Patrocinador Ejecutivo: el Patrocinador Ejecutivo tiene un gran interés en el éxito del proyecto porque se ve directamente afectado por el resultado y, a menudo, es responsable de asegurar la financiación y los recursos para el proyecto. El patrocinador ejecutivo defiende el proyecto, se mantiene informado en todas las actividades principales del proyecto (como el estado de los entregables), es el máximo responsable de la toma de decisiones, tiene la aprobación final de los cambios de alcance y aprueba las aprobaciones. Cualquier hito o peligro importante debe comunicarse al Patrocinador Ejecutivo.
• Propietario del proyecto: el propietario del proyecto es a menudo la parte interesada clave del proyecto y debe tener una visión clara de lo que se va a construir y comunicar esa visión al resto del equipo. El propietario del proyecto entiende a los usuarios, el mercado, la competencia y las tendencias futuras.
• Experto en la materia : un experto en la materia es un experto en un área o tema en particular y proporciona orientación, generalmente al propietario del proyecto, cuando se necesita claridad para comprender una característica y su desarrollo.
• Oficina de Gestión de Proyectos u Oficina de Gestión de Cartera (PMO): la Oficina de Gestión de Proyectos es el grupo, equipo u unidad de negocio de la organización que es responsable de establecer los estándares de gestión de proyectos, proporcionar herramientas y actuar como punto de contacto para el equipo de gestión de proyectos. Existen diferentes niveles de PMO, que incluyen, entre otros, Enterprise PMO, Project Support PMO y Center of Excellence.
• Equipo de gestión de proyectos: el equipo de gestión de proyectos ejecuta tareas y produce entregables como se describe en el plan de proyecto y dirigido por el gerente de proyecto.

Áreas de conocimiento
Para gestionar un proyecto, la Guía PMBOK define las áreas de conocimiento básicas que un gerente de proyecto debe entender. Estas áreas de conocimiento son el método que utiliza la Guía PMBOK para categorizar las áreas de experiencia necesarias para gestionar y completar proyectos con éxito.

• Gestión de la integración de proyectos: coordina todos los aspectos de un proyecto, garantiza que todos los procesos se ejecuten sin problemas y produce una serie de entregables.
• Gestión del alcance del proyecto: garantiza que el alcance de un proyecto se defina y asigne con precisión y permite a los gerentes y supervisores del proyecto asignar los recursos de manera adecuada.
• Gestión del tiempo del proyecto: crea procesos y resultados en un proyecto que ayudan al gerente y al equipo a completarlo de manera oportuna.
• Gestión de costos del proyecto: planifica y controla el presupuesto de un proyecto, incluida la estimación, el presupuesto, el financiamiento, la financiación, la administración y el control de los costos para que pueda completarse dentro del presupuesto aprobado.
• Gestión de la calidad del proyecto: garantiza que las actividades necesarias para diseñar, planificar e implementar un proyecto sean efectivas y eficientes.
• Gestión de recursos humanos de proyectos: identifica, documenta y asigna roles, responsabilidades y relaciones de informes del proyecto.
• Gestión de comunicaciones de proyectos: garantiza que las partes interesadas se comuniquen correctamente y determina qué artefactos de comunicación se intercambian durante el proyecto.
• Gestión de riesgos de proyectos: identifica, analiza y responde a los factores de riesgo durante un proyecto.
• Gestión de adquisiciones de proyectos: supervisa el trabajo realizado por terceros fuera del equipo del proyecto, incluida la administración y gestión de contratos, el cambio del proceso de control y las órdenes de compra.
• Gestión de partes interesadas del proyecto: identifica, analiza, planifica e implementa acciones diseñadas para interactuar con las partes interesadas. Individuos o grupos con interés en el proyecto y pueden estar involucrados en el trabajo o afectados por el resultado.

Seleccionar el marco adecuado es fundamental para el éxito
Con cualquier marco y cada uno con sus propias fortalezas y debilidades, elegir el marco adecuado para un proyecto es fundamental para el éxito.
La gestión de proyectos ha evolucionado para incluir una amplia gama de marcos y metodologías de mejores prácticas. Agile, por ejemplo, ofrece una serie de metodologías más allá de las pocas descritas anteriormente. El marco adecuado es esencial para que un proyecto tenga éxito a tiempo y en la conclusión del presupuesto. Elegir el marco adecuado significa observar cuidadosamente a las partes interesadas y los miembros del equipo y comprender sus fortalezas y debilidades, medir el proyecto y conocer cuáles son sus requisitos, hacer coincidir los recursos con las tareas y comprender el grado en que todo esto puede cambiar. Si adopta un enfoque cuidadoso y elige el marco adecuado, es muy probable que complete su proyecto con gran éxito.

¿Qué es un proyecto?
Un proyecto es un esfuerzo único para producir un conjunto de entregables dentro de limitaciones de tiempo, costo y calidad claramente especificadas. Los proyectos son diferentes de las operaciones comerciales en términos de singularidad, escala de tiempo, presupuesto, recursos, riesgo y cambio.
 
• Singularidad. Cada proyecto es diferente del anterior, mientras que las actividades operativas suelen implicar procesos repetitivos (si no idénticos).
• Escala de tiempo. Un proyecto tiene fechas de inicio y finalización claramente especificadas dentro de las cuales se producen los entregables para cumplir con los requisitos del cliente.
• Presupuesto. Un proyecto tiene un límite máximo de gastos dentro del cual se deben producir los entregables para cumplir con los requisitos del cliente.
• Recursos. A un proyecto se le asigna una cantidad específica de mano de obra, equipo y materiales al comienzo.
• Riesgo. Un proyecto implica incertidumbre y, por lo tanto, conlleva un riesgo comercial.
• Cambio. El propósito de un proyecto suele ser mejorar una organización a través de la implementación del cambio empresarial.
 
¿Qué es la gestión de proyectos?
La gestión de proyectos es la utilización de habilidades, herramientas y procesos de gestión para llevar a cabo un proyecto con éxito. Una metodología de gestión de proyectos incluye:
• Un Conjunto de habilidades. El conocimiento especializado, las habilidades y la experiencia ayudan a reducir el nivel de riesgo de un proyecto y, por lo tanto, aumentan su probabilidad de éxito.
• Un conjunto de Herramientas. Los gerentes de proyecto usan varios tipos de herramientas para mejorar la tasa de éxito de un proyecto. Los ejemplos incluyen; plantillas, formularios, registros, software y listas de verificación.
• Una Serie de Procesos. Se necesita un conjunto de procesos de gestión para supervisar y controlar el proyecto, como la gestión del tiempo, la gestión de costes, la gestión de calidad, la gestión de cambios, la gestión de riesgos y la gestión de problemas.
 
El ciclo de vida del proyecto
Un ciclo de vida del proyecto se define como una serie de fases que se llevan a cabo para entregar un resultado requerido del proyecto. El ciclo de vida de la gestión de proyectos de INNOVAXIONES consta de cuatro fases,
 
 
Inicio del proyecto
Para iniciar formalmente un proyecto, el equipo primero debe definir el propósito y la estructura del proyecto. Definir el alcance, el propósito, los objetivos, los entregables, los recursos, los plazos y la estructura de los proyectos le brinda al equipo una visión clara de los límites dentro de los cuales deben entregar los resultados del proyecto para cumplir con los requisitos del cliente. ¡Es fundamental establecer una dirección clara desde el principio! a su éxito final.
El primer paso necesario para establecer la dirección del proyecto es desarrollar un Business Case, que incluye una descripción de todas las posibles soluciones que entregará el proyecto y un análisis de costo/beneficio para cada una. Al realizar un estudio de factibilidad, puede asegurarse de elegir una solución recomendada que sea factible y tenga un nivel de riesgo aceptable. Una vez que haya elegido una solución, el siguiente paso es definir la Charter del proyecto, que describe los límites para entregar esa solución. Luego viene el nombramiento del equipo del proyecto y el establecimiento del entorno de la Oficina de Proyectos.
A estas alturas, con su proyecto claramente definido, un equipo de proyecto debidamente calificado designado y un entorno de oficina de proyectos funcional, tendrá todos los ingredientes correctos necesarios para entregar un proyecto exitoso. El paso final de la fase de Inicio consiste en realizar una Revisión de Fase para solicitar la aprobación para pasar a la fase de Planificación.
 
Planificación de proyectos
El primer paso de la fase de Planificación es la creación de un Plan de Proyecto detallado. El Project Manager se referirá a este plan durante todo el proyecto para monitorear y controlar el tiempo, el costo y la calidad, los tres principios básicos de la gestión de proyectos. El Project Manager luego creará un:
• Plan de recursos para identificar la cantidad de mano de obra, equipos y materiales necesarios
• Financia/ Plan para cuantificar la financia! gastos incurridos para completar
• Plan de calidad para establecer objetivos de calidad y enumerar los métodos de garantía y control de calidad
• Plan de Riesgos para identificar los riesgos y planificar las acciones necesarias para mitigarlos
• Plan de aceptación para especificar los criterios del cliente para aceptar entregables
• Plan de Adquisiciones para identificar los recursos y plazos para la subcontratación externa! proveedores
• Proceso de selección para enumerar los pasos necesarios para seleccionar proveedores preferidos
• Declaración de trabajo (SOW) para documentar los requisitos de adquisición del proyecto
• Solicitud de información (RFI) para solicitar información general a los proveedores interesados
• Solicitud de propuesta (RFP), para solicitar propuestas detalladas de proveedores preseleccionados
• Contrato Formal de Proveedores, para contratar a los proveedores preferentes del proyecto
Se lleva a cabo una revisión de fase para permitir que el patrocinador del proyecto evalúe los entregables producidos hasta la fecha y apruebe el inicio de la fase de ejecución del proyecto.
 
Ejecución y control del proyecto
En esta fase, el equipo del proyecto construye físicamente cada entregable. Mientras se construyen los entregables, el Project Manager monitorea y controla la entrega del proyecto al emprender:
• Gestión del tiempo: seguimiento y registro del tiempo dedicado a completar las tareas del proyecto en relación con el plan del proyecto
• Gestión de costos: identificación y registro de costos (es decir, gastos) contra el presupuesto del proyecto
• Gestión de calidad: revisión de la calidad de los entregables y procesos de gestión
• Gestión de cambios: revisión e implementación de solicitudes de cambios en el proyecto
• Gestión de riesgos: evaluar el nivel de riesgo del proyecto y emprender acciones de mitigación de riesgos
• Gestión de problemas: identificar y resolver problemas del proyecto, siempre que sea posible
• Gestión de compras: recepción y aceptación de artículos de compras y gestión del desempeño de los proveedores
• Gestión de la aceptación: identificar la finalización de los entregables y obtener la aceptación de los clientes
• Gestión de las comunicaciones: mantener informados a los interesados ​​del proyecto sobre el progreso, los riesgos y los problemas del proyecto
Una vez que el cliente haya aceptado todos los entregables y haya realizado una revisión de fase para determinar si el proyecto ha logrado sus objetivos, el proyecto está listo para cerrarse.
 
Cierre del proyecto
Cerrar formalmente un proyecto implica una cantidad razonable de trabajo. Primero se crea un Informe de cierre del proyecto para enumerar todas las acciones necesarias para cerrar el proyecto. Cuando el patrocinador del proyecto ha aprobado este informe, las acciones enumeradas se completan para liberar los recursos del proyecto, entregar los entregables, cerrar la oficina del proyecto e informar a todas las partes interesadas que el proyecto ahora está cerrado.
Entre uno y tres meses después de que se haya cerrado el proyecto, una parte independiente realiza una revisión posterior a la implementación para determinar el éxito general del proyecto e identificar si la empresa realmente obtuvo los beneficios establecidos en el Business Case original. Cualquier lección aprendida también se documenta para proyectos futuros.

A) Iniciación del proyecto El inicio del proyecto es la primera fase del ciclo de vida del proyecto y consiste esencialmente en poner en marcha el proyecto. Inicia un proyecto definiendo su propósito y alcance, la justificación para iniciarlo y la solución a implementar. También deberá contratar un equipo de proyecto adecuadamente capacitado, configurar un entorno de oficina de proyectos y realizar una revisión de fase antes de pasar a la segunda fase del ciclo de vida del proyecto: planificación del proyecto.
La fase de inicio del Proyecto implica los siguientes seis pasos clave:
 
- Desarrollar un caso de negocios
- Crear un estudio de factibilidad
- Establecer la Carta del Proyecto
- Designar el equipo del proyecto
- Establecer una oficina de proyectos
- Realizar revisión de fase
 
- Desarrollar un caso de negocio. El primer paso para iniciar un nuevo proyecto es la creación de un Business Case integral. Un caso de negocio describe el problema/oportunidad de negocio que debe abordar el proyecto y las soluciones alternativas. También se incluyen los costos y beneficios potenciales asociados con cada solución. El Business Case se convierte en la base del proyecto, ya que describe completamente el proyecto, las razones para crear el proyecto y los beneficios clave que producirá el proyecto.
- Realizar un estudio de factibilidad. Luego se completa un estudio de factibilidad para identificar la probabilidad de que las soluciones alternativas brinden los beneficios establecidos en el Business Case. Con base en los resultados del estudio de factibilidad y los beneficios y costos descritos en el caso de negocios, el patrocinador del proyecto identifica y aprueba una solución preferida.
- Establecer la Carta del Proyecto. Luego se define un nuevo proyecto para entregar la solución aprobada. El Acta de Constitución del Proyecto está documentada y describe esencialmente lo que el proyecto se propone lograr y los límites dentro de los cuales debe lograrlo. La visión del proyecto, los objetivos, el alcance, los entregables, la organización del proyecto y un plan de implementación están claramente establecidos en el documento del Acta de constitución del proyecto.
- Designar el equipo del proyecto. Ahora que el proyecto está definido, es hora de nombrar el equipo. Se establece la Junta de Proyecto y se contrata al Gerente de Proyecto para que asuma la responsabilidad del proyecto. El Project Manager recluta a los Team Leaders y ellos, a su vez, ayudan a reclutar al personal del proyecto.
- Crear una Oficina de Proyectos. El entorno de la Oficina de Proyectos se establece como el lugar de residencia del equipo durante la duración del proyecto. Este entorno proporcionará las instalaciones físicas, el equipo, los materiales, las herramientas y los procesos necesarios para que los miembros del equipo del proyecto puedan desempeñar sus funciones con éxito.
- Realizar revisión de fase. Con el proyecto definido y el equipo designado, está listo para ingresar a la fase de Planificación detallada. Se completa una revisión de fase para garantizar que se hayan completado todas las actividades de inicio requeridas y para proporcionar la aprobación formal para proceder a la fase de planificación detallada del proyecto.

B) Planificación de proyectos La fase de planificación implica completar los siguientes 10 pasos clave. Todos estos pasos se completan en la fase de planificación. Los pasos no se realizan necesariamente de manera secuencial, como se muestra en el siguiente diagrama. Esta secuencia simplemente muestra el orden en que se describe el trabajo .
La fase de Planificación se realiza a lo largo del proyecto según sea necesario. Aunque gran parte del trabajo de planificación se completa al principio del proyecto, es posible que sea necesario revisar la planificación a lo largo del proyecto. Por ejemplo, crea un plan de comunicaciones inicial al principio del proyecto. A medida que avanza el proyecto, es posible que sea necesario actualizar el Plan de comunicaciones. Si es así, se revisa la fase de Planificación y se revisa el Plan de Comunicación.
- Crear un plan de proyecto
- Crear un plan de recursos
- Crea un plan financiero
- Crear un Plan de Calidad
- Crear un plan de riesgos
- Crea un plan de aceptación
- Crea un plan de comunicación
- Crear un Plan de Adquisiciones
- Contratar al proveedor
- Realizar revisión de fase
 
-Crear un plan de proyecto. La creación de un plan de proyecto integral es fundamental para el éxito del proyecto. El Plan del Proyecto identifica la Estructura de Desglose del Trabajo (EDT) de fases, actividades y tareas que se llevarán a cabo para completar el proyecto. Identifica la secuencia, la duración y las dependencias de las tareas, así como los recursos genéricos y los gastos financieros necesarios para completar el proyecto.
-Cree un plan de recursos. Tras la creación de un Plan de Proyecto, se debe realizar una evaluación detallada de los recursos necesarios para llevar a cabo el proyecto. Se debe enumerar la mano de obra, el equipo y los materiales necesarios y cuantificar la cantidad de cada recurso. Finalmente, el uso de los recursos debe programarse para proporcionar al Gerente de Proyecto una vista completa de la cantidad total de recursos necesarios para cada etapa del proyecto.
-Crear un Plan Financiero. El Plan Financiero describe la cantidad total de recursos financieros requeridos durante cada fase del proyecto. Se calcula el costo total de cada elemento de mano de obra, equipo y materiales, así como el costo total de realizar cada actividad dentro del Plan del Proyecto.
-Crear un Plan de Calidad. Se desarrolla un Plan de Calidad para garantizar que los entregables del proyecto cumplan con los requisitos del cliente. Este plan enumera explícitamente los objetivos de calidad que se deben lograr, y se programan un conjunto de actividades de control y garantía de calidad para garantizar que se logre el nivel de calidad requerido a lo largo del proyecto.
-Crear un Plan de Riesgos. La gestión del riesgo del proyecto es un proceso crítico dentro del ciclo de vida del proyecto. Para mitigar el riesgo de manera efectiva, todos los riesgos previsibles del proyecto se identifican y clasifican en términos de su probabilidad de ocurrencia y su impacto potencial en el proyecto. Los riesgos se priorizan y se identifica un conjunto de acciones para reducir la probabilidad de cada riesgo y su impacto en el proyecto en caso de que ocurra.
-Crear un Plan de Aceptación. La clave para la satisfacción del cliente está en obtener la aprobación del cliente de que los entregables cumplen con los criterios de calidad establecidos en el Plan de calidad. Se crea un Plan de Aceptación para asegurar que se busque la aceptación del cliente para cada entregable producido por el proyecto. El Plan de aceptación proporciona un cronograma de Revisiones de aceptación que se llevan a cabo para obtener la aceptación del cliente para la finalización de cada entregable dentro del proyecto.
-Crear un Plan de Comunicación. Un Plan de Comunicaciones es un documento que describe la información que se proporcionará a las partes interesadas del proyecto para mantenerlas informadas sobre el progreso del proyecto. Se enumera cada parte interesada y se identifican claramente sus requisitos de información. Se establece un cronograma de eventos y actividades de comunicación para garantizar que la información correcta se comunique a las personas adecuadas en el momento adecuado.
-Crear un Plan de Adquisiciones. Los proyectos a menudo necesitan adquirir artículos adquiridos (como productos, servicios y resultados específicos) de proveedores externos. El Plan de Adquisiciones describe qué artículos se obtendrán de fuentes externas. proveedores y los plazos y métodos de entrega.
-Contratar a los Proveedores. Con una visión clara de los elementos de adquisición que se adquirirán, el equipo del proyecto se dispondrá a seleccionar y contratar uno o un pequeño número de proveedores preferidos para el proyecto. Esto puede implicar:
•Definición de un Proceso de Selección para seleccionar los proveedores preferentes
•Emitir una Declaración de trabajo para documentar los requisitos de adquisición del proyecto.
•Emisión de una Solicitud de Información a un grupo de proveedores potenciales para permitirles registrar su interés en suministrar el proyecto
•Emisión de una Solicitud de Propuesta a una lista corta de proveedores para permitirles presentar una propuesta formal para suministrar el proyecto
•Negociación de contratos de proveedores para acordar un conjunto de responsabilidades, términos y condiciones para el suministro de productos al proyecto.
-Realizar revisión de fase. El equipo está listo para ingresar a la fase de Ejecución con una comprensión detallada de las actividades, los recursos, las finanzas y las relaciones con los proveedores necesarios para llevar a cabo el proyecto. Se lleva a cabo una Revisión de Fase para garantizar que se hayan completado todas las actividades de Planificación requeridas y para proporcionar aprobación para pasar a la fase de Ejecución del Proyecto


C) Ejecución y Control del proyecto Armado con una definición clara del proyecto y un conjunto de documentos de planificación detallados, está listo para ingresar a la fase de ejecución del proyecto. Esta es la fase en la que los entregables se construyen físicamente y se presentan al cliente para su aceptación.
Mientras se construye cada entregable, se utiliza un grupo de procesos de gestión para monitorear y controlar los entregables del proyecto.
 
Estos procesos incluyen la gestión del tiempo, el costo, la calidad, el cambio, los riesgos y los problemas, así como los proveedores, la aceptación del cliente y la comunicación del proyecto.
Una vez que se han producido todos los entregables y el cliente ha aceptado la solución final, el proyecto está listo para su cierre.
 
-Construir entregables
- Seguimiento y Control
• Realizar la gestión del tiempo
• Realizar la gestión de costos
• Realizar Gestión de Calidad
• Realizar Gestión de Cambios
• Realizar Gestión de Riesgos
• Realizar la gestión de problemas
• Realizar Gestión de Compras
• Realizar Gestión de Aceptación
• Realizar la Gestión de las Comunicaciones
-Realizar revisión de fase
 
-Construir entregables. El primer y más importante paso en la fase de Ejecución es la construcción de cada uno de los entregables del proyecto especificados en el Acta de Constitución del Proyecto. Durante esta actividad, se crea un diseño detallado de cada entregable, y los entregables se construyen y prueban físicamente. Los entregables luego son revisados ​​por el Gerente de Calidad y el Cliente para determinar si cumplen con los criterios de calidad (definidos en el Plan de Calidad) y los criterios de aceptación (definidos en el Plan de Aceptación). Si se han cumplido todos los criterios, el cliente firma los entregables y los entrega al entorno del cliente. Una vez que todos los entregables han sido producidos y aprobados por el cliente, el proyecto está listo para cerrarse.
-Seguimiento y Control. Junto con la actividad 'Construir entregables', el Project Manager realiza un conjunto de procesos de gestión para monitorear y controlar el tiempo, el costo y la calidad de cada entregable que se produce, de la siguiente manera:
• Realizar la Gestión del Tiempo. Este es el proceso de seguimiento y control del tiempo dedicado por el personal al proyecto. Las hojas de tiempo se pueden usar para rastrear y registrar el tiempo empleado, de modo que el Gerente de Proyecto pueda determinar el progreso general del proyecto.
• Realizar la Gestión de Costos. Garantizar la entrega de proyectos dentro del presupuesto siempre es una tarea difícil. Para monitorear y controlar los costos de manera efectiva, se implementa un Proceso de administración de costos para identificar los costos del proyecto (es decir, los gastos) y registrar la tasa de consumo del presupuesto del proyecto.
• Realizar Gestión de Calidad. Para asegurar que el proyecto produzca entregables que cumplan con los requisitos del cliente, es necesario utilizar un Proceso de Gestión de Calidad formal. Este proceso involucra actividades de Garantía y Control de Calidad como se especifica en el Plan de Calidad para administrar el nivel de calidad de un proyecto.
• Realizar la Gestión de Riesgos. Si bien la gestión del tiempo, el costo y la calidad puede ser un trabajo de tiempo completo, otro proceso clave dentro de la gestión de proyectos es la mitigación del riesgo del proyecto. Para realizar la gestión de riesgos en un proyecto, debe monitorear y controlar los riesgos del proyecto tomando las medidas necesarias para prevenir riesgos y minimizar el impacto en el proyecto en caso de que ocurran esos riesgos.
• Realizar Gestión de Incidencias. Durante el ciclo de vida del proyecto, a menudo surgen problemas imprevistos que afectan la capacidad del proyecto para cumplir con los objetivos establecidos. La clave del éxito es contar con un proceso para revisar y resolver problemas antes de que tengan un impacto severo en el proyecto.
• Realizar la Gestión de Compras. Los proyectos a menudo requieren bienes y servicios externos a proveedores para ayudarles a cumplir los objetivos marcados. En estas situaciones, se implementa un Proceso de Gestión de Adquisiciones para monitorear y controlar el desempeño de los proveedores del proyecto.
• Realizar Gestión de Aceptaciones. Puede entregar un conjunto de entregables de primera clase, pero a menos que el cliente acepte que sus entregables cumplen con sus requisitos, el éxito del proyecto se verá comprometido. Para obtener la aprobación del cliente de cada entregable, se deben realizar Revisiones de Aceptación como parte de un Proceso de Gestión de Aceptación.
• Realizar la Gestión de Comunicaciones. Todos los miembros del equipo deben estar informados regularmente sobre el progreso del proyecto. Al completar las actividades de comunicación enumeradas en el Plan de comunicaciones, se asegurará de que cada parte interesada dentro del proyecto reciba la información correcta, en el momento adecuado.
-Realizar revisión de fase. Con todos sus entregables aprobados por el cliente, está casi listo para cerrar el proyecto. Pero primero, se lleva a cabo una revisión de fase para garantizar que todas las actividades requeridas en la fase de ejecución se hayan completado y que el proyecto esté listo para pasar a la fase de cierre.

D) Cierre del proyecto Puede parecer fácil, pero cerrar un proyecto implica más de lo que parece. El cierre del proyecto implica la entrega de los entregables finales al cliente, la entrega de la documentación del proyecto a la empresa, la rescisión de los contratos con los proveedores, la liberación de los recursos del proyecto y la comunicación del cierre del proyecto a todas las partes interesadas. El último paso restante es una revisión posterior a la implementación para identificar el nivel de éxito del proyecto y anotar las lecciones aprendidas para proyectos futuros. Los pasos involucrados en la fase de Cierre se describen en:
 
- Realizar el Cierre del Proyecto
- Revisar la finalización del proyecto
 
-Realizar el cierre del proyecto: El primer paso que se toma al cerrar un proyecto es crear un Informe de cierre del proyecto. Es extremadamente importante que enumere todas las actividades necesarias para cerrar el proyecto dentro del informe de cierre del proyecto, para garantizar que el cierre del proyecto sea fluido y eficiente. Una vez que el informe ha sido creado y aprobado por el Promotor del Proyecto, se realizan las actividades de cierre establecidas en el informe. A continuación, el proyecto se cierra oficialmente.
-Revisar la finalización del proyecto: Entre uno y tres meses después de que se haya cerrado el proyecto y el negocio haya comenzado a experimentar los beneficios que brinda el proyecto, es importante realizar una Revisión posterior a la implementación (PIR). Esta revisión le permite a la empresa identificar el nivel de éxito del proyecto y enumerar las lecciones aprendidas para proyectos futuros.

Anexo 1: 
Proceso de implementación de la metodología de gestión de proyectos
Teníamos garantizados dos de las tres etapas del contrato, pero la tercera etapa era una opción para el cliente. Al comienzo del proyecto, no estaban seguros de si les gustaría implementar la metodología con nosotros o intentar hacerlo por su cuenta.
Queríamos ejecutar el proyecto correctamente y mostrarle al cliente cómo se puede liderar de manera efectiva un proyecto maduro. Entonces, por nuestra parte, comenzamos con un acta de constitución formal del proyecto y un análisis de las partes interesadas. Una parte muy importante de la preparación fue el análisis de riesgos. Sabíamos que si en algún punto del camino perdíamos el apoyo de los ejecutivos, el proyecto estaría en problemas. Otra cosa que nos quedó clara desde la fase de inicio de este proyecto fue que si decidían implementar la metodología sin nuestro apoyo, podrían perder la paciencia y no alcanzar sus objetivos.

Evaluación de madurez
El primer paso fue evaluar dónde estaban realmente en lo que respecta a las prácticas cotidianas de gestión de proyectos. Llevamos a cabo una serie de entrevistas con representantes de su entorno de gestión de proyectos, incluido el propietario de la organización (para garantizar su participación desde el principio), miembros del directorio, la alta gerencia y personas que actualmente desempeñó el papel de gerente de proyecto en la empresa.

Descubrimos que la organización no adoptó un enfoque estándar para la gestión de proyectos. Algunas personas cuestionaron la presencia de proyectos en la empresa. Los responsables de marketing y administración respondieron: “¿Qué proyectos? No tenemos ningún proyecto aquí. Todo lo que tenemos es trabajo que debe hacerse”. La gente regresaba a nosotros con todos los diferentes comentarios con respecto a nuestra cooperación potencial. Algunos estaban muy contentos, esperando una mejora del entorno del proyecto y deseosos de trabajar en un entorno predecible. Algunos estaban tomando esta oportunidad común como una amenaza. Querían mantener el statu quo y permanecer en las viejas aguas turbias con sus proyectos fuera del control de sus gerentes. Por lo tanto, también fue un desafío político involucrar a las partes interesadas más importantes y mantener sus mentes abiertas a lo que se avecinaba.

Nuestros hallazgos mostraron que no había un enfoque común de gestión de proyectos en la organización. Hubo una carga sustancial de trabajo que determinamos que eran proyectos, pero estos no eran proyectos formales y, por lo tanto, nadie los controlaba, el alcance se arrastraba y los plazos no estaban fijados. No había ningún conjunto de herramientas de gestión de proyectos común disponible. Algunas personas estaban usando herramientas como Microsoft Project y OpenProject, pero la organización no estaba impulsando esto como un estándar y no tenía un proceso de gestión de proyectos que esas herramientas pudieran abordar.

Presentamos estos hallazgos en un informe formal y una presentación resumida para la junta directiva. En esos documentos, destacamos las fortalezas de la práctica actual de gestión de proyectos de la empresa y áreas claramente definidas para mejorar. Como resultado de esta etapa, acordamos la hoja de ruta para seguir mejorando la función de gestión de proyectos.

Talleres PM
Desde las primeras fases del proyecto, queríamos sentir que estábamos trabajando con un grupo de personas que sabían de qué se trata la gestión de proyectos maduros. Así que decidimos comenzar con un taller que presenta el estado deseado de gestión de proyectos. La audiencia del taller estuvo compuesta por los principales actores de nuestro proyecto:

• Propietario de la organización y asesores
• CEO
• Junta Directiva
• Gerentes funcionales
• Los principales directores de proyectos

En total teníamos un grupo de 16 personas trabajando en un estado futuro de la gestión de proyectos. Estuvieron separados de sus escritorios durante dos días, concentrándose únicamente en la función de gestión de proyectos con un fuerte apoyo del propietario de la organización. Paso a paso, les presentamos las mejores prácticas en el inicio, planificación, ejecución, seguimiento y control, y cierre del proyecto. Cada uno de estos grupos de procesos fue presentado como un modelo de la Guía del PMBOK ® y luego comparado con la realidad de la organización. Realizamos un análisis de brechas grupales y luego elaboramos la estrategia de mejora en esas áreas.

Desarrollo de Metodología
Después de recopilar los requisitos durante el taller, regresamos a nuestra oficina y comenzamos un análisis de lo que habíamos encontrado. Dos consultores tardaron 10 días hábiles en preparar una versión preliminar de la metodología de gestión de proyectos, incluido un proceso y plantillas de documentación de respaldo. Sabíamos que solo podíamos usar la documentación de Microsoft Office y no había presupuesto para implementar ningún sistema de información de gestión de proyectos (PMIS) de inmediato. Esta también fue una de nuestras tácticas: en lugar de pasar de un entorno sin herramientas directamente a un PMIS, preferimos tomar las cosas con calma e intentar organizar un ciclo de vida de proyectos basado en herramientas simples de Microsoft Office.
La metodología incluyó dos procesos de gestión de proyectos:

• Proceso para proyectos estratégicos: mayor riesgo, presupuestos más altos, más complejos, a largo plazo, multifuncionales, que involucran a varios proveedores externos
• Proceso para proyectos de mejora: a corto plazo, de baja prioridad, de bajo riesgo, de bajo presupuesto, en su mayoría realizado por recursos internos
• Proceso para proyectos de cumplimiento legal: a corto plazo, de alta prioridad, de alto riesgo, de presupuesto aceptado, en su mayoría realizado por recursos externos.

Metodología 1.0 - Ajuste Fino
La metodología en versión 1.0 fue enviada para evaluación. El equipo de evaluación estaba formado por nuestros principales interesados, incluido el propietario de la organización, que se mantuvo activamente involucrado en el proceso. Este fue su primer acercamiento a la lectura y comprensión de todo el sistema, por lo que hubo muchas preguntas y se dedicó mucho tiempo al teléfono para lograr una comprensión común del proceso. Después de dos semanas y algunos ajustes, recibimos permiso para seguir adelante con la metodología.

Metodología 1.0 - Talleres de Simulación
Luego de obtener la aprobación inicial de la metodología, decidimos probarla en un taller de simulación, donde los representantes del cliente trabajaron en la implementación de la metodología en dos proyectos estratégicos que estaban por iniciar. Un grupo de 20 personas que representaban a las principales partes interesadas se reunieron en un centro de capacitación fuera de su oficina. Nuestro objetivo era intentar desplegar la metodología en dos proyectos reales que la organización estaba a punto de iniciar. Se suponía que en dos días íbamos a presentar los estatutos del proyecto, el análisis de las partes interesadas y un plan de gestión del proyecto para cada uno de esos proyectos.

La simulación dio a los participantes la oportunidad de hacer una planificación real basada en el nuevo proceso. La simulación de proyectos reales que estaban a punto de comenzar demostró ser efectiva. Garantizó una fuerte participación de los participantes y, lo que es más importante, permitió que dos equipos de proyecto salieran del taller con planes de gestión de proyectos que estaban casi listos para implementar.

Metodología 1.0 Aprobación
La evaluación del taller y la efectividad de la metodología en la planificación de un proyecto condujo a la aprobación formal de la metodología. Recibimos una aprobación formal de los resultados del patrocinador del proyecto. Entonces estuvimos listos para apoyar a nuestro cliente en la implementación de la metodología. Nos pidieron que esperáramos la llamada y estuviéramos listos para la siguiente etapa.

Implementación de la metodología
Luego de la presentación oficial de la metodología y sutiles refinamientos, los resultados fueron aprobados oficialmente y la metodología estuvo lista para su implementación. Pero entonces, como ocurre con casi todos los proyectos, llegó el momento del cambio. El cliente decidió implementar la metodología sin nuestro apoyo. Su oficina de estrategia y desarrollo constaba de tres personas, y estaban muy seguros de que podrían implementar la metodología por su cuenta.

Primer enfoque: lo haremos por nuestra cuenta
Una de las principales amenazas del proyecto se materializó. El principal interesado del proyecto, la persona que nos había contactado inicialmente tres meses antes, decidió no continuar con su contrato con la empresa. No se debió a los resultados de nuestro proyecto común. Como supimos más tarde, este movimiento había sido planeado durante meses y estaba relacionado con algunos asuntos personales de la parte interesada.

La situación era difícil: nuestro principal apoyo en la organización se mudaba y no había nadie para asumir su papel. Sabíamos que el cliente estaba en proceso de contratar un reemplazo, pero también sabíamos que esto podría tener un impacto negativo en nuestro proyecto. La nueva persona provenía de un entorno completamente diferente, no había estado involucrado en el diseño del proceso de la metodología de gestión de proyectos y no era un partidario natural de este cambio. Además, vendría a este nuevo entorno con la ambición de demostrar que tiene experiencia y que no necesita ningún apoyo para hacer que sus proyectos funcionen. Finalmente, no entendería la metodología desarrollada por la empresa, pero nunca lo diría abiertamente. Como descubrimos más tarde, no tenía ninguna experiencia con la gestión de proyectos maduros y estructurados.

Ven y mira lo que hicimos
Después de seis meses, la empresa se puso en contacto con nosotros y solicitó una auditoría rápida del proceso de implementación. No estaban contentos con los resultados de la implementación. Básicamente, las cosas no avanzaban y los resultados no eran los esperados. Nos tomó una semana revisar la organización, ver los documentos del proyecto, entrevistar a las personas (incluido el nuevo director de la oficina de estrategia y desarrollo) y elaborar el diagnóstico. Parecía que la mayoría de nuestros esfuerzos habían sido en vano. La metodología no se había implementado, la gente estaba cansada de intentarlo sin ningún apoyo interno y la junta directiva estaba presionando para obtener resultados.  
Presentamos nuestro diagnóstico a la junta directiva y nos preguntaron si estaríamos disponibles para ayudarlos en el proceso de implementación adecuado.

Segundo enfoque: ven y hazlo con nosotros
La presentación de los resultados de la auditoría no dejó dudas en la junta directiva. No estaban ni cerca de donde inicialmente querían estar en seis meses. Tuvimos que recopilar información nuevamente y preparar otro plan de implementación. El documento final se basó en el supuesto de que uno de nuestros consultores sería designado asesor de la junta directiva en el campo de la gestión de proyectos y reportaría directamente a ellos; esto fue para asegurar la autoridad formal requerida en el proceso de implementación. Adicionalmente, se le asignó un programa estratégico compuesto por 11 proyectos que generaron cambios importantes y esperados en la organización. Ambas partes decidieron comenzar a trabajar de inmediato.

Programa piloto
El programa que consta de 11 proyectos de diferentes tamaños fue elegido para ser un piloto real de la implementación de la metodología. Asignamos un gerente de programa subcontratado, cuya función era cumplir los objetivos del programa y probar la metodología de gestión de proyectos. Para asegurar un buen comienzo, elegimos un equipo de gestión de programas formado por personas involucradas en el proceso de desarrollo de la metodología de gestión de proyectos. El CEO inició personalmente el programa.
Para asegurar la participación de los directores de proyecto, implementamos un sistema de motivación. Una vez alcanzados los objetivos de nuestros proyectos, podrían solicitar beneficios económicos para ellos y sus equipos. En muchos casos, terminar proyectos a tiempo, dentro de los presupuestos y con el nivel de calidad solicitado requería horas extra, trabajar en casa y salir de la zona de confort a la que la gente estaba acostumbrada. Para muchos de ellos resultó ser útil y se convirtieron en defensores naturales de la nueva metodología. Llegamos a una situación de ganar-ganar cuando tanto la junta directiva estaba contenta con los resultados de los proyectos como las personas involucradas estaban contentas con el reconocimiento por su trabajo extra.

Apoyo a Proyectos Paralelos
También fue entonces cuando se dieron los pasos iniciales para crear una PMO (Project Management Office) . Nuestro rol era apoyar a un grupo de gerentes de proyecto para cumplir con los objetivos del programa, pero en paralelo se nos pidió que apoyáramos a otros gerentes de proyecto que estaban iniciando sus proyectos basados ​​en la metodología. Comenzó a surgir una cultura de apoyo mutuo y comunicación abierta. Las personas estaban abiertas a los cambios y motivadas para lograr los objetivos del proyecto.

Programa de entrenamiento
Simultáneamente, iniciamos un programa de capacitación para el grupo de 20 gerentes de proyecto de la empresa. Consistió en cuatro sesiones de dos días, presentando tanto la metodología de gestión de proyectos organizacionales como el PMBOK como estándar. En tres meses, construimos una base de habilidades no solo para implementar lo establecido en la forma de una metodología actual, sino también para mejorar los estándares en el futuro en beneficio de la empresa.

Mejora continua
Se evidencio, que esta metodologia, seria el inicio de formalizarla dentro d ela organizacion con un sistema, el sistema de gestion de proyectos y desde ahi el futuro se convierte en presente de modo sostenidamente.

La gestión de activos de TI (ITAM) es la práctica que ayuda a su organización a gestionar, controlar y proteger sus activos de TI y los servicios de TI que los utilizan. Bien hecho, ITAM ayudará a su organización a aumentar el valor, respaldar la toma de decisiones, controlar los costos y administrar los riesgos de manera efectiva. Para ayudar, este blog considera la nueva guía ITIL 4 ITAM y cómo usarla para mejorar sus prácticas de ITAM.
Actualización de su alcance ITAM
​Al establecer el alcance de las capacidades de ITAM de su organización, deberá considerar las redes, los servicios basados ​​en la nube y los dispositivos cliente además del hardware y el software corporativos. Por ejemplo:

• Infraestructura de red: enrutadores, concentradores y conmutadores
• Servicios en la nube: ofertas de software como servicio (SaaS), como Office 365 o G-Suite, ofertas de plataforma como servicio (PaaS), como Microsoft Azure, y ofertas de infraestructura como servicio (IaaS), como Amazon Web Services o Google Compute Motor
• Dispositivos de cliente: dispositivos personales de los empleados que pueden acceder a los sistemas y la información de la empresa.

Creación y mantenimiento de su registro de activos

El registro de activos es un paso vital para realizar un seguimiento de los activos de TI, y la guía ITIL 4 ITAM reconoce que existen múltiples formas de capturar esta información. Por ejemplo, mediante el uso de software de descubrimiento de redes, auditorías de activos físicos o la captura de información de activos durante las tareas rutinarias de soporte de TI.

Aquí hay algunas ideas sobre cómo construir y mantener un registro preciso de activos de TI:

• Incorporar las necesidades de ITAM en las prácticas de trabajo existentes. Por ejemplo, los especialistas en proveedores que actualizan la herramienta de ITAM con las fechas de renovación del contrato o la práctica de habilitación de cambios incorpora preguntas de ITAM en el proceso de aprobación de cambios.
• Reconozca que ITAM solo funciona bien cuando los equipos colaboran y trabajan juntos. Por ejemplo, al trabajar con otras prácticas de ITSM, como la mesa de servicio, la gestión de configuración, la gestión financiera, la gestión de versiones y la gestión de proveedores para acordar convenciones de nomenclatura de activos y protocolos de captura de datos para evitar tener información contradictoria o desactualizada.
• Utilice las fuentes de datos existentes y apóyese en la automatización . Su aplicación de ITAM puede tener una herramienta de descubrimiento para informar qué software está instalado en su entorno. Su herramienta de soporte remoto puede informar sobre los activos de TI que están conectados a la red. El equipo de compras tendrá detalles sobre qué servicios de TI se han comprado. Utilice el principio ITIL 4 de " comenzar donde está " (o, en este caso, utilice lo que ya tiene) para identificar qué activos componen su entorno de TI.
• Utilice la estandarización para mantener los datos de activos lo más precisos posible. Por ejemplo, acordando claves de reconciliación, convenciones de nomenclatura y prácticas de sincronización de datos.
• Otro principio de ITIL que se relaciona particularmente bien con ITAM es "centrarse en el valor". Cuando ejecuta una práctica de ITAM, puede ser tentador tratar de capturar información para todos sus activos a la vez, y si usa una herramienta de descubrimiento, le proporcionará una lista extensa de activos. Las herramientas de descubrimiento son muy beneficiosas para identificar y recopilar información sobre los componentes de TI, pero si intenta administrar todo a la vez, corre el riesgo de que su práctica se vuelva inflada y difícil de manejar. En lugar de tratar de administrar "todas las cosas", concéntrese en sus activos más importantes: los componentes básicos que componen sus servicios más críticos. Siempre puede volver atrás y aumentar su alcance a medida que madura su práctica.

Ejecutar su práctica de ITAM como una práctica en vivo y continua
Demasiadas prácticas de ITAM no brindan valor porque las personas las tratan como un trato de "uno y listo". La realidad es que ITAM es una práctica que vive y respira, y debe tratarse como tal para mantener la información de activos actualizada y las prácticas de concesión de licencias bajo control.
Aquí hay algunas ideas para comenzar aquí:

• Programe informes regulares para que pueda conciliar los activos con sus propietarios.
• Al diseñar flujos de trabajo de aprobación para solicitudes de servicio, incluya el sistema ITAM para que las solicitudes puedan generarse, aprobarse y conciliarse con la información de activos en vivo.
• Trabaje con la mesa de servicio y los equipos de soporte para convertir las tareas de ITAM en actividades de soporte de rutina. Por ejemplo, hacer que los técnicos de la mesa de servicio verifiquen la licencia o la información de la etiqueta de activos al registrar incidentes y solicitudes de servicio.

Gestión de activos basados ​​en la nube
Una de las formas en que ITAM puede demostrar el valor empresarial es mediante la gestión eficaz de los servicios basados ​​en la nube. Por ejemplo, al tener un flujo de trabajo para administrar activos virtuales para que puedan ser rastreados y administrados. Es esencial tomar las disposiciones adecuadas para las estructuras de licencias basadas en la nube o SaaS para evitar la "expansión de la nube" o que accidentalmente se queden sin licencias. Es fácil de hacer; un colega podría descargar la misma aplicación en varios dispositivos (por ejemplo, su teléfono del trabajo, su teléfono personal y una tableta) y, de repente, una persona ha tomado tres licencias. Por lo tanto, verifique las reglas cuando cambie a proveedores basados ​​en la nube.

Al agregar activos basados ​​en la nube a su herramienta de ITAM, el tipo de información que deberá capturar estará más orientada al servicio que al nombre tradicional, el número de serie y la fecha del último servicio.
Algunos detalles potenciales para capturar en su herramienta de ITAM incluyen:

• Cómo se accede al servicio, por ejemplo, a través de un navegador web o una aplicación
• Cómo se almacenan los datos
• Cómo el proveedor de servicios en la nube mantendrá los datos seguros
• Cómo se gestionará la actividad de mantenimiento y cambio
• Cómo se controlarán los costos
• Cómo se gestionarán las licencias

Activos del cliente y soporte para BYOD
Una de las partes más valiosas de la guía actualizada de ITIL 4 es el soporte de los activos del cliente o enfoques de "traiga su propio dispositivo" (BYOD). Con el uso de dispositivos personales por parte de los empleados en el trabajo, existe el riesgo de lo que sucede con los datos de la empresa si algo le sucede al dispositivo. Afortunadamente, la necesidad de buenas prácticas de datos y resiliencia cibernética está bien publicitada, y muchas organizaciones están administrando su conocimiento y datos como un activo de TI.
Algunas cosas a considerar al extender su práctica de ITAM para cubrir los activos del cliente incluyen:

• Involucrarse con la comunidad de usuarios finales para acordar una política de uso aceptable que sea acordada por todos
• Contar con procesos y medidas de seguridad para administrar los datos de la empresa en dispositivos móviles
• Uso de herramientas de administración de dispositivos móviles (MDM) para administrar dispositivos con información de la empresa en ellos
• Garantizar que existe la capacidad de borrar dispositivos de forma remota si un dispositivo se pierde o es robado

La gestión de activos de TI (ITAM) es una capacidad de gobierno, riesgo y cumplimiento (GRC) de gestión de TI corporativa y granular de gran alcance que (no hay otra opción) su organización debe tener algunas métricas de ITAM adecuadas para permanecer en la pista.
Una buena capacidad de ITAM (para su organización) puede significar la diferencia entre ahorros de costos significativos versus fallas de auditoría y tarifas de liquidación. Por lo tanto, es de interés de todos garantizar que las actividades y los resultados del ITAM se mantengan encaminados.
En este blog, quiero echar un vistazo a algunas de las cosas clave que se deben medir, es decir, métricas adecuadas para el propósito, al observar el estado general de sus capacidades de ITAM .
Métricas de ITAM de hardwareAl ejecutar ITAM a nivel empresarial, es importante recordar realizar un seguimiento de los activos de hardware, así como de las licencias de software. Con demasiada frecuencia, el lado del hardware se puede descuidar solo para que los costos aumenten y luego, llegado el momento de fin de año, surjan preguntas sobre los costos de los activos de TI que se disparan.
Aquí hay algunas métricas de ITAM apropiadas para considerar que ayudarán a mantener la gestión de su patrimonio de hardware en el buen camino:

• El costo promedio de una estación de trabajo, además, ¿cómo es su PC estándar? ¿Es un escritorio? ¿Un ordenador portátil?
• El costo promedio del hardware del servidor, además, ¿cómo es el estado de su centro de datos? ¿Puramente WinTel? ¿Qué pasa con Linux u otros servidores basados ​​en SO?
• El costo promedio del hardware de la red central; además, ¿cómo es su red central? Los servicios de red son un área con la que muchas organizaciones luchan en términos de deuda técnica, entonces, ¿su equipo de red se mantiene de acuerdo con las mejores prácticas de la industria?

Métricas de software ITAMAl incorporar métricas relacionadas con el software en sus capacidades de ITAM, siempre comience como si fuera a ser auditado (por un proveedor de software) mañana. Pregúntese: ¿Cuáles son las cosas clave que me preguntarían los auditores?
Las medidas de ITAM relacionadas con el software a considerar podrían incluir:

• El número total de activos de software y aquellos "bajo administración" para brindarle la escala de su entorno de software.
• La cantidad total de licencias necesarias para asegurarse de tener la cantidad correcta de licencias para sus entornos de producción.
• Las instancias totales de software instalado, para permitirle prepararse para las auditorías. Los auditores siempre solicitarán ver pruebas de las instalaciones de software frente a las licencias adquiridas.
• El número total de licencias disponibles: ¿tiene suficientes licencias para satisfacer la demanda?
• La relación entre licencias usadas y compradas: ¿hay un umbral de alerta para que se pueda tomar la acción adecuada cuando se acerque al límite?
• El número promedio de versiones diferentes implementadas de cada aplicación. No todas las licencias cubren todas las versiones de software, así que asegúrese de tener la licencia adecuada para cumplir con sus obligaciones con el proveedor de software.

Métricas operativas de ITAMAdemás de las métricas puramente basadas en hardware y software, su organización también necesitará algunos informes operativos para ayudar a mantener todo bajo control.
Los ejemplos de métricas operativas incluyen:

• El porcentaje de dispositivos activos para los cuales el inventario actual de hardware y software está disponible y en uso, es decir, ¿qué porcentaje de su entorno está activo y bajo el control de ITAM?
• El porcentaje de dispositivos encontrados en la red que no se reconocen como activos conocidos: es importante medirlo al administrar el riesgo. Entonces, ¿cómo administrará estos elementos?
• El porcentaje de dispositivos encontrados activos en la red que tienen un estado no activo, por ejemplo, activos que se han retirado y/o están pendientes de eliminación.
• El porcentaje de activos sin ubicación o propietario registrados: deberá activar una tarea o paso de proceso que investigue la propiedad y/o vuelva a implementar estos activos.

La cantidad de activos que se asignan a las personas que han dejado la organización: esto es para que puedan recopilarse (si es necesario) y redistribuirse de manera efectiva. Además, investigue si existe un proceso de mesa de servicio de TI para tratar con los empleados que se van, de modo que no haya duplicación de esfuerzos, ¡o grietas y agujeros por los que desaparezcan los activos!


Las métricas de ITAM de mejores prácticas deben mirar más allá de "lo físico"

ITAM no se trata solo de administrar activos de hardware y software . También se trata de activos en la nube y entornos virtualizados; en última instancia, se trata de todos los componentes básicos que componen su entorno de TI. Y, por supuesto, está el lado del costo de lo que cuestan los activos de TI y cómo se puede optimizar.
Cuando busque administrar las eficiencias de ITAM, observe:

• Tasas de depreciación de activos y su desempeño a lo largo del tiempo.
• El costo total de propiedad (TCO).
• Los activos mantenidos por socios externos: asegúrese de tener un proceso sobre cómo se administran las licencias y cómo lidiar con las excepciones. Recuerde que, incluso si subcontrata un aspecto de sus servicios de TI, no niega su responsabilidad por el cumplimiento de licencias.
• Controle los activos de TI no autorizados o no corporativos: con traer su propio dispositivo (BYOD) y Shadow IT es más desafiante que nunca mantener el control de su patrimonio de TI. Al poder marcar excepciones o activos no corporativos, podrá investigar y otorgar acceso o notificar a la persona por qué ese activo no se puede usar de manera segura dentro de su entorno.
• Los activos vinculados a incidentes y problemas para que pueda ayudar a otros equipos a comprender el estado general de su infraestructura.
• Historial de auditoría: tanto los hallazgos como las multas pagadas históricamente para darle una mejor idea de los niveles de riesgo.
• Los niveles de uso de los servicios en la nube, incluido el software como servicio (SaaS), para identificar si este uso justifica los costos mensuales.
• El porcentaje de máquinas virtuales en su propiedad, así como los detalles de propiedad.
• El porcentaje de máquinas virtuales para las que se desconoce la información del host físico.
• El porcentaje de dispositivos cubiertos por su herramienta de ITAM; además, ¿cómo administrará las excepciones? ¿Serán suficientes las comprobaciones manuales?
• El porcentaje de nuevas instalaciones de software que pasan por la mesa de servicio a través del cumplimiento de solicitudes para que pueda asegurarse de que las solicitudes se realicen a través de los canales apropiados.

Al aplicar medidas (y métricas) adecuadas a sus capacidades de ITAM, su organización debería poder ver, de un vistazo, qué va bien y qué debe mejorarse, impulsando mayores eficiencias y oportunidades para la mejora continua del servicio (CSI) .
 

​Si la gestión de servicios de TI (ITSM) es el arte de habilitar un negocio a través de la tecnología (también utilizando personas, proveedores, procesos y otras cosas divertidas), entonces Lean es la capacidad de observar las operaciones comerciales y los problemas para mitigarlos o eliminarlos, en última instancia. en beneficio de un cliente. En mi opinión, Lean es una combinación perfecta para ITSM; llamémoslo LeanITSM (pero no se lo digas a los puristas de ITSM).
La importancia de los KPI
Para hacer LeanITSM (o solo ITSM) bien, necesitamos una forma de saber que vamos por buen camino con nuestras mejoras. Aquí es donde entran los indicadores clave de rendimiento (KPI), aunque es de esperar que no sean KPI como este:

​Este KPI específico se creó para mostrar la productividad de los desarrolladores, utilizando líneas de código escritas como medida. ¿Podrías usar o explicar esto? Bueno, vi la consternación de la gerencia cuando sus desarrolladores presentaron este KPI, dijeron: “Somos ágiles, por lo que esto no funcionará para nosotros. ¿Deberíamos renunciar o volver a la antigua forma de codificación? Es un gran ejemplo de KPI que: se basan en tiempos pasados, son complicados, están desconectados de los objetivos comerciales y/o no motivan. O bien, podría decir que es más probable que dichos KPI generen comportamientos incorrectos, a menudo colocando la cantidad por delante de la calidad.
Cómo puede ayudar Lean
Lean e ITSM pueden ayudar a todos a trabajar juntos hacia un objetivo común. Ambos utilizan un enfoque de ciclo de vida de: crear una estrategia, descubrir cómo ejecutar la estrategia, introducir esos pasos, verificar los resultados y, a través de la retroalimentación (personas o herramientas), mejorar esa estrategia o producto. ITSM agrega la asistencia de la tecnología al ciclo de vida.
En lean, el ciclo de vida de la estrategia se llama Hoshin Kanri , donde la estrategia de la alta gerencia se lanza a cada nivel hacia abajo (" catchball ") de modo que puedan crear su propia forma de abordar los desafíos de la estrategia. Esta cascada de estrategia podría ser a nivel de negocio o a nivel de producto. No importa: Hoshin Kanri permite que cada persona vea y establezca su propia forma de trabajar para alcanzar la meta.
KPI esbeltos
La creación de KPI en los puntos donde se realiza el trabajo es la sugerencia esbelta para la medición del rendimiento, en lugar de utilizar un KPI obligatorio de nivel superior que todos luego " juegan " para hacer feliz al jefe.
El modelo esbelto a continuación es para una organización de atención médica, y este es el modelo de elección en DevOps y entrega continua .

​Fíjate en las flechas de catchball hacia arriba y hacia abajo. Dentro de la "bola" catchball están los objetivos, y la pelota se puede lanzar en cualquier dirección, con KPI diseñados para ayudar a responder las siguientes preguntas:

• ¿Mejoramos o declinamos?
• ¿Estamos en curso?
• ¿El impacto afecta a nuestra organización?
• ¿Necesitamos ayuda?

 
Los KPI provocan una respuesta Sí/No, de lo contrario, son meras métricas. Si bien las métricas son útiles y, a veces, se requieren como parte de un KPI, no son clave para ayudarnos a cumplir una estrategia o solicitud.
 
Llevar los KPI Lean a ITSM a través del Titanic
Los marcos de ITSM brindan una guía clara sobre el propósito de un KPI: validar, justificar, intervenir o dirigir.   Estoy seguro de que también ha oído hablar del enfoque Planificar, Hacer, Verificar, Ajustar, que cuando se combinan significa que:

• Validas y Justificas el KPI en la etapa de Plan.
• Entonces lo haces
• Luego Validas el desempeño en la etapa de Verificación
• Luego Intervenir o Dirigir en la etapa de Ajuste.

Una analogía podría ser estar al mando de un barco donde:

1. El capitán proporciona el curso y, potencialmente, el por qué.
2. La tripulación realiza sus tareas en consecuencia.
3. A lo largo del viaje, se toman lecturas para confirmar el rumbo, de modo que si están fuera de curso, podrían ajustarse.
4. El capitán no dice cómo, sino que cada miembro de la tripulación determina esto frente a los objetivos de nivel superior y establece su propio KPI para cumplir con el plan.

¿Cuántos de nosotros es más probable que hagamos Plan, ¿Do, Check, Act? Creyendo que es mejor decirle al capitán lo que quiere escuchar en lugar de la verdad. ¿El resultado - Titanic alguien?
Los KPI son, o deberían ser, limitados en número, aunque finalmente necesitará tantos como necesite. Como ejemplo, si la alta gerencia tiene 5-6 KPI, entonces cada capa posterior hacia abajo podría tener 6-8 KPI vinculados, pero podría ser más o menos. Finalmente, los KPI deben ser inamovibles a menos que se acuerde que el indicador debe cambiar.
 
 
 
¿Cómo se crea un KPI?
Lo primero que debe hacer al crear un KPI para cualquier parte de sus operaciones de TI, incluida la mesa de servicio, es observar un objetivo comercial. ¿Puedes ver lo que se requiere para ayudar a lograr la meta o eliminar el obstáculo para lograr la meta? Si es así, determine cómo sabría que esto estaba sucediendo y si podría probarlo. Recuerde, todas las respuestas deben ser Sí/No.

​A continuación, deberá observar el objetivo, desglosarlo en sus activos de servicio, crear un indicador de rendimiento de alto nivel vinculado al objetivo de nivel superior y luego desglosarlo nuevamente hasta que tenga suficiente información para confirmarlo. estás, o no estás, en curso. El siguiente ejemplo es un árbol de KPI, en el que cada KPI tiene un propietario, una definición, un propósito, una ecuación, una frecuencia, una dependencia y, lo que es más importante, la respuesta requerida cuando se marca.

Este árbol de KPI en particular se usó como tablero, primero en una gran pizarra que se actualizaba manualmente, luego en pantallas para que todos los miembros del equipo y la gerencia lo vieran. Los colores de estado utilizados fueron: verde: todo está bien; ámbar: este KPI no es significativo para este período, así que ignórelo; y rojo: tenemos un problema, por lo que toda la tripulación puede ver si pueden ayudar (incluida la gerencia).
 
Catchball: ¿la esencia de la gestión estratégica?
Para que lo anterior funcione, deben ocurrir dos cosas. Primero, el equipo debe crear los KPI que se alinearán con cada nivel y los ayudarán a tomar el rumbo correcto. En segundo lugar, el equipo debe tener una dirección clara sobre cuándo involucrar a la alta dirección en los problemas o cómo informar en general sobre lo que está sucediendo. Este enfoque se alinea con la historia del barco donde la tripulación acudió en ayuda de los demás según fuera necesario, con el capitán involucrado según la situación. Es catchball clásico y LeanITSM.
 

Service Automation impregna todos los aspectos de la prestación de servicios, manejando todo el trabajo pesado hasta que ITSM básicamente funciona por sí solo. Las entradas están cerradas. Las tareas están terminadas. Los usuarios resuelven problemas comunes por su cuenta. Flujos de trabajo completos hacen lo suyo. Y el personal de TI puede concentrarse en lo que hacen mejor.
Algo así como Starbucks.
Automatización de tickets

Tu pedido tiene que llegar al barista correcto, el que sabe exactamente cómo te gusta tu café.
Ticket Automation clasifica, enruta y envía cada ticket entrante al escritorio correcto, sin necesidad de intervención manual. Con base en parámetros personalizados, que pueden incluir la fuente del ticket y campos personalizados, cada solicitud se prioriza automáticamente y se asigna a la persona o grupo de resolución más apropiado dentro de la organización. Sin despeinarse sin problemas.
Automatización de tareas¿Crees que el barista realmente hace el café de la A a la Z? Por supuesto no. Hay una máquina, lo que podría llamarse el barista autónomo, que hace gran parte del trabajo por ellos, para que puedan concentrarse en usar sus habilidades para las tareas más complejas de preparar su bebida.
Las tareas manuales y repetitivas que tienden a consumir tanto tiempo de TI todos los días pueden desaparecer "automágicamente". Con un solo clic, el trabajo de rutina puede automatizarse por completo y luego olvidarse rápidamente. Los miembros del equipo de TI pueden dedicar más tiempo a aportar valor a su negocio y menos a restablecer las impresoras, crear nuevos usuarios y cosas por el estilo.
Automatización del flujo de trabajoCada barista es visto como un "socio" que trabaja en coordinación para un mejor servicio. Como resultado, las solicitudes de bebidas más complejas se pueden simplificar con un sistema optimizado.
Los flujos de trabajo que involucran diferentes tareas, equipos, departamentos y aplicaciones se pueden automatizar completamente de principio a fin. Los procesos complejos, como la incorporación de empleados, pueden ejecutarse sin problemas por sí mismos, con varios permisos y acciones que se activan automáticamente, eliminando prácticamente el error humano y ahorrando tiempo a todos. En resumen, menos trabajo, más flujo.

El valor estratégico de un ITSM 
Un ITSM estrategica , gracias a Service Automation, puede ayudar a allanar un camino claro para que el departamento de TI se convierta en un socio mucho más estratégico en cualquier organización. Todo lo que se necesita es aprovechar la excelencia operativa introducida por la automatización para tres propósitos principales.

• Brindar servicio a los empleados en cualquier lugar y en cualquier momento, para que puedan trabajar y colaborar en el entorno que mejor se adapte a sus necesidades. Esto significa admitir varios sistemas y aplicaciones (Slack, Microsoft Teams, etc.), así como tecnología para trabajar desde casa, en la oficina, en el aeropuerto, en el tren o en cualquier otro lugar. Su experiencia de TI no debería quedarse corta de lo que esperan como consumidores de Uber, Amazon y WhatsApp.

• Conecte todas las aplicaciones y personas de la empresa, de modo que TI pueda brindar servicios a través de los flujos de trabajo de manera inteligente y sin problemas. Esto incluye la coordinación de la tecnología y las soluciones adquiridas de forma independiente por los empleados de varios otros departamentos corporativos.

• Aproveche las lecciones aprendidas para transformar la prestación de servicios en toda la empresa, ya que se espera que cada vez más departamentos brinden servicios de manera digital. Con años de experiencia, el liderazgo de TI se encuentra en una posición única para compartir las reglas y los procesos que funcionan, así como para adaptar las herramientas del servicio digital (como SysAid) a las necesidades de otras organizaciones.

Desde recursos humanos hasta adquisiciones y todo lo demás, la automatización hace que las cosas funcionen de manera más eficiente y efectiva. Con la llegada de la Automatización de servicios, los equipos de TI ya no están estancados en funcionamiento, centrándose solo en el mantenimiento. En cambio, pueden convertirse en una fuerza que impulse la innovación en el espacio de trabajo digital.
​