Criterios para gestionar No Conformidades

July 18, 2013 jmartinmateocontrol de calidad, ISO, NoConformidadLeave a comment

El punto 8.3 de la norma ISO 9001 nos obliga a asegurar que el producto no conforme es identificado y controlado adecuadamente para prevenir su uso no intencionado.

El tratamiento a realizar puede ser diverso, desde tomar acciones para eliminar la no conformidad hasta autorizar su utilización bajo ciertas condiciones. No voy a entrar en ello en este artículo.

Lo que me interesa tratar hoy es: ¿cómo gestionar formalmente estas No Conformidades para cumplir con la norma de la forma más eficiente posible?

Una posibilidad es abrir una No Conformidad cada vez que se produce una incidencia. Eso obliga a realizar Acciones Correctivas por cada incidencia detectada.

Una segunda opción consiste en gestionar y registrar incidencias (y no necesariamente tomar acciones) por departamentos o por procesos. Más tarde, de forma periódica, se pueden revisar todas estas incidencias, analizarlas y plantear Acciones Correctivas en bloque.

No creo que ninguna de las dos opciones sea mejor que la otra sin más. Como en muchas otras cosas depende, por ejemplo, del volumen de No Conformidades a gestionar.

Hay sectores como el farmacéutico en los que cada incidencia suele representar una No Conformidad que debe ser abierta y tratada, generalmente de forma independiente. Al tratarse de sectores altamente regulados, hay mucha conciencia de esta necesidad y se destinan recursos a la formación para que los empleados informen de manera sistemática de cada incidencia por pequeña o repetitiva que ésta sea.

En otras áreas de actividad económica, la cultura corporativa puede ser muy diferente y sólo se abren No Conformidades cuando las incidencias detectadas son de cierta entidad o si siendo poco importantes se repiten con frecuencia.

Mi criterio es que si la cantidad de No Conformidades a tratar es pequeña, en relación a los recursos disponibles para ello, es mejor abrir una No Conformidad para cada incidencia y gestionarla de forma independiente. Eso le da mayor entidad y asegura que le vamos a dedicar mayor atención.

Por el contrario si, en nuestra actividad, se genera un gran número de incidencias diario (me refiero a decenas o centenares) y muchas de ellas son repetitivas creo que es mejor hacer una revisión periódica (diaria o semanal) y plantear No Conformidades que agrupen un gran volumen de incidencias del mismo tipo. Ésto asegura igualmente el tratamiento pero mejora la eficiencia y evita perder el tiempo en tareas repetitivas que no aportan valor.

¿Qué opinas? ¿Qué criterio seguís en tu organización?

¿Cómo mejorar identificación de interesados en tu proyecto?

June 30, 2013June 30, 2013 jmartinmateocomunicación, gestión, PMP, proyecto, stakeholdersLeave a comment

¿Qué hacer si durante la fase de ejecución y seguimiento/control nos encontramos con que no hemos identificado a un interesado (stakeholder) en nuestro proyecto que, además, resulta que tiene mucho interés y/o influencia en el mismo?

La gestión de interesados es un proceso vivo durante todo el proyecto

La gestión de los interesados es, en cierto modo, como la gestión de los riesgos en nuestro proyecto; no debemos darla nunca por cerrada y hay que revisarla sistemáticamente. Periódicamente es necesario revisar el registro de interesados, el análisis de cada interesado y la estrategia utilizada con él, para introducir los cambios que sean necesarios.

Stakeholder dashboard (Robert Higgings –CC BY 2.0-)

Inclusión de nuevos interesados durante el proyecto

El inicio del proyecto es la fase en que menos información disponemos. Si, como planteaba la pregunta inicial, nos hemos olvidado o no conocíamos a alguien importante deberemos:

1. Añadirlo al registro de interesados.

2. Evaluar su poder dentro de la organización y su posible interés en relación al proyecto.

3. Analizar cómo puede haber afectado al proyecto su no inclusión hasta la fecha en el grupo de interesados.

4. Definir una estrategia para gestionar nuestra relación con él, partiendo del reconocimiento de que no hemos empezado con buen pie.

