Resultados de búsqueda de enero 2nd 2016

The Project Management Principles That (Almost) Nobody Teaches

I have been doing project management for seventeen years already. I have carried out software development projects for a bank, for civil engineers and for document management.

I have applied practices ofProjectMgmt_En

  • Rational Unified Process (RUP)
  • Earned Value Method
  • PMBoK
  • CMMI
  • Agile Project Management (based on Scrum )

Although I was always trying to apply correctly the methods, identify and address risks properly, communicate with the team on a daily basis (this has never been a problem in our projects), communicate with the customer often, I have suffered the problems of (más…)

Los principios de gestión de proyecto que (casi) nadie enseña

Me dedico a la gestión de proyectos desde hace ya diecisiete años. He llevado a cabo proyectos de desarrollo de software para banca, para ingenieros civiles y para gestión documental.

He aplicado las prácticas deProjectMgmt_Sp

  • Rational Unified Process (RUP)
  • Método de Valor Ganado
  • PMBoK
  • CMMI™
  • Gestión de proyecto ágil (basada en Scrum)

Aunque siempre estaba tratando de aplicar correctamente los métodos, identificar y abordar los riesgos adecuadamente, hablar con el equipo a diario (la comunicación nunca ha sido un problema en nuestros proyectos), comunicar con el cliente a menudo, he sufrido los problemas de:

  • Estimaciones inexactas
  • Tener que trabajar largas horas y los fines de semana para cumplir fechas
  • “Todo es urgente” y se tiene que implementar en la iteración en curso
  • Tener que parar todo el proyecto para corregir un error en el diseño de la arquitectura
  • Subir a producción sin haber hecho todas las pruebas por falta de tiempo.
  • No saber cómo exactamente actuar para eliminar una desviación de plazo o de presupuesto y volver el proyecto a lo estimado

Hasta que aprendí Kanban y asistí al curso Kanban Coaching Professional Masterclass de David Anderson, ninguno de los métodos me había enseñado que para que fuese bien el trabajo en los proyectos tenía que enfocarme también en lo siguiente:

  • Asegurar un flujo de trabajo suave
  • Aplicar la Ley de Little para equilibrar la demanda de trabajo y la capacidad del equipo
  • Resolver los cuellos de botella para mejorar el flujo de trabajo
  • Conocer la variación de los procesos y los efectos de esta.
  • Hoy me pregunto ¿por qué nadie me enseñó esto antes?

Si tuviera estos conocimientos antes, mis proyectos hubieran ido mucho más suave…

En fin, la máquina del tiempo todavía existe sólo en las películas.

De todos modos, si eres Jefe de proyecto, Team leader o Scrum Master, cuando tengas un rato, échales un vistazo a estos temas. Te ahorrarán algún que otro fuego.

Posts relacionados

Lean Kanban Analytics: Pragmatic Project Management

I started working as software development project manager in 1996. We were a team of 5 people, young and motivated, developing a facility management system for a bank.
Just to give you an idea of that time, we had internet access on one computer only, so we were checking the team’s email (not the individual ones) twice o three times a day. The mobile phones were like the one you see on the picture bellow, i.e. no sms, no WhatsApp, nothing of this type.

Computer_Handy_1996

That was the only project we were working on, i.e. there was no resource sharing among projects and no influence from other development undertakings.

Do you remember that time too? :-) (más…)

Analíticas Lean Kanban: Gestión de proyectos pragmática

Los buenos viejos tiempos

Empecé a trabajar como jefe de proyectos de desarrollo de software en 1996. Éramos un equipo de 5 personas, jóvenes y motivados, y desarrollábamos un sistema de gestión de instalaciones (inglés: facility management) para un banco.

Sólo para darte una idea de aquel tiempo, teníamos acceso a Internet en un solo ordenador, por lo que comprobábamos el correo electrónico de todo el equipo (no el personal) dos o tres veces al día. Los teléfonos móviles eran como ves en la foto, es decir, no SMS, no WhatsApp, ni nada de este estilo.

Computer_Handy_1996

Este fue el único proyecto sobre que trabajábamos, no compartíamos recursos con otros proyectos y los otros desarrollos tampoco nos impactaban tanto.

¿Tu también te acuerdas de ese tiempo?  :-)

Como jefe de proyecto era responsable de planificar, dar seguimiento y reportar el progreso del proyecto.

