Not in charge

Recently, I was offered a position in a huge engineering project, changing transportation systems here in Bogotá. I decided to take it and I am now part of the PMO (Project Management Office), in charge of schedule and risk management. The PMO includes now 5 people and is still growing, since the project is that big.

For the last 7 or so years, I lead small software projects, 10 to 12 people tops. We didn't had a PMO, just a PM. I did all managing activities. It was doable considering the size of the projects at hand. This is my third week in this position, and I am aware of how different a project seems when you are a project worker instead of the PM.

It has been quite interesting to see how my perspective on the matters is so different when I am not in charge, and how people working in projects see their little bit of it in particular ways.

All PM books and best practices insist on communication being the main activity of any PM. It´s been sort of a revelation how more critical  this is when being a part of the team. If strategic decisions or even simple little decisions are not informed to you systematically, your job might seem irrelevant or might certainly be irrelevant. Knowing their importance before, I now give more value to team follow up meetings.

posted from Bloggeroid

Both win or lose are team results

Looking back gives perspective. You might be doing some reinterpretation of the past events, but if you are honest enough you might find the reasons that lead to the events. At least that is what I think.

I have been doing a lot of thinking of past events, those that lead to me taking the decision to close Sincronía, my former company. We had three unsuccessful projects after a long line of reasonable successful ones. What happened? What went wrong?

The first conclusion, that might be obvious to some, wasn't to me. Things don't go wrong just because the leading person (me in this case) messed up. Most of the people involved have to mess up for something to go bad. Working groups are able to level themselves, balance charges, deal with stress and move on until they reach the desired goal. When one person is not able to give his/her best, someone else takes over and keep going. When a project gets delivered in time, on budget and ending in a happy customer, you have to recognize that every single person in the project (and in the company's support system) was a part of that success.

Same happens the other way around: in order to fail you need all of the team to be unable to balance and support itself, you need a full team of people failing individually at the same time.

This is the first lesson I have learned, every single person involved helped in successes we had, and every single person helped in the final fail. Failing is easy, you get there by not caring, not having enough experience but still taking the job, not helping others, even have some serious cases of people liying, cheating or even sabotaging code. I ended up with a team that had it all to fail and it took us about 9 months to do it. I am responsible of not noticing it on time. But I was too, at that time, a person that didn't care much and wasn't interested in taking over some one else's work.

So here is what I learned and my list of unasked advice for PMs:

• Be sure to always care, and have the energy to do something about it. Don't let your self be so burned out you no longer care. Take a break when you think you can't take it any more (and don't feel guilty about it).
• Monitor individuals and their performances, but be sure to also monitor the health of the group as a whole. See how people interact, how they talk to each other, monitor if there is respect in the team. If you don't have a healthy team you will certainly fail.
• Don't hesitate (as I did) to fire those that are not working as part of the team (and not doing their jobs and expecting someone else to do it is one of the worst ways of not being a team player).
• Be sure to remember that a fail (even a huge one) does not define you. If you fail, don't care that much. Learn from it, pay for it (mistakes are often payed in the form of money) and then, move on.