Archivos

PMO Almighty

1 Star2 Stars3 Stars4 Stars5 Stars (1 votos, promedio: 3 de 5)
Cargando ... Cargando ...


There is no secret, PMO is now a need for those companies who want to formalize their projects and optimize the effort related to administrative-financial tasks in them. However there are some tips that you should take care before assign the PMO accountable for all the projects.

  1. If you are thinking on create-implement a PMO is because you already have ongoing projects. Do not start pushing your actual running projects into the new PMO.
  2. If you need a PMO is because you need to optimize repeatable tasks such, accounting, procurement, postmortem analysis.
  3. Do not use the same resources you have on your ongoing projects. A PMO will consume more time than a couple hours per day, do it right, assign dedicated resources so they can be accountable for the results.
  4. Research before doing changes. PMO should validate what you are doing right, what wrong, what can be improved, what not. Otherwise your will be implementing a Theroy-PMO instead of a real one.
  5. Be patient, do not push for results, have a plan. Your first PMOized project should be the PMO implementation -it will be the best way you can measure the progress and also validate the impact over your company’s processes.

¿Por qué fracasan los proyectos Web?

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

La lista de requerimientos creceDe acuerdo con una encuesta realizada a 100 gerentes de IT en el Reino Unido las razones principales por las que los proyectos Web fracasan son:

  • Demasiados cambios en los requerimientos
  • Demasiados stakeholders para complacer
  • Presupuesto y/o tiempo insuficiente.

Y agrega que si las compañías están predispuestas a aceptar fallas en el proceso de desarrollo de los proyectos pequeños, es mas probable que estas no definan adecuadamente los requerimientos y no eliminen la ambigüedad de los proyectos.

Algunos indicadores de la encuesta:

  • El 24% de los proyectos no está dentro del presupuesto y el 5% no pude incluso determinar el costo total.
  • El 21% no satisface los requerimientos esperados por los stakeholders.
  • El 31% de los proyectos no se entrego dentro del tiempo acordado.
  • Las causas principales asociadas a las fallas
    • Demasiados cambios en los requerimientos (55%)
    • Demasiados stakeholders a complacer (48%)
    • Presupuesto y/o tiempo insuficientes (31%)

Seria interesante incluir algunos factores de nuestra región para determinar si nuestra escala es diferente -acá en Latino américa.

El artículo sobre el cual basé este artículo fue publicado en PMFORUM

Liderar una PMO exitosa

1 Star2 Stars3 Stars4 Stars5 Stars (1 votos, promedio: 3 de 5)
Cargando ... Cargando ...

Este artículo es una traducción comentada de “Leading a Successful PMO: 10 Real-World Strategies” de Michael Wood, presentado el 17 de Marzo de 2008.

Gerenciar y administrar un portafolio de proyectos puede convertirse en un verdadero acto de malabarismo si no se es cuidadoso. Imagine la presión de tener 10, 30, 50 o más proyectos en curso, algunos de ellos activos, otros en la mitad de la implementación con un atraso siempre creciente. El secreto para liderar exitosamente una PMO (Oficina de Gerencia de Proyectos) es precisamente evitar concentrar la atención en los proyectos simultáneamente olvidando la PMO.

Antes de que las PMOs emergieran, la mayoría de las organizaciones veían al CIO (Chief Information Officer) como el administrador/gerente del portafolio de proyectos de IT. En la medida en que los líderes corporativos maduraban entendieron que eran pocos los proyectos de IT, pero sí muchos los que incrementaban la dinámica e innovación de la compañía, todos estos con una gran variedad de stakeholders -y no sólo a nivel interno, como suele ocurrir de IT. En ese momento, la PMO fue concebida.

Liderar exitosamente una PMO requiere una mezcla única de juicio prudente y delicadeza que es difícil de encontrar entre la multitud de CIO y CFO -sera por la multitud, la delicadeza o el juicio prudente?. Al mismo tiempo que mantiene una perspectiva completa del negocio y la compañía, y una sensibilidad inequívoca de las necesidades de las unidades de negocio locales y geográficamente dispersas. Todo esto puede abrumar y agotar si la mezcla no es debidamente balanceada.