El cliente esperaba un producto de alta calidad, sin embargo, fue lo suficientemente paciente para trabajar con nosotros en los requisitos y dejarnos el tiempo necesario para implementarlos y hacer las pruebas.

Está chupado, ¿verdad?

Aun así, antes de cada entrega teníamos que trabajar largas hora para asegurarnos que todo funcionaba bien. Es decir, las estimaciones no se ajustaban a los números reales.

Las estimaciones y los datos reales son diferentes valores del mismo parámetro.
No fuerces (manipules) los reales para que coincidan con las estimaciones.

La supervivencia y la sostenibilidad requieren pragmatismo

Menos de 20 años después, pocos jefes de proyectos, más bien ninguno, se puede imaginar llevar un único proyecto, con un equipo totalmente dedicado a este, sin interacciones con otros desarrollos, casi sin interrupciones, con algunos cambios de requisitos manejables, y problemas relacionados sobre todo con la tecnología.

Lo interesante es que la complejidad de los métodos de gestión de proyectos ha aumentado en paralelo con el aumento de la complejidad del desarrollo de software, mientras que el tiempo para hacer las decisiones correctas es cada vez más corto y las expectativas de los clientes cada vez superiores.

Revisé mis apuntes de los últimos años. Los jefes de proyecto comparten los siguiente acerca de su trabajo:

  • Es difícil manejar la variedad de factores que influyen en un proyecto: la claridad de los requisitos, la estabilidad de las tecnologías, el nivel de conocimientos y habilidades de los miembros del equipo, los riesgos, las dependencias de otros proyectos, etc
  • Cuanto más sofisticado sea el método de estimación, más esfuerzo (y tiempo) se necesita para hacer un buen plan de proyecto. De todos modos este tiene una vida muy corta hasta que cambie de nuevo
  • Estimación, planificación, seguimiento y re-planificación es una carga administrativa muy alta, difícil de vender a los clientes, y por lo tanto sostener
  • Hay mucha presión para dar estimaciones rápidamente y después cumplirlas
  • Difícil coordinación de los proyectos.

En una situación como esta, ¿no deberíamos de revisar las prácticas de gestión de proyectos bien establecidas y buscar algunas más pragmáticas?

Aplicar métodos complejos a situaciones
complejas las complica aún más.

 

Enfoque Lean Kanban de gestión de proyectos

¿Cuál es el propósito de gestión de proyectos? – Asegurarse que el proyecto se ajusta a los criterios de sus interesados (clientes y organización). ¿Correcto?

Aquí los tienes:

Aptitud del trabajo: Perspectivas

Cliente

  • Entregar rápidamente (tiempo)
  • Entregar a tiempo (previsibilidad)
  • Precio competitivo
  • Calidad (obtener el producto/servicio correcto)

 

 

 

 

Organización

a. Nivel de proyecto

  • Estimaciones (tiempo, coste)
  • Previsibilidad
  • Calidad
  • Coordinación de los proyectos

b. Nivel de negocio *

  • Sostenibilidad
  • Orientación a servicio
  • Supervivencia

* Ver la charla y el artículo la de David J Anderson sobre las 3 agendas de Kanban.

Entonces, las dimensiones de la aptitud de un proyecto y las herramientas analíticas correspondientes se pueden resumir de la siguiente manera:

Aptitud del trabajo: Dimensiones

Tiempo de entrega

Coste

  • Coste de las actividades de valor añadido, transaccionales y de coordinación>
  • Coste de los desperdicios (corrección de defectos, re-trabajo, espera)
  • Requisitos/historias descartados
  • Eficiencia

 

Previsibilidad

Calidad

Negocio

Pincha en los enlaces para ver cómo se utiliza cada una de las herramientas y la valiosa información que aporta a tu proyecto.

Si te fijas en las herramientas que necesitas para gestionar la aptitud del trabajo de tu proyecto con respecto a cualquier criterio, cliente o organización, te darás cuenta que lo que necesitas fundamentalmente es suficiente y, por supuesto, buenos datos reales. (En cuanto a los datos, siempre tenemos que recordar que si entra basura – sale basura).

El poder de los datos reales, no las estimaciones especulativas, te da confianza
en tus compromisos y te permite dormir tranquilo, porque
reduce los riesgos de no cumplir tus promesas.

 

Además, ahorras todo el esfuerzo para inventar y actualizar un método de estimación formal y tratar de adaptarlo a las características únicas de cada proyecto.

