Algunos pecados capitales en el proceso de estimación.

Steve McConnel autor de Software Estimation. Demystifying the Black Art y CEO de Construx pone a nuestra disposición un Webinar gratutito, 10 Deadly Sins of Software Estimation – los 10 pecados capitales de la estimación de software-,  basado en el libro referido. Así presenta Steve este Webinar:

The average project overruns its planned budget and schedule by 50%-80%. In practice, little work is done that could truly be called "estimation." Many projects are scheduled using a combination of legitimate business targets and liberal doses of wishful thinking. In this talk, award-winning author Steve McConnell presents 10 of the worst ways estimates go wrong, and presents time-tested rules of thumb for dramatically improving estimation accuracy

El seminario, de casi una hora de duración, aunque los últimos 15 minutos son de preguntas, nos lanza verdades de Perogrullo o pecados capitales que en más de una ocasión nos hacen sonreír y poner cara de “joder, pero que razón tiene” como la siguiente:

Assuming that the sales department is better at estimating software projects than the programmers are

o

Creating estimates that assume that no one will go to training …

or attend meetings …

or be called to work on another project …

Seminario imperdible que me recordado que tengo el libro en la pila de pendientes y no termina de salir de ahí.

Podéis descargaros la presentación desde aquí.

Por cierto, recordad que una buena estimación es uno de los primeros pasos hacía el éxito o fracaso de un proyecto, ¿o era el acierto o error de una estimación?

Ingeniería del software a debate.

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

Esta afirmación realizada por Tom DeMarco en el artículo Software Engineering: An Idea Whose Time Has Come and Gone? dio lugar a este otro artículo Software Engineering: Dead? el cuál llegó por twitter a ojos del agudo, provocador, ácido, ingenioso… e imprescindible Ricardo Galli quien ha escrito ¿”Ingeniería” del software? Ahora vienen los mea culpa.

En este último artículo Ricardo rechaza la calificación de ingeniería “a un proceso que tiene poco que ver con los de las ingenierías tradicionales” y critica al “establishment de la “ingeniería del software”” e incluso hace de futurólogo “en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre”.

Pues gracias Ricardo de nuevo por mantener abierto el debate, por ser capaz de argumentar como pocos, por persistir y difundir tus ideas. ¿Se puede crecer sin el debate, sin reflexión, sin disentir?

Mi opinión es que Tom DeMarco, más allá de un mea culpa que no creo que haga pues ni DeMarco ni ningún gurú puede sentirse responsable de la falta de criterio u análisis de todos los que le siguen a pies puntillas, hace una reflexión sobre la utilizad y fin de la ingeniería del software:

For the past 40 years, for example, we’ve tortured ourselves
over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

Ni las métricas, ni ninguna metodología, ni ningún proceso son un fin en sí mismo sino medios o herramientas para conseguir objetivos, fines o misiones. Como dijo Joaquín Salvachúa en WIMS 2.0: “La nueva realidad de la red” “There is no magic on OpenSource per se” y que podemos extrapolar a todo lo anterior: ni en metodologías ágiles, ni en métricas, ni en ninguna ingeniería.

Por último, no dejéis de leer los comentarios de los dos artículos escritos a partir del inicial de DeMarco pues ahí está el debate, es decir, el lugar donde crecer y construir algo mejor.

Otros artículos relacionados:

• Navegapolis.net: La Ingeniería del Software tiene aún muy poco camino recorrido

 

Plantilla para actas de reunión

Hace ya más de un año, ¡hay que ver cómo pasa el tiempo!, escribí dos artículos sobre gestión de reuniones:

• Reuniones eficaces. Mi primer paso.
• Reuniones eficaces. Versión 2.

Este artículo es la continuación de esos dos y sirve para compartir la plantilla de actas de reunion que he ido mejorando poco a poco. Podéis descargarla desde el widget de box.net que podéis encontrar en la esquina inferior derecha de este blog.

 

Esta plantilla puede ser utilizada como convocatoria puesto que incluye:

- Propósito: para qué nos reuniones.

- Agenda: qué asuntos y en qué orden los vamos a tratar.

- Material y equipamiento necesario: sala, proyector, etc.

 

Mi recomendación es que se escriba durante la reunión apoyándose sobre todo en las secciones: plan de acción, problemas, riesgos y deciones. Pienso que las actas de reunión debén ser concisas y que las habilidades literias se deben dejar para ejercicios más gratificantes y agradecidos. Todo el mundo tiene poco tiempo y, después de una reunión, necesita saber o tener constancia de:

- Qué se trato: sección Agenda

- Qué se decidió: sección Decisiones tomadas y

- Qué tareas le han tocado en suerte: sección Plan de acción

Por lo tanto mis actas tiene muy poco texto en la sección Notas y mucho en Tareas y Decisiones.

 

Por último otra recomendación: antes de compartir cualquier archivo comprueba sus metadatos para no dejar información que no quieras compartir tales como empresa, proyecto, autor, etc. Así podrás evitar situaciones embarazosas. Algunas herramientas para hacer esto son:

- FOCA online

- Doc Scrubber

Una buena explicación de lo que es un WBS.

Suele haber mucha confusión con lo que es un Work Breakdown Structure y lo que no es, aunque quizás los más importante es saber que es un medio para conseguir un fin. Me explico. Es un medio tipo boomerang, empiezas por la identificación y descomposición en partes de los entregables, para poder identificar las tareas que debes hacer para, finalmente, poder conseguir tener los entregables.

Luego los entregables son el principio y el fin de esta técnica.

En Wikipedia encontramos una buena definición:

… es una estructura exhaustiva, jerárquica y descendente formada por los entregables y las tareas necesarias para completar un proyecto.

El PMI define esta técnica así:

a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables.

Pues eso, primero entregables y luego tareas para conseguir entregables.

A continuación un artículo que lo deja muy clarito y que se lee en muy pocos minutos. Luego algunas referencias interesantes.

• Work Breakdown Structure  de Rodolfo Ambriz. (esta es la buena explicación)
• Estructura de Descomposición del Trabajo en Wikipedia
• El mapa de la isla desierta en PotPeyProject, muy buen artículo en español y con muy buenas referencias
• Work breakdown structure en Wikipedia. Es más extenso que el anterior e incluye más referencias.
• Project Work Breakdown Structures (WBS) and Schedules. Hay que estar registrado, pero se puede hacer de forma gratuita. En esta guía busca enseñar a construir un WBS partiendo de la necesidad de planificar un proyecto por fases por lo que su punto de partida son las fases del proyecto y a continuación los entregables que se generan en cada fase. 

David Allen nos cuenta GTD.

< Cualificaciones profesionales informáticas | Inicio | Una nueva categoría: Medioambiente >

Gracias a Lucas llego este vídeo -46  minutos - de David Allen publicado por Google.

Estoy finalizando la lectura de su libro Getting Things Done, en español Organízate con eficacia, por lo que aún tengo mucho camino por delante para asimilarlo e incluir sus recomendaciones en mi forma de hacer las cosas.

Le podéis ver también en su video promocional así como acceder a mucha más información sobre GTD desde su sitio Web http://www.davidco.com/

Project premorten.

< Podcasts en InformIT| Inicio |  Flexibilidad con Scrum >

 

Excelente artículo de Mario sobre esta técnica que nos sugiere visualizar el fracaso de un proyecto para identificar las causas que llevaron a esa situación y así poder desarrollar un plan para evitarlas, minimizarlas, transferirlas, asumirlas o decidir que el proyecto no es viable. El origen se encuentra en el artículo Performing a Project Premortem de Gary Klein publicado por Harvard Business Review en septiembre de 2007. Aquí tenéis la definición de la técnica:

A premortem is the hypothetical opposite of a postmortem. A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient. A premortem in a business setting comes at the beginning of a project rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure.

Otras referencias:

• FORTEblog. HBR: Performing a Project “Premortem”
• Clarke Ching. Project Tip: Conduct a Project Premortem