¿Alguno sabe por qué muchas de las PMOs son disfuncionales o han asimilado las complejidades burocráticas? ¿Qué podemos hacer para transformar la PMO en un ente simplificado, orientado al servicio, facilitador, y que sea respetado por la dirección/gerencia, los stakeholders y IT?

Para empezar, debemos asumir lo siguiente como cierto en la mayoría de las organizaciones:

  • Tienen recursos y capital limitado y pueden participar un número en un cierto número de proyectos en un momento dado -y quien no tiene recursos limitados? Y en caso que los tuviera, hay formas de analizar el costo de oportunidad para cada proyecto, ¿o me equivoco?
  • No tienen personal que se pueda dedica exclusivamente a los proyectos, entorpeciendo y complicando la operación del día-a-día que demandan las actividades de los proyectos en curso.
  • Tienden a perturbar los proyectos en curso cuando la reducción de costos se vuelve una prioridad -esto es muy común incluso en las organizaciones proyectizadas, cuando todos sabemos que los proyectos son independientes entre sí y por lo tanto es una política que causa más daño que alivio.
  • Tienen gerentes de proyecto que en realidad son administradores de un proyecto pendientes del avance y generando reportes de estado -esto es muy común en casi todo el mundo, los gerentes de proyecto por defecto, no están asociados a la venta o negociación del producto o servicio y por lo tanto su capacidad de decisión sobre los recursos y el capital es limitado.
  • Generan estimados demasiado optimistas en términos de tiempo de entrega, presupuesto y esfuerzo.

Con estos puntos en mente, considere las siguientes estrategias y tácticas para desarrollar una PMO efectiva y exitosa.

  1. Proveer soporte administrativo a los gerentes de proyecto. Tomar esta carga pesada de la gerencia del proyecto le permitirá a los PMs liderar de manera adecuada y efectiva el equipo del proyecto, resolver problemas, y sobreponerse a los obstáculos del camino. Asumir la función administrativa de los proyectos por parte de la PMO hace posible estandarizar de procesos y procedimientos de más fácilmente.
  2. Justificar el presupuesto, el cronograma y el esfuerzo de los proyectos con base en los “peores escenarios” -No puedo estar más en desacuerdo con este numeral, estimar y planear puede ser complicado y seguramente muy doloroso (costoso) al comienzo, pero no por ello la solución es estimar el peor caso.
  3. Desplegar técnicas estandarizadas y herramientas formales para estimar, reportar y evaluar. Utilizar un enfoque pragmático para resolver los problemas de estimación, planeación y reporte puede conducir a resultados acelerados y replicables. Adicionalmente, tener un enfoque consistente y previsible incrementa la credibilidad de la PMO.
  4. Racionalizar el papeleo. La mayoría de las PMO son intensivas en papeleo. Muchos documentos que agregan poco valor pueden ser unificados. La estrategia de unificación y/o consolidación de documentos no sólo reducirá el esfuerzo, sino también la persecución asociada a la firma oficial de los mismos.
  5. Responsabilizar a los dueños del proyecto por el éxito del mismo. En la mayoría de los casos los gerentes de proyecto escapan de su responsabilidad al delegarla en el gerente/director técnico. Es bueno considerar asociarlos a ambos como responsables e incluso vincular sus incentivos -bonos-. Entre más estrecho sea este vínculo entre los dos, menos problemas políticos sucederán.
  6. Transformar los PM en gerentes de ejecución. Los PM excepcionales son expertos en desplegar tácticas y logística ganadoras. Estos PM van adelante de su equipo resolviendo los obstáculos que pudieran distraer al equipo o afectar negativamente el avance. Entre tanto, mantienen a su equipo productivo y enfocado mientras garantizan que el proyecto es realizado tan pronto como es cuidadosamente posible. Esta aproximación es, desde luego muy diferente al modelo de sentarse y quejarse y ubica al PM en el centro del campo de batalla.
  7. Desarrollar un repositorio de plantillas, listas de chequeo y recursos de expertos. Entre más herramientas pueda proveerle a los PM mejor. Hay grupos de tareas que pueden ser estandarizadas a lo largo de los proyectos. Muchas de tareas pueden ser consolidadas en sola con un soporte en una lista de chequeo -esto es especialmente cierto cuando las tareas son realizadas por una sola persona de forma lineal y toman menos de ocho horas. Tener una base de datos de expertos en diferentes áreas  puede reducir el tiempo de investigación y ayudar a los PMs durante el proceso de planeación.
  8. Adoptar la política de “una vez aprobado, nunca se detiene” en los proyectos aprobados. Tal vez la táctica más compleja de ejecutar es obtener el verdadero compromiso de la gerencia para permitir que el proyecto se complete una vez ha iniciado. Muy a menudo las compañías inician y detienen los proyectos con base en eventos que poco tienen que ver con la viabilidad del mismo o los requerimientos de la compañía sobre los flujos de efectivo. Este síndrome de detener e iniciar los proyectos se presenta cuando las iniciativas de reducción de costos son implementadas o la “tiranía de lo urgente” canibaliza recursos asignados. Se puede pensar que un proyecto aprobado tiene un compendio completo de casos de uso con un ROI superior, y que detenerlo sólo debe ocurrir bajo condiciones específicas y muy contundentes.
  9. Limitar el número de tareas que puede hacer una persona activa en un momento dado. La mayoría de las personas no es consciente que cada cambio de actividad durante el día representa una reducción valiosa de su productividad; típicamente de 10 a 15 minutos. Por lo tanto, si una persona tiene una lista de cosas por hacer de seis elementos, probablemente pierda entre hora y una hora y cuarto de productividad. Muchas de estas personas sobreponen este déficit al trabajar 10 horas diarias y/o 60 horas a la semana, y al final de la semana se sienten agotados, mal pagos, sobrecargados de trabajo. Un buen PM monitorea la forma como el equipo planea y administra su tiempo, ayudándolos a ser más productivos con menos esfuerzo.
  10. Desplegar una metodología pragmática para evaluar, aprobar y priorizar proyectos. La última cosa que una PMO necesita es tener personas que crean que los proyectos son aprobados subjetivamente. Cuando esto pasa, los PMs tienden a eludir que los canales formales para lograr que los proyectos sean aprobados, resultando en un incremento

