Gestión de Proyectos Informáticos y de

Comunicación

Sesión 1.- Introducción y ciclo de

vida de los proyectos

Mg. Juan Carlos Oviedo Bejar

Objetivos de aprendizaje

1 Entender la importancia de la gerencia de

proyectos

2 Explicar que es la gerencia de proyectos y sus

elementos clave

Conocer los errores clásicos en proyectos

3 respecto de las personas, procesos, productos
y tecnología
¿Qué pasa con los proyectos?

Gerencia de proyectos

Ciclo de vida de proyectos

Procesos de dirección de proyectos

Errores clásicos
 ¿Qué es un proyecto?

PRODUCTO O
ESFUERZO TEMPORAL CREAR
SERVICIO UNICO
¿Qué es un proyecto?
Definición

- Es una combinación de - Un propósito único

recursos en un tiempo - Es temporal
determinado,
generalmente para una - Uso de múltiples
organización y para recursos
lograr un propósito - Debería contar con un
específico patrocinador o un cliente
- Crea un producto, principal
servicio o un resultado. - Incertidumbre

Atributos
¿Cuándo iniciar un Proyecto?
Crear, mejorar Cumplir
o reparar requisitos
productos, regulatorios,
procesos o legales o
servicios sociales

Proyecto

Implementar o Satisfacer las

cambiar las solicitudes o
estrategias de necesidades
negocio o de los
tecnológicas interesados
Proyecto
La triple restricción de la gerencia
de proyectos
Una visión expandida de las “3
restricciones”
Alcance

Calidad Costo

Riesgo tiempo

Satisfacción al
cliente
 Información sobre la gerencia de
proyectos
• Sólo el 55% de los proyectos finalizan cumpliendo
el presupuesto inicial del proyecto( PMI’s Pulse of
the Profession, 2015)

• Tom Peters nos dice: “Para ganar hoy debemos

dominar el arte de la gerencia de proyectos”

• 50% de los proyectos fallan por mala

comunicación interna (América Economía, 2015)
 Información sobre la gerencia de
proyectos
• Más de 16 millones de personas están
involucradas en proyectos en el mundo

• Solamente el 16.2% de los proyectos

fueron exitosos

• El 31% fueron cancelados antes de su

terminación, costando 81 billones de
dólares
Fuente: Chaos
Ventajas de la gerencia de
proyectos
Mejor control financiero, físico y recursos humanos

Mejora la relación con los clientes

Reduce lo tiempos de desarrollo

Reduce los costos

Mejora la calidad y la confiabilidad

Mayores márgenes

Mejora la productividad

Mejora la coordinación interna

Mejora el ambiente de trabajo

Portafolio de proyectos
¿Qué es gerencia de proyectos?

Es la aplicación de conocimientos,
habilidades, herramientas a las actividades
de los proyectos para satisfacer los
requerimientos de los proyectos

Los gerentes de proyectos trabajan para

satisfacer la triple restricción
10 áreas de gerencia de proyectos
Las áreas describen las competencias claves que
todo gerente de proyectos debe desarrollar:
• 4 áreas principales de conocimiento principales para
lograr los objetivos (Gestión del alcance, tiempo, costo,
calidad)

• 5 áreas de apoyo como medio por el cual los objetivos

son logrados (Gestión de recursos humanos,
comunicación, riesgo, compras, interesados)

• 1 área de integración
 Grupos de Interés
Gente involucrada en el proyecto o es afectada por
sus actividades, incluye:
Sponsor

Opositores Gerente
del del
proyecto proyecto

Grupos
de
Interés
Proveedores Equipo

Usuarios Clientes
Relación entre los interesados y el proyecto
Herramientas y técnicas de gestión
de proyectos
Acta de
constitución

Definición del
Ruta crítica, etc.
alcance

Estimación de
EDT
tiempos

Diagrama de
Gantt
“Super- herramientas”
Son las herramientas que tiene un alto uso y alto
impacto en el éxito del proyecto, tales como:
• Reporte de lecciones aprendidas
• Software
• Definición del alcance
• Reporte de los avances
• Requerimientos de cambios
• Diagrama de Gantt
¿Qué ayuda a tener éxito en los Proyectos?
Apoyo de la alta Compromiso del Experiencia del
gerencia usuario gerente de proyectos

Claros objetivos de Infraestructura

Objetivos Reales
negocios estándar de Sw y Hw

Otros criterios como

hitos, apropiado plan,
Metodologías Estimaciones
equipo competente,
formales confiables
adueñarse del
proyecto
¿Qué hacen los ganadores?

Utilizar herramientas y técnicas de la

gerencia de proyectos (muchas
plantillas por ejemplo).

Dan énfasis en el negocio

Desarrollan un proceso simple de

gerencia de proyectos

Miden la salud del proyecto

utilizando métricas como satisfacción
del cliente, retorno de la inversión
Sugerencias para los gerentes de proyectos

Deben tener Entender las

una serie de organizaciones
habilidades donde trabajan

Adecuarse a
los cambios

Ser capaz de
guiar al equipo
a cumplir los
objetivos del
proyecto
Las 10 habilidades y competencias de los gerentes de
proyectos

Habilidades Capaz de
Capaz de
para llegar a Liderazgo Integridad construir
escuchar
la gente confianza

Pensamiento Pensamiento
Entender y
Habilidad de Gestión de crítico, crítico,
balancear
comunicación conflicto solucionar solucionar
prioridades
problemas problemas
Diferentes habilidades en diferentes situaciones

• Liderazgo, experiencia, planeamiento, manejo de

Proyectos Grandes gente, comunicación, “team building” son los más
importantes

Proyectos altamente • Gestión de riesgos, gestión de las expectativas,

liderazgo, manejo de gente, habilidades de
inciertos planeamiento son los más importantes

• Liderazgo, manejo de gente, visión, confianza, manejo

Proyectos novedosos de las expectativas, habilidades de escuchar son los
más importantes
Estructura del ciclo de vida
Organización
Inicio y
preparación

Ejecución

Cierre
Costos y dotación de personal
durante el ciclo de vida del proyecto
Inicio Organización Ejecución Cierre
y preparación
Nivel de costo y personal

Salidas de la Acta de Plan de Entregables Documentos

gestión de constitución Dirección del Aceptados del Proyecto
proyectos Proyecto Aceptados

Tiempo
Impacto de los interesados, riesgos y la
incertidumbre
Alto

Influencia de los
interesados,
riesgo e incertidumbre
Nivel

Costo de los
cambios

Bajo

Tiempo
Fases del proyecto
Son las divisiones dentro del mismo proyecto, donde es
necesario un control adicional con el fin de gestionar
eficazmente la conclusión de un entregable mayor.

Las fases pueden completarse de manera secuencial, pero en

determinados casos de un proyecto pueden superponerse.

La estructuración de fases permite la división del proyecto en

subconjuntos lógicos para facilitar su dirección, planificación y
control.
Proyecto de una sola fase
Proyecto de tres fases
Activos de los procesos de la organización

Son algunos o todos los

activos relativos a procesos de
alguna o todas las
organizaciones participantes en Estos activos contemplan
el proyecto que puedan planes, políticas,
utilizarse para influir en el éxito procedimientos y lineamientos,
de un proyecto. formales e informales.
Procesos de la organización
Procesos y procedimientos
• Procesos estándar de la organización
• Lineamientos, instrucciones de
trabajo, etc.
• Lineamientos y criterios para adaptar
el conjunto de procesos
• Requisitos de comunicación de la
organización
• Lineamientos del cierre del proyecto
• Procedimientos de control financiero
• Procedimientos para la gestión de
problemas y defectos
• Procedimientos de control de cambios
• Procedimientos de control de riesgos
• Procedimientos para priorizar, aprobar
y emitir autorizaciones de trabajo.
Base corporativa del
conocimiento
• Base de datos para la medición de
procesos
• Archivo de proyectos
• Información histórica y bases del
conocimiento de lecciones aprendidas
• Base de datos sobre la gestión de
problemas y defectos
• Base del conocimiento de la gestión
de la configuración
• Base de datos financieros que
contienen informaciones como horas
de trabajo, costos incurridos,
presupuestos y déficit presupuestario.
Procesos de Dirección de
Proyectos
Procesos de dirección de proyectos
El grupo de procesos de la gestión
de proyectos
Procesos de Proceso de
iniciación Planificación

Procesos de control Procesos de ejecución

Procesos de cierre
 Grupos de procesos de la dirección
de proyectos

PROCESOS DE MONITOREO Y CONTROL

PLANIFICACIÓN
PROCESO

EJECUCÓN
INICIO PROCESO FIN

PROCESO
PROCESO
PROYECTO DE INICIO DE CIERRE PROYECTO
 Define y refinan los objetivos y
preparan el plan de Gestión del
Integran a la gente y
Proyecto con la mejor alternativa
otros recursos para
de acción para lograr los
Define y llevar a cabo el plan
objetivos y el alcance que el
autorizan un de gerencia del
proyecto o fase debe realizar
proyecto o proyecto para un
fase proyecto o fase

INICIO PLANIFICACIÓN EJECUCIÓN

SEGUIMIENTO Y
CIERRE
CONTROL

Formalizan la aceptación Miden y supervisan

regularmente el avance a fin de
del producto, servicio o
identificar las variaciones
resultado y lleva al respecto del plan de gestión del
proyecto, o a una fase, a un proyecto, de tal forma que se
final deseado. tomen medidas correctivas
cuando sea necesario.
Grupo de procesos que interactúan en
una fase o proyecto
Procesos de Iniciación
Procesos de Iniciación

Compuesto por aquellos procesos realizados

para definir un nuevo proyecto o una nueva fase
de un proyecto existente al obtener la
autorización para iniciar el proyecto o fase.

Dentro de los procesos de inicio, es donde se

define el alcance, se comprometen los recursos
financieros iniciales, se identifican los
interesados internos y externos, y si no ha sido
nombrado se selecciona al director del proyecto.
Propósito
Alinear las expectativas de los
interesados con el propósito del
proyecto.

Dar visibilidad sobre el alcance y los

objetivos.

Mostrar cómo su participación en el

proyecto y sus fases asociadas puede
asegurar el logro de sus expectativas.
Procesos de Planificación
Compuesto por aquellos
procesos realizados para
establecer el alcance total
del esfuerzo, definir y refinar
los objetivos y desarrollar la
línea de acción requerida
para alcanzar los objetivos.
Desarrollan el plan para la
dirección del proyecto y los
documentos del proyecto
que se utilizarán para llevarlo
a cabo.
Beneficios

Resulta sencillo conseguir la

aceptación y participación de los
interesados.

Trazar la estrategia y las tácticas,

como la línea de acción o ruta
para completar con éxito el
proyecto o fase.
Procesos de Ejecución

Compuesto por aquellos procesos realizados

para completar el trabajo definido en el plan para
la dirección del proyecto a fin de cumplir con las
especificaciones del mismo.

Implica coordinar personas y recursos, gestionar

las expectativas de los interesados, así como
integrar y realizar las actividades del proyecto
conforme al plan para la dirección del proyecto.
Procesos de Monitoreo y Control

Compuesto por aquellos procesos

realizados para establecer el Desarrollar la línea de acción
alcance total del esfuerzo, definir requerida para alcanzar los
y refinar los objetivos. objetivos.
Procesos de Monitoreo y Control

Compuesto por aquellos procesos requeridos

para rastrear, analizar y dirigir el progreso y el
desempeño del proyecto, para identificar
áreas en las que el plan requiera cambios y
para iniciar los cambios correspondientes.

El beneficio de este proceso es que el

desempeño del proyecto se mide y se analiza
a intervalos regulares y como consecuencia
de evento determinados condiciones de
excepción.
Procesos de Monitoreo y Control
Controla los cambios y
recomienda acciones
correctivas o preventivas para
anticipar posibles problemas.

Monitorear las actividades del

proyecto, comparándolas con el
plan para la dirección del
proyecto y con la línea base
para la medición del
desempeño del proyecto.

Influir en los factores que podrían

eludir el control integrado de
cambios o la gestión de la
configuración, de modo que
únicamente se implementen
cambios aprobados.
Procesos de Cierre
Compuesto por aquellos procesos
realizados para finalizar todas las
actividades a través de todos los
grupos de procesos de la
dirección de proyectos.
Verifica que los procesos
definidos se han completado
dentro de todos los Grupos de
Procesos a fin de cerrar el
proyecto o una fase del mismo y
establece formalmente que el
proyecto o fase del mismo ha
finalizado.
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel

Motivación débil o mediocre
Motivación débil
• Estudio tras estudio se ha mostrado que la motivación
probablemente tiene mayor efecto sobre la productividad y la
calidad que ningún otro factor.

Personal mediocre
• Después de la motivación la capacidad individual de los
miembros del equipo, así como sus relaciones como equipo,
probablemente tienen la mayor influencia en la
productividad.
Empleados problemáticos incontrolados

• Un fallo al tratar con personal problemático también

amenaza la velocidad de desarrollo.

• Un fallo al tomar una decisión cuando se trata con un

empleado problemático es una de las quejas mas
comunes que tienen los miembros del equipo respecto de
sus responsables.
Añadir más personal a un proyecto
retrasado
Esta es quizás el mas clásico de
los errores clásicos.
Cuando un proyecto se alarga,
añadir mas gente puede quitar
mas productividad a los miembros
del equipo existente de la que
añaden los nuevos miembros.
Fred Brooks compara añadir
gente a un proyecto retrasado
con echar gasolina en un fuego
Oficinas repletas y ruidosas

La mayoría de los desarrolladores consideran sus condiciones

de trabajo como insatisfactorias. Alrededor del 60% indican
que no tienen suficiente silencio ni privacidad
Fricciones entre los clientes y los
desarrolladores
Las fricciones entre los clientes y los desarrolladores
pueden presentarse de distintas formas. A los clientes
puede parecerles que los desarrolladores no
cooperan cuando rehúsan comprometerse con el
plan de desarrollo que desean los clientes o cuando
fallan al entregar lo prometido.

A los desarrolladores puede parecerles que los

clientes no son razonables porque insisten en planes
irreales o cambios en los requerimientos después de
que estos hayan sido fijados.

En el caso medio, las fricciones entre clientes y

desarrolladores de software llegan a ser tan severas
que ambas partes consideran la cancelación del
proyecto.
Expectativas poco realistas
Una de las causas mas
comunes de fricciones entre
los desarrolladores y sus
clientes o los directivos son las
expectativas poco realistas
Una inspección de Standish Group
marcó las expectativas realistas
como uno de los cinco factores
principales necesarios para
asegurar el éxito de los proyectos
internos de software de gestión
(Standish Group, 2013)
Falta de un patrocinador efectivo del
proyecto
Para soportar muchos de los aspectos del
desarrollo rápido es necesario un promotor del
proyecto de alto nivel, incluyendo una
planificación realista, el control de cambios y la
introducción de nuevos métodos de desarrollo.

El consultor Australiano Rob Thomsett afirma

que la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto.
Falta de participación de stakeholders

Falta de participación de los Falta de participación del usuario: La

implicados: Todos los principales inspección de Standish Group descubrió
participantes del esfuerzo de desarrollo que la razón numero uno de que los
de software deben implicarse en el proyectos de Sistemas de Información
proyecto. Incluyendo a los promotores, tuviesen éxito es la implicación del
ejecutivos, responsables del equipo, usuario.
miembros del equipo, personal de
ventas, usuarios finales, clientes y
cualquiera que se juegue algo con el
proyecto.
Política antes que desarrollo
• Larry Constantine indicó que si hay cuatro equipos. Hay cuatro
tipos diferentes de orientaciones políticas.
• Los políticos están especializados en la gestión, centrándose en
las relaciones con sus directivos. Los investigadores se centran en
explorar y reunir información.
 Ilusiones

• Cuantas veces hemos escuchado cosas como

estas a distintas personas: “Ninguno de los
miembros del proyecto cree realmente que
pueda completarse el proyecto de acuerdo
con el plan que tiene, pero piensan que
quizás se trabajan duro, y nada va mal, y
tienen un poco de suerte, serán capaces de
concluir con éxito.”.
• Las Ilusiones no son sólo optimismo.
Realmente consisten en cerrar los ojos y
esperara que todo funcione cuando no se
tienen las bases razonables para pensar que
será así. Las Ilusiones al comienzo del
proyecto llevan a grandes explosiones al
final. Impiden llevar a cabo una planificación
coherente y pueden ser la raíz de más
problemas en el software que todas las otras
causas combinadas.
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel

 Planificación excesivamente optimista:
