Just read the PMBok book! (or not)

I still find strange that Project Management Best Practices are uncommon or not known by companies working with Engineering Projects. 

Being common in the Engineering(or almost any) discipline, projects represent doing something specific, like creating a new product, in a predefined period of time. Since the idea is to do it efficiently, using developed techniques (even templates) would be an easy way, a natural shortcut. Yet, many people still think that Project Management happens magically if you put many people and give them requirements to fulfill. It doesn´t, and after some time, the team ends up frustrated and the requirements, if fulfilled are done with pour quality or triple budget or time.

The Project Management discipline has been around for 30 year or so. There are hundreds or books, blogs, websites on the subject. You can take courses, even post graduate programs, or get certifications that are recognized worldly (like the PMP). Yet, still, in some organizations it’s a completely new and novel approach.

If by fate or choice you end up in such organizations, you might spend much of your time struggling to get your boss to read the damned PMBok. But it might not happen. It they made it so far without it, why will they want to change their approach? According to their experience, projects are messy but somehow get done.

Do you want to give the fight and try to change your organization? If you do, my advice is not to battle but show how project management techniques can solve daily problems efficiently. Take little steps, don´t fight (creating more chaos into the chaos). Remember one of the most important responsibilities of a PM is communicating. Make sure all people have the information they need when they need it, and that issues are properly communicated to the involved before becoming an issue. This talking, is nothing else but coordination. If you are able to do this successfully, you have gained a lot, and made a big step in the right direction.

Then, start using planning techniques to eliminate the sense of  "no control" your team might be experiencing. Start by doing a simple work break down structure, a list of tasks and a Pert diagram. (Try not to call them that, you boss might think you are bringing those hippie PM things). Planning means nothing if a team is not committed to fulfilling it. Try doing that, but just talking to people. A Schedule should not be enforced, but sweet talked into people. If the team is convinced the planning is right and the due dates are required to make it all work, you will then have a very decent planning and will be able to follow it and see significant delays.

Budget will not be hard to include into the plans and follow ups. Next step, will be to plan for quality. Both can be done by slowly including into the plan control activities. If you do all this, probably the project is over and you had a lot of work in it. But you will have interesting data to show your boss and your bosses boss. You can show results of using project management techniques and have arguments to keep on the battle for introducing the best practices you know really work.

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.