Reuniones eficaces. Versión 2.

< PRINCE2 Project management forum 2007 2ª edición | Inicio | Entornos productivos >

Gracias por los comentarios recibidos en Reuniones eficaces. Mi primer paso, comentarios que han motivado este segundo artículo. Aquí prentendo exponer el antes, durante y después de la reuniones. Ya sé que hay mucha literatura sobre este asunto, pero la diferencia con ella es que aquí está recogida mi experiencia y la de Ricardo, Eduardo y José.

Antes de la reunión

Se enviará una convocatoria con la siguiente información:

• Fecha, horario de inicio y finalización y lugar de celebración de la reunión
• Lista de personas que deben asistir, personas cuya asistencia es opcional y personas que, no estando convocadas, recibirán copia del acta que se escriba.
• Asuntos que se tratarán y responsable de la exposición inicial de cada uno de ellos.
• Material disponible para la preparación de la reunión
• Material que deberá llevarse a la reunión para ser utilizado en la misma

Durante la reunión

• El moderador de la misma expondrá al inicio de la reunión:
  • Los objetivos y asuntos de la reunión.
  • Si hay personas que no se conocen hará una presentación breve de todos los asistentes.
  • Recordará las reglas de juego: puntualidad, teléfonos apagados, respeto, etc.
• Durante la reunión:
  • Los asuntos fuera de agenda serán apuntados por el moderador para el final de la reunion valorar la necesidad de una nueva reunión que incluya dichos asuntos.

Después de la reunión:

En el plazo de tres días laborales después de la reuninón se enviará un acta de la misma con la siguiente información:

• Asistentes a la reunión.
• Principales conclusiones expuestas de forma breve.
• Tareas identificadas con el responsable y una fecha objetivo de realización.
• Decisiones tomadas y quienes las tomarón.

Pero lo difícil no es escribir este artículo sino conseguir que las reuniones sean así y que los que participan en ellas de esta manera salgan convencidos de que han participado en una reunión eficaz.

Reuniones eficaces. Mi primer paso.

< Entornos productivos | Inicio | ¡Humildes sí, pacatos no! >

Empezamos las tareas de toma de requisitos con reuniones con muchísimas personas que tienen poco tiempo, muchas ideas y montón de trabajo que hacer además de estar en la reunión. He decidido incluir en todas las convocatorias, y justo antes de describir la agenda, los siguientes “Principios generales”. ¿Conseguiré que se sigan?

PRINCIPIOS GENERALES

Para que estas reuniones sean lo más cortas y productivas posibles es importante que todos sigamos algunos principios – por favor, seguid leyendo y atendedlos cuidadosamente – :

• Comunicar la asistencia o ausencia a la reunión
• Puntualidad
• Preparación:
  • Llevad la información en soporte electrónico o papel que consideréis pueda ser de interés para la reunión
  • Enviad antes de la reunión la información que se haya solicitado para la misma
  • Llevad realizadas las tareas que se hayan planificado hacer antes de la reunión
• Respeto:
  • No atender llamadas de teléfono. Mantened los teléfonos móviles apagados o en silencio
  • No ausentarse durante la reunión. Si se debe hacer una salida planificada deberá anunciarse al inicio de la reunión
• Objetivos:
  • Evitar atender temas que no se han previsto para la reunión. Si se identifica la necesidad de tratar otros asuntos quizás lo más conveniente es planificar otra reunión.
•  Antes de finalizar la reunión:
  • Repasar las principales conclusiones a las que se hagan llegado
  • Identificar tareas y quienes y cuándo deben hacerlas
  • Planificar la fecha de la siguiente reunión

Artículos relacionados:

Reuniones eficaces. Versión 2.

La realidad de la práctica del Project Management.

< Project Management Office of the Year Award | Inicio | Agile 2006 Survey. >

Hace unas semanas escribí un artículo sobre la encuesta que la Business School de la Universidad de Quebec en Montreal está realizando con el fin de conocer el nivel de uso de las técnicas y herramientas más comunes en la dirección de proyectos.

