Tip #1

To choose and implement a PM software tool is not the same of implementing a PM process. Many organizations try to implement a software tool expecting a nonexistent-unnatural process improvement. If you do not have a formal process, or even if your process is not working you have to stop thinking that automation will fix/improve/solve your problems. Automation should be used to reinforce a process and minimize the weaknesses.

Tip #2

Every software implementation process includes at least the following steps -of course every company has its own natural process. Public companies have also additional restriction and evaluation/validation processes that will extend the suggested process:

• Identify needs
• Define selection criteria
• Create a list of options
• Create the request for information
• Evaluate responses
• Reduce the list of options
• Ask for demonstrations or pilot programs
• Choose one

Tip #3

Try to isolate your needs by using the following dimensions to measure the products you are considering:

• Scale – how big the change will be?
  • Simple: are you going to organize your projects?
  • Personal: are you going to automate estimation and planning on you projects
  • Collaborative: are you going to support a team? are you going to share information? do you need to centralize team communications?
  • Enterprise: are you affecting the whole company? are you going to bill to your clients using your projects’ data? do you have virtual teams all around the globe?
• Management Paradigm – do you and your team follow a traditional or agile approach to project management?
• Process Maturity – how formal/strong is your process?
  • Chaotic: No evidence of documented processes or best practices
  • Active: Documented processes carried out, but not formalized
  • Efficient: Consistent discipline started
  • Responsive: Ubiquitous and measured
  • Business driven: Provides data and information to drive business decisions
• Implementation model – are you going to buy the product and support it by yourself? are you going to adopt the SaaS model?
• Budget -
  

Tip #4

Set your goals – do not expect to do everything better and to include any improvement during the first phase (or the initial implementation cycle). Prioritize to get faster results. Below you will find a list of possible goals that you could address with a PM software tool

• Improve project reporting and tracking
• Improve estimating and scheduling
• Reduce cost or speed process up by automating workflows
• Improve resource assignments
• Improve project communication
• Improve project team collaboration
• Improve overall project process

Every goal will impact different functional areas within an organization. You should plan your implementation to impact those areas and improve those process that will add the most value.

References:

• 7 Goals of PM Software @ Software Projects.org
  
• Software Selection @ SoftwareProjects.org
• Evolving the Maturity Level of Your Project Management Office @ CA

Project Management isn’t new in Colombia. At least for IT and software related companies Project Managers have been there forever (due to the nature of the IT and software development processes). But, there is something missing about PM here in Colombia: Team Building.

I do believe that Labor Climate and Team Building aren’t the same. As I said to Bas, almost all Colombians -good, not so good, and bad ones- will try to be your friend. Colombian people is really appreciated because of their willingness and attitude of service and camaraderie (did I write it right?). However those are two different things: try to be your friend, and be a good boss, project manager or director.

And that’s why Labor Climate seems to be amazing on Colombian SW development related companies even when “team building” is not a priority. And it could be good, because of its impact on the organizational behavior, improve the labor climate will probably  boost the team efficiency and collaboration. But, not to perform team building activities will be bad for long-term employee & employers relationship, because “personal” friendship isn’t necessarily based on the idea of personal and professional growth and career development.

Furthermore,  SW developers, designers, and architects, and IT project managers, prefers to have project-based relationships with their employers. And for those who know, contractors, even if they are good doing what they do, increase the probability of certain risks to occur -example: dependency on people because there is no knowledge spread opportunity.

To conclude. there is a big difference between “having a great time with amazing people at the office” and “having a great work experience”. It should be a balance between labor climate and team building to ensure a short-term motivation, but also a long-term relationship between employers and employees.

Self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Wikipedia

Self-organized teams can be identified by some simple rules -I didn’t think about it until I heard Esther Derby @Project Shrink- that I would try to explain as maturity levels.

• Stage One: Managing and monitoring their own work performance. They assess the complexity of the tasks and the skills required to validate and assign the work in an effective manner. Then they also monitor the progress and performance.
• Stage Two: Cross training. Team is able to identify its weaknesses and bottleneck and plan a training to transfer knowledge and skills across the team members.
• Stage Three: Hiring and Firing. This one is, one of the most difficult levels to achieve due to the ability of the team to manage/control their own cost and budget. Most of the teams do not have even knowledge about the assigned budget, the project expected profitability or even to handle overhead. This is because small teams are most of the cases self-organized and probably do not have other knowledge than its production skills -production means skills required to do the job. At this level, the whole team is able to participate during a new team member hiring process or even to decide -on a performance basis- who should leave the team.

Self-organized doesn’t mean at all “unmanaged” team, it probably means that team is a mature enough to execute few of the manager tasks -but not all of them. Even inside self-organized teams is possible to find a leader or somebody that gives directions to the team -because the team is designated to do something that for sure somebody is requesting somewhere. So, yes, self-organized also have to follow directions (client or top-management). So there is room for Project Managers. However it is complicated to find the balance between what has to be done and what has to be delegated by the PM without negatively affecting the performance. Team is mature enough to be empowered but, I believe, if there is nothing to be managed then it is probably because it is not a self-organized team, it is because it is probably a spin-off.