Liderar una PMO puede ser una experiencia intimidante incluso en los mejores momentos. Al seguir las estrategias y tácticas antes mencionadas, quizá  la PMO y la experiencia de gerenciar proyectos esten tan libres de molestias como sea posible.

Nuevamente en el Blog

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

Luego de una larga ausencia y de un poco de trabajo de traducción, escribo nuevamente en este mi blog Simple ProjectZ. Es dificil decidir sobre el idioma, curiosamente la blogosfera asociada al tema de gerencia de proyectos es inexistente o muy insípida en español y demasiado extensa en inglés.

Por lo que sin agüeros he decidido empezar a escribir en español, seguramente traduciré algunos de los artículos que considere relevantes y desde luego espero una participación mas cercana.

La iniciativa de desarrollar una plataforma de herramientas para simplificar nuestra labor gerencial sigue en firme.

Moving to Castellaño

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

I’ve been decided to move my blog to Castellaño -Spain. I will keep posting some articles in English, but I think Spanish will simplify my blogging mode :-)

The PM fears -on Software Projects

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

Recently I published a survey in many local distribution lists and groups -here in Colombia- about the challenges of the Colombian Software Development PM role. My findings didn’t surprise me at all. The two main concerns for the project managers -apart of those that you can find in any PM book, “like keep the project on track within the cost and time estimations“, “have a successful project” are explained below -let me know if those applies for other projects:

  • Requirements definition is not accurate: Most of the times, clients do not know what they want or they just do not know it exactly -those inconsistencies or lags in their ideas become issues during the implementation or disillusions during the delivery.
  • Implement and execute a formal software development methodology. PMI theory says that PM role can be done without dependency of the product execution -in this case software development. Probably the pure management can be done without technical knowledge but, in my humble opinion, the stakeholder expectations management and the team management will require it. I’m pretty sure it should be the same for other knowledge areas.

