Funciones de una PMO en una organización ágil

Tradicionalmente se ha considerado una PMO (Project Management Office – Oficina de gestión de proyectos) como una entidad encargada de la centralización y coordinación de proyectos de la organización: coordinando recursos compartidos entre proyectos; identificando metodologías, buenas prácticas y estándares; formando y mentorizando a los Project Managers o coordinando la comunicación entre proyectos. Sin embargo, en una organización ágil este paradigma debe ser modificado en parte. En el “agilismo” hay una serie de principios que se tratan de respetar: personas sobre procesos, software que funciona sobre documentación, colaboración con el cliente sobre el contrato y respuesta al cambio sobre planificación.

Así pues, en una organización ágil, la PMO no es una entidad controladora y perseguidora de estándares. Más bien se debe convertir en una entidad facilitadora para los diferentes equipos de trabajo y que promueva el aprendizaje continuo.

Su rol se debe reorientar hacia otras funciones que aporten más valor y sean coherentes con la filosofía ágil:

  • Mentorizar y proporcionar servicios de coaching a los equipos de trabajo y a los scrum masters.
  • Desafiar continuamente a los equipos de trabajo para que apliquen la mejora continua en sus prácticas ágiles.
  • Ayudar con los informes de seguimiento: determinando qué métricas utilizar y ayudando a los equipos a concentrarse en la entrega continua de valor. Todo lo que no proporciona valor es desperdicio.
  • Gestionar el WIP (Work In Progress): Todas las organizaciones tienen un ratio de ‘trabajo en curso’ con el que trabajan de forma óptima. La PMO ágil debe vigilar que su organización se encuentre lo más cercana posible al valor óptimo. Se puede incorporar un nuevo proyecto a la cartera de proyectos en curso sólo cuando se ha finalizado un proyecto de esfuerzo similar que haya liberado recursos de la organización. En cuanto a las herramientas, podemos apoyarnos en aquellas que nos ayuden a planificar y hacer un seguimiento de los proyectos (herramientas visuales para definir y seguir los backlogs, controlar el WIP, etc.).
  • Reducir el desperdicio (muda en términos ‘lean’): ayudando a los equipos de trabajo a identificar y eliminar todas aquellas actividades y artefactos que no aportan valor.
  • Coordinar equipos: especialmente cuando tenemos miembros que trabajan de forma parcial para varios proyectos de forma simultánea.
  • Fomentar la comunicación entre equipos: favoreciendo que las buenas ideas y buenas prácticas identificadas por un equipo sean conocidas y aprovechadas por otros. En este ámbito, es útil el uso de herramientas para facilitar el rápido intercambio de información entre los miembros del equipo (que cada vez de forma más habitual trabajan distribuidos). Dicha información debe ser clasificable para su rápida recuperación posterior. Necesitamos herramientas de colaboración tanto síncronas (chats, teléfono, Skype, etc.), como asíncronas (correo electrónico).
  • Proteger a los equipos de proyecto: defendiendo y explicando sus necesidades a otros departamentos (personal, CEO, etc.) cuando deben tomarse decisiones que afecten a la ubicación de los miembros de un equipo en la oficina, la adquisición o eliminación de herramientas de trabajo, etc.

Y todo esto sin olvidar que estamos hablando de trabajos intensivos en conocimiento, en los que el principal activo son las personas, los profesionales que llevan a cabo el desarrollo. Por ello, es fundamental dedicar el tiempo necesario a hablar con el equipo y con los project managers; actuando en cada momento según lo requiera la situación: a veces sólo preguntando y ayudando a que el propio equipo encuentre las soluciones, a veces siendo más expeditivo y marcando el camino a seguir y en otras ocasiones sólo escuchando.

En resumen; en una organización que busca ser ágil el rol de la PMO debe ser, como siempre, apoyar la estrategia corporativa. Esto no cambia. Sin embargo, si la estrategia pasa por la agilidad, la PMO debe pasar a ser una entidad más orientada a aconsejar y orientar que a controlar. En lugar de focalizarse en garantizar el cumplimiento de los calendarios y presupuestos de proyectos, debe poner más énfasis en que los proyectos proporcionen el máximo valor posible al negocio o a los clientes finales (sin que esto signifique que calendarios y presupuestos dejen de tener que cumplirse).