Para las empresas CMMI:

  • El tiempo de entrega se recoge principalmente en proyectos orientados a los servicios (por las necesidades de la gestión los ANS). Sin embargo este es un dato valioso para los proyectos de desarrollo de software también.
  • En los proyectos de desarrollo de software por lo general se registra el esfuerzo de realización de la tarea, pero no el tiempo de entrega (el Lead time) de un requisito o historia. Esfuerzo y duración no es lo mismo. Conocer la distribución del Lead time para los tipos de trabajo o las clases de servicios ayuda a conseguir una planificación más realista.
  • Conociendo el Rendimiento permite (a través de la ley de Little) dar una estimación rápida y fiable del tiempo de entrega necesario para implementar un conjunto de historias / requisitos.
  • La visualización del trabajo en curso facilitan enormemente la coordinación de los proyectos.
  • El DFA es quizás el mejor indicador en tiempo real del ritmo del trabajo (proyecto) y los riesgos.

Te gustaría leer también:

Listen to defects to effectively hedge risks

“If you do not actively attack risks, they will actively attack you”
– Tom Gilb

What I usually see in the risk tables of project or service plans are “deliver late”, “surpass the budget”, or “does not pass customer acceptance due to unclear requirements”.

At the same time, teams most often complain from not being able to meet deadlines, and surpassing budget.

Obviously we are rather attacked than attacking risks.

Why analyse defect data?

What can we do to protect better the projects and the services from the risks?
Logically, understanding better the causes and the circumstances for the problems should help.

Have you checked what part of the total delivery time (lead time) is effective development, rework due to defects, or waiting for some input? In other words do you know the efficiency of your process?

When estimating the delivery time, did you include the time for rework and waiting?

My experience shows that few companies systematically analyse their defects and blockers with the aim to understand their root causes and act on them. Blockers are sort of defects in some of the processes involved in carrying out the work, e.g. managing suppliers, scheduling, handling customer information, etc.

Several times I have seen surprise on the faces when people realize that resolving blockers and fixing defects takes them more than 30% of the total estimated effort, prolongs project duration with more than 20%, and affects significantly customer satisfaction.

If you want that your work be fit for purpose, you should listen to your defect data (including blockers) and act adequately.

How to analyse defect data?

Analyse defect data is not so difficult – there are several techniques that help with this. The main reason for not taking advantage from this valuable source of information is that the majority of the companies still do not collect data about defects and/or do not know what this data say.
Fishbone

A simple practice that you can use to learn from your defect data is to follow these steps:

  1. Classify the defects based on criteria that emerge from telling the story of each defect. For instance, we started working without getting commitment from the customer about the functionality, dependencies with another system were not taken into account, the person involved was new and with insufficient domain knowledge, etc.
  2. Analyse the causes and look for patterns. Although each story has its individual aspects, problems share great part of the roots.
    Focus on the lead time and efficiency of resolving the defect or blocker
  3. Decide how to address the causes as to prevent them from occurring.

What do defects have to do with risks?

Most of the problems are recurring at least until we manage to preclude them completely.

This means that we have to be prepared to see our experience again in the future. The point here is how we can identify the risk well in advance and effectively avoid it.

Mirroring the past through the “now” point is a simple and helpful technique.
Cause-Problem EnThe problem from the past becomes a risk in the future. The causes from the past convert to risk symptoms that we have to carefully watch for.

Which is the right place to discuss risks?

Lots of teams try to mitigate their risks individually and independently on the others. This is not very effective especially when there are dependencies between the services.

I assume you conduct some periodic meetings at which you review your projects and services. If you use the Kanban routines (cadences), the ideal place is the Risk Review meeting.

KanbanCadences

Image copied with permission from David J Anderson’s post Kanban cadences.

Make sure that you have a good understanding of the entire context to be able to make pragmatic decisions about how to hedge risks.

Summary

  • At team level not understanding the causes for the defects and blockers makes you vulnerable to project and service risks
  • At organization level not addressing properly the risks reduces your fitness for your business purpose.
  • Applying a pragmatic approach to defect analysis, understood and shared by all stakeholders, facilitates risk hedging.

Related posts:

Escucha los defectos para limitar los riesgos eficazmente

«Si no atacas los riesgos activamente, ellos te atacarán activamente»
– Tom Gilb