The Scope definition challenge

Software development is more sensible and can be deeply impacted by the “what if” changes. Software is not like a building, so clients cannot perceive the progress and so many times changes are included without that concern -I do my best every day to avoid this to happen, but as PM my main responsibility is not to avoid changes, is to keep the course of the ship.

Scope definition for SW development is specially complicated. That’s why now we can find many undergraduate and graduate programs that address that need of a good “need specification“. A new profession have been created Business Analyst or System Analyst/Designer -I really like those programs but for now do not have enough money to take one :-) - if you want to learn more check the CMU or MIT programs.

Why scope definition and control are so complicated?

  1. Client do not know what they want. This is the typical example of a company that do not evaluate their needs before starting a software development project. It could be probably because they believe innovation is related to implement a new software product. My suggestion, get enough time to research with the stakeholders and the sponsor, the expected results and try to associate them to the business needs.
  2. Your company is sells whatever it takes to keep the client. Probably you were there, development teams complaining about the client services because they sell something that cannot be done with donating an organ -The Chicken and the Pig
  3. You need a technical person gathering the requirements. I was reluctant to include this item because I believe -I really do- if a company does not include a teki guy during the requirements definition FOR A SOFTWARE PROJECT then there is no hope! :-)

The key factor to simplify the scope management tasks is to have a change control system -a tracking system. If you cannot control the client requests, log, and plan them, you will have a lot of status calls, meetingitis, post-it-ingitis (i do not trust those guys with the monitor with fifty post-its with the PRIORITIES), or persons manually helping you -we call that here in Colombia chinomatic: chino can be translated -in Colombia- to guy, but in this context it means a person, that is not officially in charge of, but is more like an an assistant; and matic is an ironic use of the automatic word, obviously because it is manual procedure that the “chino” will execute. :-D

The development methodology

There are hundreds of methodologies for software development. I cannot even use this Blog to discuss them, however there are some elements that you have in consideration before start your project under any given methodology:

  1. You need time to do what you have to do. Today software projects seems to have the “agile pain“. Agile doesn’t mean fast, it means agile!!! -time cannot be reduced, there is no relativity in software development. If you have a sponsor or senior management that reduce the time by only including developers then my recommendation is to set the expectations since the beginning and use more than one release for the software product, in order to reduce the pressure periodically -BTW do not address the simplest things before, the idea is to reduce the pressure, not to postpone it.
  2. You should have the right team. This can be read as you do not need a team upgrade :-). It is possible to start a project -and even common for those projects that innovates a lot the development process through new frameworks or technologies- to have the need to evaluate the team to validate if the can handle the project. My personal opinion is, if you want to get respect and commitment from your team, be the example, train yourself and lead your team through those dark times. If you do not want to do it, the lead the request of getting a new team leader. -I love to change my hat to senior programmer / architect / developer / system designer / whatever and lead the team to the victory -almost all the times :-)
  3. Technology is out there. Many companies in the software development business, these days almost all of them related to Internet / Web based / Interactive Agencies, do not use or plan their infrastructure. Many of those companies do no understand the need to have real development environments for development, testing and even support to production environments. It is amazing but true how something so important that supports the team work and improves the performance. Methodology is not about documentation only, is also about infrastructure.
  4. Innovation also means Investments. Almost all the methodologies talk about process innovation, maturity of the process, cycles of  verification, improvement, or any other term that can be linked to improve the overall quality of processes and products. But even implement simple methodologies will required an extra effort that WILL HAVE A COST. The thing is, by improving the process you reduce the risk and time of a project.
  5. Pick one. Last but not least, pick one methodology, could be your own, could be a standard, could be something in a book that nobody except you read it. However, pick only one, and make it your own. Companies will mature their own process through the time, and will reduce costs of moving team members from one project to another by only implementing a formal process.

Web based project management tool

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

More than ten years I was forced to wait to see a real web based project management tool -by real I mean a decent software product that seems to address the PM needs and it is not a poor desktop application pushed to the web -like Microsoft Problem Server -oops I mean Project Server. Browsing the web I found the PMXPO 2008 and the SIIA CODiE Awards 2008 pages. Looking at the CODiE Awards 2008 finalists’ list I found @task, a company dedicated to deliver real software that uses the web.

