13/11/2018 Using Project Management Principles to Manage Small Projects

Mini y micro proyectos

¿son los principios de gerencia de proyectos aplicables a pequeñas empresas o pequeños
proyectos? = Mini and micro projects: are the principles of project management
appropriate for managing small companies or small projects?

CONFERENCE PAPER ǀ Quality Management ǀ 2007

Rincon, Ivan Daniel

How to cite this article:

Rincon, I. D. (2007). Mini y micro proyectos: ¿son los principios de gerencia de proyectos aplicables a pequeñas empresas o pequeños proyectos?
= Mini and micro projects: are the principles of project management appropriate for managing small companies or small projects? Paper
presented at PMI® Global Congress 2007—Latin America, Cancún, Mexico. Newtown Square, PA: Project Management Institute.

Extracto
Not all projects are big projects; better yet, small companies usually have very small projects. There is a general agreement on how to manage
big and complex project, but what about those small ones that can make a difference? This presentation will show the general principles applied
in some small and medium IT and software development companies to manage projects between 8 and 120 hours of work and it will also show
that accepted PM principles like the ones proposed in the PMBOK® are a very effective tool to keep those projects under control.

Resumen
No todos los proyectos son grandes; más aún, las compañías pequeñas y medianas usualmente ejecutan pequeños proyectos. Existe un acuerdo
general acerca de cómo manejar proyectos grandes y complejos. Sin embargo, ¿qué sucede con aquellos pequeños proyectos que pueden hacer
la diferencia? Esta presentación mostrará principios generales extractados de pequeñas y medianas compañías y tecnología y desarrollo de
aplicaciones para administrar proyectos entre 8 y 120 horas, y demostrara cómo los principios de gerencia de proyectos presentados en el
PMBOK® proporcionan excelentes herramientas para mantener este tipo de proyectos bajo control.

Una historia corta, Capítulo 1

Advertencia: Esta es una historia ficticia. Cualquier similitud con personas, compañías o proyectos reales es pura coincidencia.

“Hola José”, saludo mi jefe, “tu eres uno de nuestros mejores gerentes de proyecto y sé que tienes algún tiempo libre en tu agenda”. Me senté en
su escritorio para escuchar su petición. “El área de Mercadeo acaba de comprar esta aplicación para ayudarles a mantener bajo control sus
campañas y necesitamos a alguien que esté pendiente de la instalación del paquete. No requiere de mayor trabajo pues es una de esas
aplicaciones ya empaquetadas, la instalación es muy sencilla y no esperamos mayores requerimientos. Te pido tu ayuda porque el VP de
Mercadeo esta un poco preocupado y se sentiría mejor si asignamos a alguien para que supervise el proceso.” Después de unos segundos, mi
procesador de gerente de proyectos empezó a trabajar y pregunté: “¿Tenemos las especificaciones técnicas del software? ¿Tenemos el servidor?
¿La aplicación estará en red o estará en el escritorio de alguien en mercadeo?” (Demasiadas preguntas, pensé en silencio). Mi jefe sonrió y me
dijo: “Todo está arreglado, es un proyecto insignificante”. Yo contesté: “Esta bien; hablaré con Mercadeo.” Mi suerte estaba echada.

¿Existen pequeños proyectos?

Los gerentes de proyecto tienden a pensar en un proyecto de forma diferente al resto de los miembros del equipo que lo integra. Tal vez por
razones históricas, los proyectos se ven como grandes esfuerzos para producir un producto o servicio único. Cuando se usa la palabra “proyecto”,
el adjetivo “grande” casi siempre se asocia a él. Sin embargo, el PMBOK en su definición de proyecto no menciona nada acerca del tamaño del
mismo. Sólo menciona que es un “esfuerzo temporal”.

Asumamos, como parte de la discusión, que los proyectos son “grandes esfuerzos” por definición. Parece muy apropiado establecer una serie de
fases muy bien estructuradas, las cuales toman cierto tiempo para ser completadas. Adicionalmente, es obvio que deben usarse procesos muy
estructurados para asegurar el éxito del proyecto. Todo el contenido del PMBOK está creado bajo la premisa de que un proyecto bien manejado
tiene todo el tiempo requerido para completar algunos, si no todos, los procesos. O al menos, ésa es la impresión.

