Las métricas de calidad en el proyecto

Dentro del proceso “8.1.3. Planificar la Calidad” en el PMBOK, una de las salidas son las Métricas de Calidad en el proyecto. Para explicar el concepto de métrica, el PMBOK hace una diferenciación entre métrica y medición. Una métrica de calidad es una definición operativa que describe un atributo del producto o del proyecto. Una medición es un valor real.

Una métrica indica la manera en que el proceso de control de calidad medirá el trabajo o el producto.

A su vez, la tolerancia define la variación permisible de las métricas.

Para ejemplificar los tres conceptos: una métrica de calidad en el proyecto puede ser el tiempo de respuesta de un sistema informático para elaborar un reporte de datos específico. Imaginemos que el sistema es un sistema de banca por internet (“Home banking”) de un banco líder en el mercado. El reporte es la lista de movimientos del día en una cuenta bancaria. Una métrica de calidad en el proyecto podría ser “Elaborar el Reporte X en un tiempo de 3 segundos de espera para el usuario con una tolerancia de un segundo, asumiendo que su conexión a internet funciona correctamente y tiene una velocidad estándar en el mercado”. Una medición de esta característica sería la medición real de este tiempo una vez que el sistema se encuentra en producción: 3,1 segundos, 2,8 segundos, 2,3 segundos, etc.

Voices on Project Management

The more than 40 comments on my last post Hey Boss, What About Work-Life Balance? provide an interesting mix of views. Here are my thoughts on how to work effectively and build a relationship with someone like "Sebastian." This input comes from a position of advantage since I knew the real person.

The first key to building any effective relationship is to avoid stereotyping. Sebastian was a very effective, upwardly mobile manager with a focus on being promoted to the main board. Interestingly, most people liked him as well as respected him. It's just that he had a different life focus, which is not uncommon in successful senior executives.

The second key is to recognize that in every relationship there is a power dimension. How a manager like Sebastian would use his power is to an extent a generational issue. Many younger managers would see nothing wrong in you setting reasonable boundaries and procedures, as long as they understand their purpose. Managers with more experience are used to operating in a command and control environment are likely to react negatively to a "junior" pushing rules upwards.

The third key is mutuality. Team members need to understand what he or she needs from the relationship (support, resources, backing) but also what Sebastian needs from the relationship. Then, work to negotiate mutually beneficial outcomes that meet both sets of requirements.

For the team member discussed in the post, the requirement was time-related; Sebastian's requirements were not defined in the original post. However, by defining what's important to Sebastian, then linking your requirements to the achievement of his requirements, you can start to achieve real communication inside an effective relationship.

Finally if you wish to be taken seriously, you need to develop a reputation for credibility. Senior management needs to recognize that if you say something, it is backed up by facts, and if you commit to something, it is delivered. Credibility is earned by performance, but there is no harm in quietly making sure your performance is noticed in the right places.

In the end, relationships all depend on the situation. But mutuality and credibility are the two keys to advising upwards. If you are seen as a serious contributor to the organization's success and can link your needs to the needs of senior management, there's a high probability of achieving your desired outcome and benefiting the organization at the same time.

La Corrupción del Alcance (Scope Creep) en el proyecto

Existe un concepto en inglés que se llama Scope Creep, que está asociado a problemas con el alcance del proyecto en la fase de ejecución: es cuando el equipo del proyecto agrega funcionalidades al producto sin saber que no estaban pactadas en la definición original, o cuando acepta nuevas funcionalidades pedidas por el cliente porque no sabe decir que no, o porque no se da cuenta de que eso causará problemas en el futuro. “Creep ” tiene muchas acepciones, pero la más acertada para nuestro caso es “escalofrío” o “estremecimiento”. “Tener escalofríos de alcance” en la ejecución, esa es la interpretación correcta.

En el PMBOK Cuarta Edición este término ha sido traducido (en mi opinión, correctamente) como Corrupción del Alcance.

En el Glosario del PMBOK dice: Corrupción del Alcance (“Scope Creep”) es la adición de funciones y funcionalidad sin considerar los efectos sobre el tiempo, los costos y los recursos, o sin la aprobación del cliente. También conocido como: Adiciones al Alcance; Alteración del Alcance; o Cambio Mayor del Alcance; o Deslizamiento de Alcance.

El proceso “5.5. Controlar el Alcance” en la ejecución habla de este problema. La premisa más importante a tener en cuenta en este proceso es: “Habrá cambios al alcance”. Esto es un dato, un supuesto del proyecto. La responsabilidad del gerente de proyecto es definir e implementar un proceso para analizar y rechazar o aceptar esos cambios. El control del alcance del proyecto también se utiliza para gestionar los cambios reales cuando suceden y se integra a los otros procesos de control.  Los cambios no controlados se denominan corrupción del alcance del proyecto (Scope Creep = cambios no controlados). Es decir: los cambios no controlados deberían hacerte estremecer.