Esta encuesta se realizó por primera vez entre los años 2002 y 2004 con la participación de unas mil personas trabajando el 58,6% de las mismas en IT o telecomunicaciones. A los participantes se les realizaron sólo tres preguntas para cada una de las 70 herramientas o técnicas estudiadas:

• Nivel de uso
• Soporte de la organización
• Contribución potencial ante un uso mayor o mejor en los resultados de los proyectos

Los resultados muestran que las organizaciones dan soporte a las herramientas o técnicas que más se utilizan y, viceversa, los usuarios utilizan más aquellas herramientas o técnicas que reciben más soporte por parte de la organización.

Más sorprendente resulta ver que la lista de herramientas y técnicas con un potencial mayor de contribución es muy distinta de las actualmente son más utilizadas tal como se puede ver a continuación:

	Level of Usage	Improvement Potential		Usage
1	Progress report	Database of lessons learned	1	51
2	Kick-off meeting	Lesson learned/post-mortem	2	13
3	PM software for task scheduling	Database of historical data	3	46
4	Gantt chart	Risk management documents	4	23
5	Scope statement	Requirements analysis	5	8
6	Milestone planning	Ranking of risks	6	33
7	Change request	Database of risks	7	62
8	Requirements analysis	Scope statement	8	5
9	Work Breakdown Structure	Database for cost estimating	9	50
10	Statement of work	PM software for monitoring of schedule	10	12
11	Activity list	Work Breakdown Structure	11	9
12	PM software for monitoring of schedule	PM soft. for multi-project sched./level.	12	47
13	Lesson learned/post-mortem	Contingency plans	13	24
14	Baseline plan	PM software for resources scheduling	14	17
15	Client acceptance form	PM software for task scheduling	15	3
16	Quality inspection	Team building event	16	30
17	PM software for resources scheduling	PM software for monitoring of cost	17	41
18	Project charter	Stakeholders analysis	18	39
19	Responsibility assignment matrix	Communication plan	19	21
20	Customer satisfaction surveys	PM software for cost estimating	20	49
21	Communication plan	Earned value	21	48
22	Top-down estimating	Quality inspection	22	16
23	Risk management documents	Financial measurement tools	23	34
24	Contingency plans	Cost/benefit analysis	24	26
25	Re-baselining	Critical path method & analysis	25	27
26	Cost/benefit analysis	Change request	26	7
27	Critical path method & analysis	Statement of work	27	10
28	Bottom-up estimating	Responsibility assignment matrix	28	19
29	Team member performance appraisal	Quality plan	29	35
30	Team building event	Customer satisfaction surveys	30	20
31	Work authorization	Feasibility study	31	37
32	Self directed work teams	Database of contractual commitment	32	58
33	Ranking of risks	Team member performance appraisal	33	29
34	Financial measurement tools	Bottom-up estimating	34	28
35	Quality plan	Project charter	35	18
36	Bid documents	Progress report	36	1
37	Feasibility study	Configuration review	37	38
38	Configuration review	PM software for resources leveling	38	40
39	Stakeholders analysis	Graphic presentation of risk information	39	56
40	PM software for resources leveling	Baseline plan	40	14
41	PM software for monitoring of cost	Milestone planning	41	6
42	Network diagram	Re-baselining	42	25
43	Project communication room (war room)	Kick-off meeting	43	2
44	Project Web site	Activity list	44	11
45	Bid/seller evaluation	Gantt chart	45	4
46	Database of historical data	Project Web site	46	44
47	PM soft. for multi-project sched./level.	Client acceptance form	47	15
48	Earned value	Life Cycle Cost (“LCC”)	48	57
49	PM software for cost estimating	Value analysis	49	61
50	Database for cost estimating	Critical chain method & analysis	50	67
51	Database of lessons learned	Product Breakdown Structure	51	52
52	Product Breakdown Structure	PM software for simulation	52	69
53	Bidders conferences	Project communication room (war room)	53	43
54	Learning curve	Quality function deployment	54	60
55	Parametric estimating	Parametric estimating	55	55
56	Graphic presentation of risk information	Top-down estimating	56	22
57	Life Cycle Cost (“LCC”)	Self directed work teams	57	32
58	Database of contractual commitment	Learning curve	58	54
59	Probabilistic duration (PERT Analysis)	Work authorization	59	31
60	Quality function deployment	Trend chart or S-Curve	60	63
61	Value analysis	Network diagram	61	42
62	Database of risks	Probabilistic duration (PERT Analysis)	62	59
63	Trend chart or S-Curve	Control charts	63	64
64	Control charts	Bid documents	64	36
65	Decision tree	Bid/seller evaluation	65	45
66	Cause and effect diagram	Decision tree	66	65
67	Critical chain method & analysis	Cause and effect diagram	67	66
68	Pareto diagram	Pareto diagram	68	68
69	PM software for simulation	Bidders conferences	69	53
70	Monte-Carlo analysis	Monte-Carlo analysis	70	70