Si eliminamos este supuesto y decimos que existen esfuerzos temporales donde, o bien el tiempo es un recurso escaso o bien el proyecto mismo
es de corta duración, la situación cambia radicalmente. ¿Será que este proyecto necesita la aprobación de los ejecutivos? ¿Será que el gerente de
proyecto debe planificar las tareas? ¿Será que estas tareas deben ser controladas? ¿Es necesario que el gerente de proyecto evalúe los riesgos? La
respuesta a todas estas preguntas debería ser sí. Las temáticas tras cada una de ellas son parte del cuerpo de conocimiento de la gerencia de
proyectos y sí, todas ellas son importantes. En una palabra: el concepto de proyecto no puede estar limitado en el tiempo; así pues es posible
hablar de pequeños proyectos.

https://www.pmi.org/learning/library/project-management-principles-manage-small-projects-7168 1/5
13/11/2018 Using Project Management Principles to Manage Small Projects
Si aún existe alguna sombra de duda acerca de la existencia de pequeños proyectos, es muy sencillo adicionar otra dimensión a la discusión:
recursos. ¿Tienen todas las compañías equipos de proyectos dedicados a ellos? ¿Tienen suficientes recursos para asignar cada uno de ellos a un
único proyecto o para manejar y ejecutar múltiples proyectos a la vez? La respuesta claramente es NO. Como resultado, ¿están las pequeñas
compañías condenadas a desarrollar sus esfuerzos tipo proyecto en una forma que afecte su habilidad de crear excelentes productos o servicios?
No debería ser así. Incluso las compañías muy pequeñas deberían poderse beneficiar de un cuerpo de conocimiento bien concebido en el área de
gerencia de proyectos. Por supuesto, sus proyectos serán mas pequeños que aquellos de las grandes compañías, pero este hecho no debería ser
una desventaja en el mundo de los negocios. Las pequeñas compañías muy probablemente ejecutarán pequeños proyectos.

Un ejemplo real de pequeños proyectos

Durante los años de explosión de Internet, una pequeña compañía se encontró con el predicamento típico de la época: la velocidad lo es todo.
Docenas de compañías con los mismos modelos de negocio estaban luchando por sus ciber-compradores en todo el mundo. Necesitaban hacer
las cosas rápido. “Cosas” llamadas proyectos. Y entonces la burbuja explotó. Esta compañía fue muy afortunada de poseer un buen modelo de
negocios que le permitió sobrevivir a la debacle mundial de las punto-com. Todos pensaron que la presión había pasado y que las cosas podían
hacerse ahora más despacio; había más tiempo para pensar, actuar y salir al mercado. Pero estaban equivocados.

En la medida en que los usuarios de Internet se hacían más exigentes, la situación para las empresas que sobrevivieron a la catástrofe cambió
dramáticamente. Las pocas que quedaron TENÍAN que ser excelentes, tenían que innovar, tenían que demostrar que eran merecedoras de la
lealtad de sus clientes. Proyectos pequeños y rápidos eran la norma y no la excepción. Y estos proyectos eran tan pequeños que el concepto de
gerencia no estaba siendo aplicado.

Por lo general, las áreas de negocio generaban una idea para un nuevo producto. Alguien (en ocasiones, el mismo usuario, y en otras, un
desarrollador) creaba un “alcance” y escribía los “requerimientos”. Estos requerimientos eran entregados a un desarrollador o un equipo de
desarrolladores quienes programaban y entregaban el producto final, usualmente en producción. Allí era validado por las áreas de negocio (por
supuesto, si había problemas, los usuarios finales los veían antes de que los detectara la gente en la compañía) y el proyecto se cerraba.

Considerando los productos que eran entregados como fueron concebidos, la tasa de éxito era, por supuesto, muy baja. Debido a que no existían
métricas, era imposible saber qué tan grave era el problema, pero todos sabían que se estaba haciendo peor en la medida que esos pequeños
proyectos aumentaban.