5. Efectuar las correcciones necesarias en nuestro Plan de Proyecto, de acuerdo con el sistema de gestión de cambios que hayamos definido, para tener en cuenta a este nuevo interesado. Ésto es especialmente importante si su nivel de influencia en el proyecto es alto.

Técnicas de identificación de interesados

Para evitar que un interesado, especialmente uno importante, se quede fuera de nuestra estrategia de comunicación del proyecto hay algunas herramientas que podemos usar:

– Nominación de interesados: a partir de una lista inicial podemos pedir a cada uno de los interesados ya identificados que nos proponga nuevos interesados en el proyecto. Es recomendable empezar por el sponsor del proyecto y continuar luego con los interesados más influyentes.

– Investigación de base: se trata de estudiar toda la documentación existente en relación a nuestro proyecto y localizar en la organización documentación análoga de proyectos similares. A partir de aquí se toma nota de todos los interesados que aparezcan en dicha documentación, para evaluar si también pueden estar involucrados en nuestro proyecto.

Esta técnica es especialmente interesante si somos directores de proyecto trabajando en una organización nueva para nosotros o que desconocemos.

– Rueda de interesados: La rueda interesados es una especie de lista de control en la que se han identificado todos los principales grupos de interesados. Se usa para comprobar la lista de grupos de interés frente a grupos de interés genéricos, con objeto de identificar los que falten.

Es bueno actualizar la documentación del proyecto (lecciones aprendidas) con nuevos grupos o roles que se hayan identificado, para que pueda ser aprovechada en futuros proyectos.

Resumen final

La no inclusión de un interesado importante dentro del Plan de Proyecto puede ser catastrófica. Para evitarlo, utiliza las tres técnicas mencionadas de identificación de interesados y revisa sistemáticamente tu registro de interesados del proyecto y tu estrategia frente a cada uno de ellos.

¿Qué otras técnicas conoces para identificar interesados? Compártelas mediante un comentario a esta entrada para que todos nos beneficiemos de su uso.

Problem solving process

May 20, 2013 jmartinmateo5whys, fishbone, herramientas, resolucion problemasLeave a comment

Many times we must deal with problems in our management activity that it is necessary to face in a systematic way, without improvisations, in order to be able to solve them effectively.

3D Problem Solving by StockMonkeys (under CC by 2.0)

During my professional activity I have successfully used many times the following process of 7 steps:

1. Symptom detection.

2. Problem definition

3. Root cause analysis

4. Research of various alternatives of solution

5. Analysis of alternatives

6. Decission taking

7. Action plan.

Now I am going to explain each phase a little bit:

Symptom detection.

Frequently, it is not the root cause of a problem what we notice but some of its consequences, its symptoms. It is important not to take a symptom as the cause of a problem.

Problem definition

Once we have analyzed the symptoms it is important to focus in the real problem. For instance, maybe you have found that you cannot access the intranet of your company but the real problem is that your LDAP services has failed and you cannot also start a session in your file server or navigate using the corporative proxy server. In this phase it is very important to collect as much data as possible about the problem.

Root cause analysis

What is the real reason of the problem? This is probably the most important point. If you fail to identify the root cause of the problem any solution that you may implement will not solve the problem.

There are many methodologies to help you find the root cause of a problem: 5 whys method, fishbone diagrams, pareto charts, brainstorming, …

Research of various alternatives of solution

Once we have identified the root cause of the problem we can start looking for apropriate solutions. it is important not to stop once we have found a feasible solution. That is laziness of thinking. It is necessary to struggle a little bit more and look for some more alternative solutions.

Analysis of alternatives

When we have a group of solutions, it is necessary to study each one. We must look for pros and cons of each solution and decide which one is the best one.

Decission taking

Once we have the best possible solution it is important to review it again from another point of view. We must look for all the possible inconveniences of the solution. One way to do so is to put yourself in the place of your boss or somebody who will have to aprove the final action plan and try to find all the possible weak points in our argumentation.

Action plan

After one of the alternative solutions has been approved it is necessary to implement an action plan to take it into practice. The action plan must have a set of ordered actions with people responsible to carry them on and the final dates to have each one implemented.