En cualquier caso, no todo es blanco o negro; predictivo o ágil. Cada organización debe buscar su camino entre las metodologías predictivas de gestión de proyectos y los modelos más ágiles y muchas veces la opción más adecuada estará en el medio. La PMO deberá ser coherente con la opción escogida por su organización y apoyar al máximo la implementación de su estrategia.

Este post fue publicado primero en el blog de Slashmobility.

Funciones de una PMO en una organización ágil

How to select a business management software in 7 steps

Once we have decided the kind of enterprise software we are going to use in our organization, it is yet necessary to choose amongst many available alternatives. No matter if we are talking about ERPs, CRMs, Project Management software, … all these markets are quite fragmented and we must decide which provider better suits our needs. But how to do it? Is there a proceeding to reduce the risks of making a wrong decision?

There are no magic recipes but in this post I will explain you how we choosed the CRM in our organization. Previuously we had decided to use a Cloud based CRM but there were yet many options in the market.

1. Organize a team that represents the key affected areas

Any business management software is a tool that affects many areas of an organization. In fact, they are designed to work in processes instead of functional departments. So, it is important to involve in the selection process users of the main areas affected by the new tool.

For instance, in an ERP I would try to include at least, people from Operations, Sales, Finance, Production, Warehouse and IT. The team should be leaded by a Project Manager with experience and knowledge of the company and the industry. In a CRM I would like to have at least people from Marketing, IT, Sales and Operations.

In both cases the composition of the team would depend on the modules of the tool that we want to implement. These management tools usually include many modules and every organization must decide which ones are necessary in its case or simply which ones they want to implement in a first stage.

2. Decide what is important for you

It is important to consider your specific situation and decide what aspects of the new tool are more important to you. Everything does not have the same weight when taking decisions.  For instance, in the selection process we followed to choose the CRM of my company we analyzed:

  • Price
  • Strength of the manufacturer
  • Maturity level of the product
  • Backup offline (availability)
  • Data protection compliance (housing)
  • Processes automation
  • Activity audit
  • Workflows customization
  • Level of possible customization to our needs
  • Storage capacity
  • Possibility to implement the tool without external providers
  • Availability of external support (manufacturer or consultants) if needed.

Everyone of these criteria must have assigned a weight according to its relative importance. Indeed, maybe some of them can be mandatory.

3. Analyze the market to find posible candidates

This is a market research. Now that the team knows what is important for the organization, let them explore the market to find possible candidates.

In this phase it is important to read comments from current users of possible candidates on specialized web sites, talk to consultants, contact the manufacturers, contact to other companies who are using the soft, …

Let the team work

4. Let the team evaluate the candidates

After the research, the team should have some meetings to exchange views and to decide the final candidates that they will assess.

Once they have the group of candidates, one member of the team can present one candidate to the rest of the group, explaining the results of his research. After that, every member of the team should evaluate the candidate according to the criteria identified in point 2.

Finally, every candidate will have a final score based on the average points awarded by the team.

5. Make your proposal to the Direction

In this moment the team is ready to present its results to the managers of the company. The whole group or the members who are more skilled doing presentations should conduct one introduction to the performed study and its results. As a result the team will recommend the implementation of one of the applications studied or consider that there is nothing in the market that suits the needs of the organization.

In the second case, the requirements or the criteria of the organization should be reconsidered. Another possibility could be considering the development of  a customized software for the company. But this is out of the scope of this post.

The company management may accept the recommendation of the team or may consider that a further research must be done to be showed in another presentation.

Once the direction of the company accepts the proposal of the team, the ideal case would be to have a first (or preferred) option and a second option (or B plan).

6. Negotiate with the main candidate

It is important to keep a second option available until the end. This provides your organization some extra bargain power with the providers. They must know that if there is no agreement with them the company has other options.

I am not going to detail in this post how to negotiate with potential vendors. I would need a new post. But it is important to assign the role of main negotiator to a member of the team with experience in these situations.

If you do not achieve an agreement with the main candidate, start your B plan and give the opportunity to the second candidate.

7. Choose

Finally, if you consider that you have achieved a deal with the potential provider that satisfies your needs, propose the agreement to the Direction of your company with your reasons to choose this vendor. And let them decide.

How to select a business management software in 7 steps

5 key benefits obtained when choosing a cloud based software

Some months ago I was involved in the selection of a CRM for my company. The first decision was easy to take: we needed a cloud based CRM. Why?

The benefits

We are a young start-up so the next benefits applied to us:

1. No investment required. It is all Opex, no Capex. You just pay a monthly fee based in the number of licenses that you order.

