Fundamentos para el desarrollo de proyectos

de 39
MODULO 1.
FUNDAMENTOS PARA EL DESARROLLO DE
PROYECTOS INFORMÁTICOS
1
Alejandro Domínguez Torres, jadoming@mail.unitec.mx, www.unitec.mx
INTRODUCCIÓN
La industria de la informática ha desarrollado nuevos métodos para administrar la
creciente complejidad de los proyectos informáticos. En el pasado hubo varias
evoluciones, revoluciones y temas recurrentes de éxito y fracaso.
En el presente, el éxito de los proyectos informáticos depende de encontrar un equilibrio
de cinco componentes principales: Personas, Información, Procesos, Herramientas y
Productos/Servicios. Los cinco componentes son importantes al momento de desarrollar
cualquier proyecto informático. Por varios años, dos de estos elementos han sido
explorados en detalle. Estos dos componentes son: Personas y Procesos.
Las personas y los procesos requieren tener un canal conductor que permita la
comunicación entre varios de sus elementos componentes, así como entre ellos. Sin la
comunicación no existe forma alguna de desarrollar cualquier proyecto informático.
El estudio y descripción de la relación y equilibrio de estos cinco componentes, poniendo
especial atención en las Personas y los Procesos, así como en la comunicación como
integrador del desarrollo de proyectos, son los propósitos de este primer modulo.
La Sección 1 discute el desarrollo de proyectos informáticos como parte de la entrega de
las funciones y los servicios informáticos, presenta a los cinco elementos del desarrollo
de proyectos informáticos como fundamento para la especificación de prácticas y
procedimientos normalizados, y muestra la relación entre los elementos y cómo los
cambios en un elemento afectan a los otros.
La Sección 2 aborda a los componentes Procesos y Personas y discute dos modelos para
el éxito del desarrollo de proyectos. Estos modelos son el “Software Capability Maturity
Model (S-CMM: Modelo de Madurez de la Capacidad de Software)” y “People
Capability Maturity Model (P-CMM: Modelo de Madurez de la Capacidad de las
Personas). Ambos generados por el Software Engineering Institute (SEI).
Finalmente, la Sección 3 discute dos tópicos principales: los elementos de un plan de
comunicación y algunas estrategias de comunicación.
1
Desarrollo y gestión de proyectos informáticos. Curso a distancia. Centro Interamericano de Estudios de
Seguridad Social. Septiembre de 2003.

de 39
OBJETIVOS
 Analizar los cinco elementos fundamentales para el desarrollo de proyectos
informáticos como fundamento para la especificación de prácticas y
procedimientos normalizados, así como analizar la relación entre los elementos.
 Analizar las dos normas internacionales para el desarrollo de proyectos asociadas
a las Personas y a los Procesos.
 Analizar la importancia de la comunicación en el desarrollo de proyectos.
PALABRAS CLAVE
Desarrollo de proyectos informáticos Nivel de madurez
Personas Capacidad de procesos de software
Información Áreas de procesos clave
Procesos Metas
Herramientas Características comunes
Producto/Servicio Prácticas clave
Modelo de Madurez de la Capacidad de Software Plan de comunicaciones
Modelo de Madurez de la Capacidad de las
Personas
Estrategias de comunicación
CONTENIDO
1. Elementos básicos para el desarrollo de proyectos informáticos
2. Los Modelos de Madurez de la Capacidad
3. El proceso de comunicación dentro de un proyecto informático
ACTIVIDAD DE EVALUACIÓN
Considerar el estado actual de una organización; ésta puede ser en la que se labora o
cualquier otra (esta organización debe desarrollar aplicaciones de software).
Utilizando la Tabla siguiente, evaluar esa organización con el fin de conocer la distancia
que la separa del nivel 2 del S-CMM.

de 39
Cumplimiento Total No Cumple
No Aplicable No Evaluado
Cumplimiento Total No Cumple
No Aplicable No Evaluado
Administración de la configuración
Aseguramiento de la calidad del software
Administración de subcontratos de software
Casilla
inválida
Supervisión y vigilancia del proyecto
Casilla
inválida
Planeación del proyecto
Casilla
inválida
Casilla
inválida
Administración de requerimientos
Meta 4Meta 3Meta 2Meta 1KPAs del Nivel Repetible
Administración de la configuración
Aseguramiento de la calidad del software
Administración de subcontratos de software
Casilla
inválida
Supervisión y vigilancia del proyecto
Casilla
inválida
Casilla
inválida
Casilla
inválida
Administración de requerimientos
Meta 4Meta 3Meta 2Meta 1KPAs del Nivel Repetible
Una vez que se haya analizado la situación de la organización, evaluar cada meta y
redactar (en MSWord) una justificación para cada una. Cada justificación debe ser clara,
concisa y menor o igual a media página.
El documento que se genere debe tener la siguiente estructura:
 Portada o página de presentación, indicando los siguientes datos: nombre
completo, dirección de correo electrónico, ciudad, país, nombre del documento, y
fecha de creación
 Página de resumen (no más de 200 palabras)
 Antecedentes de la organización donde se aplicará la evaluación. Debe contener
información para conocer el tipo de organización que se está evaluando.
 La evaluación y su justificación
 Para cada “No Cumple”, indicar cómo proceder para cambiar ésta a
“cumplimiento total”; es decir, indicar cómo resolver el problema (de nueva
cuenta, la solución para cada “No Cumple” debe ser menor o igual a una media
página)
 Conclusiones (propias y originales)

de 39
MODULO 1.
1 ELEMENTOS BÁSICOS PARA EL DESARROLLO DE
RESUMEN
Esta sección presenta algunos lineamientos útiles para desarrollar proyectos informáticos
tal como se muestra en la siguiente Tabla.
Tabla 1. Organización y presentación de los lineamientos para el desarrollo de proyectos.
SUBSECCIÓN RESUMEN DE LA SUBSECCIÓN
1.2 DESARROLLO DE PROYECTOS
INFORMÁTICOS
Discute el desarrollo de proyectos informáticos como parte de la
entrega de servicios y funciones informáticos
1.3 ELEMENTOS PARA EL
DESARROLLO DE
Presenta los cinco elementos principales para el desarrollo de
proyectos informáticos como fundamento para la especificación de
practicas y procedimientos normalizados
1.4 LA RELACIÓN DE LOS CINCO
ELEMENTOS
Muestra la relación entre los elementos y cómo los cambios en un
elemento afectan a los otros
1.1 EL DESARROLLO DE PROYECTOS INFORMÁTICOS
La informática está presente en todos los aspectos empresariales. Sin embargo, si las
metas empresariales deben cumplirse, los procesos de selección, diseño e implementación
de las soluciones informáticas tienen que ser desarrolladas por un conjunto
cuidadosamente diseñado de estrategias y procedimientos. Esta es la esencia del
desarrollo de proyectos informáticos.
El desarrollo de proyectos informáticos consiste de un conjunto de procesos estructurados
que sirven para alcanzar una salida específica y única en un periodo de tiempo definido y
acotado. Las salidas exitosas son más frecuentes cuando un proyecto informático está
definido, diseñado, implementado y controlado de forma apropiada.
Los proyectos informáticos pueden ser de diferentes tipos y tamaños, algunos de ellos se
enuncian en la siguiente Tabla.

de 39
Tabla 2. Algunos proyectos informáticos y su descripción.
TIPO DE PROYECTO
INFORMÁTICO
DESCRIPCIÓN
ESTUDIOS DE
FACTIBILIDAD
La evaluación de la informática y su uso en una organización, incluyendo la
selección de soluciones informáticas y recomendaciones para estrategias futuras
DESARROLLO DE LA
INFORMÁTICA
El diseño, pruebas, integración e implementación de aplicaciones informáticas
personalizadas, así como de las plataformas e interfaces relacionadas
ACTUALIZACIÓN DE
LA INFORMÁTICA
La actualización de las plataformas, soluciones y productos informáticos
existentes
MIGRACIÓN DE LA
INFORMÁTICA
El reemplazo y/o retiro de plataformas y soluciones informáticas existentes,
frecuentemente reemplazadas por diferentes productos
SERVICIOS DE APOYO
La participación de la informática como un agente de cambio; así como en
renovaciones departamentales, reubicaciones, fusiones organizacionales,
programas de capacitación, y reorganizaciones internas
ADMINISTRACIÓN DE
LA INFORMÁTICA
Relacionada con la mejora y entrega del servicio de la informática, incluye
procesos de reingeniería informática, mantenimiento, auditorías de seguridad, y
documentación de proyectos
Sin embargo, la lista no finaliza aquí, ya que cuando una solución informática es
seleccionada e instalada, se le debe dar mantenimiento y soporte técnico. Más aún, la
rápida evolución de los cambios tecnológicos provoca la implementación de ciclos de
mejora, actualización y renovación.
Sin importar que la meta del desarrollo informático sea el diseño, instalación, o
reingeniería, las iniciativas informáticas son a menudo conducidas por fechas fijas y
periodos de cambios frecuentes. Para alcanzar las metas, los recursos deben estar
identificados y asignados, y las actividades deben estar organizadas y estructuradas de
forma apropiada de acuerdo con los requerimientos empresariales e informáticos.
No obstante, considerando la diversidad de soluciones informáticas disponibles, aplicadas
dentro de un rango amplio de entornos empresariales y profesionales, el desarrollo de
proyectos informáticos no es una tarea fácil, por ejemplo:
 A menudo, la funcionalidad informática no es la deseada debido a problemas
técnicos;
 Existe una tolerancia limitada a los tiempos fuera de servicio, la cual puede
complicar enormemente la implementación de actualizaciones y migraciones de
plataformas.
De esta forma, las cotas existentes entre los proyectos informáticos y las operaciones
diarias empañan los esfuerzos de desarrollo informático, creando así retos de desarrollo
únicos.
Se pueden utilizar las mejores prácticas para el desarrollo de proyectos informáticos y así
enfrentar estos retos. Considerando la necesidad de calidad consistente y entrega a
tiempo, las prácticas diseñadas para mostrar desempeño y productividad deben ser la
apropiadas, a condición de que las prácticas no sobrepasen el propósito deseado.

de 39
Como en cualquier otra disciplina, el desarrollo de proyectos informáticos debe ponerse
en la perspectiva organizacional. Para efectuar un desarrollo efectivo de proyectos
informáticos se debe tener:
 Políticas y procedimientos definidos para la selección, definición, diseño y control
de los proyectos;
 Apoyo administrativo comprometido;
 Personal capacitado y comprometido;
 Un entorno que fomente el trabajo en equipo y la cooperación;
 Fuertes capacidades técnicas;
 Una comprensión de las metas y objetivos empresariales;
 Las herramientas informáticas apropiadas que se ajusten a los requerimientos y
capacidades técnicas del proyecto;
 La autoridad para aplicar y actualizar las prácticas de administración de proyectos