Of course, the plan must be communicated apropriately and have the approval and support of at least a member of the organization with enough authority and executive power to ensure it will be implemented as planned.

A final step.

And a final point. It is a must to verify the results of the action plan and review if the problem has been solved. If it has not yet been solved it will be necessary to analyze if the failure has happened because of a bad implementation or because of a bad root cause analysis, and act in consequence going back to point 7 or to point 3 of the method.

What about you? Do you use this methodology to solve problems? What could be improved? Please, share with us any alternative methodologies that you know or use.

Gestionar la incertidumbre

April 7, 2013 jmartinmateocambio, mindfulness, proyecto, riesgosLeave a comment

Cambios y más cambios

Vivimos tiempos de profundos cambios. Posiblemente por el hecho de estar en pleno ojo del huracán no seamos conscientes de lo mucho que está cambiando nuestra vida en los últimos años. Y lo que queda.

Los cambios generan incertidumbre y la incertidumbre da paso al estrés. ¿Estamos preparados para gestionarlo? La situación es complicada porque es importante tener autocontrol y gestionar correctamente nuestras emociones en casa con la familia, en la oficina con nuestros compañeros de trabajo, jefes o clientes. Y lo cierto es que las tensiones se observan a cada paso que das.

He leído bastante sobre el tema y he practicado algunas técnicas. No me considero un experto ni mucho menos pero sí que me gustaría compartir (siguiendo la filosofía básica de este blog) algunas ideas con vosotros, por si os pueden ser de utilidad.

Incertidumbre, por Manon71. Licencia Creative Commons.

No tenemos el control de nuestros proyectos

Hay técnicas aplicables a la gestión de proyectos y técnicas aplicables a nuestra forma de actuar personal, como jefes de proyecto.

En mi opinión un concepto fundamental es asumir que no tenemos el control. Con frecuencia pensamos ésto pero nuestra mente se empeña en mantenernos en una especie de falsa ilusión de que tenemos el control de nuestra vida, de nuestros proyectos. Sin embargo, momentos clave como la muerte repentina de un ser querido o las drásticas decisiones empresariales que están a la orden del día y que cambian de un plumazo la vida de muchos trabajadores o el rumbo de muchos proyectos nos vuelven a poner en nuestro sitio y nos sirven para recordar que somos muy pequeños y que sería muy osado creer que lo controlamos todo.

Es inútil preocuparse, y mucho menos enfadarse, por aquellas cosas que no podemos controlar. Debemos centrarnos en hacer bien todo aquello que depende de nosotros y olvidarnos de todo lo demás. En el ámbito de la gestión de proyectos, a mi me ayuda mucho una buena gestión de los riesgos del proyecto: no podemos evitar que algunas cosas pasen pero sí que podemos preverlas, analizar cual debe ser nuestra respuesta (si es que debe haber respuesta) y prepararnos para poder actuar cuando sea preciso.

No todo es previsible y solucionable pero saber que has previsto respuestas frente a los principales riesgos de tu proyecto te da tranquilidad. Una vez hecho ésto, relájate y disfruta. Y periódicamente, dentro de la vida de tu proyecto, vuelve a revisar riesgos. Algunos de los anteriormente identificados se podrán descartar ya y probablemente aparecerán otros nuevos que habrá que gestionar.

No tenemos el control de nuestra vida

A nivel más personal, lo que nos hace daño no es lo que nos sucede sino la forma como reaccionamos ante lo que nos sucede.

No podemos controlar todo lo que nos puede llegar a suceder pero sí que podemos controlar la forma como vamos a reaccionar ante lo que nos sucede. Sé que es más fácil decirlo que hacerlo y que se necesita una fuerte disciplina mental para actuar de esta forma pero yo lo he intentado hacer en algunas situaciones críticas y me ha servido.

Otro concepto importante. Debemos vivir el ahora, no el pasado (que ya no está) ni el futuro (que puede no ser como esperamos). No debemos pasarnos la vida, perdiendo el tiempo con nuestra mente siempre viviendo en un momento que no es el presente, el único que es real. Hay que tratar de olvidarse del futuro y de las consecuencias de nuestros actos del presente. La mente debe estar centrada en el ahora y lo que deba venir ya vendrá. Sobretodo, y vlviendo sobre un concepto anterior, si no depende de mi lo que suceda en el futuro no vale la pena preocuparse por ello. En inglés, esta actitud se describe como “mindfulness“, que en español podríamos traducir como “conciencia plena”. No quiero extenderme en ello porque hay muchos recursos sobre el tema en internet y es algo que va más allá del propósito de este blog.