Cuando una nueva administración llegó a la empresa, era obvio que, para poder sobrevivir, algo tenía que hacerse y rápido. La primera etapa fue
separar las áreas de negocio de los aspectos técnicos del proyecto. Desde la perspectiva de la gerencia de proyectos, una de las entradas más
importantes de cualquier proyecto es el caso de negocio y los objetivos del proyecto, usualmente reflejados en los documentos de iniciación del
mismo. Al separar a la gente de negocio de la responsabilidad técnica del mismo (asociada, por ejemplo, con los requerimientos), fue evidente
que se necesitaba que alguien manejara realmente a los equipos que ejecutaban los proyectos. Estas personas serían responsables de dar el
alcance al proyecto y hacer lo necesario para entregarlo a tiempo y dentro del presupuesto.

La segunda mejora se estableció al dar a los proyectos un tamaño específico. La compañía decidió usar una medida estándar tipo “prenda de
vestir”. Los proyectos fueron clasificados entonces como grandes, medianos y pequeños. Los grandes proyectos eran llamados “proyectos”, los
medianos fueron llamados “mini-proyectos”, y los pequeños “micro-proyectos”. Un micro-proyecto era un proyecto cuyo estimado era entre 8 y
40 horas de trabajo, un mini-proyecto tenía entre 40 y 120 horas de trabajo y un proyecto era un esfuerzo mayor.

Una propuesta
La aproximación propuesta en el ejemplo anterior ha probado ser muy efectiva en situaciones similares. Con base en datos obtenidos de
experiencias personales y sesiones de trabajo con áreas de negocio y gerentes de proyecto de pequeñas y medianas organizaciones, es posible
llegar a plantear un modelo práctico (muy cercano a un marco de referencia) para manejar pequeños proyectos. (Nota: Los rangos 8-40 y 40-120
fueron usados porque tenían sentido en el contexto de esta compañía. El mérito de estos números no será discutido en este documento. Sin
embargo, cada compañía debe encontrar sus propios números en la medida que apliquen los principios generales). La clasificación de micro y
mini proyectos se mantiene, pues existen diferencias muy importantes en estos dos sub-tipos de proyectos.

Ciclo de vida del proyecto

Tal y como lo propone el PMI (Project Management Institute, 2004, p 23), cada proyecto debe tener una fase inicial, intermedia y final, y la
ejecución de procesos de gerencia de proyectos es especifica a cada uno de ellos. Dado que muchas compañías tienen que ejecutar proyectos
pequeños y muy ágiles, ¿es esto posible?

Mini-Proyectos
El ciclo de vida típico de los mini-proyectos comienza cuando una idea es presentada por los ejecutivos de negocio. Los ejecutivos califican estas
ideas en una variedad de factores (impacto inmediato en la satisfacción de los clientes, crecimiento de los ingresos, reducción de costos, riesgos,
fuente de la idea, etc.). Una vez que las ideas son priorizadas, se les asignan espacios de tiempo para ser ejecutadas. Estos espacios de tiempo
están directamente relacionados con consideraciones de negocio y con disponibilidad de recursos. El paso final de este proceso previo es la
creación de un documento llamado la “visión”; éste se puede asimilar a un “alcance de negocio” y se le llama el documento del “por que” (¿por
qué queremos hacer este proyecto?). Para un mini-proyecto, este documento no debe tener más de dos o tres páginas de longitud. Es un
documento que se correlaciona muy bien con el resultado de la fase inicial propuesta por el PMI.

En este punto, el proceso cae en manos de un gerente de proyecto. Incluso si la organización no tiene una asignación formal para este cargo, es
importante que alguien tenga el rol de gerente del proyecto. Un gerente de proyecto puede tener en un momento dado varios pequeños
proyectos. Cuando el gerente del proyecto recibe el documento (firmado por los ejecutivos, por supuesto) que describe el por qué, su primera
tarea consiste en crear un documento llamado el “qué” (¿qué es lo que queremos construir?). Este documento es el alcance del proyecto y puede
contener algunos de los componentes típicos de un documento de alcance de un proyecto más grande. Cuando el documento es aprobado