informáticos cuando sea necesario.
Muchas organizaciones enfrentan diversos tipos de proyectos informáticos, cada uno con
su propio grado de dificultad, urgencia y prioridad. Las mejores prácticas para el
desarrollo de proyectos informáticos agregan estructura y definición a este caos. Al ser
aplicadas, influyen en las decisiones y actividades. La velocidad, creatividad, e
innovación encuentran un lugar dentro de un ambiente de normas, reglas, formatos y
plantillas.
El éxito del proyecto es más factible cuando los entregables requeridos se producen en
tiempo y dentro de presupuesto. Más aún, para ser verdaderamente exitoso, los proyectos
informáticos deben tener:
 Planes reales y funcionales;
 Fuerte compromiso administrativo;
 Monitoreo y supervisión adecuada;
 Análisis efectivo de riesgos;
 Fuertes justificaciones empresariales;
 Control de costos;
 Diseño técnico y planes de implementación consistentes;
 Expectativas reales;
 Equipos de trabajo sólidos.
Para generar resultados exitosos sobre una base consistente, se deben definir y aplicar
normas y mejores prácticas realistas y funcionales. Estas normas deben estar alineadas
con los requerimientos organizacionales, capacidades internas, y características de los
proyectos.

de 39
1.2 LOS ELEMENTOS DEL DESARROLLO DE PROYECTOS
INFORMÁTICOS
Cualquier proyecto informático contiene cinco elementos principales: Personas, Procesos,
Producto/Servicio, Información, y Herramientas. El desarrollo exitoso de proyectos
informáticos requiere que estos elementos estén en equilibrio. Equilibrar los elementos
implica observar quién está tratando de hacer qué, por lo que resulta importante
reflexionar acerca de los elementos desde el inicio del desarrollo del proyecto.
1.2.1 PERSONAS
El elemento primario de cualquier proyecto informático es las Personas:
 Las Personas recolectan requerimientos;
 Las Personas entrevistan a los usuarios (Personas);
 Las Personas diseñan la informática para las Personas;
 Sin Personas no existiría la informática.
Lo mejor que puede ocurrir en cualquier proyecto informático es tener:
 Personas que conozcan lo que estén haciendo y tener la voluntad y la
autodisciplina para hacerlo;
 Personas con conocimiento para hacer lo correcto y evitar lo que no lo está;
 Personas responsables para decir la verdad, aunque otras deseen escuchar algo
diferente;
 Personas disciplinadas para trabajar en los proyectos y no para sabotearlos.
Un desarrollo de proyectos exitoso requiere que el equipo del proyecto participe en el
proceso de diseño y sea responsable del cumplimiento de las tareas.
Es importante definir una organización formal del proyecto y del personal que participa
en él. Esto provee a cada persona una clara comprensión de su compromiso y de la
responsabilidad necesaria para el cumplimiento exitoso de las actividades del proyecto.
Los miembros del equipo del proyecto deben ser responsables del desarrollo efectivo de
sus tareas.
Las estructuras organizacionales del proyecto pueden ser diversas, aunque su impacto
sólo pueda verse durante el desarrollo del proyecto. Por ejemplo:
 En proyectos grandes, las tareas asignadas pueden requerir la totalidad del tiempo
del personal;
 En proyectos pequeños, las tareas asignadas pueden requerir solo una parte del
tiempo del personal, el cual puede tener otras funciones de forma paralela.
El equipo del proyecto debe estar compuesto por personas con diferentes habilidades.
Este equipo debe contener al menos el siguiente personal:

de 39
 Personal responsable de la implementación de la solución del proyecto (equipo
del proyecto):
o Personal para el desarrollo de los requerimientos;
o Personal para las especificaciones de las reglas de negocios;
o Personal para la administración del proyecto;
o Expertos en áreas propias del proyecto;
o Personal responsable de la documentación de los usuarios y la técnica;
o Personal para capacitar;
o Personal técnico;
o Líderes o tomadores de decisiones;
 Clientes (tanto internos como externos) para el producto/servicio a desarrollar;
 Patrocinador del proyecto;
 Actores en el proyecto.
Los actores en el proyecto son personas y organizaciones que tienen interés en el éxito
del proyecto. La identificación e insumos de los actores ayudan a definir, clarificar,
conducir, cambiar y contribuir en la determinación del alcance del proyecto, y por ende
en su éxito.
Para asegurar el éxito del proyecto, el equipo necesita identificar a los actores desde su
concepción, determinar sus requerimientos y expectativas, y administrar e influenciar
esas expectativas en el curso del proyecto.
El conjunto de actores del proyecto incluye a las siguientes personas (ver Tabla
siguiente):
Tabla 3. Responsabilidades de los actores.
ACTOR RESPONSABILIDAD
ADMINISTRADOR DEL PROYECTO Responsable total del éxito del proyecto
PATROCINADOR DEL PROYECTO
Responsable de hacer ver la necesidad del proyecto y, posiblemente,
de proveer los recursos financieros
ADMINISTRADOR Responsable administrativo del proyecto
MIEMBROS DEL EQUIPO DEL
PROYECTO
Responsables de ejecutar las tareas requeridas por el proyecto
ADMINISTRADORES DE LA
CONFIGURACIÓN
Responsables de administrar la configuración del proyecto y
mantenerlo dentro de sus fronteras
EQUIPO DE ASEGURAMIENTO DE
LA CALIDAD
Responsable de verificar que el producto/servicio cumple con los
requerimientos
PERSONAL DE ADQUISICIONES Responsable de adquirir los recursos del proyecto
CLIENTE Responsable de utilizar el producto/servicio del proyecto

de 39
1.2.2 PROCESOS
Los procesos son el “cómo” las personas ejecutan las tareas desde el inicio hasta el fin del
proyecto. Todos los proyectos utilizan al menos un proceso. Sin embargo, muchos
administradores de proyectos informáticos no eligen un proceso basado en las personas y
en el producto/servicio del proyecto en cuestión: simplemente utilizan el mismo proceso
que siempre han utilizado sin importar si es el apropiado.
Los procesos siempre deben estar sujetos a mejora y ser los apropiados (ver Tabla):
Tabla 4. Mejora y conveniencia de los procesos.
ENUNCIADO DESCRIPCIÓN
MEJORA DE LOS
PROCESOS
 Es la clave para incrementar la habilidad para generar el producto/servicio
 Debe existir un proceso previo antes de que exista una mejora
CONVENIENCIA DE
LOS PROCESOS
 Existen varios modelos de procesos de gran utilidad
 Dos de estos modelos son el “Software Capability Maturity Model (S-CMM)”
y el “Capability Maturity Model for People (P-CMM)”
 El S-CMM y el P-CMM tienen una serie de niveles a través de los cuales una
organización puede progresar de un nivel caótico o inicial (nivel 1) hasta un
nivel optimizado (nivel 5) (ver la Sección 2 para mayores detalles)
1.2.3 PRODUCTO/SERVICIO
El producto/servicio es el resultado del proyecto por lo que debe satisfacer a los clientes.
Sin embargo, algunas veces no lo satisface del todo.
Es importante señalar que el producto/servicio es la razón por la cual se obtienen
remuneraciones económicas, así que es necesario no perderlo de vista, aún cuando el
proceso requiera toda la atención. Si se pierde de vista, el resultado es un
producto/servicio inapropiado, no existencia de recursos económicos, falta de
oportunidades de negocio y despidos del personal.
En lugar de discutir los diferentes tipos de productos/servicios (sistemas de cómputo,
redes de voz y datos, etc.), en lo sucesivo la discusión se centrará en otros dos aspectos de
los productos/servicios:
 La dificultad inherente;
 La calidad interna y externa.
La dificultad del producto/servicio repercute en el proceso requerido para desarrollarlo.
La “dificultad” es subjetiva y depende de la familiaridad de las personas con el
producto/servicio. Por ejemplo, para algunas personas desarrollar un editor de texto es
difícil, mientras que para otras desarrollar un analizador de imágenes es sencillo.

de 39
Una forma de determinar la “dificultad” de un producto/servicio y el tipo de procesos
requerido es responder a las siguientes preguntas:
 ¿El producto/servicio es conocido o nuevo?
 ¿En novedoso?
 ¿La interfaz del usuario requiere de precisión?
Los productos/servicios difíciles demandan modelos de procesos que permitan
experimentar y aprender. Los productos/servicios fáciles por lo general requieren
modelos sencillos, directos y eficientes. Los productos/servicios difíciles son fáciles si se
cuenta con personas conocedoras de los mismos.
Por otro lado, es importante mantener en mente la calidad externa e interna del
producto/servicio. La calidad externa es lo que el cliente ve. El cliente está satisfecho si
el producto/servicio cumple con todos sus requerimientos funcionales, es fácil de
aprender, se ejecuta de forma rápida y no demanda muchos recursos para operar.
La calidad interna es lo que el desarrollador ve. Una alta calidad interna indica, entre
otras cosas, que el diseño es fácil de comprender y el resultado está acorde a las
especificaciones del cliente. Cuando el cliente solicita cambios en la plataforma
informática, una alta calidad interna permite llevar a cabo los cambios en el
producto/servicio de forma rápida y sencilla.
Estos factores de calidad también influyen en las personas y en los procesos. Por ejemplo,
si la portabilidad (calidad interna) es importante, en el desarrollo deben participar
personas expertas en varias plataformas informáticas. El no contar con estas personas,
elevará el número de riesgos para desarrollar el proyecto.
1.2.4 INFORMACIÓN
La información es esencial para la operación, desarrollo y organización de un proyecto.
Con el propósito de comprender la naturaleza de la información, es importante
comprender los propósitos para los que se provee. Sin embargo, el propósito primario de
la información es ayudar a la toma de decisiones.
La estimación del valor de la información es un área difícil. En algunos casos una medida
cuantitativa puede ser útil si se desea medir la rapidez con que se provee, como en el
control de deudas, o en la reducción de la incertidumbre. Sin embargo, en estos casos el
beneficio es intangible. Es difícil, sino imposible, analizar las contribuciones de una
información más efectiva para una mejor toma de decisiones, o más aún, aislar el impacto
de disponer mayor información para conocer cómo los clientes hacen sus compras. Es un
gran error ignorar los beneficios intangibles y no medibles que provee la información a
una organización.
Finalmente, es importante hacer notar que el desarrollo de proyectos informáticos se basa
en la información disponible, ya sea ésta formal o informal (ver la Tabla y Figura
siguientes):

de 39
Tabla 5. Información formal e informal.
TIPO DE INFORMACIÓN CARACTERÍSTICAS
INFORMACIÓN FORMAL
Es producida por procedimientos normalizados, es objetiva y por lo general
es considerada como relevante para la toma de decisiones
INFORMACIÓN INFORMAL
A menudo es subjetiva, se pasa de boca en boca; y comprende contracciones,
opiniones, interpretaciones, y rumores; además comprende información
explicativa y/o evaluativa
Información formal: cuantitativa,
producida por reglas conocidas, objetiva
Información informal: cualitativa,
no producida por reglas conocidas, subjetiva
Información formal: cuantitativa,
producida por reglas conocidas, objetiva
Información informal: cualitativa,
no producida por reglas conocidas, subjetiva
Figura 1. Información formal e informal.
1.2.5 HERRAMIENTAS
Las herramientas para el desarrollo de proyectos son los medios por los cuales los
procesos se convierten en realidad. A través del uso de software, plantillas, capacitación y
sistemas de comunicación, se les da forma y fondo a las directivas de los procesos (ver la
siguiente Tabla). Como resultado, estas herramientas son la parte tangible de que los
compromisos de desarrollo del proyecto se pueden llevar a la práctica.
Tabla 6. Herramientas para el desarrollo de proyectos.
HERRAMIENTA PROPÓSITO
SOFTWARE Automatizar las actividades de administración del proyecto
PLANTILLAS Documentar las actividades del proyecto
CAPACITACIÓN Educar a personal y a los usuarios finales
SISTEMAS DE COMUNICACIÓN Compartir el conocimiento, la información y el estado del proyecto
Antes de elegir las herramientas e integrarlas dentro del programa de normas del
proyecto, se deben tomar en cuenta ciertos criterios clave (ver la siguiente Tabla). Estos
criterios forman un conjunto útil para la evaluación y selección de las herramientas para
el desarrollo de los proyectos.

de 39
Tabla 7. Criterios para la evaluación y selección de herramientas para el desarrollo de los proyectos.
CRITERIO DESCRIPCIÓN
OBJETIVOS DEL DESARROLLO
DEL PROYECTO
¿Qué es lo que el producto/servicio lleva a cabo y qué papel juegan el
software, la capacitación, las plantillas y la comunicación en la entrega y
ejecución del producto/servicio?
CARACTERÍSTICAS DEL
PROYECTO Y
ORGANIZACIONALES
Las herramientas de software deben estar acorde a las características y
requerimientos del proyecto, incluyendo su tamaño, duración,
complejidad de las tareas, reportes, asignación de recursos y necesidad
de administrar varios proyectos en la organización
CAPACIDAD TÉCNICA
Se deben considerar las capacidades y características del entorno técnico
actual. Entre las que se encuentran el acceso a Internet, acceso a la
Intranet, poder de computo, acceso a impresoras, conectividad a redes
LAN/WAN, acceso a correo electrónico y la habilidad de compartir
datos con proveedores de servicio externos y teleconmutadores
COMPATIBILIDAD CON LAS
PLATAFORMAS TECNOLÓGICAS
ACTUALES
Para lograr compatibilidad técnica total, es necesario poseer información
detallada de las configuraciones de las plataformas, las capacidades y
limitaciones estructurales, así como de los requerimientos respectivos de
los productos y conjuntos de herramientas a considerar
HABILIDADES DEL PERSONAL Y
DISPONIBILIDAD DE RECURSOS
El desarrollo de proyectos informáticos requiere de cierto
mantenimiento y administración. Estos requerimientos deben
considerarse al evaluar las habilidades y disponibilidad de los recursos
COSTOS DE LAS COMPRAS Y EL
MANTENIMIENTO
Al seleccionar las herramientas para el desarrollo del proyecto, se deben
tomar en cuenta los costos asociados a las pruebas, la evaluación, la
adquisición, el desarrollo, la implementación y el mantenimiento
1.3 LA RELACIÓN ENTRE LOS CINCO ELEMENTOS
Las Figuras 2 a 5 muestran una visión gráfica integral de los cinco elementos. La Figura
2 muestra una situación de equilibrio entre los elementos (pentágono equilátero):
Situación deseable en cualquier desarrollo de proyectos. La región pentagonal muestra la
dificultad del desarrollo de un producto/servicio. Obviamente, es más fácil construir
productos/servicios que se encuentren cerca del centro del pentágono puesto que son
menos complejos. Los productos/servicios sencillos no requieren de toda la capacidad de
los otros cuatro elementos. Si el producto/servicio se aleja del centro, es más complejo y
demanda más recursos de los elementos complementarios.
Personas
Información
ProcesosHerramientas
Producto/Servicio
Figura 2. Relación de los cinco elementos: Equilibrio.

de 39
Las Figuras 3 a 5 muestran que la capacidad necesaria para construir un producto más
complejo puede provenir de diversas combinaciones de mejora en las personas. El
producto/servicio en cada una de las tres figuras tiene la misma complejidad. En cada una
de ellas, el producto/servicio la complejidad se mueve de un nivel bajo a uno más alto. En
la Figura 3, la capacidad necesaria proviene de las personas. Esta capacidad extra se
puede lograr agregando algunos expertos o capacitando al personal. La Figura 4 muestra
que la misma cantidad de capacidad extra puede provenir de una mejora de los procesos
en lugar de las personas. Una forma de agregar esta capacidad es utilizar un modelo de
entregas incremental o comprimiendo los calendarios. La Figura 5 muestra que la
capacidad extra puede provenir de la mejora de las personas y los procesos. Esto se puede
lograr si se agrega un consultor de tiempo parcial, se capacita a algunas personas, se
utiliza un desarrollo rápido de prototipos en una de las partes del desarrollo del
producto/servicio, se utiliza un modelo de entregas incremental en otra de las partes, etc.
Personas
Información
Producto/Servicio
Figura 3. Construcción de un producto/servicio más complejo incrementando la capacidad de las
personas.
Personas
Información
Producto/Servicio
Figura 4. Construcción de un producto/servicio más complejo incrementando la capacidad de los
procesos.

de 39
Personas
Información
Producto/Servicio
Figura 5. Construcción de un producto/servicio más complejo incrementando la capacidad de las
personas y los procesos.
Así, la construcción de un producto/servicio más complejo requiere mayor capacidad de
algún lado, por lo que no se puede desarrollar algo nuevo con las mismas personas y
esperar que algo novedoso ocurra. Se debe mejorar la capacidad de las personas, los
procesos, la información, las herramientas, o todas en su conjunto.
El desarrollo exitoso de proyectos informáticos no es casual. Una forma de incrementar
su frecuencia es lograr la relación apropiada entre los cinco elementos. Dado un
producto/servicio y las personas para construirlo, se deben seleccionar los procesos, la
información y las herramientas apropiadas. De igual forma, dadas las personas con
preferencia por un tipo de procesos y con un cierto tipo de herramientas e información, se
deben construir sólo los productos apropiados.
La capacidad para construir productos/servicios más complejos debe provenir de las
personas, los procesos, la información y las herramientas. Los productos/servicios
específicos requieren de personas con conocimiento en el área de éstos, o hacer algo
diferente con los procesos, la información y las herramientas.
Siempre es recomendable seleccionar personas responsables y disciplinadas que
conozcan el producto/servicio en cuestión y que puedan trabajar en los procesos
utilizando las capacidades de la información y las herramientas. La utilización de un
proceso, información y herramientas permiten a las personas construir el
producto/servicio requerido. Es importante señalar que sólo se deben construir
productos/servicios dentro de las capacidades de las personas, procesos, información y
herramientas.
Por otro lado, no se recomienda utilizar más capacidad de la necesaria para construir un
producto/servicio. Utilizar un experto en redes únicamente para conectar dos
computadoras es un error. Siempre es recomendable pensar en las personas, procesos,
información, herramientas y productos/servicios como algo integral, de forma que se
acoplen unos con los otros. Esto siempre es posible debido a que en desarrollo de un
proyecto siempre existe un cierto nivel de flexibilidad y acoplamiento.

de 39
REFERENCIAS BIBLIOGRÁFICAS
Edman, E. G. The project management analysis companion: Creating and implementing
standards for IT project management. Right Track Associates, Inc. www.ittoolkit.com.
USA, 2001-2002.
McConnell, Steve. Desarrollo y gestión de proyectos informáticos. Microsoft Press,
McGraw-Hill. España, 1998.
McConnell, Steve. Software project survival guide. Microsoft Press, McGrah-Hill. USA,
1998.
Phillips, Dwayne. The software project manager’s handbook. IEEE Computer Society
Press. USA, 1998.
Phillips, Dwayne. People, process, and product.
http://members.aol.com/dwaynephil/CutterPapers/ppp/ppp.htm . Visited August 2003.

de 39
MODULO 1.
2 LOS MODELOS DE MADUREZ DE LA CAPACIDAD
RESUMEN
Esta Sección presenta las dos normas internacionales para el desarrollo de proyectos
asociados a los componentes de Procesos y Personas discutidos hasta el momento. Estos
son, respectivamente:
 El Modelo de Madurez de la Capacidad del Software (S-CMM: The Software
Capability Maturity Model);
 El Modelo de Madurez de la Capacidad de las Personas (P-CMM: The People
Capability Maturity Model).
Ambos modelos son fundamentales para el éxito en el desarrollo de proyectos puesto que
son el resultado de muchos años de experiencia de diversas organizaciones.
Con el fin de introducir ambos modelos, esta sección inicia estudiando cómo una
organización debe madurar cada uno de los cinco elementos. La discusión continúa
explorando las principales características de ambos modelos de madurez antes indicados.
2.1 ANTECEDENTES
Como se discutió en las Subsecciones 1.3 y 1.4, los cinco elementos son fundamentales
para el desarrollo de cualquier proyecto informático. Estos elementos cambian cada vez
que el elemento producto/servicio cambia. Así, la construcción de un producto/servicio
con mayor complejidad implica un incremento en la capacidad de los otros cuatro.
Incrementar la capacidad de los cinco elementos requiere un incremento en la madurez
para administrar cada uno de ellos. Si al inicio de cada proyecto no existe un acuerdo en
un conjunto de pasos para el desarrollo, entonces la madurez para administrar los
elementos del proyecto se encuentra en su nivel más bajo (nivel inicial de madurez). En
este nivel, probablemente se utilice y comparta una terminología común, mientras que el
éxito del proyecto dependerá de los esfuerzos personales y actos heroicos.
Si cada vez que se desarrolla un proyecto éste se lleva a cabo repitiendo un proceso que
resultó exitoso en el pasado, entonces se genera una reducción de riesgos en el desarrollo
y por lo tanto un incremento en el éxito del proyecto. Debido a esto, el nivel de madurez
asociado es conocido como “nivel de madurez repetitivo”.
Por otro lado, si varias de las actividades de desarrollo y los procesos de administración
se encuentran definidos formalmente, están documentados e integrados, entonces el nivel
de madurez se denomina “nivel de madurez definido”.

de 39
Más aún, si se hace énfasis en la importancia de medir cuantitativamente la calidad de los
productos/servicios resultado de cada proceso, fijando metas cuantitativas tanto para
productos/servicios como para los procesos, entonces es nivel de madurez se denomina
“nivel de madurez administrado”.
En el quito nivel de madurez, llamado “nivel de madurez optimizado”, la atención es
puesta en la mejora continua de los procesos a través de identificar pro-activamente sus
fortalezas y debilidades, todo con el propósito de prevenir la ocurrencia de defectos. En
este nivel, la mejora continua es obligatoria en el proceso de desarrollo. En lugar de sólo
corregir los defectos cuando éstos aparezcan, el propósito principal en este nivel es el de
prevenir esos defectos a través de la planeación.
La siguiente Figura es una representación gráfica de los niveles de madurez. En ella se
observa que en el nivel inicial los productos/servicios que podrían ser exitosos son
aquellos con una baja complejidad; mientras que en el nivel optimizado, los
productos/servicios podrían tener una complejidad mucho mayor.
Personas
Información
Producto/Servicio
Nivel de Madurez Inicial
Nivel de Madurez
Repetitivo
Nivel de Madurez Defiido
Nivel de Madurez
Administrado"
Nivel de Madurez
Optimizado
Figura 6. Representación de los niveles de madurez.
El conjunto de niveles de madurez para los procesos de software en una organización se
conoce como “Modelo de Madurez de la Capacidad del Software (S-CMM)”. Este
modelo ha sido desarrollado por el “Software Engineering Institute (SEI)” y se discute en
la Subsección 2.2. Es importante señalar que el S-CMM ha sido creado únicamente para
proyectos de desarrollo de software y no para proyectos informáticos en general.
De igual forma, el SEI ha desarrollado un marco de trabajo para mejorar la forma en que
una organización administra su capital humano, éste se conoce como “People Capability
Maturity Model (P-CMM)”. Este modelo se discute en la Subsección 2.3.

de 39
2.2 EL S-CMM
2.2.1 EL PROCESO DE DESARROLLO DE PROYECTOS DE SOFTWARE
Dentro del contexto de desarrollo de software, el “proceso” define la forma de hacer un
proyecto, los proyectos por lo general producen un producto (software) y un producto es
algo generado para un colega, un empleado, o un cliente.
Esta concepción de “proceso” es de utilidad para alcanzar el éxito del proyecto. Para
lograr este éxito, se deben llevar a cabo los siguientes tres pasos:
 Analizar el proceso actual con el cual la organización ejecuta sus proyectos;
 Determinar las fortalezas y debilidades de el proceso actual;
 Mejorar las fortalezas y remover las debilidades.
Los anteriores, y aparentemente sencillos, pasos han desconcertado a la industria de
software por muchos años. Varias organizaciones de software han adoptado diversas
técnicas para implementarlos con diferentes niveles de éxito. El problema ahora es tratar
de interpretarlos y dominarlos.
La discusión puede ser más puntual si se considera el conjunto de pasos que se sigue al
desarrollar un proyecto de software. En la Tabla siguiente, estos pasos se enuncian y
describen de forma general sin entrar en detalles, ya que estos detalles dependen de la
naturaleza de los proyectos.
Tabla 8. Pasos para desarrollar un proyecto de software.
PASO ACTIVIDADES
1.REQUERIMIENTOS
 El cliente define un conjunto de requerimientos del producto
 La organización discute estos requerimientos con el cliente
 La discusión se centra en remover cualquier ambigüedad, conflicto
o problema relacionado con el producto/servicio
 El resultado de esta discusión será, de forma ideal, un conjunto de
funcionalidades bien definidas que el producto debe cumplir
2.PLANEACIÓN (ESTIMADOS DE
COSTO Y TIEMPO)
 La organización estima y asigna recursos humanos y materiales
 Para facilitar el monitoreo del proyecto, se definen diversos hitos
 Se realizan planes para subrogar (si es necesario) algunas partes
del proyecto
3.DESARROLLO DEL PROYECTO
La organización está lista para iniciar el trabajo de desarrollo del
proyecto
4.MONITOREO CONTINUO
La organización monitorea de forma continua el progreso del proyecto
comparándolo con los hitos definidos en el Paso 2
5.MONITOREO CONTINUO DE
LOS PROVEEDORES
Los proveedores (si existe alguno) son monitoreados para asegurar
que no existan retrasos debido a falta de comprensión del proyecto
6.ASEGURAMIENTO DE LA
CALIDAD DEL SOFTWARE
La organización debe asegurar que el trabajo se lleva a cabo acorde a
las normas y a los requerimientos

de 39
7.ADMINISTRACIÓN DE CAMBIOS
 La organización debe asegurar que todas las partes del proyecto
estén bien coordinadas
 La organización debe determinar si un cambio en una parte del
proyecto requiere cambiar otras partes, y si es así, entonces los
cambios deben ser los apropiados (administración de la
configuración)
Obviamente, las actividades anteriores son ejecutadas de alguna forma u otra en casi
todos los proyectos de software; entonces, ¿qué hace diferir una organización de otra? La
respuesta es sencilla: No todas las organizaciones siguen los pasos con igual rigor. Estos
pasos son muy sencillos de comprender pero extremadamente difíciles de ejecutar de
forma efectiva.
El propósito de la discusión anterior fue el de apreciar la necesidad de trazar un camino a
seguir por las organizaciones para producir software de calidad, dentro de presupuesto y
en los tiempos estipulados. Este camino se denomina S-CMM. Este modelo no es fácil de
comprender, ni mucho menos fácil de implementar de forma exitosa.
2.2.2 COMPONENTES DEL S-CMM
El S-CMM es el resultado de décadas de investigación y estudio de proyectos exitosos y
no exitosos. La filosofía principal del S-CMM es muy similar a la vida misma. Cuando
un niño nace está en su nivel “inicial” de madurez. Cuando el niño crece y aprende,
alcanza un nivel de madurez mayor. Este proceso se extiende hasta que se convierte en un
adulto maduro, aunque su proceso de aprendizaje continúa. De acuerdo al S-CMM una
organización de software sigue (o debería seguir) evoluciones similares de madurez. Es
importante señalar que el S-CMM no es un modelo de ciclo de desarrollo de software. Es
una estrategia para mejorar el proceso de software sin importar el modelo de ciclo de vida
utilizado.
En la Tabla siguiente se presenta una breve explicación de los diversos componentes del
S-CMM. Esta explicación ha sido extraída de los documentos oficiales del SEI (ver las
referencias bibliográficas al final de esta Sección).
Tabla 9. Algunos componentes del S-CMM.
COMPONENTE EXPLICACIÓN
NIVEL DE
MADUREZ
Es una meseta evolutiva bien-definida para lograr un proceso del software maduro.
Los cinco niveles de madurez son la estructura de más alto nivel del S-CMM
CAPACIDAD DEL
PROCESO DE
SOFTWARE
Describe el rango de resultados esperados y que pueden lograrse siguiendo un
proceso del software. Es una forma de predecir los resultados esperados en el
próximo proyecto del software
ÁREAS DE
PROCESOS CLAVES
(KPAS)
Cada nivel de madurez está compuesto de sus propias KPAs. Cada una de ellas
identifica una serie relacionada de actividades que, cuando se ejecutan de forma
colectiva, alcanzan un conjunto de metas consideradas como importantes para
determinar la capacidad del proceso en ese nivel de madurez. Por ejemplo, una KPA
para el nivel 2 es: “Planeación del Proyecto de Software”

de 39
METAS
Las metas resumen las prácticas clave de una KPA y se utilizan para determinar si un
proyecto ha implementado de forma efectiva esta KPA. Las metas definen el alcance,
las fronteras y el propósito de cada KPA. Un ejemplo de una meta para la KPA
“Planeación del Proyecto de Software” es: “Se documentan las estimaciones de
software para ser utilizadas en la planeación y seguimiento del proyecto de software”
CARACTERÍSTICAS
COMUNES
Las prácticas clave están divididas en cinco secciones de Características Comunes:
 Compromiso para el Desempeño
 Habilidad para el Desempeño
 Actividades Desempeñadas
 Medición y Análisis
 Verificación de la Implementación
Estas características son atributos que indican si la implementación e
institucionalización de una KPA es efectiva, repetible y duradera. La característica
común “Actividades Desempeñadas” describe las actividades de implementación,
mientras que las otras cuatro describen los factores de institucionalización que son
parte de la cultura organizacional
PRÁCTICAS CLAVE
Cada KPA está descrita en términos de las prácticas clave, que al implementarlas
ayudan a satisfacer las metas de esa KPA. Las prácticas clave describen la
infraestructura y actividades que contribuyen a la implementación e
institucionalización efectiva de la KPA.
2.2.3 EL MARCO DE TRABAJO DEL S-CMM
El S-CMM es un marco de trabajo que caracteriza un proceso evolutivo de mejora para
lograr una organización más madura. Una organización puede utilizar el S-CMM para
determinar su estado actual de madurez del proceso de software y entonces establecer
prioridades para la mejora. Los estados de madurez pueden ser categorizados como
Inicial, Repetible, Definido, Administrado y Optimizado. Por lo tanto, el S-CMM define
cinco niveles de madurez, descritos brevemente en las siguientes Tabla y Figura.
Tabla 10. Los niveles del S-CMM.
NIVEL DESCRIPCIÓN
1.INICIAL
El proceso de software se caracteriza como ad hoc y frecuentemente caótico. Pocos
procesos están definidos y el éxito depende de los esfuerzos individuales
2.REPETIBLE
Se establecen los procesos fundamentales de la administración de proyectos con el fin
de dar seguimiento a los costos, calendarización y funcionalidad. Se establece una
disciplina para repetir los éxitos pasados en proyectos similares
3.DEFINIDO
El proceso de software para las actividades de administración e ingeniería está
documentado, normalizado e integrado en un proceso normalizado organizacional de
software. Todos los proyectos utilizan un proceso normalizado organizacional
debidamente aprobado e instanciado para desarrollar y dar mantenimiento al software
4.ADMINISTRADO
Existe un conjunto de métricas para el proceso de software y para la calidad del
producto. Tanto el proceso como el producto de software se comprenden y controlan
de forma cuantitativa
5.OPTIMIZADO
La mejora continua del proceso se habilita a través de la realimentación cuantitativa
del proceso, de ideas innovadoras y nuevas tecnologías

de 39
2. Repetible
1. Inicial
3. Definido
4. Administrado
Proceso
disciplinado
Proceso
normalizado y
consistente
Proceso
predecible
Proceso sometido
a mejora continua
Impredecible y
pobremente controlado
Puede repetir tareas
previamente dominadas
Proceso caracterizado
y bien comprendido
Proceso medido
y controlado
Enfocado a la
mejora de procesos
5.Optimizado
Administración
del proyecto
Proceso
integrado de
ingeniería
Calidad de
producto y
proceso
Administración
de cambios
2. Repetible
1. Inicial
3. Definido
4. Administrado
Proceso
disciplinado
Proceso
normalizado y
consistente
Proceso
predecible
Proceso sometido
a mejora continua
Impredecible y
pobremente controlado
Puede repetir tareas
previamente dominadas
Proceso caracterizado
y bien comprendido
Proceso medido
y controlado
Enfocado a la
mejora de procesos
5.Optimizado
Administración
del proyecto
Proceso
integrado de
ingeniería
Calidad de
producto y
proceso
Administración
de cambios
Figura 7. Los cinco niveles de la madurez del proceso de software.
Cada nivel de madurez está compuesto por cinco partes. Con la excepción del nivel 1. La
descomposición de cada nivel comprende desde resúmenes de cada nivel hasta su
definición operacional en las prácticas clave, tal como se muestra en la siguiente Figura.
Cada nivel está compuesto por varias KPAs. Cada KPA está organizada en cinco
secciones denominadas Características Comunes. Éstas últimas especifican las prácticas
clave que, de forma colectiva, hacen que se cumplan las metas de la KPA.
Capacidad
de los procesos
Metas
Implementación o
institucionalización
Infraestructura o
actividades
Niveles de Madurez
Áreas de procesos clave
Características
comunes
Prácticas
clave
Contiene
Organizado por
Contiene
Indica
Cumplen
Dirigidas a
Describen
Capacidad
de los procesos
Metas
Implementación o
institucionalización
Infraestructura o
actividades
Niveles de Madurez
Áreas de procesos clave
Características
comunes
Prácticas
clave
Contiene
Organizado por
Contiene
Indica
Cumplen
Dirigidas a
Describen
Figura 8. Estructura del S-CMM.
La discusión anterior puede causar confusión. El S-CMM es un tema amplio y pocas
líneas no son suficientes para explicarlo del todo. Sin embargo, con el fin de
comprenderlo, el resto de esta Subsección se adentra en los niveles de madurez de
acuerdo a su estructura.

de 39
2.2.4 ÁREAS DE PROCESOS CLAVE (KPAS)
Cada nivel ha sido dividido en KPAs. Para que una organización alcance un cierto nivel
de madurez debe cumplir con todas las KPAs. Puesto que cada organización se encuentra
al menos en el nivel 1, no existen KPAs para este nivel. Esto significa que una
organización no requiere hacer algo para alcanzar el nivel 1. Las KPAs pueden
concebirse como una lista de tareas que una organización necesita ejecutar. Una KPA
contiene un grupo de actividades comunes a ejecutar por la organización para cumplir de
forma total con esa KPA. En la Tabla siguiente se muestra la lista de KPAs para cada
nivel de madurez.
Tabla 11. KPAs del S-CMM.
NIVEL ÁREAS DE PROCESOS CLAVE
1.INICIAL Sin KPAs
2.REPETIBLE
a. Administración de Requerimientos del Software
b.Planeación del Proyecto de Software
c. Seguimiento y Vigilancia del Proyecto de Software
d.Administración de los Proveedores de Software
e. Aseguramiento de la Calidad del Software
f. Administración de la Configuración del Software
3.DEFINIDO
a. Enfoque al Proceso Organizacional
b.Definición del Proceso Organizacional
c. Programa de Capacitación
d.Administración Integrada del Software
e. Ingeniería del Producto de Software
f. Coordinación Intergrupal
g. Revisión de Pares
4.ADMINISTRADO
a. Administración Cuantitativa del Proceso
b.Administración de la Calidad del Software
5.OPTIMIZADO
a. Prevención de Defectos
b.Administración del Cambio Tecnológico
c. Administración del Proceso de Cambio
Por lo tanto, existen 18 KPAs en el S-CMM. Lo que el S-CMM señala acorde a estas
KPAs es: Para que una organización alcance un nivel de madurez óptimo, DEBE cumplir
con las 18 KPAs. No cumplir una o más de ellas implica una inmadurez de la
organización, lo que a su vez resulta en un decremento de la productividad y un
incremento en los riesgos.

de 39
2.2.5 METAS
La única forma en que una organización puede estar segura de que ha cumplido
exitosamente una KPA es alcanzar todas las metas asociadas con esa KPA. En la Tabla
siguiente se muestra la lista completa de METAS asociadas a cada una de las 18 KPAs.
Tabla 12. Metas para cada KPA.
NIVEL KPA META
REPETIBLE
Administración
de
Requerimientos
del Software
 Meta 1: Se controlan los requerimientos del sistema asignados al
software para establecer una línea base para la ingeniería y
administración de software en uso
 Meta 2: Existe consistencia entre los planes, productos y
actividades del software con los requerimientos del sistema
asignados al software
Planeación del
Proyecto de
Software
 Meta 1: Se documentan las estimaciones de software para
utilizarse en la planeación y seguimiento del proyecto de
software
 Meta 2: Se planean y documentan las actividades y compromisos
del proyecto de software
 Meta 3: Se acuerdan los compromisos relacionados al proyecto
de software entre las personas y grupos afectados
Seguimiento y
Vigilancia del
Proyecto de
Software
 Meta 1: Se comparan los resultados y desempeño reales con
respecto a los planes del software
 Meta 2: Se toman y administran acciones correctivas para hacer
el cierre cuando los resultados y desempeño se desvían
significativamente de planes del software
 Meta 3: Se acuerdan los cambios a los compromisos del
software entre las personas y los grupos afectados
Administración
de los
Proveedores de
Software
 Meta 1: El contratista principal selecciona a subcontratistas de
software calificados
 Meta 2: Se acuerdan los compromisos mutuos entre el contratista
principal y los subcontratistas de software
 Meta 3: Se mantienen en comunicación continua el contratista
principal y los subcontratistas de software
 Meta 4: Se da seguimiento por el contratista principal a los
resultados y desempeño reales de los subcontratistas de software
comparándolos con los con sus compromisos
Aseguramiento
de la Calidad del
Software
 Meta 1: Se planean las actividades de aseguramiento de la
calidad del software
 Meta 2: Se verifica de forma objetiva el apego de los productos
y actividades del software a las normas, procedimientos y
requerimientos
 Meta 3: Se mantiene informados a las personas y grupos
afectados de las actividades y resultados del aseguramiento de la
calidad del software
 Meta 4: Se asigna al administrador en jefe los puntos sin cumplir

de 39
y que no pueden ser resueltos dentro del proyecto de software
Administración
de la
Configuración
del Software
 Meta 1: Se planean las actividades de administración de la
configuración del software
 Meta 2: Se identifican, controlan y ponen a disposición los
productos de trabajo de software seleccionados
 Meta 3: Se controlan los cambios a los productos de trabajo de
software identificados
 Meta 4: Se informan a las personas y grupos afectados del estado
y contenido de las líneas base del software
DEFINIDO
Enfoque al
Proceso
Organizacional
 Meta 1: Se coordinan en toda la organización las actividades de
desarrollo y mejora del proceso de software
 Meta 2: Se identifican, con base en un proceso normalizado, las
fortalezas y debilidades de los procesos de desarrollo de
software utilizados
 Meta 3: Se planean las actividades de desarrollo y mejora del
proceso organizacional
Definición del
Proceso
Organizacional
 Meta 1: Se desarrolla y da mantenimiento a un proceso de
software normalizado
 Meta 2: Se recolecta, revisa y hace disponible la información
relacionada a la utilización del proceso de software normalizado
de la organización
Programa de
Capacitación
 Meta 1: Se planean las actividades de capacitación
 Meta 2: Se capacita para el desarrollo de habilidades y
conocimiento necesarios para desempeñar los puestos técnicos y
de administración del software
 Meta 3: Se capacita para que las personas, los grupos de
ingeniería de software y los grupos relacionados al software
desempeñen sus puestos
Administración
Integrada del
Software
 Meta 1: Se hacen ajustes al proceso de software normalizado de
la organización para definir una versión del proceso de software
del proyecto
 Meta 2: Se planea y administra el proyecto acorde al proceso de
software definido para el proyecto
Ingeniería del
Producto del
Software
 Meta 1: Se define, integra y se lleva a cabo de forma consistente
las tareas de ingeniería de software para definir el software
 Meta 2: Se mantienen consistentes entre ellos los productos de
trabajo de software
Coordinación
Intergrupal
 Meta 1: Se acuerdan los requerimientos del cliente por todos los
grupos afectados
 Meta 2: Se acuerdan los compromisos entre los grupos de
ingeniería por los grupos afectados
 Meta 3: Se identifica, da seguimiento y resuelve los aspectos
intergrupales por los grupos de ingeniería
Revisión de
Pares
 Meta 1: Se planean las actividades de revisión por los pares
 Meta 2: Se identifican y remueven los defectos en los productos
de trabajo de software

de 39
ADMINISTRADO
Administración
Cuantitativa del
Proceso
 Meta 1: Se planean las actividades cuantitativas de
administración de procesos
 Meta 2: Se controla cuantitativamente el proceso de desempeño
del proceso de software definido para el proyecto
 Meta 3: Se conoce de forma cuantitativa la capacidad del
proceso del proceso de software normalizado para la
organización
Administración
de la Calidad del
Software
 Meta 1: Se planean las actividades de administración de la
calidad del software del proyecto
 Meta 2: Se definen metas medibles para la calidad del producto
de software y sus prioridades
 Meta 3: Se cuantifica y administra el progreso real a través del
logro de las metas de calidad para los productos de software
OPTIMIZADO
Prevención de
Defectos
 Meta 1: Se planean las actividades de prevención de defectos
 Meta 2: Se buscan e identifican las causas comunes de defectos
 Meta 3: Se priorizan y de forma sistemática se eliminan las
causas comunes de defectos
Administración
del Cambio
Tecnológico
 Meta 1: Se planea la incorporación de cambios tecnológicos
 Meta 2: Se evalúan las nuevas tecnologías para determinar su
efecto en la calidad y la productividad
 Meta 3: Se convierten en practicas normales en la organización
las nuevas tecnologías apropiadas
Administración
del Proceso de
Cambio
 Meta 1: Se planea la mejora continua de procesos
 Meta 2: Se participa a lo largo de la organización en las
actividades de mejora continua del proceso de software
 Meta 3 Se mejoran de forma continua los procesos de software
normalizados de la organización y los procesos de software
definidos para el proyecto
2.2.6 CARACTERÍSTICAS COMUNES
Las KPAs están organizadas en Características Comunes. Éstas son atributos que indican
cuando la implementación e institucionalización de una KPA ha sido efectiva, repetible y
duradera. Las cinco características comunes están descritas en la Tabla siguiente.
Tabla 13. Descripción de la Características Comunes.
CARACTERÍSTICAS
COMUNES
DESCRIPCIÓN
COMPROMISO PARA EL
DESEMPEÑO
Describe las acciones que la organización debe llevar a cabo para asegurar que
el proceso esté establecido y sea permanente. Implica el establecimiento de
políticas organizacionales y patrocinio de la administración
HABILIDAD PARA EL
DESEMPEÑO
Describe las precondiciones que deben existir en el proyecto u organización
para implementar de forma competente el proceso de software. Requiere de
recursos, estructuras organizacionales y capacitación

de 39
ACTIVIDADES
DESEMPEÑADAS
Describe los roles y procedimientos necesarios para implementar una KPA.
Implica el establecimiento de planes y procedimientos, llevar acabo las tareas,
darles seguimiento y tomar acciones correctivas cuando sea necesario
MEDICIÓN Y ANÁLISIS
Describe la necesidad de medir el proceso y analizar las mediciones.
Comprende considerar muestras de mediciones para determinar el estado y
efectividad de las actividades desempeñadas
VERIFICACIÓN DE LA
IMPLEMENTACIÓN
Describe los pasos para asegurar que las actividades se llevan a cabo conforme
al proceso establecido. Implica llevar a cabo revisiones y auditorias
administrativas y asegurar la calidad del software
Las prácticas en las Actividades Desempeñadas describen lo que debe implementarse
para establecer una capacidad el proceso. Las otras prácticas, consideradas como un todo,
forman la base para que una organización pueda institucionalizar las prácticas descritas
en las Actividades Desempeñadas.
2.2.7 PRÁCTICAS CLAVE
Cada KPA está descrita en términos de las prácticas clave que contribuyen a satisfacer
sus metas. Las prácticas clave describen la infraestructura y actividades que contribuyen
a la implementación e institucionalización más efectiva de la KPA.
Cada práctica clave consiste de una única oración, a menudo seguida por una descripción
más detallada, que puede incluir algunos ejemplos y mayor detalle. Estas prácticas clave
establecen las políticas, procedimientos y actividades fundamentales para la KPA. Los
componentes de la descripción detallada se les llaman “subprácticas”. La siguiente Figura
muestra un ejemplo de la estructura de una práctica clave para la KPA Planeación del
Proyecto de Software.
Nivel de madurez:
2, Repetible
Nivel de madurez:
2, Repetible
KPA:
de software
KPA:
de software
Característica común:
Actividades desarrolladas
Característica común:
Actividades desarrolladas
Práctica clave:
Actividad 9. Las estimaciones para el tamaño
de los productos del trabajo de software (o cambios
al tamaño de productos del trabajo de software)
se derivan según un procedimiento documentado
Práctica clave:
Actividad 9. Las estimaciones para el tamaño
de los productos del trabajo de software (o cambios
al tamaño de productos del trabajo de software)
se derivan según un procedimiento documentado
Capacidad del proceso:
Proceso disciplinado
Meta 1:
Se documentan las
estimaciones de software para
utilizarse en la planeación y
seguimiento del proyecto
de software
Implementación o
institucionalización:
Implementación
Infraestructura o
actividades:
Actividad
Indica Contiene
Logra Organizado por
Dirigida a Contiene
Describe
Figura 9. Ejemplo de una práctica clave.

de 39
2.2.8 S-CMM EN LAS ORGANIZACIONES
Muchas organizaciones han implementado exitosamente el S-CMM y han reportado
mejoras considerables en casi todos los aspectos del ciclo de vida del software. Algunas
de estas organizaciones son: Bull HN, GTE Government Systems, Hewlett Packard,
Hughes Aircraft Co., Loral Federal Systems (anteriormente IBM Federal Systems
Company), Lockheed Sanders, Motorola, Northrop, Schlumberger, Siemens Stromberg-
Carlson, Texas Instruments, United States Air Force Oklahoma City Air Logistics Centre,
United States Navy Fleet Combat Direction Systems Support Activity.
S-CMM ayuda a una organización en dos formas:
 S-CMM implementa prácticas que resultan en un incremento en la productividad;
 Trae consigo un cambio inmediato en la cultura y mentalidad de la organización,
lo que implica poder escalar los niveles del S-CMM.
De entre las más de 900 organizaciones que han sido evaluadas por el SEI, la mayoría de
ellas se encuentran dentro de los niveles 1 (34.9%) y 2 (38.2%).
Sin embargo, el recorrido para alcanzar un nivel superior de la madurez del proceso
requiere una cantidad considerable de tiempo y esfuerzo. Los esfuerzos para instrumentar
el S-CMM iniciaron en 1992 y la experiencia ha mostrado que el tiempo requerido para
ascender de un nivel a otro es como sigue:
 Del nivel 1 al nivel 2: 25 meses;
 Del nivel 2 a nivel 3: 22 meses;
 Del nivel 3 al nivel 4: 36.5 meses.
La Tabla siguiente muestra el número de organizaciones que han obtenido los niveles 4 y
5 hasta octubre de 2002.
Tabla 14. Organizaciones en el nivel 4 y 5 del S-CMM.
PAÍS
NÚMERO DE ORGANIZACIONES EN EL NIVEL
4 DEL S-CMM
NÚMERO DE ORGANIZACIONES EN EL NIVEL
5 DEL S-CMM
AUSTRALIA 2
CANADÁ 1
CHINA 2
FRANCIA 1
INDIA 27 50
IRLANDA 1
ISRAEL 1
RUSIA 1
SINGAPUR 1
USA 39 20

de 39
Las ventajas de escalar los niveles del S-CMM son evidentes en un gran número de
organizaciones. Alcanzar un nivel superior implica una mejora en el desempeño
organizacional. Algunos de los beneficios principales que trae consigo el S-CMM son:
 Migración de una administración reactiva a una preactiva;
 Ayuda a construir una fuerza de trabajo hábil y motivada;
 Reducción en los costos en el desarrollo y mantenimiento de los sistemas;
 Reducción en los tiempos de entrega y mejora en la entrega de los requerimientos;
 Mayor satisfacción al cliente;
 Mejora la calidad de los productos de software;
 Induce el robustecimiento;
 Mejora la administración de toma de decisiones;
 Introduce nueva tecnología para crear ventajas competitivas.
Los niveles del S-CMM son como las prescripciones dadas por un médico. De igual
forma que el cumplimiento de las normas sociales son de ayuda para mejorar la calidad
de vida, los criterios de los procesos clave del S-CMM ayudan a la organización a
mejorar sus niveles de madurez. El ascenso de los diferentes niveles hace que se mejore
de forma significativa el desempeño y competencia de la organización.
El S-CMM ayuda a mejorar los procesos de ingeniería de software desde un nivel ad hoc
hasta niveles disciplinados y administrados, ambos apoyados por tecnología actual. Esto
permite que la organización alcance los niveles de madurez desde un punto de vista de
negocios.
De acuerdo a las estadísticas del SEI, cuando el S-CMM se aplica de forma apropiada,
puede (ver también la siguiente Tabla):
 Mejorar la productividad;
 Mejorar los tiempos de puesta en el mercado del producto hasta en un 70%;
 Decremento en los defectos de los productos hasta en un 90%.
Tabla 15. Porcentaje de mejora comparado con los resultados de los niveles previos.
CRITERIOS NIVELES 1 - 2 NIVELES 2 - 3 NIVELES 3 - 4
REDUCCIÓN DE DEFECTOS 12% 40% 85%
REDUCCIÓN EN LOS CICLOS 10% 38% 63%
REDUCCIÓN EN EL COSTO 8% 35% 75%
VARIANZA DE LA CALENDARIZACIÓN 145% 24% 15%

de 39
El S-CMM por si mismo no garantiza que el trabajo realizado sea exitoso. Lo que asegura
es que el trabajo organizacional realizado de una forma ordenada permita predecir los
resultados de este trabajo.
A través de la práctica de los procesos del S-CMM, una organización puede alcanzar
nuevas metas y un incremento en sus perspectivas y alcances.
2.2.9 CONCLUSIÓN
Se puede concluir que el S-CMM ayuda en evaluar los procesos de software de una
organización, así como a identificar los prerrequisitos necesarios para alcanzar un nivel
de madurez de esos procesos. Adicionalmente, traza una ruta que permite mejorar la
administración y desarrollo de los productos de software de una forma ordenada y
disciplinada. Si se aplica de forma adecuada, el S-CMM es un sistema poderoso que
puede ayudar a la transformar a la organización y ayuda a alcanzar su máximo nivel de
desempeño.
2.3 CMM PARA PERSONAS
2.3.1 ANTECEDENTES
Cada empleado de una organización tiene un impacto en la calidad del producto/servicio.
Es imperativo que el nivel de desarrollo del empleado refleje las expectativas de calidad
requeridas. Puesto que los empleados bien capacitados y competentes son una ventaja
estratégica para una organización, ésta debe ver a las actividades de capacitación como
tal.
El Modelo de Madurez de la Capacidad para Personas (P-CMM) también fue
desarrollado por el SEI de la Carnegie-Mellon University en Pennsylvania. El SEI tuvo la
colaboración de representantes de la industria, gobierno, milicia y organizaciones
académicas para diseñar un modelo evolutivo para desarrollar y optimizar la capacitación
y competencia del personal de una organización.
2.3.2 TEMAS
El P-CMM define el éxito en términos de la madurez de una organización. La estructura
del P-CMM demuestra cómo las organizaciones pueden progresar de forma secuencial a
través de niveles de madurez crecientes hasta alcanzar un nivel óptimo de desempeño.
Existen 5 niveles de madurez en el P-CMM, descritos brevemente en la siguiente Tabla.
Tabla 16. Niveles del P-CMM.
NIVEL DESCRIPCIÓN
1.INICIAL No aplica ningún proceso
2.REPETIBLE
Los procesos están enfocados a establecer las prácticas fundamentales para la fuerza
de trabajo y eliminar los problemas que tienden a minimizar el desempeño del trabajo.
El propósito es implementar una disciplina en las actividades de la fuerza de trabajo

de 39
3.DEFINIDO
Los procesos se enfocan a los aspectos organizacionales, ajustando las prácticas de la
fuerza de trabajo a las competencias fundamentales definidas por el entorno. El
propósito es identificar las competencias primarias y alinear las actividades de la
fuerza de trabajo con estas competencias
4.ADMINISTRADO
Los procesos se enfocan en la construcción de competencias basadas en equipos y en
el establecimiento de tendencias para el desarrollo de conocimientos y habilidades,
asó como en la alineación del desempeño a lo largo de los diferentes niveles
organizacionales. El propósito es administrar de forma cuantitativa el crecimiento
organizacional de las capacidades de la fuerza de trabajo y establecer competencias
basadas en equipos
5.OPTIMIZADO
Los procesos cubren aspectos que las personas y las organizaciones deben tomar en
cuenta para implementar la mejora continua en sus capacidades. El propósito es
mejora de forma continua los métodos para el desarrollo del personal y la
competencia organizacional
Existen relaciones que vinculan los niveles de madurez de forma que el progreso pueda
ocurrir siguiendo un conjunto de relaciones. A través de estas relaciones o Temas, la
implementación de los procesos en un nivel de madurez hace que éstos puedan servir
como un fundamento para las prácticas y capacidades en niveles superiores. Los temas
del P-CMM se describen en la Tabla siguiente:
Tabla 17. Temas del P-CMM.
TEMAS DESCRIPCIÓN
CAPACIDADES EN
EL DESARROLLO
La tendencia inicia con la identificación de las necesidades reales de capacitación
dentro de una unidad, avanza hacia la identificación de las competencias
fundamentales y evoluciona a tener individuos que les sea posible establecer sus
propios programas de desarrollo profesional
CONSTRUCCIÓN DE
EQUIPOS Y
CULTURA
La tendencia inicia con el establecimiento de las habilidades de comunicación
básica, continua con el desarrollo de una cultura basada en la participación y avanza
hacia la construcción formal de equipos y la mejora continua de sus capacidades
MOTIVACIÓN Y
ADMINISTRACIÓN
DEL DESEMPEÑO
La tendencia inicia con el establecimiento de prácticas de administración y
compensación del desempeño, continua con la mejora de estas prácticas
adaptándolas al desarrollo de las competencias y a la construcción de equipos. A
partir de este nivel, la tendencia busca optimizar a través de la búsqueda de fuentes
de innovación
MOLDEO DE LA
FUERZA DE
TRABAJO
La tendencia inicia con el establecimiento de prácticas básicas en el personal.
Continua con el desarrollo de planes para el desarrollo de la fuerza de trabajo,
establece y da seguimiento a los objetivos para desarrollar competencias en la
fuerza de trabajo, y entonces busca fuentes de innovación
2.3.3 ÁREAS DE PROCESOS CLAVES (KPAS)
Las KPAs se refieren a tareas y actividades particulares que deben completarse con el fin
de que una organización madure y progrese en la optimización de sus iniciativas de
capacitación. La siguiente Tabla identifica las KPAs apropiadas para cada uno de los
cuatro Temas.

de 39
Tabla 18. KPAs necesarias para cada uno de los cuatro Temas del P-CMM.
NIVELES DE
MADUREZ
TEMAS
DEL P-CMM
TEMA 1:
CAPACIDADES DE
DESARROLLO
TEMA 2:
CONSTRUCCIÓN
DE EQUIPOS Y
CULTURA
TEMA 3:
MOTIVACIÓN Y
ADMINISTRACIÓN
DEL DESEMPEÑO
TEMA 4:
MOLDEO DE LA
FUERZA DE
TRABAJO
NIVEL DE
MADUREZ 5:
OPTIMIZADO
Entrenamiento
Desarrollo de
Competencias del
Personal
Innovación Continua de la Fuerza de Trabajo
NIVEL DE
MADUREZ 4:
ADMINISTRADO
Tutelaje
Construcción de
equipos
Alineación del
Desempeño
Organizacional
Prácticas Basadas
en los Equipos
Administración
de la
Competencia
Organizacional
NIVEL DE
MADUREZ 3:
DEFINIDO
Desarrollo de
competencias
Análisis de
conocimiento y
habilidades
Cultura
participativa
Prácticas Basadas
en la Competencia
Desarrollo
Profesional
Planeación de la
Fuerza de
Trabajo
NIVEL DE
MADUREZ 2:
REPETIBLE
Capacitación
Comunicación
Comunicación
Compensación
Administración del
Desempeño
Entorno Laboral
Adquisición de
Personal
NIVEL DE
MADUREZ 1:
INICIAL
Ninguno
2.3.4 IMPLEMENTACIÓN
La implementación del P-CMM requiere del apoyo y aprobación de las diversas unidades
de la organización. Este modelo no será efectivo si es impuesto o forzado en esas
unidades. Puesto que el modelo es genérico, tiene que ser interpretado e instanciado con
el fin de hacerlo adecuado a la naturaleza de la organización.
Este modelo fue diseñado para proveer de beneficios en cada nivel de madurez, por lo
que no es recomendable saltarse un nivel o desatender las características de los procesos
de un nivel previo. Las salidas de cada nivel sirven de fundamento para las prácticas de
los niveles de madurez subsecuentes, las cuales están descritas en los cuatro Temas del
modelo.
Para ayudar en la interpretación e implementación de este modelo en una organización, el
P-CMM ha identificado los siguientes criterios de aceptación para cada KPA:
 Metas;
 Compromiso para el Desempeño;
 Habilidad para el Desempeño;

de 39
 Actividades Desempeñadas;
 Medición y Análisis;
 Verificación e Implementación.
Como un ejemplo, la siguiente Tabla es la partición para la KPA: Capacitación
Tabla 19. Ejemplo para la KPA: Capacitación.
METAS
COMPROMISO
PARA EL
DESEMPEÑO
HABILIDAD
PARA EL
DESEMPEÑO
ACTIVIDADES
DESEMPEÑADAS
MEDICIÓN
Y ANÁLISIS
VERIFICACIÓN DE
LA
IMPLEMENTACIÓN
Proveer de
capacitación
en las
habilidades
críticas
requeridas en
cada unidad
La
organización
sigue una
política
documentada
para estas
actividades de
capacitación
Dentro de cada
unidad, se asigna
a un responsable
de asegurar que
las actividades de
capacitación se
lleven a cabo
En cada unidad
se identifican
las habilidades
para
desempeñar las
tareas críticas
Dentro de
cada unidad
se hacen
mediciones
para
determinar
el estado de
las
actividades
de
capacitación
Se asigna a un
responsable para
verificar que las
actividades de
capacitación sean
conducidas acorde
a los planes de la
unidad y a las
políticas
documentadas de
la organización
La
capacitación
se lleva a
cabo en los
tiempos
adecuados de
forma que se
puedan
desempeñar
las tareas
Se asigna un
responsable
para ayudar y
colaborar con
las unidades
en las
actividades de
capacitación
Se provee de de
recursos y
financiamiento
para implementar
las actividades de
capacitación
planeadas
Se identifican
las actividades
de capacitación
para cada
unidad
Se
recolectan
y se dan a
conocer las
mediciones
del estado
de la
capacitación
de cada
unidad
Los directivos
revisan
periódicamente las
actividades de
capacitación de la
organización para
determinar si
cumplen con las
políticas
documentadas
Las
oportunidades
de
capacitación
están
disponibles
para todo el
personal
Se destinan
tiempos para la
capacitación a
todo el personal
acordes a las
políticas de
capacitación de
la organización
Cada unidad
desarrolla y da
mantenimiento
a un plan para
satisfacer sus
necesidades de
capacitación
Las personas
responsables de
identificar las
necesidades de
capacitación se
capacitan en
métodos
relevantes a sus
responsabilidades
Las personas
y/o grupos
reciben la
capacitación
necesaria para
llevar a cabo las
tareas asignadas
Los instructores
tienen la
capacitación y/o
requeridas para
Se identifican y
hace
disponibles las
oportunidades

de 39
desempeñar sus
responsabilidades
de capacitación
relevantes para
apoyar el
desarrollo del
personal
Se le da
seguimiento a la
capacitación en
base al plan de
capacitación de
la unidad
Con el fin de ayudar a la interpretación e implementación, el P-CMM provee
descripciones similares detalladas para cada KPA. La aplicación de este sistema pretende
ser una guía para las organizaciones.
El desarrollo del personal en los activos productivos y estratégicos es una iniciativa que
puede dar grandes beneficios a una organización. Para obtener estos beneficios, una
organización debe examinar los diversos procesos y actividades indicadas en el P-CMM,
y determina una estrategia aplicable y apropiada para optimizar el desempeño del
personal.
2.4 REFERENCIAS BIBLIOGRÁFICAS
Bardoloi, Sabyasachi. Quality: A Health Capsule to Retain Growth. Pinnacle Systems,
Inc. ftp://projectperfect.com.au/CMM.pdf. Visited August 2003.
Curtis, Bill, William E. Hefley, and Sally A. Miller. People Capability Maturity Model®
(P-CMM®), Version 2.0. CMU/SEI-2001-MM-01. July 2001. www.sei.cmu.edu. Visited
August 2003.
Hefley, William E. Where Does Team Building Fit As A Component of Mature Software
Development Processes? http://hsb.baylor.edu/ramsower/ais.ac.96/papers/hefley2.htm.
Visited August 2003.
Manzoor, Kashif. CMM – an introduction.
http://homepages.com.pk/kashman/CMMIntro.htm. Visited August 2003.
Paulk, Mark C. Using the Software CMM in small organizations. 1998.
www.sei.cmu.edu. Visited August 2003.
Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability
Maturity Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR-024 ESC-
TR-93-177. www.sei.cmu.edu. February 1993.
Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. The Capability
Maturity Model for Software. www.sei.cmu.edu. February 1993.
Zrymiak, Dan. People - Capability Maturity Model. http://www.msi.ms/MSJ/People-
Capability_Maturity_Model.htm. Visited August 2003.

de 39
MODULO 1.
3 EL PROCESO DE COMUNICACIÓN EN UN PROYECTO
INFORMÁTICO
RESUMEN
La comunicación es la pieza angular de cómo el trabajo se realiza por las diversas partes
dentro de un proyecto. La comunicación no es una tarea fácil y requiere de un gran
esfuerzo de la partes para lograrla.
Con el fin de conocer cómo administrar las comunicaciones en el desarrollo de un
proyecto informático, en lo que sigue se desarrollan dos temas principales: los elementos
de un plan de comunicación y algunas estrategias de comunicación.
3.1 ELEMENTOS DE UN PLAN DE COMUNICACIÓN
Los proyectos informáticos exitosos se obtienen a través de una combinación de acciones
y estrategias efectivas y en momento adecuado. Muy rara vez los proyectos son
completados por una única persona. Muchos de los proyectos informáticos son
completados por un equipo de personas con diferentes roles y responsabilidades.
Dependiendo del tamaño y naturaleza de los proyectos, estos equipos están compuestos,
por una combinación de (ver Sección 1.2.1):
 El equipo del proyecto;
 Los clientes (tanto internos como externos) de los productos/servicios creados;
 Los patrocinadores del proyecto;
 Los actores en el proyecto.
Cada miembro del equipo del proyecto puede tener diferentes niveles de experiencia
técnica y en administración de proyectos. De igual forma, puede tener diferentes actitudes
y opiniones sobre la dirección y metas del proyecto. Mantener a este equipo
completamente informado y trabajando como una unidad es un reto que sólo se puede
cumplir utilizando un conjunto de estrategias de comunicación creativas y prácticas.
Cuando estas estrategias pasan a ser parte de una política y acciones determinadas, se
convierten en un Plan de Comunicaciones del Proyecto, de forma que para lograr
finalizar el proyecto y por obtener el éxito, este plan debe estar presente en proyecto
desde el primer hasta el último día.
Mientras que los detalles de cualquier Plan de Comunicaciones del Proyecto pueden
variar acorde a la complejidad, tamaño y duración, cada plan debe contener al menos tres
elementos fundamentales (ver Tabla siguiente).

de 39
Tabla 20. Elementos fundamentales a ser considerados en cualquier Plan de Comunicaciones.
ELEMENTO FUNDAMENTAL SIGNIFICADO
PROPÓSITO Son las metas de comunicación del proyecto (formales e informales)
MÉTODOS Son los mecanismos y formatos para las comunicaciones del proyecto
FRECUENCIA La duración y la frecuencia de las actividades formales de comunicación
Con estas metas en mente, un Plan de Comunicaciones del Proyecto puede ser útil para
varios propósitos clave:
 Asegurar que la información importante llegue a las partes correctas de forma
oportuna;
 Identificar y resaltar los problemas vía los reportes de estado y los calendarios;
 Generar ánimo y entusiasmo en el proyecto;
 Facilitar la toma de decisiones y el control de cambios;
 Proveer un proceso específico para la realimentación y la resolución de conflictos;
 Asegurar la transición adecuada al cierre del proyecto;
 Resaltar y facilitar el trabajo en equipo, la cooperación y la colaboración.
3.2 ESTRATEGIAS DE COMUNICACIONES
Para iniciar la planeación de cualquier estrategia de comunicaciones, se debe primero
considerar los requerimientos específicos del proyecto en cuestión. El enfoque de la
planeación de las comunicaciones variará acorde a las necesidades del proyecto, su
complejidad y tamaño. Por ejemplo, las actividades de comunicaciones formales tendrán
mayor significado a largo plazo en la organización del proyecto que una iniciativa
específica y dirigida a un grupo pequeño de participantes.
Existen cuatro variables clave para la planeación que deben ser consideradas en el
desarrollo de estrategias de comunicaciones apropiadas:
 Características y Requerimientos del Proyecto;
 Requerimientos de Comunicaciones;
 Capacidades Técnicas;
 Consideraciones del Personal.
3.2.1 CARACTERÍSTICAS Y REQUERIMIENTOS DEL PROYECTO
Para crear un Plan de Comunicaciones realista y efectivo, primero se deben considerar los
requerimientos y características del proyecto en cuestión. Cada proyecto tiene su propia
personalidad, formada por una combinación de varios factores clave. Con el fin de
facilitar y planear las comunicaciones efectivas del proyecto, se debe considerar las
necesidades presentadas por cada uno de los factores enunciados en la Tabla siguiente.

de 39
Tabla 21. Factores clave para cada proyecto.
FACTOR CLAVE DESCRIPCIÓN
TIPO DE PROYECTO
El tipo específico de proyecto a completar (i.e., migración, aplicación, desarrollo,
reasignación, etc.)
TAMAÑO DEL
PROYECTO
El número de fases y tareas comprendidas
DURACIÓN ESPERADA La longitud del proyecto
RIESGOS DEL
PROYECTO
El grado de riesgo para los negocios y para la organización patrocinadora
COMPLEJIDAD
TÉCNICA
El número de sistemas involucrados y el grado de complejidad de la solución
técnica
ORGANIZACIÓN DEL
PROYECTO
El tamaño y estructura de los recursos de la organización requeridos para
completar y dar soporte al proyecto
COSTOS Y
PRESUPUESTOS
El costo del proyecto en términos de los entregables del proyecto
VALOR DEL NEGOCIO El valor y significado del proyecto para los negocios
Los proyectos complejos y costosos con una duración sustancial y con altos riesgos
requieren de mayor atención a los detalles, y por ende requieren de programas de
comunicación mayores. Por otro lado, los proyectos pequeños y sencillos dependerán de
la comunicación para su éxito, sin embargo esa comunicación será menos estructurada y
más informal.
3.2.2 REQUERIMIENTOS DE COMUNICACIONES
Cuando se analizan los requerimientos de comunicaciones del proyecto, se deben
considerar dos elementos primarios:
 Las partes involucradas en el proyecto. ¿Con quién se requiere comunicación?
 El propósito de las comunicaciones. ¿Con quién es necesario comunicarse?
Al explorar la primera de estas preguntas, es necesario ir más allá del nombre y el título;
y considerar una perspectiva más amplia, considerando roles, responsabilidades, políticas
y requerimientos de comunicaciones.
Las siguientes preguntas se pueden utilizar como guía a través de este proceso analítico:
 ¿Quién tiene un especial interés en el proyecto, ya sea en términos de los procesos
o los resultados?
 ¿Quién tiene la información y experiencia para colaborar?
 ¿Quién tiene la responsabilidad funcional del proyecto y sus resultados?
 ¿Quién debe tomar las decisiones en el proyecto?

de 39
 ¿Quién tiene la autoridad para aprobar asignación de recursos y compras?
 ¿Quién se beneficiaría de la participación u observación (i.e., para el desarrollo
del personal)?
 ¿Quién debe estar involucrado desde una perspectiva organizacional o política?
Habiendo considerado a las partes, ahora es necesario revisar el propósito de las
comunicaciones: ¿Cuáles son las metas de las comunicaciones y cómo se pueden alcanzar
estas metas?
La siguiente Tabla lista y define los siete elementos de la comunicación en los proyectos,
diseñados para ayudar en la evaluación de las necesidades de comunicación de acuerdo a
su “propósito”.
Tabla 22. Análisis de los requerimientos de comunicaciones: El propósito.
ELEMENTO DE COMUNICACIÓN
DEL PROYECTO
PROPÓSITO
COMUNICACIONES GENERALES
Mantener informados a todos los participantes de las actividades y
eventos del proyecto
REPORTES DE ESTADO
Mantener informados al equipo y a los actores en el proyecto de la
información que permita implementar acciones de planeación y
acciones correctivas
ADMINISTRACIÓN DE REUNIONES Planear y calendarizar reuniones de trabajo efectivas y productivas
ELEMENTOS DE
ADMINISTRACIÓN
Organizar y dar seguimiento a los aspectos técnicos y operacionales
ESCALAMIENTO DE PROBLEMAS Dar seguimiento y escalar los problemas y retrasos
ADMINISTRACIÓN DE LA
REALIMENTACIÓN
Proveer de mecanismos para una realimentación efectiva
ADMINISTRACIÓN DE CAMBIOS
Permitir y facilitar la comunicación y control de las solicitudes de
cambio en el proyecto
Como se observa en esta Tabla, las comunicaciones pueden tener diversas metas, algunas
de ellas pueden ser más importantes que otras dependiendo de la naturaleza del proyecto
y de las partes involucradas. Al momento de planear las estrategias de comunicaciones,
es necesario tener presente la siguiente pregunta: ¿De los siete elementos, cuáles deben
estar en el Plan de Comunicaciones del Proyecto, y en qué grado y proporción?
La respuesta determinará el marco de trabajo del plan resultante. Dependiendo del
proyecto, se pueden ocupar los siete elementos en diferentes proporciones. Como ya se
señaló, la comunicación es una combinación compleja de factores que resultan en un Plan
de Comunicaciones que varía de proyecto en proyecto.

de 39
3.2.3 CAPACIDADES TÉCNICAS
La comunicación efectiva es un elemento clave para el éxito del proyecto. Para mantener
a todas las partes informadas y tener relaciones positivas de trabajo, se debe utilizar en su
máxima extensión cada mecanismo disponible para la llevar a cabo la comunicación. Los
sistemas de comunicación proveen de medios técnicos a través de los cuales se distribuye
la información del proyecto, se reporta el progreso y se solicita y adquiere la
realimentación.
Para desarrollar estrategias efectivas de comunicaciones, se deben conocer la
disponibilidad y las capacidades de estos sistemas. Basados en el entorno personal, las
herramientas de comunicación pueden ser entre otras:
 Software de administración de proyectos;
 Correo electrónico;
 Foros de discusión y GrupWare;
 Sistemas de calendarización;
 Conferencias telefónicas;
 Videoconferencias;
 Comunicaciones inalámbricas;
 Sitios Web.
Al momento de planear las estrategias y actividades de comunicaciones, es necesario
considerar la disponibilidad de los diversos sistemas de comunicación, además de como
se pueden utilizar para cumplir las metas del proyecto tomando como base las
características y los requerimientos de comunicaciones del proyecto.
3.2.4 CONSIDERACIONES DEL PERSONAL
Aunque las compensaciones y resultados sean deseados, las actividades de
comunicaciones formales del proyecto requieren de tiempo y esfuerzo tanto en términos
de planeación como en el de ejecución. Por lo tanto, al planear estas actividades y
estrategias es importante tomar en cuenta la calendarización, restricciones de recursos y
toda la carga de desarrollo del proyecto. Será necesario balancear los requerimientos de
información con respecto a las actividades de comunicación reales, tales como el reporte
del estado y la participación en las reuniones de trabajo.
Las actividades de reporte del estado no debe interferir con las actividades reales del
proyecto, y siempre debe tomarse en cuenta el tiempo invertido en las reuniones y en la
preparación de reportes.
3.3 CONCLUSIONES
Los planes de comunicaciones efectivos nacen de un balanceo cuidadoso de las
necesidades, los requerimientos, las capacidades técnicas, y los aspectos del personal del
proyecto.

de 39
Cada uno de éstos elementos se pueden combinar de diferentes formas de acuerdo a las
circunstancias cambiantes del proyecto y los negocios. Sin embargo, si se utiliza un
proceso estructurado para la revisión de requerimientos y la planeación de las
comunicaciones, estos elementos pueden analizarse e identificarse si es necesario, y ser
utilizados como el fundamento con el cual se construyen los planes de comunicaciones
(ver la siguiente Figura).
Coordinador
del proyecto
Los clientes, patrocinadores
o el director de proyectos
proveen dirección
y financiamiento
Los miembros del equipo del
proyecto y los proveedores
requieren de liderazgo,
planeación y coordinación
Los administradores de otras
áreas, los coordinadores de
otros proyectos y el personal
requieren de coordinación y
de apoyo en la negociación
Los directivos proveen
de apoyo y estímulo
organizacional
Comunicación
informal
Comunicación
formal
Dirección y
clarificación
Reportes de
progreso
Reportes de progreso
y previsión
Directivas
del proyecto
Políticas de la
organización
Reportes de
estado y previsión
Dirección del
proyecto
Reportes
de estado
Figura 10. Canales de comunicación del proyecto.
REFERENCIAS BIBLIOGRÁFICAS
Edman, E. G. The IT Project Communications Planner: Communications Strategies for
Information Technology Projects. Right Track Associates, Inc. www.ittoolkit.com. USA,
2001-2002.
Project Management Institute. A guide to the project management body of knowledge:
PMBOK Guide. 2000 Edition. www.pmi.org. Visited August 2003.

Fundamentos para el desarrollo de proyectos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Fundamentos para el desarrollo de proyectos

Similar a Fundamentos para el desarrollo de proyectos (20)

Más de Alejandro Domínguez Torres

Más de Alejandro Domínguez Torres (20)

Fundamentos para el desarrollo de proyectos