Conclusiones

No te obsesiones por tener el control. No es posible.

Ten una actitud flexible, previendo posibles eventualidades y preparándote para ellas. Una vez hecho ésto, olvídate de los riesgos que corres hasta que un desencadenante haga que se materialicen y, con ellos, tu respuesta. Mientras ésto no se produzca, estate tranquilo y céntrate en el ahora, no en el futuro ni en el pasado. Haz bien tu trabajo.

Periódicamente revisa de nuevo los riesgos de tu proyecto, para adaptarte a los cambios.

¿Qué opinas de estos planteamientos? ¿crees que te pueden servir? ¿qué técnicas utilizas para gestionar la incertidumbre en tu vida personal o en tus proyectos?

Green Project Management

March 2, 2013 jmartinmateoISO, proyecto, sostenibilidadLeave a comment

Hace unas semanas tuve la oportunidad de asistir a una sesión sobre Green Project Management, organizada por el Capítulo de Barcelona del PMI, del que soy miembro y voluntario. A pesar de tener un cierto bagaje en gestión de proyectos y conocimientos y experiencia en la norma ISO 14001 debo confesar que esta certificación es para mi una total novedad.

La sesión resultó muy interesante. Conocimos los fundamentos de la metodología PRISM y también sus objetivos, de entre los cuales destacaría el compromiso de hacer que las actividades asociadas a los proyectos que llevamos a cabo dentro de nuestras organizaciones sean sostenibles y se limite y controle el impacto que tienen en el entorno en el que se realizan. Todo muy en línea con conceptos como responsabilidad social corporativa y sostenibilidad.

Algunos de los momentos más interesantes de la sesión se dieron al final, en la tanda de preguntas.

Imagen via Samuel Mann bajo licencia Creative Commons

Muchos de los compañeros del capítulo expresaron algunas dudas sobre la viabilidad de esta certificación en el contexto económico en el que nos encontramos. Seamos realistas, el criterio número uno (y con diferencia) que siguen las empresas a día de hoy en la gestión de sus proyectos es la rentabilidad y el control de los costes. La ponente, Lorena Perdomo, de avanzaproyectos, se esforzó en convencernos de que el reto está en conseguir ser sostenibles sin incrementar por ello los costes de los proyectos; ahí es nada.

Sin embargo, mi opinión es que si en el futuro un país quiere mantener ciertos niveles de bienestar debe aspirar a gestionar sus empresas y proyectos teniendo muy presentes los criterios económicos pero midiendo también muy bien su impacto en el entorno; la afectación medioambiental y social.

Desconozco, y no me atrevo a aventurar, qué recorrido tendrá esta certificación entre los profesionales de la gestión de proyectos pero, de entrada, es de agradecer que ponga sobre la mesa nuestra responsabilidad sobre la afectación que nuestros proyectos tienen en el entorno tanto durante como después de su ejecución.

¿Qué opinión tenéis sobre el tema? ¿qué pensáis de esta nueva certificación? ¿os planteáis habitualmente cómo afectan vuestros proyectos al entorno en el que se desarrollan o os limitáis a ejecutarlos? ¿qué grado de influencia pueden tener los project managers sobre las empresas en que trabajan para que se tengan más en cuenta los criterios de sostenibilidad en la gestión de proyectos?

Using a Blog to support your Project Management Information System

December 30, 2012December 30, 2012 jmartinmateocloud computing, colaboración, comunicación, social mediaLeave a comment

Last summer I started reading “Social Media for Project Managers”, from Elizabeth Harrin. There were many concepts I already knew and some tools I was already using but the book gave me some ideas to use those tools for new purposes. One of them was using a Blog as a part of the PMIS (Project Management Information System) as a project log.

Blog image from http://www.sxc.hu/profile/svilen001

How we use a blog in our project