https://www.pmi.org/learning/library/project-management-principles-manage-small-projects-7168 2/5
13/11/2018 Using Project Management Principles to Manage Small Projects
(usualmente por las áreas de negocio involucradas o el gerente del producto), se inicia la ejecución. Una vez que el proyecto se completa, existe
un cierre formal (basado en una valuación de calidad del producto) y el producto se entrega a operaciones. Estas fases también son muy similares
a las fases intermedia y de cierre del ciclo de vida del proyecto propuesto por el PMI.

Micro-Proyectos
Bajo el modelo propuesto, un micro-proyecto es cercano a una semana de trabajo. Es muy difícil lograr pasar por todo el ciclo de vida en tan
corto tiempo. Una posibilidad es usar principios de Administración Total de la Calidad (TQM, por sus siglas en Inglés). El área de negocio
responsable de la definición y el desarrollo del producto crea una idea en borrador (usualmente una mejora o adición a un producto existente) en
conjunto con todos los afectados. Esta idea se presenta entonces en forma de un requerimiento (alcance). Por definición, el alcance ya está
firmado por las áreas de negocio. El requerimiento es entonces presentado al gerente del proyecto quien es responsable (junto con los recursos
técnicos requeridos) de revisarlo y encontrar cualquier zona gris. Una vez que las dudas son resueltas, el gerente de proyectos asigna las tareas a
los recursos, usando alguna herramienta de seguimiento de tareas, y hace el seguimiento del desarrollo. Por experiencia, el número de tareas
requeridas no debería superar a 10. El ciclo de vida de este tipo de proyectos, desde la idea inicial hasta la entrega del producto desarrollado, es
cercano a las dos semanas (asumiendo que existen los recursos para ejecutar el trabajo).

Ésta es claramente una aproximación diferente a la propuesta por el PMI. Sin embargo, es una propuesta lógica dado que los micro-proyectos no
están orientados a revolucionar la manera en que la compañía hace negocios sino a realizar mejoras incrementales en sus productos. Sin
embargo, incluso en estos casos, el rol del gerente de proyecto es instrumental en el éxito final del trabajo realizado.

Procesos de la gerencia de Proyectos aplicados a pequeños proyectos

Una vez que se ha definido el ciclo de vida del proyecto, el siguiente problema es encontrar cuánta gerencia de proyectos es necesaria para que
éste sea exitoso. Usando el PMBOK® como guía, es posible encontrar una aproximación práctica: qué elementos deben ser utilizados y cuáles
deben ser abandonados o probados en el contexto de la empresa para saber si son útiles o no.

Mini-Proyectos
El gerente de proyecto es claramente responsable por su ejecución. Esto significa que, bajo cualquier circunstancia, se requiere cierto grado de
control del mismo. En un mini-proyecto, es evidente que el gerente del mismo debe crear el alcance y el plan del proyecto, controlarlo,
monitorearlo y administrar los controles de cambio. En un mini-proyecto, se requiere crear un alcance formal y un WBS básico. Estos elementos
deben ser socializados con los recursos, especialmente los líderes técnicos, quienes usualmente pueden proporcionar información valiosa en esta
etapa.

Para poder crear un WBS, se genera una secuencia Entregable > Tareas > Sub-tareas, basada en el consenso experto del alcance. En esta etapa,
una herramienta que permita estructurar ideas disímiles (MindManager®, por ejemplo) puede resultar muy útil. De esta forma, se puede llegar a
un acuerdo rápido acerca de los entregables y los criterios de aceptación del mini-proyecto. No se recomienda el uso de herramientas de
administración de proyectos, ya que la sobrecarga de trabajo para documentar la plantación es muy grande.