Lo que suelo ver en las tablas de riesgos de los planes de proyecto o servicio es «retraso de la entrega», «sobrepasar el presupuesto», o «problemas en la aceptación del cliente debido a requisitos poco claros».

Al mismo tiempo, los equipos más a menudo se quejan de no poder cumplir los plazos, y superar los presupuestos.

Obviamente estamos más atacados que atacando los riesgos. (más…)

It is about making work flow, stupid

In 1992 Bill Clinton chose an interesting slogan for his political campaign:

Bill Clinton Economy

Of course, there were many other important topics for the country and a lot of factors that were influencing their resolution. However, Bill Clinton’s key message was focused on the core driver for the country, the economy.

I frequently meet companies that struggle with the need to reduce delivery time for their projects and services, provide more competitive prices, and adapt better to changing customer needs.

It is difficult to introduce drastic changes in organizations where hierarchical structures and responsibilities have been settled for long years and any disruption scares people and makes them resist. For such organizations, the need of change is definitely recognized. How to approach it, however, is not yet completely clearly. (más…)

Se trata de hacer el trabajo fluir, estúpido

En 1992 Bill Clinton eligió un lema interesante para su campaña política: 

Bill Clinton Economy

Por supuesto, había muchos otros temas importantes para el país y una gran cantidad de factores que estaban influyendo su resolución. Sin embargo el mensaje clave de Bill Clinton se centró en el punto central para el país, la economía.

Yo me encuentro frecuentemente con empresas que se enfrentan con la necesidad de reducir el tiempo de entrega de sus proyectos y servicios, ofrecer precios más competitivos, y adaptarse mejor a las necesidades cambiantes de sus clientes.

Es difícil introducir cambios drásticos en las organizaciones donde las estructuras y responsabilidades jerárquicas llevan establecidas largos años y cualquier interrupción asusta a la gente y la hace resistir. Para estas organizaciones, la necesidad de cambio es, sin duda, reconocida. Cómo enfocar y llevarlo a cabo, sin embargo, no está bien claro. (más…)

Communication and visibility – the vitamins for ICT companies

This month I had an interesting service for the IT department of a bank. I say ‘interesting‘ because they asked me to visit them, see how they were carrying out and managing their projects and tell them how I found it. Nothing about particular problems they want to resolve, objectives they are pursuing, or a method that is interesting form them. Just comesee – and give us your opinion.

I went with a good dose of curiosity and with some anxiety because I did not know what to expect.

The context

To understand the context I asked both the software development team and the business users (the customer) to describe their workflow as well as any difficulties they had in their daily work (a problem per post-it).

A summary of the current situation can be drawn as follows:

Workflow And Pains

The pains that need urgent treatment according to the prioritization of both teams are:

  1. Poor user requirements (defined at the level of idea)
  2. Insufficient business analysis
  3. Task estimation problems – users do not understand why developers need so much time to the work, there is pressure to reduce the estimates, and then the problems of not meeting the dates appear
  4. Frequent priorities changes
  5. High workload and inability by the development team to respond quickly to user requests.
  6. Lack of risk management

The analysis of the problems can be summarized like this, reading the tree bottom – up.

Pains Analysis

«Quick wins» are needed.

What vitamins should I prescribe them that will bring them
noticeable improvements in a short time?

Defining an estimation method would help, also establishing criteria and policies for managing requirement changes and risks, but all this will take time and effort. In addition, they have to be accepted well by the people, both the users and the developers.

Listening to the pains and fears of both sides the following image appeared in my mind:

Communication Problems

What lays at the bottom of the problems is the matching between the user requirements, in the business people language, and the development team work, with all its creative and technical aspects.

Communication and shared visibility in the work are
vitamins the ICT companies.

 

No technology or formal method will give positive results in short time, if the communication between people fails and there is a lack of visibility in the work that is carried out.

I confirmed this idea with the team and all together we came to the following two elements of the «quick win» solution:

  • Work in multidisciplinary teams

Multidisciplinary Team

  • Use a shared kanban board to visualize the work in progress and facilitate its understanding and management.

Draft Kanban Board

Now back to the pains that need urgent resolution. All of them will be positively affected by this simple solution, won’t they?

At least the team and I are convinced so.

What is your opinion?

If you think this experience can help a friend of yours, forward her the message. She will pay you back the favor at another important to you moment.

Related posts: