Los resultados de la encuesta online (nuevo servicio de Linkedin, ojo no me pagaron por esa mención), han votado 2771 usuarios, supongo que todos miembros del grupo The Project Manager Network, la pregunta exacta es: Is PMP certification becoming more or less important for project managers?

Está bastante parejo el resultados, contrario a lo que se podría pensar, un 57% lo encuentra importante y un 43% menos importante.  Digo que sorprende ya que en un grupo como ese la mayoría a favor de la certificación sería bastante más abrumadora.

Al revisar los comentarios surgen básicamente dos ideas fuerza asociadas a cada posición

• A Favor, la certificación PMP (Project Management Professional) es un must que todo gerente de proyecto debe tener si quiere ascender en su carrera gestionando proyectos cada vez más importantes, y por lo tanto debe enfocarse en obtener la referida certificación, como un prerequisito para aquello.

• En contra, que básicamente se trata de un negocio del PMI, ya que por un curso de aproximadamente 1.500 dólares, más el costo del examen y la declaración de una experiencia de 4.500 horas gestionando proyectos (la otra forma es tomar otros cursos de organizaciones certificadas por el PMI) se puede obtener el PMP, pero ello no asegura que tengan las competencias necesarias.

Debo reconocer que en el año 2007, realice todas las gestiones para certificarme, para lo cual presenté las horas de pre requisito, según me consta las personas de contacto (contrapartes de los proyectos presentados) que puse en mi solicitud, algunas fueron contactadas y otras no.  Tenía programado un curso intensivo de una semana para preparar el examen, finalmente tuve que abortar mi proceso ya que fui nombrado Secretario Ejecutivo de la Estrategia Digital y la verdad es que se me hizo inviable cerrar el referido proceso.

Los Europeos, en particular los ingleses con su metodología de gestión de proyectos Prince2, su gran argumento a su favor es que no existe un modelo de negocios detrás de ella, el PMI se defiende con el argumento de que se trata de un método reconocido a nivel mundial y un estándar desde el punto de vista de la gestión d proyectos.

En todo caso se debe señalar que las certificaciones Prince2 o PMP no aseguran calidad, es igual que las certificaciones ISO, aseguran que se cumple un método/procedimiento para el proceso, lo cual al menos da garantías de consistencia en el proceso y los artefactos que se utilizan para su desarrollo.

Usted,  ¿qué piensa al respecto? , los gerentes PMP desempeñan una mejor labor a la hora de administrar proyectos, en este punto me encantaría contar con la retroalimentación de Eduardo Díaz, digo yo para seguir con el debate sobre proyectos TI y su gestión.

Andreessen realiza un planteamiento interesante y que me llevó a reflexionar si nuestros países van por el camino correcto en materia de industria tecnológica.  Ya desde el título del artículo Why Software Is Eating The World, hasta la muestra de lo que está ocurriendo con varios sectores industriales y como en cada uno de ellos el software está tomando un rol preponderante y en algunos caos resulta ser fundamental, algunos ejemplos de ello:

• Amazon: La librería más grande del mundo y camino a transformarse en el retailer más grande
• Netflix: El servicios de video más grande del mundo
• Itunes, Spotify, Pandora: Compañías dominantes en el mundo de la música
• Google, Groupon, Foursqare: Líderes en marketing directo a nivel mundial
• Skype: La empresa de telecomunicaciones que más crece a nivel mundial
• LinkedIn: La empresa de reclutamiento que más crece en el sector
• Paypal: Servicios financieros

Lo que tienen estos ejemplos en común son que las compañías que hay detrás de los distintos negocios, esto es, retail, entretenimiento, marketing, comunicaciones, reclutamiento y servicios financieros es que son empresas de software.

¿Por qué me llevó a reflexionar respecto de nuestro sector en la región?, es que en en general la industria del software representa un porcentaje muy bajo del total del marcado TIC en la región, somos básicamente revendedores (hardware, software básico) de tecnologías diseñado y producido en otras latitudes, al revisar las cifras de negocios asociadas a servicios de valor agregado y en particular desarrollo de software, estas son bastante más bajas.