I will try to get a demo or at least a try to that software product. As developer I know a lot of things about web development but also as PM I feel frustrated about the poor quality of the products delivered -that is one my personal reasons because I decided to start the SpZ Framework project. However, there are hope on new products that are jumping in and doing a great work.

Open UP project management - the discipline

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

According to the official OpenUP website the PM for a software development project that follow the OpenUP methodology is supposed to

  1. Encourage stakeholder consensus on prioritizing the sequence of work
  2. Stimulate team collaboration on creating long term and short term plans for the project
  3. Focus the team on continually delivering tested software for stakeholder evaluation
  4. Help create an effective working environment to maximize team productivity
  5. Keep stakeholders and the team informed on project progress
  6. Provide a framework to manage project risk and continually adapt to change

Points 1, 2, 5 are common to all PM in the universe, stakeholder management, expectation management and motivation management are part of the communication ability required as part of the role. However there are some other points that make me feel not so good:

Focus the team on continually delivering tested software for stakeholder evaluation

Stakeholder evaluation expression seems to be wrong. Stakeholder could be anyone with special interest in the project but not necessarily with decision power. Therefore, stakeholder is not the target of the deliverables for testing. More than one time you will be asked for “What if…” items, “Now that we already do this why…” items that everybody hate. Deliver & Deploy should be done only to the focus group -the right persons that will manage the results in an effective manner and following the software specs, probably an offshore QA team, a client QA or internal QA.

Help create an effective working environment to maximize team productivity

The working environment could be a lot of things, but probably means all external factors related for example to company environment, place/location and contractual stuff. However as IT and software developer I recommend to improve also the software environment -i.e. improve the software tools that the team use to do their work. I will recommend free/open source software :-) but obviously is not necessarily the situation for every project. Something that is common in the companies is to have tools but most of the m out of date, not legally acquired -at least in Colombia is a common practice- not working. As PM you should validate the work effort to build the software but also additional effort imposed by the use of the tools -even the time logger tool that I hope you use. If you will ask the team for additional tasks like time logging, change control documentation and other tasks related to software development and project management, be sure that they can do it fast and easy.

Provide a framework to manage project risk and continually adapt to change

A framework is a set of tools, for a person that is handling a project in progress in quite unfair to ask her/him for also the PM framework. In the most of the cases PM should ask the PM Office or the historical records of the company projects to get templates or at least examples. In the case there is no information available you will have to take a look to the templates available in the Internet :-) - I hope I can finish my templates soon so I can post them.

OpenUP site provides a lot of useful information but please validates it before use.

Integrated open source tools

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

PM should not have to deal with IT project strategy however almost all the time PM are “abandoned” in the middle of nowhere with a simple request: build a software tool that probably the client do not understand at 100% and it for sure is not documented.

The first steps are to (re)build the project scope and have a plan, but in the meanwhile your new team will need to have the tools to start their work. As PM you probably will have your own tools and templates but the team will have an IDE and that’s it. You should not deal with technical issues, but the reality is that as PM team will depend on you to get the right/optimal resources to simplify the developers work.

If you are those lucky guys that receive a software project since the beginning and not sometime after then you will have a better chance to get the right resources. My recommendation: Keep it simple but useful -even notepad is a useful tool if you use it correctly.