We started using a blog in a software development project I am managing. The team is young and they are used to these kind of tools so it was not difficult to convince them to start blogging everyday their project activities.

As we all are not working at the same office and also some team members have different working hours, we thought that this tool would help us with its universal accessibility (well, in fact we have limited the access to the blog to the project stakeholders).

These have been the results

After some months of work we have:

A project log, explaining what we have done and why we have done it that way. A knowledge repository.
A tool useful to train new team members is they are needed in the future.
A tool to collaborate. We can receive feedback from the community of project stakeholders through their comments at the blog posts.
A tool to build relationships between the team members, as not all of them are collocated.

Some difficulties and risks

But not everything has been easy. We have had establish some ground rules about what to post and how. As every stakeholder may read a post it is not easy to decide the kind of information to include as not all of them have the same needs.

There are some posts that are for internal use (just for the team members), some others are for everybody involved in the project and we are working now in the weekly project status reports, for the project sponsor and the final product users.

As everybody can read every post, the tool we use to filter are tags. If you want to read a project status report you must look for “status” tags in the blog. When a team member looks for some information about the data base he must use some of the tags we have previously agreed to use for these issues, and so on.

What’s your opinion?

What about you, are you using any social media tool to support your projects? What has been the most difficult challenge you have faced to deploy it? What have been the benefits for the project? Any negative result?

Validación y pruebas de servicio. Tests unitarios.

December 22, 2012December 22, 2012 jmartinmateoaplicaciones, aseguramiento calidad, desarrollo, ITIL, testLeave a comment

Nuestro equipo de desarrollo de aplicaciones es joven, con ganas de probar y aprender pero también con limitada experiencia en algunos temas. Uno de los que me preocupa últimamente es el control de los cambios de las aplicaciones que tenemos en producción pero que seguimos desarrollando y evolucionando.

No es lo mismo ir cambiando versiones de una aplicación mientras está en desarrollo que hacerlo una vez ha pasado a producción, con las repercusiones que puede tener un corte de servicio o un fallo en una funcionalidad.

Una de las aplicaciones que hemos desarrollado controla una línea de producción de equipos en nuestra planta. Desde que la pusimos en marcha el departamento de Producción ha podido ir incrementando considerablemente su ritmo de fabricación semanal, de forma que cualquier corte en el servicio, por pequeño que sea, ahora tiene gran repercusión.

En otra entrada ya explicaré cómo tenemos implementada la gestión de cambios en la aplicación pero ahora lo que me interesa es lo que en ITIL se denomina Validación y Pruebas del Servicio, dentro del proceso de Transición del Servicio.

Tras haber aprobado un cambio es preciso, por este orden y a grandes trazos, definir los requisitos que debe cumplir la solución, diseñar la solución y las pruebas que deberá pasar antes de entrar en producción y, lógicamente, desarrollarla.

Modelo de desarrollo y test "en V" — Modelo de desarrollo y test “en V”

Siguiendo el Modelo V, empezaríamos las validaciones con pruebas unitarias, seguidas de pruebas de sistema y acabando por las pruebas de integración. También será preciso hacer tests de regresión, para verificar no sólo que la entrega cubre los objetivos del cambio planificado sino que todo lo que nuestra aplicación hacía bien antes de la entrega lo siga haciendo después.

Cuando las aplicaciones se hacen grandes verificar la cobertura de las pruebas respecto a los requerimientos y/o las líneas de código no es trivial.

Según se desprende del modelo en V, una buena base desde la que construir la aplicación deben ser los test unitarios. En el BCNDevCon12 tuve oportunidad de asistir a un par de master sessions en las que se explicaba de forma práctica la metodología TDD (Test Design Driven). Este método de desarrollo nos asegura que nuestro código va a cumplir con los requerimientos.

En pocas palabras se trata de diseñar los tests que deberá pasar nuestro código antes incluso de desarrollarlo, en base a cada uno de los requerimientos que nuestro cliente nos haya planteado. Una vez diseñado el test hacemos el mínimo código para cumplir con el requerimiento y lo probamos contra nuestro test.

Si el resultado es positivo pasamos al siguiente requerimiento y su test asociado. Si es negativo rehacemos el código y volvemos a testear hasta que lo pase.

