Los términos del examen, en español.
125 términos de ágil, predictivo e híbrido, análisis de negocio y herramientas para resolver problemas, con el nombre en inglés que verás en otros materiales y, cuando hace falta, cómo suele aparecer en el examen.
- Ciclo de vida predictivopredictive life cycle
El alcance, el plazo y el costo se definen al inicio y el producto se entrega completo al final, tras fases que suelen ir en secuencia. Los cambios pasan por un control formal.
En el examen. Encaja cuando los requisitos son estables y cambiar tarde es caro, como en una obra o un proyecto regulado.
Ciclos de vida y procesos- Ciclo de vida iterativoiterative life cycle
La solución se refina en ciclos repetidos de construir, recibir opinión y mejorar, por ejemplo con prototipos, hasta que queda clara.
En el examen. No confundirlo con el incremental: el iterativo refina la misma solución; el incremental entrega partes nuevas utilizables.
Ciclos de vida y procesos- Ciclo de vida incrementalincremental life cycle
El producto se entrega por partes utilizables que se van sumando hasta completarlo. Cada entrega agrega funciones a las anteriores.
Ciclos de vida y procesos- Ciclo de vida adaptativoadaptive (agile) life cycle
Combina iterar e incrementar: entregas frecuentes de valor y ajuste continuo según la opinión del cliente. Plazo y costo suelen quedar fijos y el alcance se ajusta.
En el examen. Si el cliente no puede participar durante el proyecto, se pierde la principal ventaja del enfoque adaptativo.
Ciclos de vida y procesos- Enfoque híbridohybrid approach
Mezcla elementos predictivos y adaptativos en un mismo proyecto, por ejemplo una obra planificada por adelantado y una app desarrollada en iteraciones.
Ciclos de vida y procesos- Grupos de procesosprocess groups
Inicio, planificación, ejecución, monitoreo y control, y cierre. Agrupan procesos que interactúan; no son fases y pueden repetirse dentro de cada fase.
En el examen. Una opción que trata los grupos de procesos como fases que ocurren una sola vez es incorrecta.
Ciclos de vida y procesos- Fase del proyectoproject phase
Un conjunto de actividades relacionadas que termina con uno o más entregables. Al final, una revisión de fase decide si se sigue, se ajusta o se detiene.
Ciclos de vida y procesos- Adaptación de procesostailoring
Ajustar los procesos, artefactos y formatos al tamaño, la complejidad y el contexto del proyecto: usar lo que aporta valor y dejar lo que solo agrega trabajo.
Ciclos de vida y procesos- Estructura organizacionalorganizational structure
Cómo se reparte la autoridad entre gerentes funcionales y project managers: funcional (manda el área), matricial débil, equilibrada o fuerte, y orientada a proyectos (manda el project manager).
En el examen. En una matricial débil, el project manager tiene poca autoridad: actúa más como coordinador.
Ciclos de vida y procesos- Diagrama de rednetwork diagram
Muestra las actividades y sus dependencias. Sirve para calcular la ruta crítica y la holgura de cada actividad.
Ciclos de vida y procesos- Adelanto y retrasolead and lag
Un adelanto permite que una actividad empiece antes de que termine la anterior; un retraso obliga a esperar un tiempo entre las dos, como el fraguado del concreto.
Ciclos de vida y procesos- Hitomilestone
Un evento importante del proyecto, con duración cero, como «diseño aprobado». Un cronograma de hitos muestra solo esos eventos y sus fechas.
Ciclos de vida y procesos- Análisis de negociobusiness analysis
Entender una necesidad del negocio y definir la solución que la resuelve: identificar el problema, recopilar y gestionar requisitos y comprobar que la solución aporta el valor esperado.
En el examen. El analista se ocupa del producto (qué se necesita); el project manager, del trabajo para entregarlo.
Análisis de negocio- Requisitorequirement
Una condición o capacidad que la solución debe cumplir. Hay requisitos de negocio, de los interesados, de la solución (funcionales y no funcionales) y de transición.
Análisis de negocio- Requisito no funcionalnon-functional requirement
Describe cómo debe comportarse la solución, no qué hace: rendimiento, disponibilidad, seguridad o facilidad de uso. «Responder en menos de dos segundos» es un ejemplo.
Análisis de negocio- Requisito de transicióntransition requirement
Lo necesario para pasar del estado actual al futuro y que luego deja de hacer falta: capacitación, migración de datos, soporte inicial.
En el examen. Si el sistema funciona pero los usuarios no saben usarlo, faltaron requisitos de transición.
Análisis de negocio- Regla de negociobusiness rule
Una política o restricción del negocio que la solución debe respetar, como «un cliente no puede tener más de dos créditos activos». Se documenta aparte porque afecta a varios requisitos.
Análisis de negocio- Matriz de trazabilidadrequirements traceability matrix
Relaciona cada requisito con su origen, su diseño y sus pruebas. Permite ver qué afecta un cambio y comprobar que cada requisito se probó.
En el examen. Un requisito obligatorio sin prueba asociada es una alerta que la matriz hace visible.
Análisis de negocio- Recopilación de requisitoselicitation
Obtener información de los interesados y de otras fuentes: entrevistas, talleres, observación, encuestas, grupos focales, prototipos y análisis de documentos.
Análisis de negocio- Observaciónobservation (job shadowing)
Ver cómo se hace realmente el trabajo. Útil cuando las personas lo hacen de memoria y no logran describir todos los pasos.
Análisis de negocio- Grupo focalfocus group
Una conversación guiada con un grupo pequeño de personas parecidas, como clientes habituales, para conocer opiniones y expectativas.
Análisis de negocio- Prototipoprototype
Un modelo temprano de la solución para que los usuarios reaccionen a algo concreto. Ayuda cuando no saben describir lo que quieren, pero reconocen lo que les sirve.
Análisis de negocio- Análisis de brechasgap analysis
Compara el estado actual con el futuro deseado e identifica lo que falta para pasar de uno a otro: procesos, capacidades, sistemas o personas.
Análisis de negocio- Análisis de interfacesinterface analysis
Identifica dónde se conecta la solución con otros sistemas, procesos o personas, y qué información se intercambia, en qué formato y cuándo.
Análisis de negocio- Diagrama de contextocontext diagram
Muestra la solución en el centro y, alrededor, las personas y sistemas externos con los que intercambia información. Una vista simple del alcance.
Análisis de negocio- Caso de usouse case
Describe, paso a paso, cómo interactúa un actor con el sistema para lograr un objetivo, incluidas las excepciones como un pago rechazado.
Análisis de negocio- Diccionario de datosdata dictionary
Define cada dato de la solución: nombre, significado, formato, valores permitidos y origen. Evita que distintos sistemas o áreas entiendan cosas distintas.
Análisis de negocio- MoSCoWMoSCoW prioritization
Técnica para priorizar requisitos: Must have (imprescindible), Should have (importante), Could have (deseable) y Won't have (esta vez no).
En el examen. Una función sin la cual el producto no puede lanzarse es un Must have.
Análisis de negocio- Modelo de KanoKano model
Clasifica las características según cómo afectan la satisfacción: básicas (se dan por hecho y su falta molesta), de desempeño (más es mejor) y de entusiasmo (sorprenden).
Análisis de negocio- Hoja de ruta del productoproduct roadmap
Muestra a alto nivel hacia dónde va el producto: qué grandes resultados o funciones llegarán y en qué orden aproximado. Cuanto más lejano el horizonte, menos detalle.
En el examen. No es un compromiso de fechas exactas ni el cronograma del proyecto: se actualiza cuando cambian las prioridades.
Análisis de negocio- Prueba de aceptación del usuariouser acceptance testing (UAT)
Usuarios reales prueban la solución en sus tareas antes de ponerla en producción, para confirmar que les sirve.
Análisis de negocio- Verificación y validaciónverification and validation
Verificar es comprobar que el producto cumple lo especificado; validar, que resuelve la necesidad real.
En el examen. Si el sistema hace lo que dice el requisito pero no sirve a los usuarios, pasó la verificación y falló la validación.
Análisis de negocio- Preparación para el cambiochange readiness
Evaluar si las personas, los procesos y la cultura de la organización están listos para adoptar la solución, y qué hace falta para que lo estén.
Análisis de negocio- Diagrama de ParetoPareto chart
Ordena las causas de un problema de la más a la menos frecuente. Muestra que unas pocas causas suelen explicar la mayoría de los casos.
Herramientas para resolver problemas- Diagrama de causa y efectoIshikawa / fishbone diagram
La «espina de pescado»: organiza las posibles causas de un problema en categorías, como personas, métodos, materiales y equipos.
Herramientas para resolver problemas- Cinco porquésfive whys
Preguntar «¿por qué?» varias veces seguidas para pasar del síntoma a la causa raíz de un problema.
Herramientas para resolver problemas- Histogramahistogram
Muestra cómo se distribuyen los datos agrupándolos en intervalos, por ejemplo cuántas solicitudes se resolvieron en uno, dos o tres días.
Herramientas para resolver problemas- Diagrama de dispersiónscatter diagram
Muestra si dos variables están relacionadas, como las horas de capacitación y los errores de cada técnico.
Herramientas para resolver problemas- Gráfico de controlcontrol chart
Muestra si un proceso es estable a lo largo del tiempo, con una media y límites de control. Un punto fuera de los límites, o siete seguidos del mismo lado de la media, piden investigar.
Herramientas para resolver problemas- Hoja de verificacióncheck sheet
Una planilla para contar datos mientras ocurren, como cuántas veces aparece cada tipo de defecto. No confundir con la lista de verificación, que repasa pasos para no olvidar ninguno.
Herramientas para resolver problemas- Diagrama de afinidadaffinity diagram
Agrupa muchas ideas o problemas por temas parecidos para entenderlos mejor, por ejemplo después de una lluvia de ideas.
Herramientas para resolver problemas- Técnica de grupo nominalnominal group technique
Cada persona genera ideas en silencio, se comparten sin debatir y al final el grupo las vota para priorizarlas. Así participan todos.
Herramientas para resolver problemas- Valor monetario esperadoexpected monetary value (EMV)
Probabilidad por impacto: un riesgo con 20 % de probabilidad y USD 50 000 de impacto vale USD 10 000. Sirve para comparar riesgos y opciones.
Herramientas para resolver problemas- Análisis de escenarioswhat-if analysis
Evaluar el efecto de situaciones posibles sobre el proyecto, como «¿qué pasa con la fecha si el proveedor se retrasa dos semanas?».
Herramientas para resolver problemas- Métodos de decisión en grupogroup decision-making
Unanimidad (todos de acuerdo), mayoría (más de la mitad), pluralidad (gana la opción con más votos aunque no llegue a la mitad) y decisión autocrática (decide una persona).
Herramientas para resolver problemas- Dueño del productoProduct Owner
La persona que maximiza el valor del producto: ordena el backlog, decide qué se construye primero y acepta o rechaza lo entregado.
En el examen. Si la pregunta es sobre prioridades o alcance del producto, la decisión es suya, no del project manager ni del equipo.
Ágil y Scrum- Scrum Master
Líder al servicio del equipo: le enseña Scrum, facilita los eventos y retira impedimentos que el equipo no puede resolver solo.
En el examen. No asigna tareas ni decide cómo se hace el trabajo.
Ágil y Scrum- Equipo autoorganizadoSelf-organizing team
Equipo que decide por sí mismo cómo hacer el trabajo y quién hace cada parte para cumplir el objetivo acordado.
En el examen. La opción correcta rara vez es que el líder reparta las tareas; suele ser facilitar que el equipo decida.
Ágil y Scrum- Backlog del productoProduct backlog
Lista ordenada de todo lo que podría necesitar el producto. Es la única fuente de trabajo del equipo y la mantiene el dueño del producto.
En el examen. Un cambio de alcance en ágil se trata añadiéndolo y priorizándolo en el backlog, no con una solicitud de cambio formal.
Ágil y Scrum- Refinamiento del backlogBacklog refinement
Trabajo continuo de detallar, estimar y ordenar los elementos del backlog para que los próximos estén listos para planificarse.
Ágil y Scrum- Sprint o iteraciónSprint / iteration
Periodo fijo y corto (de una a cuatro semanas) en el que el equipo construye un incremento terminado. Su duración no se alarga.
En el examen. Si el trabajo no cabe, se devuelve al backlog; no se extiende el sprint.
Ágil y Scrum- Planificación del sprintSprint planning
Evento al inicio del sprint en el que el equipo decide qué puede terminar, con qué objetivo y cómo lo hará.
Ágil y Scrum- Reunión diariaDaily standup / Daily Scrum
Encuentro corto del equipo (unos 15 minutos) para revisar el avance hacia el objetivo del sprint y detectar impedimentos.
En el examen. No es un informe de estado para el líder; los problemas se resuelven después, con quien corresponda.
Ágil y Scrum- Revisión del sprintSprint review
Evento al final del sprint en el que el equipo muestra el incremento a los interesados y se recoge su retroalimentación para ajustar el backlog.
Ágil y Scrum- RetrospectivaRetrospective
Evento en el que el equipo revisa cómo trabajó (personas, procesos, herramientas) y acuerda mejoras para el siguiente ciclo.
En el examen. Es la respuesta habitual cuando el equipo repite un problema de forma de trabajo.
Ágil y Scrum- IncrementoIncrement
Parte del producto terminada y utilizable que se suma a lo entregado antes. Cada sprint produce al menos uno.
Ágil y Scrum- Definición de hechoDefinition of Done (DoD)
Criterios que todo trabajo debe cumplir para considerarse terminado (probado, documentado, integrado…). La comparte todo el equipo.
En el examen. No confundir con los criterios de aceptación, que son propios de cada historia.
Ágil y Scrum- Definición de listoDefinition of Ready (DoR)
Criterios que debe cumplir un elemento del backlog para que el equipo lo acepte en un sprint: claro, estimado y lo bastante pequeño.
Ágil y Scrum- Historia de usuarioUser story
Descripción breve de una necesidad desde el punto de vista de quien la usa: «como…, quiero…, para…». Invita a conversar, no reemplaza la conversación.
Ágil y Scrum- Criterios de aceptaciónAcceptance criteria
Condiciones concretas que una historia debe cumplir para que el dueño del producto la acepte.
Ágil y Scrum- Puntos de historiaStory points
Unidad relativa para estimar el tamaño de una historia (esfuerzo, complejidad e incertidumbre), sin horas.
En el examen. Solo tienen sentido dentro del mismo equipo; no se comparan entre equipos.
Ágil y Scrum- VelocidadVelocity
Cantidad de trabajo terminado por iteración, normalmente en puntos. Sirve para que el equipo pronostique cuánto podrá hacer.
En el examen. No es una medida de productividad para comparar equipos ni para presionarlos.
Ágil y Scrum- Producto mínimo viableMVP
La versión más pequeña del producto que permite aprender de usuarios reales si la idea funciona.
Ágil y Scrum- Spike
Trabajo corto y acotado en el tiempo para investigar o probar algo técnico y reducir la incertidumbre antes de estimar o decidir.
Ágil y Scrum- Liderazgo de servicioServant leadership
Estilo de liderazgo que pone al equipo primero: escucha, retira obstáculos, protege su foco y lo ayuda a crecer.
En el examen. Es el estilo esperado del project manager en entornos ágiles e híbridos.
Ágil y Scrum- Tiempo fijoTimebox
Duración máxima acordada para una actividad o evento. Al llegar al límite, se para y se decide qué hacer con lo pendiente.
Ágil y Scrum- Radiador de informaciónInformation radiator
Información visible para todos, sin pedirla: tablero de tareas, gráfico de avance, impedimentos. Favorece la transparencia.
Ágil y Scrum- Kanban
Método para gestionar el trabajo como un flujo continuo, visualizándolo en un tablero y limitando el trabajo en curso.
Kanban y flujo- Límite de trabajo en cursoWIP limit
Número máximo de elementos que puede haber a la vez en una etapa del flujo. Obliga a terminar antes de empezar algo nuevo.
En el examen. Ante un cuello de botella, la primera medida suele ser respetar o bajar el límite, no empujar más trabajo.
Kanban y flujo- Tiempo de entregaLead time
Tiempo desde que se pide algo hasta que se entrega. Es lo que percibe el cliente.
Kanban y flujo- Tiempo de cicloCycle time
Tiempo desde que el equipo empieza a trabajar en un elemento hasta que lo termina. Siempre es menor o igual que el tiempo de entrega.
Kanban y flujo- Cuello de botellaBottleneck
Etapa del flujo con menos capacidad que las demás, donde el trabajo se acumula y que marca el ritmo de todo el sistema.
Kanban y flujo- Diagrama de flujo acumuladoCumulative flow diagram (CFD)
Gráfico de bandas que muestra cuánto trabajo hay en cada estado a lo largo del tiempo. Una banda que se ensancha delata un cuello de botella.
Kanban y flujo- Acta de constituciónProject charter
Documento que autoriza formalmente el proyecto y da al project manager autoridad para usar recursos. Lo emite el patrocinador.
En el examen. Sin acta no hay proyecto autorizado; si falta, es lo primero.
Planificación- Estructura de desglose del trabajo (EDT)WBS
Descomposición jerárquica de todo el trabajo del proyecto en entregables y paquetes de trabajo. Lo que no está en la EDT no está en el alcance.
Planificación- Paquete de trabajoWork package
El nivel más bajo de la EDT, en el que se puede estimar y gestionar el costo y la duración del trabajo.
Planificación- Línea baseBaseline
Versión aprobada del alcance, el cronograma o el costo contra la que se mide el desempeño. Solo cambia con el control de cambios.
En el examen. Nadie la ajusta por su cuenta para «que cuadren los números».
Planificación- Ruta críticaCritical path
Secuencia más larga de actividades dependientes del proyecto; fija la duración mínima. Sus actividades no tienen holgura.
Planificación- HolguraFloat / slack
Tiempo que una actividad puede retrasarse sin retrasar el fin del proyecto (holgura total) o a su sucesora (holgura libre).
Planificación- IntensificaciónCrashing
Acortar el cronograma añadiendo recursos a actividades de la ruta crítica. Cuesta más dinero.
Planificación- Ejecución rápidaFast tracking
Acortar el cronograma haciendo en paralelo actividades que estaban en secuencia. Añade riesgo de retrabajo.
Planificación- Estimación análogaAnalogous estimating
Estimar a partir de un proyecto anterior parecido. Rápida y barata, poco precisa; útil al principio.
Planificación- Estimación paramétricaParametric estimating
Estimar multiplicando una cantidad por un rendimiento histórico (por ejemplo, metros por costo por metro). Tan precisa como el dato que usa.
Planificación- Planificación gradualRolling wave planning
Planificar en detalle lo cercano y a grandes rasgos lo lejano, y detallarlo a medida que se acerca.
Planificación- Valor ganadoEarned value (EV)
Valor presupuestado del trabajo realmente hecho. Comparado con lo planificado y lo gastado, dice cómo va el proyecto en costo y plazo.
En el examen. Las fórmulas están en la hoja de fórmulas de PMNOVA.
Seguimiento y control- Índice de desempeño del costoCPI
Valor ganado dividido entre el costo real. Menor que 1: se gasta más de lo que vale lo hecho.
Seguimiento y control- Índice de desempeño del cronogramaSPI
Valor ganado dividido entre el valor planificado. Menor que 1: se va más lento de lo planificado.
Seguimiento y control- Gráfico de trabajo pendienteBurndown chart
Muestra el trabajo que queda en el tiempo. Si la línea real queda por encima de la ideal, el equipo va retrasado.
Seguimiento y control- Gráfico de trabajo completadoBurnup chart
Muestra el trabajo hecho y el alcance total por separado, así que distingue si el retraso es por lentitud o porque creció el alcance.
Seguimiento y control- Arrastre del alcanceScope creep
Crecimiento del alcance sin pasar por el control de cambios y sin ajustar plazo, costo ni recursos.
En el examen. La respuesta suele ser volver al proceso de cambios, no aceptar ni rechazar el pedido en el momento.
Seguimiento y control- Chapado en oroGold plating
Entregar más de lo pedido por iniciativa del equipo. Aunque parezca un regalo, añade riesgo y costo sin aprobación.
Seguimiento y control- ImpedimentoImpediment / blocker
Cualquier cosa que frena al equipo y que no puede resolver por sí mismo. Retirarlo es tarea del líder.
Seguimiento y control- RiesgoRisk
Evento incierto que, si ocurre, afecta a algún objetivo del proyecto. Puede ser negativo (amenaza) o positivo (oportunidad).
Riesgos y cambios- IncidenteIssue
Algo que ya está ocurriendo y afecta al proyecto. Un riesgo que se materializa pasa a ser un incidente.
En el examen. Riesgo = puede pasar; incidente = ya pasó. Se registran en lugares distintos.
Riesgos y cambios- Registro de riesgosRisk register
Documento donde se anotan los riesgos identificados, su análisis, sus responsables y las respuestas acordadas.
Riesgos y cambios- Dueño del riesgoRisk owner
La persona encargada de vigilar un riesgo y de ejecutar su respuesta si se materializa.
Riesgos y cambios- Apetito de riesgoRisk appetite
Cuánta incertidumbre está dispuesta a aceptar la organización a cambio del beneficio esperado.
Riesgos y cambios- Respuestas a las amenazas
Evitar (eliminar la causa), transferir (pasar el impacto a otro, como con un seguro), mitigar (bajar probabilidad o impacto), aceptar (asumirlo) y escalar (si excede la autoridad del proyecto).
Riesgos y cambios- Respuestas a las oportunidades
Explotar (asegurar que ocurra), compartir (con quien pueda aprovecharla mejor), mejorar (subir su probabilidad o impacto), aceptar y escalar.
Riesgos y cambios- Reserva para contingenciasContingency reserve
Tiempo o dinero para riesgos identificados. Forma parte de la línea base y la administra el project manager.
Riesgos y cambios- Reserva de gestiónManagement reserve
Tiempo o dinero para lo no identificado. No entra en la línea base; usarla requiere la aprobación de la dirección.
Riesgos y cambios- Control integrado de cambiosIntegrated change control
Proceso para analizar, aprobar o rechazar los cambios a las líneas base y actualizar los planes. En predictivo, lo decide quien tiene autoridad (a menudo un comité de cambios).
En el examen. El orden habitual: analizar el impacto, presentar la solicitud, decidir quien corresponde, comunicar.
Riesgos y cambios- InteresadoStakeholder
Persona, grupo u organización que afecta al proyecto o se ve afectada por él.
Equipo e interesados- Registro de interesadosStakeholder register
Lista de los interesados con su información, interés, influencia y expectativas. Se actualiza durante todo el proyecto.
Equipo e interesados- Matriz de compromiso de los interesadosStakeholder engagement assessment matrix
Compara el nivel de compromiso actual de cada interesado (desconoce, se resiste, neutral, apoya, lidera) con el deseado, para planificar cómo acercarlos.
Equipo e interesados- Matriz RACI
Tabla que asigna a cada tarea quién la hace (R), quién rinde cuentas (A), a quién se consulta (C) y a quién se informa (I). Solo un A por tarea.
Equipo e interesados- Etapas de Tuckman
Formación, conflicto, normalización, desempeño y disolución: las etapas por las que suele pasar un equipo.
En el examen. Los conflictos al principio de un equipo nuevo son normales (etapa de conflicto); el líder los facilita, no los castiga.
Equipo e interesados- Inteligencia emocionalEmotional intelligence
Capacidad de reconocer y gestionar las emociones propias y ajenas. Es la base para liderar, negociar y resolver conflictos.
Equipo e interesados- Colaborar para resolver un conflictoCollaborate / problem solve
Técnica que busca una solución que satisfaga a todas las partes atendiendo a la causa del conflicto. Es la que produce acuerdos más duraderos.
En el examen. Suele ser la mejor respuesta; ceder, imponer o evitar lo son solo en situaciones concretas.
Equipo e interesados- Equipo virtualVirtual team
Equipo que trabaja desde lugares distintos. Exige acuerdos explícitos de comunicación, husos horarios y herramientas.
Equipo e interesados- Caso de negocioBusiness case
Justificación económica del proyecto: el problema u oportunidad, las opciones y los beneficios frente a los costos.
Negocio y gobernanza- Plan de gestión de beneficiosBenefits management plan
Describe qué beneficios debe producir el proyecto, cuándo, cómo se medirán y quién es responsable de que se logren.
Negocio y gobernanza- Gobernanza del proyectoProject governance
El marco de decisiones del proyecto: quién decide qué, cómo se escala y con qué controles.
Negocio y gobernanza- PatrocinadorSponsor
Quien aporta los recursos y respalda el proyecto; aprueba el acta, defiende el caso de negocio y resuelve lo que excede al project manager.
Negocio y gobernanza- Oficina de gestión de proyectos (PMO)PMO
Área que estandariza la gestión de proyectos en la organización. Puede ser de apoyo, de control o directiva, según cuánta autoridad tenga.
Negocio y gobernanza- CumplimientoCompliance
Asegurar que el proyecto respeta leyes, normas y políticas que le aplican. Los requisitos de cumplimiento no se negocian como el resto del alcance.
Negocio y gobernanza- Gestión del cambio organizacionalOrganizational change management
Preparar a las personas para adoptar lo que entrega el proyecto: comunicación, formación y apoyo para que el cambio se sostenga.
Negocio y gobernanza- Transferencia de conocimientoKnowledge transfer
Asegurar que lo aprendido en el proyecto llegue a quien lo necesita: lecciones aprendidas, documentación y relevo a operaciones.
Negocio y gobernanza- Calidad y gradoQuality vs. grade
Calidad es cumplir los requisitos; grado es la categoría o nivel de prestaciones. Un producto de grado bajo puede tener calidad alta.
En el examen. Baja calidad siempre es un problema; bajo grado puede ser justo lo que se pidió.
Calidad y entrega- Costo de la calidadCost of quality
Lo que se gasta en prevenir y evaluar (conformidad) más lo que cuestan las fallas internas y externas (no conformidad).
Calidad y entrega- Control de calidadQuality control
Inspeccionar los entregables para comprobar que cumplen los requisitos. Es correctivo: encuentra defectos.
Calidad y entrega- Aseguramiento de la calidadQuality assurance
Revisar y mejorar los procesos para que los defectos no ocurran. Es preventivo.
Calidad y entrega- Análisis de causa raízRoot cause analysis
Buscar el origen de un problema (con los cinco porqués o un diagrama de Ishikawa) para corregirlo de fondo y no solo el síntoma.
Calidad y entrega- Entregables aceptadosAccepted deliverables
Entregables que el cliente o el patrocinador revisó y aprobó formalmente. Es el paso previo al cierre de esa parte del proyecto.
Calidad y entrega- Lecciones aprendidasLessons learned
Lo que el proyecto aprendió, bueno y malo, registrado para aprovecharlo. Se recogen durante todo el proyecto, no solo al cierre.
Calidad y entrega
Contenido original de PMNOVA. No afiliado ni respaldado por PMI.