Fijar un plan excesivamente optimista
predispone a que el proyecto falle por Gestión de riesgos insuficientes
infravalorar el alcance del proyecto,
minando la planificación efectiva y Si no ejercemos una gestión activa de los
reduciendo las actividades criticas para el riesgos, con que solo vaya mal una cosa se
desarrollo, como análisis de requerimientos pasara de tener un proyecto con un
o el diseño. desarrollo rápido a uno con un desarrollo
También supone una excesiva presión para lento. El fallo de no gestionar uno solo de
los desarrolladores, quienes a largo plazo estos riesgos es un error clásico.
se ven afectados en su moral y su
productividad.
Fallo de los contratados
• Las empresas a veces contratan la realización de partes de
un proyecto cuando tienen demasiada prisa para hacer el
trabajo en casa. Pero los contratados frecuentemente
entregan su trabajo tarde, con una calidad inaceptable o que
falla al no coincidir con la especificación.
• El problema no esta en el abandono del plan, sino mas bien
en fallar al no crear un plan alternativo, y caer entonces en el
modo de trabajo de codificar y corregir.

Planificación insuficiente
• Si no planificamos para conseguir un desarrollo rápido, no
podemos esperar obtenerlo.
Abandono de la planificación bajo presión
• Los equipos de desarrollo hacen planes y rutinariamente
los abandonan cuando se tropiezan con un problema en
la planificación.
• El problema no está en el abandono del plan, sino mas
bien en fallar al no crear un plan alternativo, y caer
entonces en el modo de trabajo de codificar y corregir.

Pérdida de tiempo en el inicio difuso

• El inicio difuso es el tiempo que trascurre antes de que
comience el proyecto; este tiempo normalmente se
pierde en el proceso de aprobar y hacer el presupuesto.
Escatimar en las actividades iniciales
• Los proyectos que se aceleran intentando acortar las
actividades no esenciales, y puesto que el análisis de
requerimientos, la arquitectura y el diseño no producen
código directamente, son los candidatos fáciles.

Diseño inadecuado
• Un caso especial de escatimar en las actividades
iniciales es el diseño inadecuado. Proyectos acelerados
generan un diseño indeterminado, no asignando
suficiente tiempo para él y originando un entorno de alta
presión que hace difícil la posibilidad de considerar
alternativas en el diseño.
Escatimar en el control de calidad
• En los proyectos que se hacen con prisa se suele cortar
por lo sano, eliminando las revisiones del diseño y del
código, eliminando la planificación de las pruebas y
realizando solo pruebas superficiales.
• Acortar en un día las actividades de control de calidad al
comienzo del proyecto probablemente supondrá de 3 a
10 días de actividades finales .Esta reducción va contra
la velocidad de desarrollo.

Control insuficiente de la directiva

• Poco control de la directiva para detectar a tiempo los

signos de posibles retrasos en el plan, y los pocos
controles definidos al comienzo se abandonan cuando el
proyecto comenzó a tener problemas. Antes de encarrilar
un proyecto, en primer lugar debemos ser capaces de
decir si va por buen camino.
Convergencia prematura o excesivamente
frecuente
• Bastante antes de que se haya programado entregar un
producto, hay un impulso para preparar el producto para
la entrega, mejorar el rendimiento del producto, imprimir
la documentación final, incorporar entradas en el
sistemas final de ayuda, pulir el programa de instalación,
eliminar las funciones que no van a estar listas a tiempo
y demás.

Omitir tareas necesarias en la estimación

• Si la gente no guarda cuidadosamente datos de

proyectos anteriores, olvida las tareas menos visibles,
pero son tareas que se han de añadir. El esfuerzo
omitido suele aumentar el plan de desarrollo en un %20
o %30.
Planificar ponerse al día más adelante
Un tipo de estimación es responder inapropiadamente al retraso del plan. Si
hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres
meses en llegar al hito correspondiente a los dos meses, ¿Que hacer? En
muchos proyectos simplemente se plantea recupera el retraso mas tarde,
pero nunca se hace.
Otro tipo de error en la reestimación se debe a cambios en el producto. Si el
producto que estamos construyendo cambia, la cantidad de tiempo
necesaria para construirlo cambiara también.
Errores clásicos que se comenten en los
proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel

Exceso de Requerimientos
• Algunos proyectos tiene mas requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como
requisito mas a menudo de lo que es necesario, y puede
generar una planificación del software innecesariamente
larga.