2. No installation needed. You access the application just with your browser. This means you don’t need any additional hardware either.

3. You can access the CRM from anywhere (if you have internet access, of course) and also from mobile devices too.

4. No maintenance efforts required. As there is no installation in our systems we don’t have to maintain the software either. The software provider is in charge of that.

5. We don’t have to update the application. The software provider takes care of that and includes the service in the monthly fee.

Lithium-CRM

CRM System (image by Wikimedia Commons under CC-BY-SA 3.0)

The risks

But we also had to consider some potential risks. The most important ones were:

1. Will our data be safe out of our premises? There is no system 100% safe. You must study well your provider and ask for guarantees about any possible safety risk.

One point to consider is that if you compare the security level of any of the big cloud players with what an average (SMB) company can do there is a huge gap in favor of the first one.

2. What if our service provider closes and stops the service? To be protected against this possibility you should consider working with companies with years of experience and a solid financial situation. So, more homework for you.

3. Can we have legal issues if the data from our customers is out of the EU? It depends on the level of the personal data that you keep but it is very interesting to have your data in servers physically located in a EU country.

If you must use a provider who has its servers in the USA you will have to check that he is included in that Safe Harbor lists.

4. Will our data be available whenever we need it? In this case you should compare the level of availability between different service providers but also the level of availability that you could have with your own infrastructure.

After all these considerations and some discussions with the shareholders of the company we decided to start using a cloud based CRM.

But there are many of them. In another post I will share the methodology that we used to choose amongst the existing offer of service providers.

What about you? Does your company use cloud services? Why? Are you considering to start using them in the near future?

5 key benefits obtained when choosing a cloud based software

5 claves para gestionar la comunicación con tus clientes

Hasta hace 1 año mis clientes eran “internos”. El personal de la empresa en la que trabajaba: desde los otros directivos hasta los empleados que utilizaban las aplicaciones que mi departamento (TIC) gestionaba o cualquier persona de la compañía, pues todo el mundo estaba afectado y afectaba al sistema de gestión de la calidad que yo también mantenía.

Mi contacto con los clientes (finales) de mi empresa estaba limitado al aseguramiento de la calidad en los proyectos en los que interveníamos y a las auditorías de calidad que nos hacían o a la integración de algunos de nuestros sistemas informáticos con los de nuestros clientes.

Reunión con cliente

Reunión con cliente. Imagen cortesía de Daniel Vázquez bajo licencia CC BY-NC-SA 2.0

Desde hace casi un año continuo trabajando en la gestión de proyectos pero ahora tengo contacto directo con los clientes reales y potenciales de mi empresa. Mis comunicaciones con ellos afectan directamente a la cuenta de resultados de la compañía. Por este motivo he tenido que desarrollar una serie de habilidades que me han permitido sobrevivir en este nuevo rol y que ahora quiero compartir contigo:

  1. Identifica las necesidades de información de cada cliente y adaptate a ellas: tipo de información, formato, periodicidad, estilo de comunicación (empatiza). No todos los clientes son iguales y por ese motivo no se puede tratar a todos por igual. Algunos precisan de información detallada, otros de alto nivel, algunos prefieren presentaciones en powerpoint, otros excels detallados, …
  2. Procura mantener contacto personal con frecuencia con todos tus clientes. Ningún documento ni sistema de videoconferencia puede sustituir a la reunión presencial. Identifica los horarios que más les convienen y visítales periódicamente, conoce en qué trabajan, cómo trabajan, qué nuevas necesidades tienen y cómo las quieren cubrir. Te interesa todo sobre ellos.
  3. Intenta establecer una buena relación personal con tus clientes. Cualquier problema que pueda surgir en el curso del trabajo con ellos se encaja y se soluciona de forma muy diferente si la relación es buena o si es fría. Para mantener relaciones estables y provechosas a largo plazo ayuda mucho que la relación personal sea buena. Empatiza con tus clientes, intenta conocer de ellos más allá de lo estrictamente profesional, invítales a un café o a comer y entabla conversaciones más allá de lo estrictamente profesional.
  4. No te autolimites: no presupongas que un determinado producto o servicio no va a interesarle a un cliente ni tampoco que pueda ser demasiado caro para él. Un buen vendedor debe vender todo su catálogo. Tu cliente siempre te va a sorprender, nunca lo conoces lo suficiente. Deja que sea él quien ponga los límites.
  5. Registra tus interacciones con tus clientes: llamadas, correos, documentación intercambiada, entrevistas, reuniones,… Esto es particularmente importante cuando tu base de clientes empieza a crecer y para que el resto de tu equipo pueda compartir datos contigo. Si puedes, utiliza un sistema CRM para gestionar la relación.