It depends on the project manager culture and his/her personal strategy of management implementation -could be based on trust, or performance control, or micromanagement, because not all of the PM out there will have the aptitude to handle self-organized teams. And by the way, not all the skilled workers will fit in a team of this nature, some people is great following instructions, other people would be more productive if they are empowered to take some decisions.

I was wondering why the most visited blog in my country is like E! channel, pure useless information about fancy people that have millions -that they have gained doing pure fancy things like movies. And the horrible thing is that nobody cares about IT, therefore nobody cares about IT Project Management. I even tried to create a blog for my comunity -IT PMs here in Colombia, and unfortunately it seems to be failing, nobody writes even a comment. Is it so dificult? Probably. Colombia is not the right place for an enthusiastic IT PM like me.

Should I keep writing about PM? Should I keep writing about Digital? Should I keep writing? Do I write even right? Probably I do not.

Anyway, new l&f of my blog makes me feel good , so I will keep writing for a while.

Read more >> Options >>

Strategy will give you -as PM- the tools to deal with any situation, a good strategy could be have a close relationship with the sponsor in order to use the power of the sponsor to deal with problems. Another could be knowledge, if you are an experienced professional in the area of the project execution process you can lead by example or solve the issues by bringing solutions.

It should be impossible -I will not even try to do it- to have a list of strategies, however keep in mind that if you want to do a successful management of your project you should have at least a good strategy.

El Project Management Institute ha sido abiertamente reconocido por la mayoría de compañías del sector y desde luego su certificación profesional (PMP). En la última década el número de profesionales certificados ha crecido alrededor de un 550%, y se estima que un 80% de esos nuevos miembros estén vinculados directamente con proyectos de TI.

El artículo presenta 7 razones para dicho comportamiento de la industria, los enuncio y comento a continuación:

1. Inversión masiva en TI a nivel mundial. De USD$ 2 billones en 1999 a cerca de USD$3.3 billones en 2007 -nota: billones como millones de millones. Es de anotar que el crecimiento esperado para el primer trimestre del 2008 es superior al 5% según algunas fuentes y que este periodo tambien incluye un decrecimiento asociado al “dot-com bubble”. Según el WITSA -publicación Digital Planet 2008, de mayo de 2008- la inversión estimada para 2008 será de USD$ 3.7 billones.
2. La naturaleza orientada a proyectos de las TI. Esta industria esta naturalemente asociada a los proyectos, a todo nivel: desarrollo de nuevos productos o servicios, implementaciones de SW, cambios o renovaciones de HW, migraciones, etc.
3. El fracaso de muchos proyectos de TI. El riesgo de los proyectos de TI se considera superior y segun los estudios realizados, es definitivamente un desastre el desempeño general de la industria. De ahí, supongo yo, el éxito de muchos modelos de offshoring -The Chaos Report (1995), The OASI G Study (1995), The KPMG Canada Survey (1997), The Conference Board Survey (2001) y el The Robbins-Gioia Survey (2001)
4. La creciente complejidad de los programas y proyectos de TI. Creo que este punto no requiere mayor explicación, sin embargo una frase podría resumir esta situación: ante una mayor demanda tecnológicas, la especialización de las necesidades y sus soluciones, y la madurez de un mercado sólo podemos esperar un incremento exponencial en la complejidad de los proyectos -sólo por mencionar algunas de las variables.
5. La evolución acelerada de las tecnologías. Lo que hace unos meses era nuevo, hoy no lo es, lo que hace un año era innovación, hoy es un estandar. Creo es un círculo vicioso, el crecimiento de la demanda y evolución y renovación de la oferta han mantenido el crecimiento del sector, que se ve reflejado en los valores presentados al principio.
6. La era de la información – la Tercera Ola ha llegado. Esta explicación requeriría literalmente copiar el artículo original, pero les recomiendo leer un poco sobre Alvin Toffler el autor del libro La Tercera Ola (1979)
7. Las TI son transversales a toda industria, organización, programa o proyecto. Más que esto diria que las TI prestan los servicios públicos de nuestra era y son el agua y la electricidad de nuestro siglo. Las TI estan implicitas en casi todo nuestro actuar diario, más aún en nuestro trabajo dentro de un mundo globalizado.

Mañana viernes 27, estaré intentando presentar una breve introducción a la gerencia de proyectos de software. Creo que sera más una presentación que intente generar expectativa en estos jóvenes y desde luego espero que al menos el 1% logre evitar los errores que cometí yo cuando tenia su edad -tiempo atrás en mis épocas de universitario. El reto:  hacer atractivo el tema de gerencia de proyectos en los geeks. TIP MENTAL: definitivamente no empezar la charla con Valor Ganado, o Control de Presupuesto o Procurement

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.

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.

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:

• SVN, MediaWiki and BugZilla working together
• MantisBT & DokuWiki
• MantisBT & Subversion

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