Según vamos incorporando requerimientos deberemos ir refactorizando nuestro código y volviéndolo a probar contra la batería de tests. Todo el proceso está muy bien explicado aquí.

En otro post hablaremos de los tests de sistema y los de integración. Me interesa mucho encontrar herramientas para automatizarlos en el marco de desarrollo de aplicaciones web. Pero, como decía, eso será en otra entrada. ¿Qué métodos y/o herramientas utilizáis en vuestras pruebas unitarias? ¿usáis TDD? ¿con qué resultados?

El proceso de test en el desarrollo de software

October 12, 2012 jmartinmateoaplicaciones, aseguramiento calidad, ISTQB, lecciones aprendidas, planificación, testLeave a comment

La calidad del software que generamos para nuestras organizaciones es muy dependiente del esfuerzo y tiempo dedicados a su testeo.

No obstante, ese esfuerzo debe ser objeto de un análisis crítico que asegure que los resultados obtenidos compensan el coste dedicado. Por otra parte se debe ser consciente de los riesgos asumidos al limitar el esfuerzo de test. Como en muchas otras situaciones de la vida, se trata de buscar el equilibrio.

De acuerdo con el ISTQB el proceso de test debe seguir las siguientes fases:

Planificación y control
Análisis y diseño
Implementación y ejecución
Evaluación y reporte
Cierre

Estas fases se suceden secuencialmente, si bien el control debe seguirse durante todas las fases del proceso, no sólo en la planificación inicial.

1. Planificación y control

Debe iniciarse, idealmente, lo antes posible dentro del ciclo de desarrollo del software. Es preciso completar un plan de test que incluya:

recursos necesarios,
tiempo estimado,
servicios, medios adicionales,
herramientas, …

El testeo exhaustivo es, por lo general, imposible. Es preciso, por tanto, definir prioridades y analizar los riesgos de omitir determinados tests o de limitar su intensidad o alcance.

2. Análisis y diseño

En esta fase se determinan las técnicas de test a seguir, alineadas con la estrategia definida en el paso anterior, se definen los casos de test y el calendario o secuencia. En paralelo se deberá poner en marcha la infraestructura necesaria para realizar los tests.

3. Implementación y ejecución

A partir de los casos de test definidos de forma lógica en la fase anterior se derivarán y ejecutarán casos de test concretos.

En esta fase es preciso seguir un protocolo de test que incluya las partes a testear, las personas asignadas, los tiempos y calendarios, la extensión de cada test a realizar y los resultados esperados.

Además, es fundamental realizar un registro de los resultados. Éstos nos pueden llevar a plantearnos si los posibles errores encontrados están dentro o fuera del objeto del test y, consecuentemente, a replantearnos el protocolo diseñado y seguido.

Al mismo tiempo, los errores encontrados deben ser documentados, priorizados y asignados a los desarrolladores para solucionarlos.

En otra entrada entraré en mayor detalle pero aquí quiero comentar la importancia de agrupar los casos de test en secuencias y/o escenarios y de realizar primero los llamados “smoke tests” que permitan verificar la bondad de las funciones principales antes de entrar en casos más detallados y completos (que no tienen sentido si los tests básicos no han sido superados).

4. Evaluación y reporte

En esta fase empezaremos por evaluar si los criterios de finalización de los tests han sido alcanzados.

En caso negativo será preciso analizar si se ha debido a que algunos casos de tests han tenido que ser bloqueados o si es preciso añadir más casos de test.

Para tomar una decisión razonada, como siempre, habrá que tener en cuenta tanto los riesgos asociados con no añadir más casos de test como los costes (dinero y tiempo) de hacerlo.

En cualquier caso, finalizaremos esta fase con un informe que incluya todos los resultados y las conclusiones y decisiones tomadas.

5. Cierre

Esta fase, desgraciadamente, suele ser olvidada en, muchos proyectos.

La experiencia obtenida durante el proceso de test debe ser analizada y puesta a disposición de otros proyectos. En otro post de este mismo blog ya he hablado sobre ello dentro del contexto de la gestión de proyectos en general.