Estos son algunos de mis puntos de aprendizaje. Seguro que tú puedes aportar otros. Me gustaría conocer tu opinión siguiendo tus comentarios.

5 claves para gestionar la comunicación con tus clientes

Diseño de un SGC según ISO 9001

Ya he hablado en otras entradas de este blog de los principios y fases de un proceso de implantación de un sistema de gestión de la calidad (SGC) según ISO 9001. También de la primera fase; la planificación. Para continuar con el ciclo, voy a dedicar esta entrada al diseño del sistema. La D del ciclo PDCA.

Una vez realizado el diagnóstico de la situación, después de haber logrado el compromiso efectivo de la dirección y tras haber llevado a cabo una buena planificación debemos pasar a la acción. En mi opinión hay 4 ingredientes imprescindibles es esta segunda fase: información a todo el personal de la organización, formación en gestión de la calidad adaptada a las necesidades de cada grupo de empleados, desarrollo de la documentación del sistema e implantación de los diferentes procesos de la empresa en base a la documentación desarrollada. Vamos a ver cada uno de estos 4 puntos con más detalle.

Información

En cualquier proyecto, un Director de Proyectos pasa la mayor parte de su tiempo gestionando las comunicaciones del proyecto. En un proyecto de implantación de un SGC ésto también es así. En esta fase es fundamental informar a todos los miembros de la organización de:

  • lo que se pretende conseguir,
  • el nivel de implicación que se espera de ellos,
  • cómo les va afectar el proyecto.

La información proporcionada debe ser adaptada al puesto de cada persona en la organización y debe mostrar el compromiso de la organización con el proyecto.

Comunicación con todos los interesados en el proyecto
Comunicación con todos los interesados en el proyecto

Fotografía cortesía de Paul Shanks bajo licencia CC BY-NC 2.0

Formación

La formación debe tener como objeto sensibilizar sobre la calidad en el trabajo y mejorar la comprensión del sistema de gestión, para que todos los afectados puedan comprender los cambios que se van a producir y actuar de forma favorable (o al menos no contraria) a los mismos.

Al igual que la información, la formación deberá adaptarse al puesto y responsabilidades de cada miembro de la organización. Su contenido y duración dependerán del tamaño de la organización pero también de su nivel de madurez en relación a la calidad.

Documentación

Una de las bases de la calidad es la estandarización. Una herramienta fundamental para la estandarización es la documentación, que un vehículo para lograr que las tareas se realicen siempre de la misma forma.

La documentación debe ser redactada en la forma más simple y comprensible, debe describir la forma correcta la forma de realizar las tareas, debe incorporar todo el conocimiento acumulado de la organización, informando de responsabilidades y relacionando unos procesos con otros.

Conforme se vayan redactando procedimientos (que son los documentos que describen los diferentes procesos de la organización) es bueno empezar con su implantación. No obstante, es importante remarcar que lograr la implantación requiere de mucho más tiempo que el de la simple redacción de los procedimientos, especialmente si se parte de un bajo nivel de madurez en relación a la calidad en la organización.

Implantación

Conforme se finaliza la redacción de los documentos y se arranca su puesta en marcha es preciso realizar una serie de actividades con objeto de fijar los nuevos procesos y cambios introducidos:

  • empezar a realizar las tareas cotidianas según se describe en los procedimientos e instrucciones,
  • realizar un seguimiento y verificar de forma distendida el nivel de aplicación,
  • corregir los procedimientos en base al feedback obtenido en el seguimiento.

¿Qué opinas de este modelo de diseño? ¿qué elementos utilizáis en tu organización?¿consideras que hay algún ingrediente importante que falte?

Diseño de un SGC según ISO 9001

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

Ya he hablado en este blog sobre la metodología y los principios a seguir en un proceso de implantación de un Sistema de Gestión de la Calidad (SGC) según ISO 9001.

Ahora me gustaría tratar con algo más de detalle las fases a seguir en un proyecto de este tipo. En concreto, me voy a centrar en la fase de Planificación (la P del ciclo PDCA).

Bajo mi punto de vista, los hitos más relevantes son:

1. Diagnóstico de la situación.

2. Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad

3. Elaboración de un plan de actuación para la implantación y la certificación.