Para definir las actividades, realizar el secuenciamiento y desarrollar un cronograma, el equipo del proyecto puede usar una metodología similar a
la utilizada en el Scrum: la planeación de un “sprint”. (El sprint se define como un intervalo de tiempo definido e inmodificable dentro del cual se
realizan ciertas actividades). Dado que el proyecto debe ser completado en menos de 120 horas, se planean pequeños hitos (usualmente cada
dos semanas). Usando la secuencia generada en el paso anterior, el equipo extracta las actividades relacionadas con los entregables y lista las
tareas en orden de prioridad. Aquellas con mayor prioridad serán desarrolladas primero y las de menor prioridad son almacenadas en un
“backlog”. El backlog se visita en la siguiente reunión de planeación. Si se presenta un control de cambios y se generan nuevas tareas
(entregables), el proceso se repite con el fin de priorizar, de manera objetiva, las tareas existentes. Las dependencias son analizadas en este paso
y, de esta manera, se crea un cronograma de trabajo. En este proceso, es de vital importancia contar con la opinión de los dueños del producto,
por lo cual se recomienda que asistan a las reuniones de planeación y den su opinión en cuanto a la prioridad de las tareas. Estas actividades son
almacenadas en una herramienta de control de tareas y las actividades se secuencian de manera que se ejecuten antes del final del hito.

Como parte de este proceso, se realiza también una reunión de estimación. En esta reunión, cada entregable es analizado y se le asigna un tiempo
de ejecución “ideal”. Como parte de la historia del proyecto, el tiempo real es anotado y la correlación entre el tiempo “ideal” y el tiempo “real”
se extracta para ser usada en futuros proyectos.

El control del cronograma se realiza de dos maneras diferentes: por un lado, el gerente de proyecto es responsable de mantenerlo actualizado
pero cada miembro del equipo de trabajo es responsable de actualizar su propia lista de tareas y anotar el tiempo utilizado. La herramienta de
seguimiento debe permitir funciones de reporte por recurso y por hito, de tal manera que se puedan encontrar las fuentes de retraso y efectuar
procesos de recuperación muy efectivos.

Como parte de este proceso, un miembro del equipo de control de calidad es asignado desde el inicio del proyecto y debe crear el plan de control
de calidad del proyecto. Todo este proceso debe ser considerado dentro del esfuerzo requerido.

Los mini-proyectos usualmente funcionan mejor con equipos de trabajo pequeños. Incluso se ha encontrado que el uso de equipos virtuales es
muy efectivo. Los miembros del equipo virtual están asignados a áreas funcionales, pero la asignación de los recursos es realizada por el gerente
de proyecto con base en las habilidades y necesidades del proyecto. De esta manera, un recurso está usualmente asignado a varios mini-
proyectos simultáneamente, haciendo un uso efectivo de su tiempo en función de su capacidad profesional. Es responsabilidad del gerente o los
gerentes de proyecto que este recuso no esté sobre-asignado.

La comunicación es una de las áreas de mayor preocupación en los pequeños proyectos. Los documentos son parte integral del proyecto y,
dentro del cronograma, siempre se debe presupuestar el tiempo para crearlos. Una herramienta muy poderosa que ha demostrado ser útil en este
tipo de ambientes es el concepto de un “wiki” donde los documentos son almacenados de una manera abierta pero efectiva y, por definición, son
creados por la persona responsable pero mantenidos por el equipo del proyecto. Otra herramienta útil en el proceso de comunicación son las
reuniones cortas y efectivas (conocidas en ciertas metodologías como “scrum meetings”). Éstas son reuniones de 15 minutos (usualmente de pie
y en un área abierta) donde cada miembro del equipo cuenta su avance de las ultimas 24 horas, qué espera hacer en las siguientes 24 horas y, lo

https://www.pmi.org/learning/library/project-management-principles-manage-small-projects-7168 3/5
13/11/2018 Using Project Management Principles to Manage Small Projects
más importante, si existe alguna circunstancia inesperada o perniciosa que afecte el progreso del proyecto. Estas reuniones diarias se
complementan con una reunión semanal de 30 minutos con los clientes del proyecto en la cual se informan los progresos y se toman las
decisiones requeridas.

