VERSION
MOVIL - WEB
CHOOSE YOUR LANGUAGE

El proyecto de una maratón con PMP

Tiempo estimado 3:18 minutos.

Runner y gestor de proyectos... ¿qué puede tener esto en común? salvando la complejidad de los grandes proyectos creo bastante didáctico este ejemplo para entender lo que es un proyecto así como una presentación básica de la metodología de dirección de proyectos PMP.

Es importante diferenciar que una metodología de proyectos es independiente del área de aplicación específica del proyecto y es complementaria a otras posibles metodologías del sector. Este artículo no pretende proponer una programación o plan de entrenamiento para una maratón, sino mostrar que todos los proyectos se pueden gestionar de forma muy similar y con técnicas de gestión comunes e independientemente del área de aplicación. Por ejemplo, la dirección de un proyecto de desarrollo de software se puede realizar con PMP y complementar con una metodología de desarrollo software específica como pudiera ser por ejemplo Métrica v3, RAD, SRUM, RUP etc.

Una Maratón en término de proyectos
La primera cuestión sería…  ¿podríamos pensar “correr una maratón” en términos de proyecto? Los que hemos afrontado este reto diríamos intuitivamente de forma rápida que sí, ya que es algo temporal con unos resultados, que precisa de un plan (entrenamientos, nutricional), tiene objetivos, coste etc.

Si analizamos el concepto de proyecto según el PMBOK, un proyecto es un esfuerzo que se lleva a cabo para crear un producto, servicio o resultado, y tiene la característica de ser naturalmente temporal, es decir, que tiene un inicio y un fin establecidos, y que el fin se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. A raíz de esta definición podemos observar que efectivamente correr una maratón tiene naturaleza de proyecto:

Resultado: Esencialmente será finalizar la carrera.

Objetivos: son personales de cada corredor, por ejemplo, finalizar en una marca determinada, sentirse mejor, estar en forma, superarse a sí mismo, hacer amigos, cumplir alguna promesa, organización benéfica etc.

Temporal (Inicio y Fin): desde que se inicia el entrenamiento hasta que finaliza la carrera (o hasta que se cancele por que sepamos que no se puede cumplir). Por ejemplo, para un corredor habitual podría ser de 5 a 6 meses en función de objetivos y podría tener incidentes que obligaran a cancelar el entrenamiento y por ende la propia carrera.

PMP Runner


Además podríamos pensar en otras características muy propias de los proyectos y las cuales PMP incorpora en su gestión, especialmente las variables Coste, Tiempo y Alcance.

Coste: se puede estimar un presupuesto considerando los gastos de la carrera, entrenamiento, material, coste del viaje, ingresos por patrocinador, gastos en nutrición etc.

Tiempo: existen hitos específicos en cualquier plan entrenamiento, con periodos de descansos, nutrición etc. Podrían reflejarse específicamente en un cronograma de proyecto. Lógicamente un hito sería el propio día de la carrera y el hito de cierre de proyecto podría ser una vez finalizada la recuperación y después de haber realizado un análisis de los resultados.

Alcance: debe de ser un alcance realista y factible teniendo en cuenta nuestra madurez como corredor, ritmo de vida, medios disponibles etc. ¿Corro habitualmente? ¿Qué experiencia tengo en carreras anteriores? ¿Mi vida familiar y laboral me permitirá alcanzar el reto?

Gestión de los Interesados (“stakeholders”), es decir, todas aquellas personas u organizaciones cuyos intereses puedan ser afectados como resultado de la ejecución o finalización del Proyecto: familia,  afectados en el trabajo, grupo de entrenamiento, la organización de la carrera, organización benéfica etc. Como en la mayoría de los proyectos cuando intentamos identificar interesados podemos ver que surgen muchos afectados en el proyecto con más o menos grado de influencia y con los cuales se tendrá que gestionar la comunicación, expectativas etc.

Gestión del Cambio: como en todo proyecto…  en el transcurso de la preparación será necesario afrontar los cambios que podrán afectar al corredor, resto de corredores, familia etc.  y que deberán de ser gestionados.

Gestión de Riesgos: existen probabilidades de eventos que afecten al proyecto positiva o negativamente en sus diferentes aspectos: posible lesión,  no poder seguir el plan por enfermedad o temas laborales, imposibilidad de presentarse el día de la carrera, mi empresa organiza un grupo de corredores y regala el material de entrenamiento, se cancela el grupo de entrenamiento, mi compañero de carrera se lesiona etc.