Vamos a verlos ahora con más detalle.

Diagnóstico

En esta fase es conveniente revisar la forma como se está (o no se está) gestionando actualmente la calidad en la organización.

Cuando actuamos como consultores externos, es importante dedicarle el tiempo necesario a esta fase. Se trata de comprender lo mejor posible la forma como actualmente está trabajando la organización. Hay que preguntar mucho y escuchar de forma activa, hacer participar al máximo de personas que vayan a estar afectadas por el proyecto y ser muy empático.

En esta fase, y de acuerdo con la Dirección, podremos definir el alcance más adecuado para el sistema, el tiempo que se le va a dedicar y los recursos necesarios.

Pero también, mediante el diálogo con todos los implicados, deberemos ser capaces de detectar posibles elementos de resistencia al cambio y también  posibles riesgos que puedan dificultar la consecución de los objetivos del proyecto. Como consecuencia, uno de los resultados de esta fase será un listado de alto nivel de los riesgos del proyecto junto con posibles acciones a realizar en relación a ellos.

Compromiso de la Dirección

Para empezar, se debe obtener un compromiso formal de la Dirección en relación a la implantación. Ésto es básico y si no se logra es razón suficiente para no continuar con el proyecto. Uno de los primeros entregables debe ser la definición junto a la Dirección de una Política de Calidad.

También es necesario hacer un análisis de las necesidades de los clientes, establecer métodos para medir su nivel de satisfacción y planear cómo se va evaluar a proveedores (si no se estaba haciendo ya) y analizar cómo se tratan las incidencias y/o reclamaciones de los clientes.

Acabaremos esta fase fijando los objetivos de la calidad, de acuerdo con la Dirección y con los implicados en conseguirlos.

5222966685_92f9cdc084_o

Strategic Plan – cortesía de Alper Çuğun mediante licencia CC by 2.0

Elaboración de un plan de actuación

La implantación de un sistema de gestión de la calidad debe enfocarse como un proyecto. Debe tener un alcance definido, un presupuesto y un calendario.

Al igual que es fundamental obtener el compromiso de la Dirección, también es básico designar un responsable de dirigir este proyecto. Es conveniente que sea una persona de dentro de la organización, que sea buen conocedor de su cultura y de su estructura.

También es importante que este persona tenga un perfil que le permita liderar el proyecto y ser capaz de comunicarlo adecuadamente dentro de la organización. De hecho, probablemente la actividad a la que tenga que dedicar más tiempo dentro del proyecto sea la comunicación.

Es posible que internamente dispongamos de personas con este perfil pero que no tengan conocimientos sobre gestión de la calidad. Eso no es invalidante, bajo mi punto de vista. En caso de encontrarnos en esta situación será conveniente formar adecuadamente a la persona escogida y ayudarla con un consultor externo que aporte el conocimiento sobre la gestión de la calidad y la experiencia en su aplicación en otras organizaciones.

Doy por supuesto que la persona escogida está completamente comprometida con el proyecto y dispuesta a asumir el rol de agente de cambio en la organización, en complicidad con el consultor externo. Bajo mi punto de vista, tan importante es la aptitud como la actitud.

¿Qué opináis sobre la fase de planificación? ¿Cuál es vuestra experiencia al abordar este tipo de proyectos en vuestras organizaciones?

Planificación de un proyecto de implantación y certificación de un SGC según ISO 9001

Implementación útil de un sistema de gestión de la calidad ISO 9001

Voy a dedicar algunas entradas en el blog a describir el proceso de implantación de un sistema de gestión de la calidad, según ISO 9001, en una organización.

Principios básicos

Tanto cuando he trabajado dentro de una organización con la ayuda de consultores externos como ahora que me dedico a la consultoría externa, he procurado seguir una serie de principios que me han dado buenos resultados:

  • Implantación y liderazgo internos. El equipo de la empresa debe ser el artífice de la implantación y debe haber una persona dentro de la organización que lidere todo el proceso. En función del tamaño de la organización será preciso que se dedique en exclusiva o no a este proyecto.
  • Metodología didáctica y de mejora continua:
    • dedicación continua pero no excesivamente invasiva.
    • demostrar y convencer es mejor que imponer.
    • explicación clara y concisa de los motivos de los cambios que se deban realizar en la organización.
  • Lograr un sistema de gestión útil y lo más simple posible.

Fases de un proceso de implantación