Se han dejado fuera de esta discusión los procesos de costo, riesgo y administración de contratos. Usualmente, estos procesos no aportan mayor
valor agregado al producto final en pequeños proyectos. Sin embargo, el gerente de proyecto debe estar muy vigilante en estas áreas y detectar
cualquier anormalidad que pueda afectar el desarrollo del proyecto. Si la organización considera que alguna de estas áreas es de gran
importancia, se deben seguir las políticas existentes al respecto. Por ejemplo, en el área de gobierno, se deben tener en cuenta los aspectos
legales de la contratación.

Micro-Proyectos
Los micro-proyectos tienen una aproximación completamente diferente. Como se explicó anteriormente, las áreas de negocio responsables crean
el alcance. Debido a su corta vida, realmente no se usan los procesos descritos. Sin embargo, debe haber un gerente de proyecto a cargo de la
ejecución. La principal razón es que no es inusual que los recursos asignados a estos micro-proyectos estén también asignados, al mismo tiempo,
a proyectos y mini-proyectos. En consecuencia, los gerentes de proyecto tienen un interés específico en que estos proyectos sean ejecutados y
entregados a tiempo.

La práctica más común es que las tareas requeridas para completar un micro-proyecto se deben incluir como parte de una planeación y deben
tener una prioridad asignada. De esta manera, los recursos tienen un tiempo garantizado para poder ejecutar lo necesario para entregar el
producto final. Para algunas personas (por supuesto, contradiciendo de manera clara la definición de un proyecto comúnmente aceptada), los
micro-proyectos se convierten en proyectos de duración infinita con un grupo de tareas incrementales que entregan pequeños resultados o
mejoras a productos cada cierto tiempo. Esta aproximación ha demostrado ser altamente efectiva.

Los Resultados
El uso de este marco de trabajo para mini y micro proyectos ha sido adoptado por varias compañías de tecnología y desarrollo de software en
todo el mundo en los últimos dos o tres años, con algunas variaciones menores. A pesar de que no se ha hecho una investigación formal para
documentar las mejoras, algunos estimativos informales colocan la tasa de eficiencia (definida como un proyecto entregado dentro de un rango
definido de fechas, asociadas a un sprint, unos hitos, más o menos unos días) cercana al 95%.

La efectividad de este marco también lleva a mejorar el número de mejoras que se pueden entregar en el producto en un tiempo determinado.

Lecciones Aprendidas
Como es de esperarse en compañías que ejecutan pequeños proyectos, la curva de aprendizaje es un poco dolorosa pero los resultados han
probado que el esfuerzo lo vale. Éstas son algunas de las lecciones compartidas por empresas que han seguido este proceso de adopción:

Propiedad del proyecto: Incluso los proyectos más pequeños requieren algún grado de propiedad y responsabilidad. Un balance adecuado
entre el gerente de proyecto y las áreas de negocio es clave cuando no se tienen muchos recursos y el tiempo es un factor importante.
Hay que mantener las cosas simples y prácticas: Los principios básicos de gerencia de proyectos pueden ser aplicados a cualquier proyecto,
sin importar su tamaño. Sin embargo, las organizaciones deben ser muy cuidadosas de no generar un ambiente desproporcionado para la
gerencia de pequeños proyectos. Debe usarse aquello que genera valor, nada más ni nada menos.
Herramientas: Incluso las herramientas que aparentemente son muy sencillas dentro del portafolio de ofertas para la gerencia de proyectos,
son demasiado complejas para mini y micro proyectos. Se recomienda investigar este aspecto. Existen herramientas de código abierto muy
interesantes. También resulta útil buscar herramientas con funcionalidades específicas (seguimiento de tareas, por ejemplo) como su gran
fortaleza.
No se asusten al tratar de innovar: Es evidente que un marco de trabajo como el propuesto no sigue una metodología específica, sino ciertas
líneas de pensamiento (excepto, por supuesto, los principios básicos propuestos por el PMI). Si hay algo que, tomando elementos de diversas
metodologías, tiene sentido para las áreas de negocio y el tipo de proyectos que se ejecutan, será bienvenido. Los mejores resultados
aparecen dos o hasta tres iteraciones posteriores al primer intento de colocar las piezas juntas.
Soporte ejecutivo: No hay manera de que un proceso, un estándar o una práctica sean exitosos si el equipo ejecutivo no se involucra de
manera temprana. Especialmente, si el equipo ejecutivo es pequeño, encontrar el mensaje adecuado y mostrar resultados va a generar un
soporte inmediato en toda la organización.