En el fondo, de forma más o menos consciente o formal, se está siguiendo un ciclo de gestión del proyecto que podría ser como el propuesto por PMP, es decir,  una iniciación de proyecto cuando comenzamos con la idea, definimos el alcance y los objetivos, se evalúa la viabilidad, riesgos iniciales etc., la planificación donde encajaría la realización de los planes mencionados, la ejecución de los propios planes (entrenamiento, carrera etc.),  por supuesto con una monitorización y control a lo largo del proyecto, es decir,  habrá puntos y mediciones necesarias para verificar que el avance, seguimiento de los planes, gestión de los riesgos del proyecto …  y además un cierre de proyecto, a ser posible de forma exitosa, aunque no es la única opción, y donde se guardarán las “lecciones aprendidas” que serán de utilidad para futuros proyectos similares.

Espero haber ayudado a aclarar el concepto de proyecto que muchas veces es confundido con tareas recurrentes en el tiempo cuya gestión es diferente o incluso con el propio producto o servicio entregado (es diferente el ciclo de un proyecto del ciclo de vida de un producto).  Asimismo podemos observar que existen pautas comunes en la gestión de cualquier proyecto y que son aplicables a proyectos de cualquier disciplina: “Construir un barco”, “Implantar un nuevo Centro de Datos”, “Realizar una Auditoría”, “Desarrollar un producto software”, “Realizar una campaña de ventas”, “Preparar un examen de oposición”, “Realizar un estudio estadístico”, “Publicar un libro” etc.


Project Management Institute - PMP (Project Management Professional) https://www.pmi.org/certifications

PRINCE2 (PRojects IN Controlled Environments)  https://www.prince2.com/

IPMA (International Project Management Association) http://www.ipma.world/certification/

APM (Australian Institute of Project Management) http://www.aipm.com.au/certification


CMMI (Capability Maturity Model Integration) http://www.sei.cmu.edu/certification/

Del outsourcing tradicional a los servicios en cloud

Tiempo estimado 3:13 minutos.

En el mundo de la externalización de servicios ha surgido con gran fuerza todo lo relacionado con la nube y términos como  Business as a Service (BaaS), Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) . Se ofrecen servicios sobre Internet o redes privadas, soportadas por tecnologías robustas de Cloud Computing, a diferentes niveles (negocio, software, plataforma, infraestructura etc.) y normalmente como pago por uso. Realmente se pretende ofrecer el acceso a las tecnologías de la información (TI) y a los servicios para la empresa con la misma facilidad con la que se accede por ejemplo a servicios comunes como la electricidad, gas, agua etc.

Este modelo aplicado a la capacidad de procesamiento informático, al software y a las funciones de la empresa  está redefiniendo la forma de operar de las organizaciones y de atender a sus clientes así como a las personas que las componen. También está modificando la función de los proveedores de servicios y de las empresas de outsourcing.

Las organizaciones tienen a su alcance la posibilidad de contratar proveedores en la nube de forma rápida, sin apenas necesidad de infraestructura. Desde aplicaciones de negocios (ERP, CRM, aplicaciones de Recursos Humanos, contabilidad, ventas etc.), canales de comunicación (correo, sms, faxes …), plataformas (Plataformas java, php, .net, mysql, oracle), aplicaciones sociales (redes sociales, entornos colaborativos, foros, videochats…). Posiblemente cualquier organización pequeña podría gestionar toda su informática con herramientas y servicios en la nube.

¿La nube dejará obsoleto el outsourcing tradicional?
Podríamos pensar que la nube dejará obsoleto el outsourcing tradicional, sin embargo, aunque la nube, indudablemente, ha simplificado algunos aspectos del mundo de los servicios a empresas, también ha añadido complejidad a muchos otros y especialmente en empresas grandes o que tienen negocios lo suficientemente complejos que no se pueden estandarizar. 


Cloud vs Outsourcing


Ciertamente, algunos tipos de servicios podrían llegar a resultar casi tan sencillos como la luz, sin embargo, en otros la definición de  los servicios, niveles de calidad, precios en el nuevo entorno etc. requieren una gran complejidad. El peligro para los clientes corporativos en este momento de evolución de los servicios en nube y del outsourcing radica en resaltar en exceso lo que resulta fácil y prestar insuficiente atención a las partes más difíciles. Debido a esto se necesitará de los proveedores tradicionales de outsourcing para integrar estos servicios.