Un sistema que me ha dado siempre buenos resultados consiste en utilizar el conocido proceso PDCA (Plan-Do-Check-Act). Se trata de seguir las siguientes fases:

ciclo PDCA y la mejora continua
ciclo PDCA y la mejora continua

Mejora continua y PDCA – cortesía de Wikipedia (lic CC)

1. Plan

Diagnóstico de la situación.

Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad

Elaboración de un plan de actuación para la implantación y la certificación.

2. Do

Información al personal para lograr su participación y colaboración.

Formación para una mejor comprensión del sistema y de los cambios organizativos que comporta.

Documentación del sistema: manual de calidad, procedimientos e instrucciones.

Implantación: puesta en marcha de procedimientos e instrucciones. Seguimiento inicial (informal) y adaptaciones.

3. Check

Auditorías internas.

Revisión del sistema.

Certificación del sistema por una Entidad de Certificación.

Resolución de No Conformidades.

4. Act

Revisión por la Dirección. Establecimiento de nuevos objetivos estratégicos.

Optimización y mejora continua.

Y así volveríamos a entrar en un nuevo ciclo PDCA.

Como decía al principio, en próximas entradas describiré con más detalle cada una de estas fases.

¿Habéis participado en procesos de implantación de sistemas de gestión de la calidad? ¿Qué método seguisteis en vuestra organización? ¿Qué salió bien y qué no repetiríais?

Puedes añadir un comentario en la entrada o contactar conmigo por correo electrónico rellenando el formulario y explicarme tus impresiones.

 

Go back

Your message has been sent

Warning
Warning
Warning

Warning.

Implementación útil de un sistema de gestión de la calidad ISO 9001

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

Recientemente el PMI ha publicado una extensión de software de la quinta edición de la Guía del PMBOK® (en inglés).

La Guía del PMBOK®, es un conjunto de buenas prácticas internacionalmente reconocido para la dirección y gestión de proyectos. La quinta edición se ha convertido en un estándar reconocido por ANSI (y publicado como anexo en la propia guía).

Elaboración conjunta PMI-IEEE

La “Extensión de Software de La Guía del PMBOK®” ha sido elaborada conjuntamente por el PMI y por la IEEE Computer Society. Se basa en 5ª edición de La Guía del PMBOK®, manteniendo su estructura, procesos y coherencia en el discurso pero incorpora elementos propios de los proyectos de desarrollo de software para adaptarse a sus características específicas como los métodos de desarrollo adaptativo, que permiten aprovecharse de la naturaleza específica del producto de estos proyectos: las aplicaciones. En general, se trata de productos que permiten la fácil y rápida elaboración de prototipos y el desarrollo incremental.

Público objetivo: todo el involucrado en proyectos de TI

Esta “Extensión” está escrita pensando en organizaciones y equipos que se enfrentan tanto a proyectos de desarrollo como de modificación o de implantación de software y cubre tanto proyectos llevados a cabo internamente como la gestión de proyectos externalizados.

Dado que hay aspectos que no varían en un proyecto de software respecto de uno cuyo producto sea distinto, en todos los apartados en los que no hay especificidades en un proyecto de software se deriva al lector al punto concreto de “La Guía del PMBOK®”.

Por el contrario, cuando hay técnicas o situaciones concretas y específicas de los proyectos de software éstas se mencionan o referencian en la propia “Extensión”. Como ejemplo, uno de mis intereses personales es la Calidad en los Proyectos. En el capítulo 8 del libro se trata este tema y se hace referencia a técnicas de SQA (Software Quality Assurance) y SQC (Software Quality Control) junto con estándares del IEEE aplicables a cada caso, como el IEEE Standard 829 (Software and System Test Documentation) o el IEEE 1008 (Unit Testing).

Habrá que ampliar la librería

Habrá que ampliar la librería … (Fotografía de neoprolog bajo licencia CC BY 2.0)

¿Consideráis útil esta aproximación del PMI frente a los entornos ágiles alternativos?

¿Habéis tenido oportunidad de leer el libro? ¿Qué opináis? ¿Consideráis útil y acertada su publicación o bien pensáis que no tiene sentido adaptar “La Guía del PMBOK®” a proyectos de software disponiendo de entornos ágiles como Scrum o Kanban?

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

4 beneficios de la estandarización del hardware en las organizaciones

De entrada, la estandarización aporta un beneficio claro: permite realizar la misma actividad de la misma forma cada vez.

Estandarización de hardware