Algunos países, están haciendo esfuerzos para cambiar aquello, me refiero a los esfuerzos emprendidos en Brasil, México, Uruguay por establecer una industria de valor agregado vinculada a la industria TI, me parece es la jugada correcta.

En Chile lo veníamos haciendo bien con la política de clusters, en particular el cluster de offshoring, pero alguien se llevó la pelota para la casa en el último tiempo y nos hemos quedado.

Es de esperar que en algún momento tomemos la senda adecuada y pongamos nuestras fichas en el software, por que como dice Andreessen, software is eating the world

Imagen: http://technosoftwares.com/services-2/software-development/

1. permitir acceso a los servicios on-linee
2. conectividad con socios/actores externos
3. robustecer plataforma para la introducción de nuevos servicios
4. mejorar el estado del arte del eGov

Desempeño

1. menores costos de manutención y operación
2. mejoramiento en los servicios ofrecidos
3. necesidad de mejor información para toma de decisiones
4. aumentar el rango de servicios
5. mejoramiento de las condiciones de trabajo de los servidores públicos

Tecnológicas

1. búsqueda de integración de los sistemas
2. obsolescencia
3. flexibilidad
4. complejidad de los sistemas legacy

Operacionales

1. facilitar acceso a los datos
2. modernización
3. herramientas de gestión centralizadas
4. posibilidad de analizar diversos escenarios
5. mejorar la colaboración interna y externa
6. descentralización

En general los proyectos de desarrollo de sistemas de gestión financiera en la región no han tomado la ruta de adoptar sistema del tipo ERP y adaptarlos, el argumento más frecuente es que estos sistemas no cumplen con los requerimientos funcionales.  Lo que se ve en muchos países de la región son grandes desarrollos que cuentan con varias decenas de técnicos (informáticos y funcionales), equipamiento y licenciamiento, lo cual suma en muchos cifras que van entre los 30 y 60 millones de dólares, dependiendo de la antigüedad del proyecto.  Estos modelos de desarrollo presentan algunos desafíos de sustentabilidad en el largo plazo:

• Tener un mapa de evolución de la plataforma definido (roadmap) que le de un marco claro de actualización
• Contar con recursos permanentes que permitan mantener el sistema (10%-15% del costo del desarrollo anualmente) actualizado incorporando los cambios normativos y de negocio que se produzcan
• Modelo de cobertura (instituciones que utilizan el sistema) y profundidad de su uso (profundidad del ciclo financiero)
• Establecer un modelo de soporte con sus diferentes canales (call center, web, presencial)  y adopción de usuarios, lo cual implica procesos permanentes de capacitación y difusión.

De todas formas me surge la pregunta: ¿qué será más eficiente desarrollar algo a medida o bien mover el estado más cerca de las prácticas definidas en los grandes ERP's? en muchos casos los dado ya están tirado pero creo relevante se miren con detalle los desafíos de sustentabilidad.

Imagen de: http://www.spsintellect.com/

Quiero primero que nada hacer un disclaimer, creo profundamente en el modelo de Software Público y  he sido un impulsor de este, he escrito al respecto en varias oportunidades, he dictado charlas y finalmente durante el año 2009 asesoré al Ministerio de Economía en esto.  Pero desafortunadamente el tema no se manejó adecuadamente y terminó en una discusión sin salida, cada parapetado en su lado de la trinchera.

A futuro me pronunciaré sobre el modelo de Gobforge que me parece más adecuado, por lo tanto espero sinceramente que esta iniciativa no muera del todo, y vuelva a sus orígenes: "El Estado como ecosistema privilegiado de transferencia de conocimientos"

Pero bueno parte de esta discusión en el mediano y largo plazo va a perder bastante de su sentido original, esto producto de dos hechos que van a cambiar el eje de la discusión.

En primer lugar, el Cloud computing, cuando las aplicaciones dejan de estar instaladas localmente y residen el nube, accediendo a ellas en la modalidad SaaS, en ellas el usuario final lo que requiere es un dispositivo con conectividad (PC, netbook, celular, etc.)  y un navegador (browser).  Para ese usuario el dilema de en que está desarrollada la aplicación, que tipo de base de datos utiliza y si tiene arquitectura J2EE  o .Net o está construida con el stack LAMP pierde toda relevancia.