Desde la perspectiva de las TI, la introducción del modelo de nube significa en realidad que ahora los responsables de TI deben gestionar un entorno híbrido aún más complejo: servicios externos proporcionados desde la nube, en combinación con sus propios sistemas internos gestionados de una forma similar a los de la nube, además de aplicaciones más antiguas heredadas.

Desde la perspectiva de los procesos de negocio, es necesario gestionar cuidadosamente los puntos de integración entre diferentes funciones y procesos, ya que los proveedores que operen como lo hacen en la actualidad y las empresas de suministros públicos no tendrán una  idea muy clara de cuáles son los objetivos generales de sus clientes corporativos.

cloud

He participado en varios proyectos de implantación de este tipo de herramientas en la nube. Modelos SaaS con servicios listos para configurar y operar con ciertos negocios y también con características PaaS que suelen incluir alguna plataforma de desarrollo para poder realizar modificaciones “a medida”. Además soportado con técnicas de Cloud Computing con varios Centros de Procesos de datos distribuidos en diferentes continentes. 

Las características que he encontrado con estos proyectos son las siguientes:

1. Gran rapidez de puesta en marcha y sin necesidad de infraestructura propia. Puede surgir la necesidad de un proyecto de implantación  donde es habitual contratar con una empresa especializada (normalmente el propio proveedor o bien una empresa certificada).

2. Servicios y aplicaciones WEB soportados con técnicas de Cloud Computing muy robustas con flexibilidad para el crecimiento. Soportados en Centros de Datos con las mayores garantía.

3. Suele ser una baja inversión inicial ya que se suele facturar como servicio por uso, sin embargo, hay que hacer una estimación de crecimiento ya que los gastos recurrentes podrían incrementarse mucho. El pago es por uso y habitualmente es más alto que el coste de las licencias de mantenimiento tradicionales. (La comparativa es Propiedad vs Alquiler).

4. Los contratos de servicio (SLA) de confidencialidad son primordiales en este tipo de servicios.

5. Mayor complejidad en la contratación, especialmente si se trata de contratación en Administraciones Públicas.

6. Muy importante tener en cuenta los datos personales y otros datos críticos de la organización ya que posiblemente estarán en varios países con diferentes legislaciones.

7. Considerar con mucho cuidado la interoperabilidad con sistemas ya existentes en la organización, ya que puede ser compleja y debe de considerarse que información va a “subir a la nube”.

Los servicios en la nube ofrecen otras alternativas de provisión TI a tener en cuenta, y lo más importante, quizá, es empezar a entender lo que significa operar en un entorno con múltiples proveedores, en el que es necesario integrar diferentes componentes en entornos híbridos más complejos. Además hay que ser consciente que sistemas de información son críticos y aportan valor de negocio en la organización y si es viable la estrategia de trasladarlos a servicios en la nube.  Claramente  existen notables diferencias, y aspectos a tener en cuenta, si se decide gestionar en la nube ciertos procesos de negocio, bases de datos de clientes, sistema de facturación o los recursos humanos que por ejemplo si se trata de un portal público, servicios de correo electrónico o servidores de fax.


ERP (Enterprise Resource Planning): Sistemas de información para gestionar una empresa. Normalmente estructurados en diferentes módulos: finanzas, facturación, ventas, recursos humanos, logística etc.

CRM (Customer Relationship Management): Sistemas de información para la relación con tus clientes (atención al cliente, fuerza de ventas, campañas, segmentación etc.)


Gestionando los riesgos de un proyecto

Tiempo estimado 3:02 minutos. 

Existen acontecimientos en el transcurso de un proyecto que pueden hacer que no se consigan los objetivos marcados y que impactan sobre aspectos como el coste, tiempo o alcance. Posiblemente a cualquier director de proyecto se le ocurrirían multitud de ejemplos reales y que han impactado alguna vez en su gestión,

“Se reestructura la organización y cambia el equipo de proyecto”
“Se vende parte de la compañía afectando al alcance del proyecto”
“Surge un nuevo negocio o cambia el mercado y el proyecto deja de ser rentable”
“Los equipos previstos para la compra dejan de fabricarse”
“Las condiciones climatológicas impactan considerablemente en la duración del proyecto”
“El software base sobre la construcción del proyecto queda obsoleto y deja de mantenerse”
….