En el ámbito de los sistemas de información muchas empresas, especialmente de tamaño pequeño y mediano, sufren la falta de estandarización del hardware que soporta su negocio.

Esta situación se da cuando no hay un departamento de sistemas de información que, de forma centralizada y homogénea, establezca una política o unos criterios de adquisición de hardware.

Un síntoma de la falta de estandarización de hardware es la gran diversidad de marcas y fabricantes en los PCs de los usuarios de la organización. La situación se complica aún más cuando se juntan en un departamento ordenadores de diferentes (y a veces muy diversas) antigüedades. Lo mismo ocurre con frecuencia con las impresoras: muchas empresas disponen de un bonito “jardín” con impresoras en casi cada mesa de usuario y casi cada una de ellas de un fabricante o modelo diferente.

Resultados negativos de esta situación

– Tiempos de espera innecesariamente largos cuando se produce un fallo.

– Problemas y sobrecoste en la gestión de los recambios (ya sea de piezas para los PC como de toners para las impresoras).

Almacén de recambios de hardware

Almacén de recambios de hardware (cortesía de booleancomando bajo licencia CC BY-NC-SA 2.0)

Una situación similar se puede llegar a dar en el CPD (Centro de Proceso de Datos). Como consecuencia de procesos de adquisición o fusión con otras organizaciones o porque el departamento de Compras ha encontrado una determinada “ganga” que le ha ofrecido un proveedor: variedad de servidores de diversos fabricantes y modelos, un “jardín” de switches, …

En este caso los resultados son también negativos:

– Problemas y sobrecoste en la gestión de los recambios

– Sobrecoste y mayor complejidad en la gestión de acuerdos de mantenimiento de hardware con los fabricantes

– Necesidad de mayor conocimiento (más diverso) dentro de los miembros del departamento de sistemas de información para poder gestionar un parque amplio.

Posibles vías de solución

1. Definir modelos estándar de PC según el tipo de usuario, limitando el catálogo de PCs a 2 o 3 dentro de toda la organización.

2. Realizar compras de PCs de forma regular y programada, sin esperar a que los ordenadores se vayan “muriendo”.

3. Dejar de trabajar con una impresoras para cada usuario (o compartida para grupos de usuarios muy reducidos) y pasar a trabajar con grandes impresoras en red y en modo de pago por uso.

Beneficios de la estandarización de hardware

1. Las compras “en bloque” permiten conseguir descuentos con los proveedores y ayudan a controlar mucho mejor los períodos de garantía de las máquinas.

2. Limitar el parque de PCs a 2 o 3 modelos distintos facilita mucho la labor de los responsables de su mantenimiento: por un lado limita el conocimiento de modelos a controlar y sus particularidades y por otro permite tener un reducido stock de repuestos que cubre todo el parque.

3. La limitación de modelos también favorece la resolución rápida de averías, dado que se dispone de repuestos y que se tiene mayor conocimiento de las particularidades de los 2 o 3 modelos a mantener. Esto es bueno porque limita los tiempos de caída de los servicios.

4. La estandarización de las impresoras y el pago por uso permiten a los departamentos de sistemas (o compras según el caso) olvidarse del mantenimiento y de la gestión de los toners (y su reciclaje).

En una de las empresas en las que he trabajado conseguimos poner en marcha este proceso, realizando una compra anual de PCs y renovando todo el parque cada 4 años (una cuarta parte cada año). Logramos descuentos importantes en las compras y pudimos empezar a gestionar correctamente las garantías de los fabricantes, entre otros beneficios ya mencionados.

La sustitución de más de una veintena de pequeñas impresoras “personales” por 3 impresoras en red permitió un importante ahorro de costes (que además, si así se desea, se pueden llegar a imputar por usuario) y minimizar los tiempos sin servicio.

¿Qué hacéis en vuestras organizaciones? ¿Seguís este tipo de prácticas? ¿Qué dificultades os encontráis?

4 beneficios de la estandarización del hardware en las organizaciones

El factor humano en la gestión de riesgos / Human factor in risk management

(english version below)

Hace unos días asistí a la presentación de una herramienta de gestión de riesgos, aplicable a la gestión de proyectos pero también a otros ámbitos.

La herramienta, a partir de las estimaciones realizadas por el director de proyecto y su equipo de colaboradores, realiza un elevado número de simulaciones (configurable) siguiendo el método de Montecarlo.

Qué es la simulación de Montecarlo