Entre las 10 más utilizadas actualmente no aparece ni una sola vez la palabra Database o Risk mientras que en las 10 con un potencial mayor de contribución encontramos cuatro Databases y tres referencias a Risk. Parece por lo tanto que hay un mayor enfoque hacia la recolección y utilización de datos históricos para aprender del pasado y una mayor conciencia de la necesidad de identificar y gestionar los riesgos.

Por último señalar lo interesante que resulta conocer entre el gran número de herramientas y técnicas existentes cuales son las de mayor uso actualmente y las perspectivas de futuro existentes para así poder centrar los esfuerzos de estudio, entrenamiento y selección de software de la forma más rentable.

¡Añádelo a Del.icio.us! Menéame

Volere y la gestión de requisitos.

< Project Management Today E-zine – August 2006 | Inicio | Scrum crea oportunidades >

La inscripción en PM Clinic, ver Scott Berkun, ya está dando sus frutos. En los mensajes recibidos esta mañana David Growse hace la siguiente referencia a Volere en el debate sobre “Can you manage the proof of concept project?“:

“A great BA/SA will uncover the core business needs and the values the clients attribute to them, in a way that bounds the problem without limiting the path to the solution. Some of the fundementals behind the Volere process (http://www.volere.co.uk/ ) developed by Suzanne & James Robertson provide some good methodology for this end of the project, but the key which is not necessarily clear is to have the ability to effectively regress back to a 5 year old child – no preconceived ideas and incessently asking “why”.”

Picado por la curiosidad he visitado el sitio Web referido y me he encontrado con un diseño muy sencillo, pero lleno de excelentes contenidos. Volere es una empresa de consultaría especializada en Requirements al estilo anglosajón, abarcar poco y apretar mucho, saber más que nadie y trabajar por todo el mundo. Dan formación, hacen consultoría para ayudar a mantener la salud de los proyectos -ver Consulting clinics- o revisar Requirements o adaptar el proceso de captura de requisitos -ver Requirements Process Design-, escriben libros y artículos,… y, afortunadamente, comparten con nosotros lo que saben. Son muy interesantes sus plantillas para el análisis de requisitos, stakeholders (xls, 32,5KB), … que pueden descargarse gratuitamente, así como los artículos, libros recomendados, recursos, herramientas… vamos que no tiene desperdicio.

MUY RECOMENDABLE.

¡Añádelo a Del.icio.us! Menéame

Project Management Tools and Techniques survey.

< Examen para CAPM® ahora en español. | Inicio | Earned Value (Valor Ganado) en Wikipedia. >

Como anticipe en la nota anterior las últimas lecturas de PMThink! han dado mucho juego aunque sólo comente dos de ellas, una en mi nota anterior y otra ahora.

En esta ocasión Jerry Manas nos informa que PMForum ha publicado un enlace que nos lleva a una encuesta dirigida por la Business School de la Universidad de Quebec en Montreal para conocer qué técnicas y herramientas se están utilizando actualmente en la dirección de proyectos.

La participación en esta encuesta da la posibilidad de acceder inmediatamente a los resultados acumulados de la misma, recibir el sumario de la anterior encuesta realizada en 2004 y recibir un sumario del informe que se va a elaborar durante este verano con los resultados finales de la encuesta actual.

Esta encuesta forma parte de la segunda fase de una investigación realizada por el PMI Research Department y la Business School de la Universidad de Quebec en Montreal sobre el valor que proporcionan en la dirección de proyectos las distintas herramientas y técnicas existentes.

Para la realización de la misma se proporciona una lista de 91 definiciones de técnicas y herramientas para la dirección de proyectos que supone un buen resumen de las mismas.

A día de hoy el cuestionario ha sido contestado por algo más de 600 personas entre las que me encuentro ofreciendo resultados como los siguientes:

• 67% de los participantes son hombres ,
• 71% tienen tiene un título universitario o master,
• 49% son actualmente project managers,
• 24%, los más numerosos, desarrollan su trabajo en una organización cuya actividad principal se encuadra en IT (Information Technology),
• 40%, lo más numerosos, participan en proyectos cuyo entregable principal es IT,
• 76% considera que su empresa se encuentra en un nivel 3, hay 5, o inferior de madurez en la realización de proyectos,
• 63% de los proyectos tiene una duración inferior a un año,
• 51% considera que sus proyectos están bien definidos,
• 49% considera que trabaja en una organización con índices de éxito en la media y un 44% considera que tiene un éxito superior a la media…

y hay muchos más datos que comentaré en próximos apuntes.

¡Añádelo a Del.icio.us! Menéame

Earned Value (Valor Ganado) en Wikipedia.

< Project Management Tools and Techniques survey. | Inicio | Certificaciones. >

A través de PMThink!, que hoy a proporcionado varias lecturas interesantes como se podrá ver en los siguientes apuntes, he podido saber que Garry L. Booker, Presidente de ProjectFrontier, ha revisado en Wikipedia la entrada en inglés para Earned Value Management y pide comentarios a la misma a través de la página de discusión de Wikipedia. Creo que es una interesante iniciativa que es posible llevar a la versión en español de Wikipedia donde el apunte actual es muy escueto como se puede ver desde aquí. Lo apunto por lo tanto en mi lista de tareas pendientes e invito a todos a participar bien en la traducción de la entrada de Garry bien en escribir una entrada nueva más desarrollada que la actual.No obstante, para saber más sobre el “Análisis del Valor Ganado” recomiendo la lectura de los apuntes, ya van seis, que Diego Navarro está realizando en su blog, Dirección de Proyectos.

Otra lectura interesante es el Web Seminar que Global Knowledge ofreció el pasado 14 de julio titulado Earned Value Project Management: Management with the Lights on pudiéndose bajar la presentación del seminario desde aquí.

¡Añádelo a Del.icio.us! Menéame

Análisis del valor ganado.

< no hay que dejar de escribir… | Inicio | Felicidad o Verdad >

Una de mis intenciones con este blog es ir repasando algunas de las técnicas más útiles para la dirección de proyectos informáticos. Para ello una de las cosas que haré será buscar información disponible en Internet acerca de dicha técnica, preferentemente en español, y utilizarla para mejorar mi conocimiento y también para referenciarla en el post.

En este caso he leído con interés los dos post que sobre la técnica del Análisis del valor ganado, Earned Value Management, ha escrito Diego Navarro en su Blog “Dirección de proyectos“:

• Seguimiento de proyectos con el Análisis del Valor Ganado (1): el por qué
• Seguimiento de proyectos con el Análisis del Valor Ganado (2): curvas S

y cuya lectura recomiendo.

El próximo 14 de julio Global Knowledge, otra de mis fuentes de información, impartirá un seminario Web gratuito sobre este mismo asunto cuyo título es Earned Value Project Management – Management with the Lights on. Yo ya me he apuntado.

¡Añádelo a Del.icio.us! Menéame