Es imposible controlar y conocer a priori todos los acontecimientos que pudieran ocurrir, sin embargo, sí es posible intentar anticiparse y gestionar de manera formal mediante técnicas de gestión de riesgos.

¿Qué es un riesgo?
Un riesgo es la probabilidad de ocurrencia de un evento que pueda impactar de forma negativa (amenaza) o positiva (oportunidad) en el proyecto. Por su naturaleza se trata de algo dinámico, es decir, aparecen y desaparecen riesgos, cambian las probabilidades de ocurrencia en el tiempo etc., por lo que su detección a tiempo es primordial y su gestión debe de ser continuada.

Todo riesgo tiene al menos las siguientes características:

Nombre y descripción del riesgo
Tipo: Estratégico, organizativo, funcional, técnico etc.
Externo o interno al proyecto
Tipo de impacto: Positivo (oportunidad) – Negativo (amenaza)
Probabilidad de ocurrencia del evento
Impacto: cuanto afecta al proyecto y en que dimensiones (alcance, tiempo, coste etc.)

Gestionar el riesgo
La gestión del riesgo es el proceso de planificar, detectar, analizar, responder y controlar los riesgos.

Con la planificación básicamente estaremos definiendo como vamos a realizar las tareas de detección, análisis, respuesta y control. Se suele determinar o definir la metodología que usaremos, el equipo de gestión de riesgos, el formato de los riesgos, la definición de cómo se va a evaluar la probabilidad y el impacto, la matriz de riegos que usaremos (combinación entre la probabilidad de ocurrencia y el impacto),  se podrá definir una “Risk Breakdown Structure” o estructura de desglose de riesgos para categorizar etc.


Matriz de Riesgos
Ejemplo de diseño de matrices de riesgo


La detección y análisis no es sencilla y el resultado sería una lista de riesgos con el formato y características definidas en el plan. No hay que confundir un riesgo con un hecho, es decir, el riesgo es siempre una probabilidad mientras que el hecho ya ha ocurrido.

Durante el análisis del riesgo, tanto en la probabilidad de ocurrencia como en el impacto, se podrá evaluar de forma cualitativa o cuantitativa en función de las necesidades y del grado de exactitud que podamos tener en cada fase del proyecto:

Cualitativamente con valores discretos: Por ejemplo, probabilidad de ocurrencia (muy alta, alta, media, baja) o impacto (crítico, alto, medio, bajo)

Cuantitativamente (probabilidad de ocurrencia entre 0 y 1 o %, Impacto cuantificado en euros etc.)

A partir de los valores anteriores podremos confeccionar las matrices de riesgos, conforme  se haya definido en el plan, y de esta forma tendremos clasificados los riesgos para su tratamiento.

Una vez que hemos detectado, analizado y clasificados los riesgos es necesario establecer una respuesta para cada riesgo. Existen las siguientes posibilidades de tratamiento:

1 Eliminar: acciones para eliminar completamente el riesgo. No siempre es posible o las acciones son muy costosas.
2 Mitigar o reducir: acciones con el objetivo de reducir la probabilidad de ocurrencia intentando que no se materialice. Se trata de respuestas preventivas como las anteriores aunque habitualmente más realistas y menos costosas.
3 Transferir: acciones que transfieran el riesgo fuera del proyecto ó incluso la organización etc. Por ejemplo contratar un seguro que cubra el impacto en caso de materializarse.
4 Asumir el riesgo y no hacer nada o  establecer un conjunto de acciones que se realizarán solo si ocurre el evento.
5 Provocar: en el caso de las oportunidades podrían establecerse acciones para intentar que el acontecimiento se produzca e impactar favorablemente en el proyecto.

Como es de imaginar todas las acciones anteriores tendrán un coste y un esfuerzo y no tendría sentido implantar respuestas o medidas cuyo coste fuera inviable con respecto al impacto o probabilidad del riesgo.

Finalmente, el control del riesgo se refiere a la medición y puntos de control de los riesgos durante el proyecto y que servirá para mantener la lista de riesgos actualizada así como medir el impacto real en caso de producirse algún acontecimiento.

Podremos observar que el objetivo final es intentar anticipar los riesgos, conocerlos y tener mecanismos de respuesta en el caso de que se materialicen y además realizando la gestión de forma continuada durante el proyecto.