La simulación de Montecarlo consiste en crear un modelo matemático del sistema a analizar, identificando aquellas entradas o variables del modelo cuyo comportamiento aleatorio determina el comportamiento global del sistema.

Una vez identificadas las mencionadas variables aleatorias, se procede a generar –mediante una aplicación informática- muestras aleatorias (valores específicos) para estas variables  y a analizar el comportamiento del sistema ante los resultados generados.

Repitiendo n veces este proceso, se obtienen n resultados sobre el comportamiento del sistema, permitiéndonos entender mejor el funcionamiento del mismo. A mayor número (n) de experimentos realizados, lógicamente, obtendremos más precisión en el análisis.

El Casino de Montecarlo dio nombre a la simulación
El Casino de Montecarlo dio nombre a la simulación

Foto de azugaldia bajo licencia CC BY 2.0

Cómo se aplica la simulación en la dirección de un proyecto

En nuestro caso, las variables de entrada al sistema serían, por ejemplo, las variaciones en el coste o en la duración de las actividades del proyecto en función de que se materialicen o no determinados riesgos. Como resultado, la aplicación proporciona, entre otros datos, una gráfica con las probabilidades de acabar el proyecto en determinada fecha o con un determinado coste.

Actualmente la tecnología nos puede ayudar mucho y, especialmente en proyectos de elevado coste y/o en los que no acabar en plazo pueda causar peligro para equipamientos o vidas humanas, este tipo de herramientas puede ser de gran ayuda.

El factor humano

Sin embargo, mi reflexión viene motivada porque toda la información de partida que utiliza la herramienta debe ser proporcionada por personas; la probabilidad y la estimación de impacto de que se materialice un determinado riesgo, la identificación exhaustiva de los riesgos que pueden afectar al proyecto, los criterios para definir la matriz de probabilidades e impactos … Si todo ésto no es acertado, todos los cálculos que muy afinadamente realicen las máquinas en base a esta información serán erróneos.

La experiencia del Director del Proyecto y de su equipo, su formación, la posibilidad de tener un equipo de proyectos multidisciplinar, que sea capaz de tener en cuenta todas las afectaciones e implicaciones del mismo, la posibilidad de disponer de una buena base corporativa de lecciones aprendidas de otros proyectos, el conocimiento de la organización en la que se desarrolla el proyecto y de su grado de aversión al riesgo…

¿Qué otros factores humanos consideras que pueden afectar a la gestión de riesgos de un proyecto? ¿utilizáis aplicaciones en vuestras organizaciones que os ayuden en este proceso?

—— ENGLISH VERSION —————

Some days ago I attended a presentation of a risk management tool, applicable to project management but also to other environments.

The tool performs a big number (configurable) of simulations based on the estimations made by the project manager and its team, according to the Montecarlo method.

What is Montecarlo simulation?

Montecarlo simulation consists on the creation of a mathematical model of the system to be analyzed and the identification of the inputs or variables whose random behavior determines the behavior of the whole system.

After that, random samples (specific values) are generated using an application. Those samples are used as inputs of the system and the outputs are used to analyze its global behavior.

Repeating n times this same process it is posible to obtain n results that allow to understand better the way it works. The bigger the number of samples the more precision in the analysis.

Montecarlo casino named the simulation
Montecarlo casino named the simulation

Photo from azugaldia under license CC BY 2.0

How can we apply this to project management?

In our environment, the input variables would be, for instance, the variances in cost or in the duration of project activities depending on some risks that might finally materialize or not. As a result, the application provides some graphics with the probabilities to finish a project in a specific date or with a specific cost.

Nowadays technology can help us a lot, specially in projects of high cost and / or in those projects where not finishing on time may risk infrastructures or even human lifes. In these situations these kind of tools can be very helpful.

The human factor

But the reason that has motivated me to write this post is the thinking that all the information needed by the tool must be previously provided by humans; the probability and the estimation of the impact in the case that an specific risk may finally happen, the exhaustive identification of the risks that may affect to a project, the criteria to define the probabilities and impacts matrix … If there are important mistakes or gaps in this data the later calculations made by the machines will be wrong.

The experience of the project manager and its team, their training, the chance to have a multidisciplinary project team, capable to have in mind all the potential risks and the ways they would affect the whole project, the possibility to have a good base of lessons learned available for the whole organization, the knowledge of the organization that is developing the project and its risk aversion, …

What other factors do you think that may affect a proper risk management in a project? Do you use applications in your organizations that support you in this process?

El factor humano en la gestión de riesgos / Human factor in risk management