Una historia corta, Epílogo

“Afortunadamente,” me contaba después José, “no creí todo lo que me dijo mi jefe”. “Cuando fui a hablar con mercadeo, me comentaron que la
aplicación no había sido probada en los computadores de la compañía y que alguien les había dicho que era muy probable que no funcionara por
algún requerimiento técnico. Decidí volver a hablar con mi jefe.” Puesto que José es un excelente gerente de proyectos, hizo que mercadeo
firmara un documento de una página donde se describía qué era lo que ellos esperaban al final del proyecto, habló con el departamento de TI y
averiguó cómo era el proceso para instalar una nueva aplicación; contrató entonces un recurso externo para que hiciera una evaluación técnica
de la herramienta y especificara los cambios requeridos en las estaciones de trabajo; logró que el fabricante entrenara a los usuarios en mercadeo
y documentó el proceso para futura referencia. En dos semanas, mercadeo tenía su aplicación instalada y en funcionamiento. José, su jefe, el área
de mercadeo y el equipo de TI de la compañía vivieron felices para siempre…

Cohn, M. (2005) Agile estimating and planning. New York, NY: Prentice Hall PTR.

Gorchels, L. (2003) The product manager's field guide: practical tools, exercises and resources for improved product management. New York, NY:
McGraw-Hill.

Middleton, P., Sutton J. (2005) Lean Software Strategies. New York, NY: Productivity Press.

Phillips, J. (2004) IT project management: On track from start to finish. Emeryville, CA: McGraw-Hill/Osborne.

https://www.pmi.org/learning/library/project-management-principles-manage-small-projects-7168 4/5
13/11/2018 Using Project Management Principles to Manage Small Projects
Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2004 ed.). Newton Square, PA: Project
Management Institute.

Rakos, J. (2005) The practical guide to project management documentation. Hoboken, NJ: John Wiley & Sons.

Rowe, S. (2006) Project management for small projects. New York, NY: Management Concepts.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited.
For permission to reproduce this material, please contact PMI or any listed author.
© 2007, Ivan Daniel Rincon
Originalmente publicado como parte de las Actas del Congreso Global del PMI de 2007 – Cancún, Mexico

Related Content
ARTICLE ǀ Quality Management ǀ 1 October 2018

Project Management Journal

Reconciling the Views of Project Success
By Davis, Kate ǀ This article presents a new model encompassing all the important critical attributes needed to measure project
success across different stakeholder groups. The study investigates the possibility…

ARTICLE ǀ Quality Management, Team Building ǀ 1 October 2018

PM Network
External Influence
PM Network asks the project management community: How do you ensure outside talent quickly aligns to the project's strategic
objectives?

ARTICLE ǀ Quality Management, Complexity ǀ 1 October 2018

PM Network
Cloud Formation
By Garza, Amelia ǀ Organizations have been migrating to cloud services for a while. But many are still working to improve project
outcomes.

ARTICLE ǀ Quality Management, Innovation, Complexity ǀ July 2018

PM Network
Pocket Change
By Fister Gale, Sarah ǀ Cash is no longer king. With smartphones everywhere, consumers' increasing comfort with mobile wallets has
caused digital payments to soar for virtually every kind of financial transaction and on…

ARTICLE ǀ Quality Management ǀ 1 July 2018

PM Network
Sound Decisions
By Parsi, Novid ǀ When a show-stopping flood destroyed the University of Iowa's music building, students, faculty and
administrators saw an opportunity to create a new home that met performance, rehearsal and…

© 2018 Project Management Institute, Inc. USA

https://www.pmi.org/learning/library/project-management-principles-manage-small-projects-7168 5/5