Una vez expuestos los conceptos básicos del tratamiento de los riesgos en un proyecto (especialmente proyectos grandes en entornos cambiantes), reseñar que la gestión de riesgos es de aplicación en muchas otras áreas  en las organizaciones como pudieran ser en la ejecución de políticas o estrategias, impactos normativos, economía, finanzas, seguridad, industria etc.  También mencionar que existen variedad de certificaciones, metodologías, estándares y herramientas que nos permitirán tener una gestión conforme áreas de aplicación y necesidades.

RBS Risk Breakdown Structure
Ejemplo de RBS


Certificación de PMI Risk Management Professional (Project Management Institute)


Prince2 y la gestión de riesgos http://prince2.wiki/Risk


MAGERIT V.3.: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Magerit.html

Apud acta electrónica, representación en el juzgado

Tiempo estimado 1:50 minutos

Salvo ciertos procedimientos en el orden social y civil de cuantías menores, la relación de la Administración de Justicia con los ciudadanos y empresas es en su mayoría a través de representación mediante procurador, abogado y en algunos casos graduados sociales.

Debido al carácter técnico y complejidad jurídica en muchos procedimientos judiciales es obligada la intervención del procurador o abogado e  incluso en aquellos procedimientos en que no es preceptiva esta intervención los interesados podrían designar a uno para que les representen.

Actualmente el poder de representación puede ser concedido ante notario, pagando por el servicio prestado,  o bien gratuitamente en el juzgado ante el Letrado de la Administración de Justicia (apud acta). Para la concesión de un apud acta basta con la comparecencia del interesado (poderdante), no siendo  necesaria la presencia del apoderado. El poder no se considera válido hasta su primer uso y además el apoderado podrá renunciar expresamente a él.
El apoderamiento apud acta se trata del acto jurídico mediante el cual un interesado (poderdante) faculta a un apoderado, profesional de la justicia, para que le represente y realice por él los actos a lo largo de un procedimiento judicial.



Firmando


La ley 42/2015, de reforma de la Ley 1/2000 de Enjuiciamiento Civil,  establece dos aspectos importantes referente a las apud actas y la administración electrónica:

  1. Establece la creación de un archivo electrónico de apoderamientos apud actas.
  2. Regula la posibilidad de apoderar mediante comparecencia electrónica en Sede Judicial Electrónica, es decir, el poder en que la parte otorgue su representación podrá ser conferido apud acta por comparecencia personal ante el secretario judicial (actuales letrados de la Administración de Justicia) de cualquier oficina judicial o por comparecencia electrónica.


Esta normativa habilita para que el ciudadano tenga a su disposición en la Sede Electrónica una serie de servicios electrónicos de representación,  similares a los que puede realizar presencialmente en un juzgado, y cuyas características pudieran ser de la siguiente forma:

  1. La comparecencia electrónica será mediante DNIe, certificado electrónico o similar, es decir, el ciudadano se autenticará entrando en la Sede Judicial Electrónica para poder hacer uso de sus servicios. (Habitual en cualquier sede electrónica de cualquier administración pública española)
  2. Posibilidad de realizar una solicitud de apud acta de forma electrónica facultando a un procurador, abogado o graduado social. Esta solicitud sería firmada electrónicamente por el interesado.
  3. Después de las validaciones correspondientes de la solicitud anterior, si procede,  se producirá la inscripción del poder en el archivo electrónico de apoderamientos y además se podrá obtener un certificado de inscripción sellado electrónicamente para su descarga.
  4. Sería lógico que el ciudadano poderdante pudiera consultar sus Apud actas  y además realizar operaciones como la revocación o renovación conforme normativa.
  5. El apoderado profesional de la justicia debería también poder comparecer en la Sede Judicial Electrónica para poder consultar o descargar certificado de sus poderes e incluso poder renunciar a ellos electrónicamente.

En resumen,  uno de los muchos aspectos que regula esta ley es fomentar los servicios electrónicos de representación apud acta, siendo un paso más en la relación electrónica con la Administración de Justicia y con el objetivo de evitar desplazamientos del ciudadano así como reducir la carga de trabajo en el juzgado.


Ley 42/2015 de reforma de la Ley 1/2000 de Enjuiciamiento Civil: 


Sede Judicial Electrónica (ámbito Ministerio de Justicia):
https://sedejudicial.justicia.es