Cambio de las prestaciones

• Incluso si hemos evitado con éxito los requerimientos
excesivos, los proyectos sufren como media sobre un %25
de cambios en los requerimientos a lo largo de su vida .
• Un cambio de este calibre puede producir un aumento en el
plan de al menos %25, lo que puede ser fatal para los
proyectos de desarrollo rápido.
Desarrolladores meticulosos
Los desarrolladores encuentran fascinante la nueva tecnología, y a veces
están ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o
por crear su propia implementación de una utilidad bonita que han visto
en otro producto, la necesite o no su producto. El esfuerzo requerido para
diseñar, implementar, probar, documentar o mantener estas prestaciones
innecesarias alarga el plan.
Tiras y aflojas en la negociación
• Cuando un directivo aprueba un retraso en el plan e un proyecto que
progresa mas lento de lo esperado, y entonces añade tareas
completamente nuevas después de un cambio en el plan, se produce una
situación curiosa.
• La razón subyacente de esto es difícil de localizar, puesto que el directivo
que aprueba el retraso en el plan lo hace sabiendo implícitamente que el
plan estaba equivocado. Pero una vez que se corrige, la misma persona
realiza acciones explicitas para volver a equivocarse. Esto solo puede ir en
contra del plan.
Desarrollo orientado a la
investigación

Seymour Cray, el diseñador de los supercomputadores Cray, dijo

que no intentaba sobrepasar los limites de la ingeniería en mas de
dos áreas a la vez, por que el riesgo de fallo es demasiado alto.

Si el proyecto fuerza los limites de la informática por que necesita la

creación de nuevos algoritmos o de nuevas técnicas de
computación, no estamos desarrollando software; estamos
investigando en software. Los planes de desarrollo de software son
razonablemente predecibles; los planes en la investigación sobre
software ni siquiera son predecibles teóricamente.
Errores clásicos que se comenten
en los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel

Síndrome de la panacea
Cuando un equipo de proyecto se aferra solo a una nueva
técnica, una nueva tecnología o un proceso rígido, y espera
resolver con ello sus problemas de planificación, esta
inevitablemente equivocado.

Cambiar de herramientas a mitad del proyecto

Es un viejo recurso que funciona raramente. A veces puede
tener sentido actualizar incrementalmente dentro de la misma
línea de productos, de la versión 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de
aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva,
normalmente anulan cualquier posible beneficio.
Sobreestimación de las ventajas del empleo de nuevas
herramientas o métodos

Las organizaciones mejoran raramente su

productividad a grandes saltos, sin importar cuantas
nuevas herramientas o métodos empleen o lo buenos
que sean.

Los beneficios de las nuevas técnicas son

parcialmente desplazados por las curvas de
aprendizaje que llevan asociadas, y aprender a
utilizar nuevas técnicas para aprovecharlas al máximo
lleva su tiempo.

Un caso especial de sobreestimaciones de las

mejoras se produce cuando se reutiliza código d e
proyectos anteriores. Este tipo de reutilización puede
ser una técnica muy efectiva, pero el tiempo que se
gana no es tan grande como se espera.
Cambiar de herramientas a mitad
del proyecto
Es un viejo recurso que funciona raramente. A veces puede tener sentido
actualizar incrementalmente dentro de la misma línea de productos, de la
versión 3 a la 3.1 o incluso a la 4. Pero cuando estamos a la mitad de un
proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables
errores cometidos con una herramienta totalmente nueva, normalmente
anulan cualquier posible beneficio.
Falta de control automático del
código fuente
Un fallo en la utilización del control automático del código fuente
expone a los proyectos a riesgos innecesarios. Sin el, si dos
desarrolladores están trabajando en la misma parte del programa,
deben coordinar su trabajo manualmente. Deberían ponerse de
acuerdo para poner la ultima versión de cada archivo en el
directorio maestro y verificarlos con los demás antes de copiarlas
en este directorio. Pero invariablemente alguno sobrescribirá el
trabajo del otro.

Se desarrolla nuevo código con interfaces desfasadas, y después

se tiene que re-diseñar el código al descubrir que se ha utilizado
una versión equivocada de la interfaz.
Como media, los cambios en el código fuente suelen ser de un
%10 al mes y con un control manual del código fuente no deberían
crecer.