Tech Trained Monkey

Everyday Problem Solvers

Tag Archives: tooling

Why english

As you know (or not) I’m Brazilian. I was born in Brazil, studied in Brazil, I work in Brazil, and (I’m ashamed to say) never been to a English speaking country. Nevertheless my blog is written in English and more often than not I hear the question “Why English? Why not Portuguese?” and I my answer always is “Because I want to reach as many people as possible”. Reaching people is not why I write this blog (my motives are strictly selfish) but it’s the motive why I do it in English.

I also program in English. When people ask me why I reply: Read more of this post

Advertisements

About managing risks

A little time ago I was proposing to my manager a tool and a methodology change for our PMO. The tool and the methodology were based on risk mitigation and tracking. I am a firm believer that “Issues” don’t just come up. Issues that just come up were once risks that went unnoticed and eventually, like any living (yes I belive that risks are living beings) thing, evolved to Issues.

When I exposed the principle that the project manager had to invest time discovering risk, instead that divert time to write down risks that presented themselves (btw, the risks that become god-like-issues don’t present themselves) and that map all risks was a vital part of that, he mocked me saying something like: “So when I see that an airplane is about to crash in my building im supposed to run and create a new risk entitled plane crashing at the office?” I said no, you’re not. But the risk of loosing your primary work station should be increased to 99% and the risk of being without resources should also be increased. I also said that if you were a good project manager you would also contact HR and ask for new candidates.

Of course the example above is an extreme event. The fact is: It’s uncommon that a risk escalate so fast (like living things, once again). Risks tend to grow very slowly, being fuelled by negligence, incompetence and lack of proper organization/tracking. Most risks that become problems were actually mapped and “handled”. A perfect example is: an ex-manager of mine called the client warning that he’s servers were outdated. By doing so he actually believed that he handled the risk of not being able to deploy the product due outdated software. Fact is that the deploy date came and the deploy did not happen on date because the servers were outdated. He’s mistake was to belive that because someone was warned he would take any action. What he really should have done is called day after day and only close the risk when the client confirmed that the servers were updated, and if he did not updated by the day of the deploy escalate the risk to issue.

The tool that i proposed would handle situations like that perfectly. OK its was not a third part software but a customization on Sharepoint 2010. The tool principle is that you would not only register the risk/issue. You would have to register also what actions you as project manager took in order to solve this issue, and how effective these actions were. Yes there’s an overhead but besides a complete follow-up on the evolution of the risk/issue, a PMO manager could actually see how good each project manager is based on the effectiveness of his actions. It was a thing of art. If we evolved to a “better practise” and could assign a cost value to each task we would be able to measure how much each risk/issue costed and by implication how much each actions costed. And knowing how effective an action was, we could designate a cost-benefit value. It is utopia for most of the managers.

I must disclose that I am not a project manager. I am a developer. I develop solutions for leaving… and of course… a boy can dream…