Your team needs:

  1. Deal with versions. Even before start your coding phase you MUST have a concurrent version system. In the market you will find a lot, but probably the common ones -and open source are: CVS and Subversion (a.k.a. SVN). Versions will force the team to work closer and with the same structure. If your IT team do it well, you will appreciate it a lot.
  2. Common IDE. Developers have their own affairs with specific IDEs. But you are the PM, ask your IT lead and force them all to use the same. I don’t like democracy, PM rules! However, as developer, I love Eclipse IDE.
  3. Documentation System. Most of the developers around the world will hate to document their code or applications. At least here in Colombia, when you ask developers to document their code or provide formal documentation they will give you the bad-eye look (in Spanish the malde’ojo) and you will understand that not the greatest documentation will be available at the end of the project. So provide the team with the tools to make this pain softer. I recommend only WYSIWYG tools like a Wiki, Google Docs, or any other fancy tool.
  4. Track their progress/work. Development tracking tools are suspiciously linked to Bug Tracking but it is not necessarily the truth. I’ve been using bug tracking tools like Mantis BT and Jira as Tasks Assignation tools. Keep in mind that a Bug is a request to do (fix) something. So why you cannot split your work packages in work items and assign them to the team -as you do with bugs.
  5. Provide test environments. I have to say this, why non-developer centric companies like Creative Agencies building Web applications do not understand that a Test Environment IS NOT the developer’s computer. What is this all about? What is the mystery? Test environments are needed, mandatory needed. Release building is a complex task that will have a lot of manually interactions -team pushing changes and enhancements- and it is NEEDED to have a place where to put all together and validate it before release it to a client -even to a client test environment. Please do not cut costs here. I will start a facebook group named “Why we do not have a test environment?” -BTW I do not like facebook, I do not even use it.
  6. Put it all together and working. This is the real thing about IT support. Install software is a piece of cake, is not a complex task, put all together and make it work smoothly is the key. So ask you IT team to do it, or do it yourself, like I did for some of my dev projects. There are many ways to integrate everything but I’m giving you some useful links to found the way to do it:

SpZ Team is currently designing an All-in-One integrated solution. For latest updates check the Framework page.

Open UP project management - Set your information system

1 Star2 Stars3 Stars4 Stars5 Stars
Cargando ... Cargando ...

Project managers who work in software development projects could be those who know about the software development process, probably because they were developers in the past, or those who do not have or do not want to have any technical knowledge and decide to delegate it to a third person -also know as Technical Director, Technical Lead, Team Lead, and other nice names for the man who really manage the software development process.

However this is an article for those who put their hands on projects, probably not coding but are PMs really involved in the software development process. I will explain how to set a project information system based on Open Unified Process and open source software.

The idea is simple, set a information repository accessible by anyone in the project, since the beginning of the development cycle to avoid miscommunication errors. The strategy, use a formal set of templates to document the business needs and the software design and publish them in a project site, but allowing the full access to the development team.

Before begin: you are the PM, if you do not want to go into the details ask IT team to handle the process, it is not so complicated but it takes time. It is not that easy

  • Share the information since the beginning
  • Software projects have this quality, share the information is good, all the information related to the software design and software implementation is good. There is no restriction, developers will understand better their work and BTW you will be reducing drastically the “developer” dependency -does this line sounds familiar to you? “I didn’t do it, I do not understand the code so it will take a time to do/fix/solve it“The easiest way to share documents is to have an open system that allows you to publish information in a public site -public means only to those person you want to have access. There are many ways to do -share a folder through the network :-(, share a folder through versions management system :-|, or to have groupware like Microsoft SharePoint. My case is to publish them since the beginning by setting a Wiki software that will have an ACL, a version management incorporated and all directly online -my team members do not have to install anything else than any web browser.Do not trust the model? Check the proved model by browsing Wikipedia. There is no bigger documentation team in the whole world.

    I will recommend for this experiment DokuWiki. It could be not the best, but is good enough. If you don’t like it there are hundreds so you can pick one. However I will recommend those with WYSIWYG editors to avoid the need of WikiSyntax.

  • Define what to share and how to share
  • At this point you know how to share whatever you will share. But, what is supposed to be shared? Many organizations already have their own set of standard documents, most of them because where certified in something. Like the ISO certifications. So, use them, do not worry, during the project evolution you will see how the documents grow and mature supplying with the appropriated information.Do not have template document? I see, you are on a small company or in a non-small-messy one. Don’t worry there are tons of templates available for free. ReadySET and Method123 will give you a hand but hey, you have to do your homework and build your own ones to fit your process and specific needs.

Know you are ready to start sharing your documentation. Give your team the freedom to work with the documents but track their changes, software design is not a democracy -brainstorming is a democracy where votes do not count. Software design is a Dictatorship where those who has the experience and knowledge will prevail.