En el modelo SaaS lo que interesa es la transparencia frente al browser, esto es, que los sitios sean construidos bajo los estándares de la W3C y que el almacenamiento de la data sea en formatos estándares permitiendo adecuados niveles de interoperabilidad, y que por supuesto no muestren los problemas que algunos de nuestros portales públicos presentan.

Lo segundo es el uso de estándares para el intercambio de datos, un nuevo foco de la discusión FLOSS versus software comercial cambia, es moverse del tema en que está programada la aplicación y cual es su modo de licenciamiento a cuales son los formatos de datos que utiliza y si estos son abiertos o propietarios, por lo tanto la preocupación pasa al nivel vendor lock-in producto de los formatos de la data.  Para resolver esto la discusión debe centarse en los principios del Open Data

En un futuro en el cual los porductos del tipo MS Office, Open Office o iWorks funcionen en modalidad SaaS (hoy ya tienen algunpos desarrollos en tal sentido) requiriendo sólo de un browser para utilizarlos y que los archivos de datos utilicen el estándar XML regulado por algún organismo de estandarización mundial (ISO, ANSI u otro) la discusión cambia totalmente y su eje se mueve hacia otros tópicos

• Modalidad de suscripción
• Políticas de privacidad del sitio que entrega el servicio
• Uso de formatos estándares y abiertos

Por la velocidad que esto está tomando creo que bastante más temprano que tarde veremos llegar estos modelos y nos resultará tan antigua como inoficiosa la discusión FLOSS o Comercial al menos el modo en que se estaba desarrollando.

Imagen: http://www.flickr.com/photos/andreasnilsson1976/

• Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución
• Falta de habilidades de gestión de proyectos y administración del riesgo
• Falta de liderazgo y ownership del proyecto
• Poco conocimiento de la industria TI local y de lo que realmente puede proveer.
• Presupuestos mal definidos, ni proveedor ni comprador saben cuanto cuesta la solución
• Evaluación de propuestas con mirada de corto plazo sustentado en oferta económico y no en valor del gasto
• Pocas iniciativas para segmentar los proyectos en tamaños más manejables
• Arquitectura tecnológica mal definida
• Niveles de servicio (SLA's) mal definidos y/o no administrados

En los últimos días hemos visto por la prensa información con sendos titulares, describiendo el problema del contrato tecnológico Fonasa - Entel.  Más allá de lo superficial y poco documentado análisis al que nuestra prensa local nos tiene acostumbrado (cuando leo este tipo de reportajes, me pregunto nadie cuestiona en serio la calidad de nuestro medios en temas más complejos que los últimos eventos de farandulandia).  Tanto es así que hace unos días el diario La Tercera no fue explícita en el nombre del proveedor mencionando  "El contrato, firmado en 2004 con una empresa telefónica...", cuando alguno de ustedes escucha "empresa telefónica"  ¿piensan en Entel o en Telefonica?

Eso me recuerda algo que me ocurrió hace ya muchos años, en una entrevista que me hiciera el diario Estrategia, a la pregunta cuanto le iba a costar a Chile el problema del año 2.000, o Y2K como se conoció en sus momento, dije "estimo que serán unos 400 millones de dólares", pues bien en el artículo apareció 4.000 millones, al increpar al periodista por el error (ojo que estamos hablando de un medio se supone acostumbrado al manejo de números), me dijo "que daba lo mismo, nadie lee los números", mi reacción fue como la de Condrorito, "plop".

Retomando el tema que nos convoca, me parece importante relevar algunos antecedentes que son públicos. Una de la cláusulas definía que si el proveedor no cumplía con plazos de puesta en marcha de la nueva solución se debe mantener al operador actual y el nuevo operador debe pagar por los servicios manteniendo la continuidad de servicio, recordemos que Fonasa atiende a millones de usuarios y entrega millones de prestaciones.

Si alguien analiza este proyecto con mirada monofocal y basada unicamente en los aspectos jurídicos, efectivamente pueden faltar multas a cobrar (algo que que no me consta) y por lo tanto la conclusión puede estar ajustada a derecho puede que esté en lo correcto, ahora bien como me consta el proveedor no estaba disponible a más multas en ese momento y su respuesta fue: "me cobran más multas y me retiro del proyecto, nos vemos en los tribunales y que gane el más mejor" con el consecuente riesgo para la continuidad de servicio que esa situación genera.  En situaciones como esta se debe analizar el mayor bien común, el cual probablemente podría llevar a pasar algún otro bien de carácter jurídico.

En ese escenario debe primar la cordura y que en este caso se debe regir por la continuidad de servicio en un servicio de carácter masivo y que afecta a muchas persona, millones para ser más preciso.

Independiente de que el proyecto tenía problemas en su origen, en los servicios críticos que el estado presta a sus ciudadanos uno de los valores fundamentales es la continuidad de servicio, ya que sino es finalmente el ciudadano el que paga el costo final.

¿Qué hubiera pasado con el servicio si como se plantea se le hubiera rescindido el contrato a Entel en ese momento?

Otro elemento que vale la pena evaluar es cual va a ser el impacto futuro en el costo de los proyectos y contratos TI cuando estos terminan en la prensa y en los tribunales, me pregunto: ¿que porcentaje es el factor de riesgo que los empresarios TI pondrán en sus ofertas producto de la historia pasada y el potencial de judicialización de los proyectos?

Uno de los elementos más funestos en los modelos de externalización que el Estado (ojo este problema se da casi en toda la región, más al norte las relaciones PPP tienden a establecer relaciones win-win) establece, ya que la relación al menos con sus proveedores tecnológicos es bastante esquizofrénica.  Esto no hace más que aumentar los niveles de desconfianza.  Por otra parte la industria debe ser más responsable y seria a la hora de preparar sus ofertas, hemos visto varios casos en los cuales empresas se presentan a proyectos con el modelo de que en el camino se arregla la carga.

Lo anterior significa que el Estado queda en la indefensión? la respuesta es no, pero definitivamente lo que que deben cauterlarse en todo proyecto es el beneficiario final del servicio y que no sea este el que termine pagando la cuenta.  Por lo tanto vuelvo a la pregunta inicial ¿qué bien cuatelar?

Imagen: Desde sitio del Gobierno Australiano sobre resolución de disputas

Fuente problemas en proyectos TI:Proyectos TIC - Sector Público (octubre 2006)

Esto ha generado un diferencial importante en los proyectos de desarrollo de software, particularmente en las aplicaciones de negocios.  Esta brecha se aprecia de forma importante en el no cumplimiento de tiempos y recursos definidos para el proyecto y en una percepción bastante generalizad por parte de áreas usuarias, de que los informáticos no cumplen con plazos y costos.

Las principales dificultades que se plantean a la hora de desarrollar software (aplicativos de negocios) corresponden a la etapa de capturar los requerimientos de los usuarios, ya que luego de aquello se tiene la esperanza por parte de los desarrolladores que el mundo se va a congelar, es como jugar el juego del un, dos tres momia es.  Sin hacerse cargo de los continuos cambios que tienen los modelos de negocios, producto de la competencia, otros productos y en general situaciones de mercado en muchos casos no previsibles.  Según Standish Group cerca del 60% de los requerimientos cambian a lo largo de un proyecto.  Otro elemento importante a tener en cuenta que si cambias de opinión en algún requerimiento al comienzo y esto tiene un impacto financiero de X, este mismo cambio cuando el proyecto lleva un 70% de avance el impacto se multiplica por 100 (100X).  Por eso es que hay que congelar el mundo ya que sino el costo puede ser enorme.

El desafío que se plantea a futuro en el proceso de desarrollo de software es comprimir el tiempo, esto es, reducir el tiempo entre el surgimiento de la necesidad y contar con la aplicación que la soporta.  A partir de esto es que han surgido metodologías cuyo propósito es precisamente reducir ese tiempo y hacerse cargo de que el mundo sigue girando con su consecuente impacto en los sistemas de soporte al negocio.

Las metodologías denominadas "ágiles" que las hay en varios sabores, siendo las más conocidas XP y SCRUM han comenzado a ganar gran cantidad de adeptos.

SCRUM, método desarrollado por Jeff Sutherland y Ken Schwaber, el cual se basa en un método de producción en la industria automotriz, en particular, la empresa Toyota.  Dicha empresa diagnóstico un problema similar al mencionado en el caso del software, demasiado tiempo entre la idea de un nuevo modelo y su puesta en el mercado.   Con este método logró reducir órdenes de magnitud el time to market de nuevos modelos, transformándose en un líder en esta área.

Fuente: Softhouse

Algunos elementos básico de SCRUM

1. Opera en base a iteraciones cortas (15 días a 1 mes)
2. Equipos de trabajo pequeño (7-9 personas)
3. En cada iteración se implementan funcionalidades usuarias y estas deben ser demostrables
4. Usuario participa en las iteraciones
5. No requiere que digas todo desde el comienzo
6. Puedes cambiar de opinión en el camino
7. Cada equipo tiene un líder
8. Se trabaja con reuniones diarias (CORTAS), en las cuales cada miembro del equipo contesta: ¿Qué ha cumplido desde la última reunión?, ¿Qué obstáculos se presentan?, ¿Qué voy a terminar?

El propio Schwaber define SCRUM como una colección de buenas ideas más que una metodología en el sentido estricto y se basa en la transparencia, ya que todo el mundo sabe que está pasando con el desarrollo de una determinada aplicación en periodos cortos de tiempo (cada iteración) y no se encuentra con un "conejo" al final, que habitualmente parece más un jira-mono-canguro.  No todas las organizaciones han podido implantar estas prácticas con éxito, sólo el 35% lo logra ya que muchas no están dispuestas a transparentar el proceso.

La gracia de este proceso incremental además es que se implementa lo que se requiere realmente y no todos los chiches que a alguien se le ocurrió al comienzo del tiempo, recuerden que el 65% de las funcionalidades de un producto nunca son usadas, ¿qué porcentaje de Office utilizan?

Les recomiendo vean estos videos que adjunto de los ideólogos del SCRUM

Scrum et al. - Ken Schwaber, Google Tech Talls - 5/9/2006

Scrum Tuning: Lessons learned - Jeff Sutherland, Google Tech Talks - 7/12/2006

Fuente Imagen: www.drdudd.co.uk

En el último tiempo me han llegado muchas solicitudes por herramientas para gestión de proyectos y PMO en general.  Lo primero a decir es que existe una cantidad enorme de herramientas para la gestión de proyectos, de hecho en uno de los repositorios que les menciono más abajo aparecen más de 400 herramientas, desde planillas adecuadas para tal efecto hasta sistemas de clase mundial, tales como: Primavera (Oracle), Mercury (HP) o Clarity (CA), pasando por sistemas en modalidad SaaS (Software as a Service), de desktop o bien para ser instalados en servidores corporativos.

Dado que existen una enorme variedad de soluciones de software para la gestión de proyectos, diría que el principal problema no es encontrar herramientas sino identificar cual es la que mejor se adapta a mis necesidades.  Estas herramientas cubren las diferentes necesidades funcionales: gestión de tareas y actividades, gestión de recursos, calendarios, colaboración, gestión documental, administración de portafolios, gestión de riesgos.  A continuación les adjunto un listado de sitios donde se pueden encontrar información de herramientas de gestión de proyectos.

Algunos de los sitios donde pueden encontrar referencias y análisis comparativos de estas herramientas son:

• Análisis comparativos de herramientas de gestión de proyectos en Wikipedia
  

• Evaluación de las principales herramientas de gestión de proyectos en el sitio Top ten Reviews 
  

• En el sitio Gantt Head existe una herramienta que permite seleccionar por tipo diferentes sistemas de gestión de proyectos (muy interesante)

• Portal de herramientas de gestión de proyectos del tipo web cuenta con un listado de 468 herramientas y una pequeña descripción de sus características el mismo sitio cuenta con una revisión de un panel de especialistas de algunas de las herramientas

• Artículo de revista francesa Journal du Net en el cual se analizan las principales herramientas de gestión de proyectos del tipo Open Source (afortunadamente el artículo está en francés para aquellos que nos gusta ese idioma) 

Hace pocos días se lanzó el sitio 'International Free and Open Source Software Law Review'.  Este portal pretende trasnformarse en la referencia obligada de temáticas legales y software libre (OSS).  Este tipo de software está desafiando los paradigmas tradicionales de entendimiento de la propiedad intelectual y los modelos de colaboración.

En el se desarrollan varios artículos en esta materia, los cuales pueden ser leidos en la web o bien bajandos en formato pdf, creo que el sitio puede ser un valioso aporte a la discusión jurídica en torno a al Open Source (OSS), Software libre.  En su primer número de julio aborda temas y casos que amplian la discusión de dichos aspectos, espero que sea un aporte a nuestros jursiconsultos especializados en estos temas y quienes quieran aprender.

Un ejemplo del material que tiene es el artículo The Fiduciary Licence Agreement: Appointing legal guardians for Free Software Projects de  Ywein van den Brandea

Finlandia
En la pequeña ciudad de Oulu, ubicada en el norte de Finlandia la sexta ciudad más poblada con una población de 130.000 habitantes, su municipio desarrolló una herramienta para generar portales municipales, bastante poderosa, la cual disponiblizó en un modelo de licenciamiento libre (GPL, más algunas componentes en licenciamiento MIT).  El portal que posee una arquitectura de interacción con los ciudadanos basado en la herramienta de portales Liferay puede ser utilizada por municipios de diferentes partes del mundo.  Un ejemplo de la operación de la herramienta se puede ver en este video

El proyecto se encuentra participando el UN World Summit Award Contest como una solución de gobierno electrónico local.

Brasil
El gobierno federal de Brasil cuenta con un portal de Software Público , en el cual las instituciones públicas, pueden disponibilizar en un modelo de software libre (GPL v2) aplicaciones, el portal cuenta con múltiples aplicaciones y se han estructurado comunidades de desarrollo en torno a cada aplicativo, hoy día cuenta con cerca de 30 aplicativos en diferentes ámbitos, educación, atención de público, identificación y gestión de contenidos ente otros.  En algunos casos las comunidades de desarrollo sobrepasan los varios miles, llegando en un caso a más de 18.000 usuarios.

Adicionalmente esto ha logrado establecer un ecosistema de negocios basado en el soporte en torno al algunos de los aplicativos, estos es, empresas que dan servicios de soporte y mantención de los productos allí catalogados, lo que cambia el paradigma del licenciamiento por el de servicios, en el mismo portal se inscriben las empresas/organizaciones que dan servicios relacionados con los aplicativos y quien desee instalar algunos de los productos puede contactarla.  Les recomiendo ver este video en

Me parece relevante analizar estas experiencias en nuestro país y tomar de ellas lo mejor, para que podamos avanzar de forma más efectiva en las prácticas de eGov de nuestro país.  Sobretodo aprovechando recursos y no inventando la rueda a cada rato.  El otro tema que me parece muchas veces absurdo, es por que el Estado a la hora de contratar un desarrollo a la medida trabaja con esquemas de licencimaiento tan rígidos.  Sería interesante generar un debate más amplio para el diseño de políticas públicas en esta área, en las cuales resulta muy relevante la participación de los principales actores a la hora de contratar software por parte del Estado y me refiero a la Dirección de Compras y Contratación Pública, Contraloría General de la República y la Estrategia Digital.

• Crecimiento del sector de un 12% durante el año 2007
  
• 45% de sus ventas nacionales corresponden a desarrollo de software a medida e implementación de software, si a esto le sumamos desarrollo de software empaquetado la cifra sube a 62%
• Respecto de las ventas internacionales el desarrollo de software a la medida se lleva prácticamente la mitad de los ingresos (49%)
• Si bien su principal negocio es desarrollo de software a medida, las empresas están buscando concentrarse en el desarrollo de software empaquetado (productos)
• El Principal destino de exportaciones es Europa, seguido de Perú y luego Estados Unidos y Canadá, lo que contrasta con años anetriores en que los destinos principales estaban en Latinoamérica
  
• El principal sector atendido por esta industria es Servicios Financieros, seguido del retail y después bastante más atrás el Estado, está situación cambió significativamente respecto del 2006 en el cual el principal destino era el sector telecomunicaciones seguido del Estado.
• La industria tiene muy altas expectativas del año 2008 (mejor que el anterior)

| View | Upload your own