La documentación y aplicación de los resultados de una evaluación crítica de las actividades realizadas durante el proceso de test, considerando esfuerzo en relación a resultados, nos llevará a la mejora continua.

Para acabar, otro punto a tener en cuenta en esta fase final es la necesaria conservación del “testware” (casos de test, protocolos, infraestructura, herramientas) para su uso posterior cuando nuestro cliente nos pida cambios o cuando encontremos nuevos errores ocultos en nuestra aplicación.

The importance of the lessons learnt

July 7, 2012 jmartinmateolecciones aprendidas, project mangement2 Comments

During this month (july 2012) I am going to finish a software development project that I have been leading as a project manager since its beginning in february. It has been hard, physically and mentally, and with very challenging deadlines.

Also in these weeks I am reading an interesting book from Peter Taylor, “The lazy project manager”. I have taken notes of two important ideas from the book that I can apply in this final phase of my project:

The shape of the projects.

Projects are thick in the beginning, thinner in the middle and thick again in the end.

It means that we must dedicate a lot of time and effort to bring the project inside the road at its initial phase (planning) in order to be able to “rest” a little bit during its execution and monitoring phases. Finally we have to notice the importance of the closing phase and dedicate the necessary time and effort to finish our projects properly.

This final effort must be shared with the rest of the team, the sponsor, the client and also the other stakeholders. A part from obtaining acceptance of all the deliverables and closing contracts a very important activity in this phase is to register the lessons learnt during the project.

This is something that many times is forgotten or understimated.

What we know we know, what we know we don’t know and what we don’t know we don’t know.

At the end of the book Peter Taylor quotes Mr. Donald Rumsfeld (12 February, 2002, US Dept. of Defense news briefing): ‘As we know, there are known knows. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know‘.

I have enjoyed specially this part of the book.

When we work on the registry of the lessons learnt during the chapter we must consider:

What we didn’t know at the beginning of the project and we have learnt during its development. That is to know what we know.
To know what we don’t know. The gaps in our experience of the project that we can fill up by asking our team.
The unknown unknowns. This must be unveiled through a project retrospective where all the stakeholders should participate. It is a healthy habbit to plan for this in the final phase of the project.

Would he repeat it ? — Horse stumbles after the jump, would he repeat it ?

And why do we have to dedicate so many time and effort to all these lessons learnt if our project is almost closed and the deliverables have already been accepted?

In order to avoid that the sentece that says that ‘the man is the only animal capable to trip twice over the same stone‘ continues being true in the future. At least I think we should try it. Don’t you?

Leading with our example

May 1, 2012 jmartinmateocoaching, example, leadershipLeave a comment

Some days ago I read an interesting post from Voices on Project Management. It made me think about the way our behavior can influence our team in a project, especially its young members, that can be prompted to imitate our conduct.

The way we deal with the project stakeholders or even the way we manage our relationship with managers and people from other functional areas, even if they are unrelated with the project, are telling our team mates how we expect them to deal with these people too.

For instance, if we do not control ourselves and criticize without compassion the manager from a functional area because we are having problems to obtain the resources she had committed to provide to our project we are also telling (consciously or not) our team that this behavior against some project stakeholders is accepted (or acceptable).

On a positive situation, a smart negotiation (win-win) with a project vendor can show our team that we expect them to keep a good relationship with the sellers involved in the project, we want our vendors to grow with us and we want the relationship with them to last further than the project.

Many different situations come to my mind when I think about the way that our actions or communications show our team mates what we consider an appropriate behavior:

the way we answer emails,
the way we manage meetings, especially difficult meetings,
the way we manage arguments between members of the team,
the way we react when a job mate comes to see us with a problem,
the way we follow the ground rules established for the project,
the way we act when somebody comes late to a meeting,
the way we accomplish our commitments,
the way we react when others make mistakes,
the actions we take when the team misses a milestone,
our conduct when we, or someone else from the team, receive a present from a vendor,
…

There are many situations during the life of a project that allow us to point out, implicitly or explicitly, the way to be followed by the team.

What other situations do you think that can help us indirectly coach a project team?

Technology at the service of humans

Improving quality of life through humanistic technology and coaching

Author: jmartinmateo