sexta-feira, 30 de dezembro de 2011

Projetos de US$ 25,7 bi da Vale têm risco ambiental


A Vale tem hoje uma carteira de 37 projetos de investimento com entraves devido a dificuldades de licenciamento ambiental. Desses projetos, a soma dos investimentos previstos em apenas seis atinge US$ 25,7 bilhões. O Carajás Serra Sul, para produzir 90 milhões de toneladas de minério de ferro ao ano, lidera a lista com aplicações previstas de US$ 8 bilhões. Não menos importante é a obra para elevar em 150 milhões de toneladas a capacidade da Estrada de Ferro Carajás e de embarque do porto de Ponta a Madeira, em São Luís (MA) - são mais US$ 3,4 bilhões. Em Minas Gerais, o projeto Apolo, também de ferro, está preliminarmente orçado em US$ 2 bilhões.

Para Vania Samovilla, diretora executiva de recursos humanos, saúde, segurança, sustentabilidade e energia, o grande desafio em 2012 é avançar na concessão do licenciamento para tirar do papel esses planos que somam várias dezenas de bilhões de dólares.

Em entrevista ao Valor, Vania Samovilla apontou o risco ambiental como o maior obstáculo à execução dos projetos de mineração da companhia. Ao tentar equacionar os problemas, ela descobriu que a maioria das pendências era interna, e não externa. Assim, adotou uma série de providências, como integrar as equipes da área ambiental com a de desenvolvimento de projetos e buscar maior interação com as agências ambientais. Também montou equipe de assessoramento de especialistas altamente qualificados, consultores que ajudam a Vale a aprofundar a discussão estratégica da sustentabilidade.

O "pulo do gato" nessa reestruturação foi a criação do comitê executivo de licenciamento ambiental para tornar mais ágeis as decisões internas na área. "Uma das funções do Comitê é a de acompanhar os processos para que as decisões sejam tomadas mais rapidamente e não fiquem na gaveta", informou. No momento o comitê se concentra em dois projetos gigantes de mineração de ferro da Vale no Brasil - o S11, ao sul da província mineral de Carajás, e o projeto Apolo, em Minas Gerais.

Fonte: Valor Econômico - 27/12/2011,

Saving Your Career After a Failed IT Project


The odds aren’t exactly in your favor. The Standish Group reports that more than two-thirds of all IT projects failed or didn’t meet expectations in 2008. With statistics like that, you’re probably going to face the ugly reality at least once.
Here are three tips for making sure your career doesn’t suffer:

Learn to spot failure before it happens.
Although you may not realize it the first time you work on a failing project, the warning signs are always there. If stakeholders aren’t attending meetings, developers are leaving the project or there are a lot of questions about daily expenses or resource allocations, for example, your project might be in trouble. If it happens, take some time to reflect on what those harbingers were and be on the lookout for them the next time.
Project managers should be able to step back from a project to see what’s going wrong and how they can correct the situation, says Emad E. Aziz, PMP, CEO, BRISK Consulting SAE, a project management consulting firm in Cairo, Egypt.
“They should be able to dive into the lowest level of detail and yet maintain a holistic view almost at the same time,” he says. “This allows them to learn from mistakes and measure the impact of decisions at one level or the other.”
Project managers can then transfer these learned skills from project to project, Mr. Aziz says. “This [ability] inevitably allows them to turn the negatives to positives and hence learn and progress in their careers,” he says.

Whether the project failure was completely your fault or not, you have to own up to it.
Instead of pointing fingers at others, admit your mistakes. Also clearly state what you’ll do differently next time, which will help restore your reputation.
In job interviews, failures should be presented as a balance to successful projects, says Justin Honaman, director, customer intelligence, Coca-Cola Customer Business Solutions, Atlanta, Georgia, USA.
“Most employers expect an individual to have experienced failures in life — and in projects. Honestly, expect the best leaders to learn from failures and have the strength and tenacity to acknowledge lessons learned and apply those in the future,” says Mr. Honaman, who is also the author of Make It Happen! Live Out Your Personal Brand. “Potential employers will be more concerned if a prospective project manager has never had a failure.”

Clearly, the best option is to avoid failure all together, and there are some ways to improve your odds.
Make sure you scope the project properly from its outset, Mr. Aziz says. Clearly define deliverables, project life cycle and other constraints such as time, quality, requirements and platforms. “It is very important that project managers focus on the expected benefits for which the project was incepted. They should be able to track whether the project will realize those benefits or not,” he says.
Mr. Honaman also encourages project managers to be diligent with their communication. If failure seems likely, communicate with the project’s stakeholders about potential problems long before they happen.
“You need to do meeting notes after meetings, agendas for meetings, tackle issues and define owners of those issues, document the resolution and communicate the results,” he says. “It sounds very simple, but it requires very good organization and attention to detail.

 If, despite all of your heroics, the project still fails, use that knowledge to your advantage.
“Identify what was learned from the situation and what steps were taken, to ensure the same errors are not made during the next project,” says Mr. Honaman.

Fonte: PMI Career Center, Maio 2010

segunda-feira, 26 de dezembro de 2011

Dificuldades na implantação de Métodos Ágeis


Muito se fala sobre a implantação de Métodos Ágeis em ambientes corporativos com o objetivo de agilizar e simplificar processos existentes no ambiente organizacional de trabalho. Porém, antes de implantar, é necessário refletir sobre alguns problemas que certamente serão enfrentados durante esse processo.

As metodologias tradicionais estão focadas em seguir o plano inicial, construir uma documentação detalhada, dar mais valor à ferramentas e aos processos, bem como à negociação de contratos. Por outro lado, os métodos ágeis buscam a adaptação rápida a mudanças, colaboração com o cliente, além de dar mais valor a indivíduos e interações, bem como ao progresso do produto ou serviço sendo desenvolvido.
Diante desse cenário conflituoso, os métodos ágeis enfrentam diversas barreiras para penetrar em ambientes culturalmente tradicionalistas. Talvez seja esse o maior desafio, a mudança cultural!

"Você não pode mudar a cultura organizacional sem saber aonde a sua empresa quer chegar, ou ainda que elementos da atual cultura precisam mudar"

Em outras palavras, é preciso conhecer bem o ambiente que deverá sofrer mudanças e saber claramente quais são os objetivos dessa transformação cultural. A mudança exige desaprender valores, premissas e comportamentos antigos antes que se possa aprender os novos. Os elementos mais importantes dessa mudança cultural são: apoio executivo e treinamento.

Eis aqui outro grande problema enfrentado pelos métodos ágeis durante sua implantação. É difícil obter o apoio das altas instâncias da organização, porém é fundamental. Os executivos devem liderar a transformação pela mudança de seus próprios comportamentos e assim inspirar os demais colaboradores.

O gerenciamento de equipes, tema de grande estudo nos dias de hoje, também é visto como outra imensa barreira. É o trabalho mais árduo e complexo de se realizar nesse processo. É de conhecimento geral que as pessoas representam uma grande fonte de problemas. Diante desse cenário, deve figurar o papel do líder agregador e conciliador que motiva e inspira seus liderados a formar equipes homogêneas e com um objetivo comum bem definido.

"Grandes líderes mudam de estilo para levantar a autoestima de suas equipes. Se as pessoas acreditam nelas mesmas, é impressionante o que elas conseguem realizar." (Sam Walton)

Interagir com outros departamentos da organização é outra tarefa complicada. Por isso, a mudança cultural da organização apoiada pela alta cúpula é fundamental.

Criar uma linguagem e atitudes comuns que sejam compreendidas por todos facilita as interações entre indivíduos de naturezas diferentes. Isso ajuda a criar um clima de harmonia e cooperação em prol de um objetivo comum traçado no planejamento estratégico da empresa.

Outro ponto fundamental é a interação com clientes, pois são eles quem mantêm a empresa viva!

"Não é a empresa que define o mercado. É o cliente." (Peter Drucker)

Os clientes devem participar ativamente do processo de construção de produtos, serviços ou resultados, fornecendo feedback constante. Assim como no relacionamento com os funcionários internos, a relação deve ser de cooperação no sentido de produzir os resultados desejados. Evitar conflitos e buscar soluções conjuntas são pontos relevantes dessa relação.

É válido ressaltar que esses são os principais (não únicos) problemas enfrentados pelos métodos ágeis durante sua implantação. Sendo assim, cabe àqueles que pretendem aplicar esses métodos em seu ambiente de trabalho estar preparados para as diversas situações conflituosas que irão surgir durante esse processo transitório e ser persistente e determinado. Pois, como diria  Roberto Shinyashik:

"Quem quer fazer alguma coisa, encontra um meio. Quem não quer fazer nada, encontra uma desculpa".

Escrito por Daniel Ettinger e publicado no site iMasters.com.br (http://imasters.com.br/artigo/22614/agile/dificuldades-na-implantacao-de-metodos-ageis)

domingo, 25 de dezembro de 2011

Design Thinking


Thomas Edison created the electric lightbulb and then wrapped an entire industry around it. The lightbulb is most often thought of as his signature invention, but Edison understood that the bulb was little more than a parlor trick without a system of electric power generation and transmission to make it truly useful. So he created that, too.

Thus Edison’s genius lay in his ability to conceive of a fully developed marketplace, not simply a discrete device. He was able to envision how people would want to use what he made, and he engineered toward that insight. He wasn’t always prescient (he originally believed the phonograph would be used mainly as a business machine for recording and replaying dictation), but he invariably gave great consideration to users’ needs and preferences.

Edison’s approach was an early example of what is now called “design thinking”—a methodology that imbues the full spectrum of innovation activities with a human-centered design ethos. By this I mean that innovation is powered by a thorough understanding, through direct observation, of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported.

Many people believe that Edison’s greatest invention was the modern R&D laboratory and methods of experimental investigation. Edison wasn’t a narrowly specialized scientist but a broad generalist with a shrewd business sense. In his Menlo Park, New Jersey, laboratory he surrounded himself with gifted tinkerers, improvisers, and experimenters. Indeed, he broke the mold of the “lone genius inventor” by creating a team-based approach to innovation. Although Edison biographers write of the camaraderie enjoyed by this merry band, the process also featured endless rounds of trial and error—the “99% perspiration” in Edison’s famous definition of genius. His approach was intended not to validate preconceived hypotheses but to help experimenters learn something new from each iterative stab. Innovation is hard work; Edison made it a profession that blended art, craft, science, business savvy, and an astute understanding of customers and markets.

Design thinking is a lineal descendant of that tradition. Put simply, it is a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity. Like Edison’s painstaking innovation process, it often entails a great deal of perspiration.

I believe that design thinking has much to offer a business world in which most management ideas and best practices are freely available to be copied and exploited. Leaders now look to innovation as a principal source of differentiation and competitive advantage; they would do well to incorporate design thinking into all phases of the process.

Getting Beneath the Surface
Historically, design has been treated as a downstream step in the development process—the point where designers, who have played no earlier role in the substantive work of innovation, come along and put a beautiful wrapper around the idea. To be sure, this approach has stimulated market growth in many areas by making new products and technologies aesthetically attractive and therefore more desirable to consumers or by enhancing brand perception through smart, evocative advertising and communication strategies. During the latter half of the twentieth century design became an increasingly valuable competitive asset in, for example, the consumer electronics, automotive, and consumer packaged goods industries. But in most others it remained a late-stage add-on.

Now, however, rather than asking designers to make an already developed idea more attractive to consumers, companies are asking them to create ideas that better meet consumers’ needs and desires. The former role is tactical, and results in limited value creation; the latter is strategic, and leads to dramatic new forms of value.

Escrito por Tim Brown e publicado na Harvard Business Review em Junho de 2008. 

O que torna os gerentes de projeto irritantes?


Artigo de Luiz Paiva, publicado no site www.projetizado.com.br

Quando assumem que podem fazer o trabalho da equipe
Gerentes de projeto não devem se meter a fazer o trabalho dos outros, mesmo que já tenham trabalhado nesta área antes. Trata-se de uma questão de foco, respeito e ética. Cabe ao gerente definir escopo, planejar prazos e deliverables e controlar custos, com o apoio da equipe. Também não há nada de errado em discutir diferentes técnicas e metodologias para chegar ao resultado.
O problema está quando o gerente começa a pisar na linha da arrogância e falta de respeito profissional, acreditando que pode fazer o trabalho do outro profissional melhor do que ele. Se o profissional não desempenha, há que substituí-lo, e não fazer o trabalho por ele.

Quando definem prazos ridículos
Definir uma meta de prazo insana não quer dizer que acontecerá. Este tipo de situação torna-se motivo de piada pela equipe, e o gerente perde credibilidade. No projeto, existem pressões naturais para redução de prazo, e o gerente precisa administrá-las para manter a bom senso nas estimativas, e não ceder cegamente ao que o patrocinador ou o cliente desejam.

Quando formalizam opiniões informais
Esta é ótima. Muitas vezes, especialmente em fases iniciais do projeto, o gerente quer obter algumas estimativas macro para seu planejamento. Ele insiste com a equipe que lhe passe alguns números de referência… e depois os formaliza como uma avaliação firme. Este é um “golpe baixo” que criará uma energia negativa da equipe em relação ao gerente de projeto. Pior ainda é quando, em uma reunião, ele pressiona para que se digam números em frente aos outros stakeholders, com o pretexto de que é “para ter uma idéia”. Especialmente quando quem está na reunião é o cliente, está criado o cenário para dificuldades de comunicação no projeto.

Quando estão mais preocupados com relatórios do que com resultados
Reportar atividades é fundamental nos projetos… mas bom senso também. O gerente de projeto deve saber dosar a necessidade de relatórios de status para que não se sobreponham às atividades em si. Mais ainda, deve ter o discernimento para compreender situações nas quais os relatórios devem ser simplesmente ignorados, para atender a necessidades críticas do projeto.

Quando não conhecem os detalhes do projeto
Os gerentes tem uma expectativa de que cada profissional que participa do projeto conheça muito bem sua área de atuação. No entanto, o mesmo é esperado da equipe… que o gerente saiba se comunicar adequadamente sobre o projeto e que tenha as informações chave que a equipe precisa para desempenhar bem suas atividades.

Luiz Paiva é Gerente de Projetos e mantenedor do Site www.ogerente.com

Pesquisa traz dados salariais sobre o mercado de gestão de projetos


Você sabia que o PMI disponibiliza – exclusivamente para membros – uma interessante e muito útil ferramenta on-line de pesquisa salarial? A Salary Survey Query permite que você pesquise e compare a remuneração de um gerente de projetos, programas, portfolios ou outras funções ligadas ao gerenciamento de projetos em âmbito global. A query pode ser feita por função, ano, moeda e certificação (certificados e não-certificados), trazendo como resultados a média salarial anual e a mediana salarial anual, entre outras informações.

Esse benefício exclusivo para membros faz parte da PMI Project Management Salary Survey, uma pesquisa completa (atualmente na sétima edição) conduzida pelo PMI com o apoio da consultoria independente PeriscopelQ. A pesquisa provê relatórios detalhados por região, além do resultado global, obtido com informações de aproximadamente 35 mil praticantes de gerenciamento de projetos ao redor do mundo. A pesquisa completa pode ser adquirida por US$ 150 (ou US$ 100 para membros do PMI); os relatórios regionais podem ser adquiridos por US$ 50 cada (ou US$ 20 para membros).

O relatório completo contém uma série de detalhes sobre a profissão, incluindo nível educacional, anos de experiência em gerenciamento de projetos, indústria, sexo entre outros aspectos.

O acesso a esse tipo de informação é importante para o profissional que deseja saber se sua remuneração está compatível com as suas responsabilidades e com o mercado no qual atua. Também serve de referência na busca de uma melhor colocação profissional.

Para saber mais sobre a Salary Survey, adquirir os relatórios completos ou fazer uma consulta rápida, acesse a página do PMI: www.pmi.org

Dilbert - Falhas em projetos


domingo, 18 de dezembro de 2011

Revista MundoPM é a primeira edição brasileira na Newsstand da Apple Store


A Revista MundoPM – Project Management — desenvolvida pela CINQ Technologies — é a primeira brasileira a aterrissar na Banca (Newsstand) do iOS 5 da App Store.

Especializada em gerenciamento de projetos, a MundoPM está chegando agora ao iPad e já pode ter suas edições compradas individualmente pela App Store (ao custo de US$7 cada, mas com algumas liberadas gratuitamente) ou assinaturas realizadas pelo sistema da Banca (no caso dela, US$35 anuais).

“Para a publicação ser selecionada pelo Newsstand, é necessário seguir critérios de qualidade estipulados pela Apple, como fornecer uma assinatura grátis ou autorrenovável”, explica a CINQ. Assinantes da versão impressa da MundoPM podem fazer um login pelo aplicativo e desfrutar do conteúdo em formato digital sem pagar nada a mais por ele.

A MundoPM requer o iOS 5.0 ou superior e pesa 3MB na App Store.


terça-feira, 13 de dezembro de 2011

Novidades!!!

Meus caros leitores!

Nos últimos dias, vocês notaram que fiquei um pouco ausente do nosso blog e não compartilhei novos artigos.

Pois bem... essa ausência tem um bom motivo: recentemente assumi uma nova posição no Citi, fui promovido!!!

Com esse novo cenário, naturalmente estou com uma demanda de trabalho um pouco acima da média e dedicando mais horas às minhas atividades no banco.

Em breve minha rotina será mais gerenciável e eu voltarei com tudo!!!

Abraços!


quinta-feira, 1 de dezembro de 2011

PMI Global - Estatísticas

Seguem algumas estatísticas do PMI Global, atualizados até Setembro de 2011:

Total de membros ativos: 368.349

Total de profissionais certificados ativos:
         - CAPM: 15.695
         - PMP: 464.168
         - PgMP: 625
         - PMI-RMP: 1040
         - PMI-SP: 524

Visitantes exclusivos no website oficial do PMI: 2.263.067 (Jan/Set 11)

Total de cópias do PMBOK Guide - Quarta Edição - em circulação: 895.411

Total de cópias do PMBOK Guide - considerando todas as edições - em circulação: 3.593.932

Fonte: PMI Today. Novembro 2011. pag. 4

Brazil Hits 10.000 PMI Members

Brazil recently passed an important milestone with its 10.000th PMI member. Juliano Reis, PMI's representantive in the country, notes that since 2009, project management has grown impressively in Brazil, with a corresponding increase in PMI membership from 7.000 to over 10.000. Currently there are approximately 11.000 PMI credential holders living in Brazil.

In 2010, 4.272 new Brazilian members joined PMI and started to take advantage of a large number of resources to advance their carrers and develop themselves as better project managers. Also during 2010, 1.037 practitioners earned the Project Management Professional (PMP) credential and 47 achieved the Certified Associate in Project Management (CAPM) certification. All of these statistics are significant factors in PMI's overall global growth.

What does this mean? Mr. Reis believes that Brazilians are viewing project management in a professional manner, organizations want to achieve business goals through projects and universities are preparing better professionals to fulfill the upcoming huge demand for those professionals who are able to work in project teams.

According to PMI-sponsored research, there are a large number of investments in infrastructure projects with many new organizations coming to Brazil through 2016. The economy increased a record 7.5% in 2010. Its largest increase since 1986. Helping to fuel this growth was Brazilian industry, which expanded over 10% last year. Brazil's economic growth surpassed South Korea, Japan, Germany and the United States - and also exceeded the 5% world average for GDP growth. The construction industry is predicted to be among the fastest growing in the world over the next five years.

Fonte: PMI Today. November, 2011. pag. 5.

quarta-feira, 23 de novembro de 2011

Curso de Introdução à Gestão de Projetos Agile

Nos últimos dois dias, participei do curso de Introdução à Gestão de Projetos Agile, organizado pelo PMI São Paulo e ministrado por Ricardo Guerreiro. O objetivo do curso era dar um overview das metodologias ágeis mais utilizadas no mercado, como: XP, Scrum, DSDM, Crystal, FDD entre outras.


Eu já venho pesquisando sobre o tema faz algum tempo, inclusive compartilhei alguns posts aqui no blog, e o curso foi muito esclarecedor. Depois de vários anos atuando com gestão de projetos estritamente com metodologias, digamos, "não ágeis", pela primeira vez estou atuando num projeto com a metodologia Scrum.


Tem sido uma experiência ótima, ainda mais porque estamos desafiando os próprios princípios do Scrum: a equipe do projeto não está fisicamente no mesmo local, como rege o método, estamos fisicamente espalhados pelo Brasil, Argentina, Estados Unidos, México e Cingapura.


Mesmo com os desafios da geográfia, fusos horários e idiomas, temos executado o projeto com muito êxito. Nosso daily scrum, ao invés de ser um "stand up meeting" com toda a equipe reunida presencialmente, é substituída por uma conference call, num horário que seja compatível com todos os países, tendo o Live Meeting ou Microsoft Office Communicator como suporte para visualizar arquivos. 


Nossa documentação está no SharePoint para que todo o time tenha acesso controlado ao histórico e as últimas versões (as versões vigentes) de cada artefato. Nos reunirmos de forma presencial apenas para as sessões de Sprint Planning.


Mesmo com tão pouco tempo de experiência prática com metodologias ágeis, eu já me tornei um grande entusiasta. O ritmo é frenético, praticamente todos os dias é feita uma entrega tangível e você percebe o projeto sendo construído passo a passo, pedaço a pedaço e tomando forma. A interação com o time é contínua e exige uma relação de extrema confiança mútua. Todos devem estar altamente comprometidos com suas tarefas porque as margens para atrasos são muito restritas, quando não são inexistentes.


As metodologias ágeis vieram para ficar... e eu vou embarcar nessa de cabeça!


Abraços...

segunda-feira, 21 de novembro de 2011

Completamos nosso primeiro aniversário!!!!

Hoje o nosso blog completa o primeiro ano de vida!!!

Comecei esse trabalho motivado por alguns colegas PMPs que conheci na Costa Rica, durante um congresso do PMI. Vi o quanto eles se dedicavam para divulgar as boas práticas de gerenciamento de projetos e valorizar a nossa profissão em uma região com tantas restrições e dificuldades como a América Central.

Voltei para o Brasil certo que eu poderia fazer mais do que apenas ser um PMP e participar dos eventos da área. Foi então que me tornei voluntário do PMI São Paulo e criei o blog.

É um trabalho que faço com muita dedicação, com o objetivo de compartilhar com os meus leitores temas relevantes, ajudá-los sempre que sou solicitado e valorizar a nossa profissão.

Com certeza esse é o primeiro aniversário de muitos que ainda virão! Enquanto eu estiver atuando na área de projetos, eu estarei aqui mantendo esse blog vivo e útil para vocês.

Abraços!!!

domingo, 20 de novembro de 2011

Top 10 reasons why Darth Vader was an amazing project manager


The Sith Lord Darth Vader, of Star Wars fame, often gets a bad rap, particularly in what we all think of as his ‘dark years.’

From a certain perspective his mass murder, brutal oppression, and frequent deception to serve his own ends makes him seem like a pretty bad guy. But if you look past all that to his action, you will find a very capable and effective project manager.
In the name of finding silver linings in dark clouds, I’d like to present the top 10 reasons why Darth Vader was an amazing project manager.

Number 10: Vader prioritized brutally. Over the course of Vader’s pursuit of the Rebel Alliance, you see him set and pursue priorities according to their strategic value. When he knew the plans for the Death Star had been leaked, he focused on mitigating that risk. When Luke came on the scene, he shifted priorities to recruit him to the Dark Side! Vader paid close attention to the happenings of the galaxy, evaluated the impacts of any given issue, and went after the highest priorities…time after time. No emotional attachments, no personal agendas…just the right thing to do to preserve the Imperium, and see his project through to successful completion. In project management, if you can’t prioritize, you won’t get anything done, let alone anything done well.

Number 9: Vader made decisions based on objective data, not whims. Remember that Imperial officer who had to report to Vader that they had lost Han Solo in the asteroid field, and he choked him? That was some decisive action! Vader consistently evaluated the performance of his team, and made changes to fix problems when the team didn’t perform. Sure, there may have been some fear and terror, but put all that aside. The inclination to objectively evaluate the performance of your team and not accept substandard performance is an important one. Project teams needs to feel safe and supported, but they also need to know that the project goals need to get met, and if you aren’t delivering on your commitments, changes need to get made. Thank you, Vader, for making tough choices to accomplish your goals!

Number 8: Vader made commitments, and worked hard to keep them. If you think of the Galactic Empire as something of a SCRUM project, the Emperor would have to be playing the Product Owner role. Of course, in SCRUM/Agile, the team makes commitments to achieve predefined goals over the course of any given sprint or iteration. Darth did this with the Emperor many times, and he worked REAL hard to make sure those commitments were met. I mean, how did he manage to get that second Death Star operational so quickly anyway? Hard work, that’s how. Vader understood the importance of commitments, and more importantly, the significance of fulfilling them. Trust in teams is built on commitments.

Number 7: Vader took time to re-charge, relax, and get some perspective. Projects and the achievement of project goals can often feel like super-high stakes. Everyone on the team is motivated to solve the problem, and get to done. Conflict is inevitable in that kind of environment, and a good project manager needs to get in there and confront those issues head-on. Of course, this can be exhausting, emotionally and intellectually. Vader understood this, and was careful to take time out of his busy project schedule to relax, meditate, and give himself room to gain some perspective about what was really important. Remember that awesome rehab egg thing he had in his quarters? Good project managers care, and they need to express that care, but they also need to maintain objectivity, which means they need to give themselves the time and space to regain perspective.

Number 6: Vader managed risk and expectations…pre-emptively. Remember that time when Darth Vader went to Cloud City, bought off the management, then lured Han, Leia, and Chewbacca into a trap? Genius. The amount of planning and forethought that went in to that little exercise must have been epic. After some serious prioritizations, Vader perceived the highest risk to his Galaxy, and made a plan to mitigate the risk stat! Additionally, you saw him having conversations with team members all over the place making sure they understood clearly what his expectations were with regards to the achievement of goals. Good project managers think about their projects defensively, and act to protect them aggressively.

Number 5: Such a persuasive fellow. Of all Vader’s substantial capabilities, perhaps his most effective one was his ability to persuade people to do what he needed done. With the exception of his own kids (in his defense, have you ever tried to get your kids to do something?), he did a pretty great job of getting people to cooperate (whether through fear, obligation, or The Force!). The Imperium was so enormous, so full of complexities…it must have been a serious challenge to navigate that and convince people that his vision of the project was one that they could all get behind.

Number 4: Vader picked a methodology and stuck with it…until it didn’t work. In keeping with the commitment to objectivity in performance, Vader picked his methodology of fear, manipulation, and aggression, and stuck with it, until it was clear that the methodology was not working anymore. Everyone knows that Vader betrayed his Emperor to save Luke from certain death upon Luke’s refusal to join the team in a certain role. Vader saw that his previous methods of fear and intimidation didn’t seem to work with Luke, or any of the rebels any longer. Boom! Change of tactics to get the job done.

Number 3: No problem is too big to tackle. Sure, Vader had an enormous skepticism that served him well in managing risk. All good project managers need that ability. But good project managers also have to be optimistic enough to push through tough challenges and look for solutions, however improbable their success. The point at which the Rebels had slipped off the imperial radar screen, and holed up on Hoth…Vader was feeling pretty lost at that point, you know? Where the devil had those pesky rebels gone off to? How the bantha poodoo was Vader going to find them in the enormity of the galaxy? What is that? Send out thousands of spy droids to random planets and see what turns up? Low probability of success, but still better than zero? Done! Vader’s optimism and confidence in his team’s ability to overcome all obstacles is an excellent lesson in persistence.

Number 2: It is never too late to do the right thing. Everyone is presented with choices that have questionable moral consequences. The right thing is almost always something to be wrestled with. One of the most profound moments in Vader’s career came when he took responsibility for all the morally wrong things he did, and did the right thing. He never thought it could atone, but he did the right thing anyway. Project managers will make thousands of choices in the course of a project…some of which may be of questionable moral fiber including the omissions of details, avoided conversations, hidden pieces of data all to paint a better picture of the project. Good project managers will take the time to reflect on their choices, and re-make the choices they don’t feel good about. The right thing is crucial to trust on a team, even if the right thing is a hard thing.

Number 1: Vader was never afraid of getting his hands dirty. Every project will have boundaries drawn around the responsibilities of specific roles being played, and Vader knew his own role in the imperial project. But he never asked anyone to do anything that he wasn’t willing to do himself, and he made sure he had a clear understanding and appreciation for the hard things that his team had to execute on. This, I think, is what made Vader better than just good. No detail was overlooked. He didn’t micro-manage, necessarily. He got involved in the work of the project, and his team followed him because they knew he understood and was invested in the project’s success! Whether he was force-choking a non-performing admiral, or flying a tie-fighter, he contributed to the team’s success anyway he could.

terça-feira, 15 de novembro de 2011

FDD Process #3: Plan by Feature


The third and last of the iteration-zero-style FDD processes involves constructing an initial schedule and assigning initial responsibilities. The planning team initially sequence the feature sets representing activities by relative business value. Feature sets are also assigned to a Chief Programmer who will be responsible for their development. At the end of this process, each Chief Programmer effectively has a subset of the features list assigned to them. For a Chief Programmer this is their backlog or ‘virtual inbox’ of features to implement.

The planning team may adjust the overall sequence of feature sets to take into account technical risk and dependencies where appropriate. In larger development efforts, the dependencies that have an impact on the sequence may be purely technical in nature but are just as likely to revolve around which feature sets are assigned to which Chief Programmers, and as we shall see, which classes are owned by which developers.

FDD also departs from traditional agile thinking, in that it chooses not to adopt collective ownership of source code. Instead, it assigns individual developers to be responsible for particular classes. The initial assignment of developers to classes takes place during this planning process.

The advantages of individual class ownership are many but include the following:
  • There is someone responsible for the conceptual integrity of that class. As enhancements are made, the class owner ensures that the purpose and design of the class is not compromised.
  • There is an expert available to explain how a specific class works. This is especially important for complex or business-critical classes.
  • The class owner typically implements a required change faster than another developer that is not as familiar with the class.
  • The class owner has something of his or her own that he or she can take personal pride in.
  • In addition, it can become tricky to maintain true collective ownership of code as team sizes increase. In my experience, over time, the same developers naturally gravitate to working with the same parts of the code again and again and effectively take ownership of them.

Of course, there are issues with code ownership. eXtreme programming chose collective ownership to solve real problems. We do not want delivery of features held up because one developer is waiting a long time for other developers to make changes. However, instead of allowing any pair of developers to edit any source code files whenever they think they need to, FDD address the problem differently.

Firstly, in FDD, class ownership implies responsibility not exclusivity. A class owner may allow another developer to make a change to a class they own. The big difference is that the class owner is aware of, and approves of, the change and is responsible for checking that the change is made correctly.

The other strategy that FDD uses to enable effective feature-by-feature development with individual class ownership is the idea of dynamically formed feature teams but that is a topic best postponed to the next part of this article.

As with other agile approaches, planning in FDD is not a ‘chisel in stone’ activity. Indeed, the planning team reviews and modifies the assignment of feature sets to Chief Programmers and classes to developers as often as necessary throughout the project. In addition, the planning team does not always assign owners to all the domain classes at this time and more classes inevitably emerge as the project progresses. These will get owners later. Again it is a ‘just enough’ activity.    

FDD Process #2: Build a Features List


With the first activity being to build an object model, some may conclude FDD is a model-driven process. It is not. While the model is central to the process, an FDD project is like a Scrum or eXtreme Programming project in being requirement-driven. Small, client-valued requirements referred to as features drive the project; the model merely helps guide. Formally, FDD defines a feature as a small, client-valued function expressed in the form: <action> <result> <object> (e.g., “'calculate the total of a sale'”) [Palmer-1]. By small, we mean a feature typically takes 1-3 days to implement, occasionally 5 days but never 10 or more days to implement.

Unlike Scrum and eXtreme Programming that use a flat list of backlog items or user stories, FDD organizes its features into a three level hierarchy that it unimaginatively calls the feature list. Larger projects/teams need this extra organization. It helps them manage the larger numbers of items that are typically found on an FDD features list than on a Scrum-style backlog.

To define the upper levels in the feature list hierarchy, the team derives a set of domain subject areas from the high-level breakdown of the problem domain that the domain experts naturally used during the object modeling sessions. Then within these areas, the team identifies the business activities of that area and places individual features within one of those activities. Therefore, in the features list we have areas containing activities that in turn contain features.

In practice, building the features list is a formalization of the features already discussed during the development of the object model. For this reason, lead developers or Chief Programmers can perform this task using the knowledge they gained during the modeling (FDD refers to lead developers as Chief Programmers in honor of Mills/Brooks idea of ‘surgical teams’ [Brooks]). Other members of the modeling team including the domain experts provide input to, and verification of the list as necessary.

Not only does this avoid the problems often encountered when customers/domain experts that are unused to doing this sort of formal decomposition try to do it, it provides another level of assurance that the Chief Programmers do understand what is required.

In addition, the ubiquitous language the model provides helps phrase features consistently. This helps reduce frustration in larger teams caused by different domain experts using different terms for the same thing or using the same terms differently.

FDD Process #1: Develop an Overall Model


For many who have escaped from the perils of large, upfront analysis and design phases to the freedom and discipline of Scrum and eXtreme Programming-inspired approaches, the idea of developing a domain object model at the start of a project is controversial. In FDD, however, the building of an object model is not a long, drawn-out, activity performed by an elite few using expensive CASE tools. The modelers do not format the resulting model into a large document and throw it over the wall for developers to implement.

Instead, building an initial object model in FDD is an intense, highly iterative, collaborative and generally enjoyable activity involving ‘domain and development members under the guidance of an experienced object modeler in the role of Chief Architect' [Nebulon ]. FDD Process #1 describes the tasks and quality checks for executing this work, and while not mandatory, the object model is typically built using Peter Coad's modeling in color technique (modeling in color needs an introductory article all of its own [Palmer-2 ]).

The idea is for both domain and development members of the team to gain a good, shared understanding of the problem domain. It is important that everyone understands the key problem domain concepts, relationships, and interactions. In doing so, the team as a whole learn to communicate with each other and start to establish a shared vocabulary, what Eric Evans calls a Ubiquitous Language [Evans]. The object model developed at this point concentrates on breadth rather than depth; depth is added iteratively through the lifetime of the project. The model is, therefore, a living artifact. Throughout the project, the model becomes the primary vehicle around which the team discusses, challenges, and clarifies requirements.

FDD - Feature-Driven Development - Introduction


Feature-Driven Development (FDD) is one of the agile processes not talked or written about very much. Often mentioned in passing in agile software development books and forums, few actually know much about it. However, if you need to apply agile to larger projects and teams, it is worthwhile taking the time to understand FDD a little more

The natural habitat of Scrum and XP-inspired approaches is a small team of skilled and disciplined developers. It remains a significant challenge to scale these approaches to larger projects and larger teams. Some have been successful but many have struggled.

Feature-Driven Development (FDD)  invented by Jeff De Luca  is different. While just as applicable for small teams, Jeff designed FDD from the ground up to work for a larger team. Larger teams present different challenges. For example, a small team of disciplined and highly skilled developers by definition is likely to succeed regardless of which agile method they use. In contrast, it is unrealistic to expect that everyone in a larger team is equally skilled and disciplined. For this and other reasons, FDD makes different choices to Scrum and XP in a number of areas.

In the first part of this two-part article, we briefly introduce the ‘just enough’ upfront activities that FDD uses to support the additional communication that inevitably is needed in a larger project/team. In the second part of the article, we cover how the highly iterative delivery part of FDD differs from Scrum and XP-inspired approaches.


Fonte: http://agile.dzone.com/articles/introduction-feature-driven

Curso Básico Gerenciamento de Projetos na Integra - Algumas fotos

Algumas fotos do curso básico de gerenciamento de projetos que ministrei na Unicamp de Limeira para a equipe da Integra.

Foi um grande dia!!!




sábado, 12 de novembro de 2011

Impressões sobre o Exame PMI Agile Certified Practitioner

Por João Gama Neto, publicado no site www.projetizado.com.br


Sobre o Exame:


1) -  Para quem já é PMP, é gratificante passar novamente por todo o processo de certificação: (muito) estudo, application, eligibilidade, agendamento e exame. Costumo dizer que o processo de certificação é mais importante que o título porque trás consigo um grande aprendizado e reflexões sobre nossa carreira. Mesmo sendo um Agilista antes mesmo deste nome existir (trabalhei com o DSDM nos anos 90) e  PMBOKeiro há mais de uma década, este processo me trouxe um aprendizado fantástico;


2) - As questões da prova são muito bem elaboradas e realmente exigem a experiência prévia em Agile Project Management  e o estudo de cada um dos 10 livros utilizados como bibliografia. Assim como o exame para o PMP, há tanto questões conceituais quanto situacionais, com duas ou mais respostas similares;


3) -  O que cai na prova? Acredito que não ficou nenhum tópico do PMI-ACP Certification Content Outline de fora do meu exame. Reitero que o PMI está de parabéns por ter utilizado sua bem-sucedida experiência nas outras certificações e ter criado um exame que realmente avalia o conhecimento da aplicação dos conceitos Agile. Tenho certeza que foi uma aposta certeira que terá uma excelente resposta pelo mercado;


4) -  Diferentemente do PMP, cuja prova é restrita a poucos locais, você pode fazer este exame em vários centros Prometric espalhados por todo o Brasil. A minha prova foi na Av. Paulista, por exemplo;


5) - O exame começa com o tradicional tutorial de 15 minutos. Depois são 3 horas para responder a 120 questões. Achei o tempo suficiente pois fiz a prova em 2 horas e utilizei 30 minutos para revisar as questões marcadas;


6) -  De hoje até o fim de novembro, o exame PMI-ACP permanecerá em status de "piloto". Isto significa que o resultado só sairá em dezembro. Porém, quem se inscrever e fizer a prova até 30 de novembro recebe de volta 20% do valor pago, além de se beneficiar em estar entre os pioneiros...

DSDM - Phases


The DSDM framework consists of three sequential phases, namely the pre-project, project life-cycle and post-project phases. The project phase of DSDM is the most elaborate of the three phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step approach in developing an IS. The three phases and corresponding stages are explained extensively in the subsequent sections. For each stage/phase, the most important activities are addressed and the deliverables are mentioned.

Phase 1: The Pre-Project
In the pre-project phase candidate projects are identified, project funding is realized and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project.

Phase 2: The Project life-cycle
The process overview in the figure above shows the project life-cycle of this phase of DSDM. It depicts the 5 stages a project will have to go through to create an IS. The first two stages, the Feasibility Study and Business Study are sequential phases that complement to each other. After these phases have been concluded, the system is developed iteratively and incrementally in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The iterative and incremental nature of DSDM will be addressed further in a later section.
  1. Feasibility Study
  2. Business Study
  3. Functional Model Iteration
  4. Design and Build Iteration
  5. Implementation

Phase 3: Post-project
The post-project phase ensures the system operating effectively and efficiently. This is realized by maintenance, enhancements and fixes according to DSDM principles. The maintenance can be viewed as continuing development based on the iterative and incremental nature of DSDM. Instead of finishing the project in one cycle usually the project can return to the previous phases or stages so that the previous step and the deliverable products can be refined.

DSDM - Core Concepts


The following list describes the core concepts of DSDM.

Active User Involvement
The people who will be using the product must be actively involved in its development. This important in order for the product to end up being useful to the people who will be using it.

The Team Must Be Empowered to Make Decisions
The team should be able to make rapid and informed decisions, without having to cut through red tape to get those decisions approved.

Frequent Releases
DSDM focuses on frequent releases. Frequent releases allow for user input at crucial stages in the product's development. They also ensure that the product is able to be released quickly at all times.

Iterative Development, Driven by User Feedback
The development is the system is done in iterations, which allows for frequent user feedback, and a partial but prompt solution to immediate needs, with more functionality being added in later iterations.

Changes Must Be Reversible
All products should be in a fully known state at all times. This allows for backtracking if a certain change does not work out well.

Requirements are Initially Defined at a High Level
High-level requirements are worked out at the beginning of the project, before any coding, leaving the details to be worked out during the course of the development.

Fitness for Business Purpose is the Goal
Meeting the business need is more important than technical perfection.

Integrated Testing
Testing is done at every step of the way, to ensure that the product being developed is technically sound and does not develop any technical flaws, and that maximum use is made of user feedback.

Collaboration and Cooperation are Essential
Collaboration and cooperation between all interested parties are essential for the success of the project. All involved parties (not just the core team) must strive together to meet the business objective.

20% / 80% Rule
DSDM assumes that 80% of the solution can be developed in 20% of the time that it would take to produce the total solution. DSDM focuses on this 80%, leaving another 20% for later revisions. DSDM assumes that not all of the requirements for the final solution are known to begin with, so it is likely that the final 20% of non-essential features are likely to be flawed anyway. 

DSDM - Dynamic Systems Development Method


Dynamic Systems Development Method (DSDM) is an organized, common-sense process focused on delivering business solutions quickly and efficiently. It is similar in many ways to SCRUM and XP, but it has its best uses where the time requirement is fixed.
DSDM focuses on delivery of the business solution, rather than just team activity. It makes steps to ensure the feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.


Development flow:



quarta-feira, 9 de novembro de 2011

Mais um profissional CAPM!!!!


É com grande satisfação que comunico a vocês que o PMI possui mais um profissional CAPM: Sylvio Sobreira Vieira.

Sylvio é funcionário de um grande banco brasileiro e consquitou a certificação recentemente. Essa conquista foi altamente reconhecida pela sua empresa, a qual fez questão de enviar uma mensagem para toda a equipe dando-lhe os merecidos parabéns.

A Certificação Certified Associate in Project Management (CAPM®) do PMI® é a credencial que credita o valor e conhecimentos em todos processos do PMBOK. O seu objetivo é dar reconhecimento público de que o profissional certificado tem conhecimento e experiência na Gerência/Gerenciamento de Projetos nas boas práticas de recomendadas pelo PMI.

Desejo a você muito sucesso. Estou certo que essa certificação estimulará a alavancagem da sua carreira como um profissional na área de projetos reconhecido internacionalmente. A empresa que o apoiou e reconheceu publicamente o seu esforço, só terá a ganhar mantendo você no time!

Agradeço por me autorizar a compartilhar a sua história de sucesso com os meus leitores.

Abraços!!!

domingo, 6 de novembro de 2011

Seja o CEO da sua carreira!


O que deu certo até aqui, não dará mais!”. Essa constatação sintetiza a angústia que você deve estar sentindo quanto ao seu futuro profissional. Você também deve estar se defrontando com o grande paradoxo da Era do Conhecimento: nunca teve acesso a tanta informação e, ao mesmo tempo, nunca teve tão pouca certeza sobre seu destino.
Jovens estudantes se questionam se devem seguir as carreiras tradicionais insinuadas por seus pais ou embarcar na corrida da indústria da informação abrindo seu próprio negócio. Alguns questionam até se devem continuar estudando. Funcionários de empresas estatais agonizam com as desmobilizações inerentes à  privatização. Empregados de negócios antes sólidos  acordam sobressaltados com a perspectiva de fusão ou aquisição e de “sobrarem” nesse processo. Pessoas de meia-idade questionam sua atual relação de trabalho e buscam um sentido maior para suas vidas. Aposentados precoces se recusam a sair de cena e querem se sentir úteis e produtivos. Quem não está trabalhando busca desesperadamente uma oportunidade. A maioria das pessoas que está empregada anda insatisfeita com o seu trabalho e com o rumo de sua carreira. Quais as alternativas? O que fazer?
O primeiro passo é reconhecer que ao invés de diante de um problema, você pode estar  defronte de uma grande oportunidade. Como pressentiu corretamente Clemente Nóbrega, uma das vantagens da chamada Nova Economia é que a sua falta de lógica está zerando as coisas, nos colocando, de certa forma, em pé de igualdade com os países mais avançados.
A maioria dos negócios estão sendo reinventados. As  empresas sobreviventes serão aquelas que conseguirem reinventarem-se num verdadeiro processo de “destruição criativa”. Como consequência precisamos também reinventar nossas carreiras. Chegou a hora de repensar profundamente sobre como assumir as rédeas de sua vida profissional ao invés de viver segundo a expectativa de terceiros.
Comece identificando com clareza seus Desejos, Competências, Ativos e Temperamento e pense em como transformar esse inventário em um “produto” que seja valorizado por clientes. Isso mesmo, por C-L-I-E-N-T-E-S e não pelo mercado de trabalho.
Mas, cuidado! Quando for listar suas competências essenciais fuja daquela velha e desbotada lista de Conhecimentos , Habilidades e Atitudes, um resquício da Era Industrial que se finda. O passado privilegiou o conhecimento técnico e as habilidades interpessoais — quando era importante saber tudo sobre finanças ou marketing ou técnicas de recrutamento e seleção, além de saber trabalhar em equipe,  liderar subordinados, fazer apresentações convincentes etc… Esses atributos tradicionais continuam sendo necessários mas não são  mais suficientes. Por si só, vão garantir apenas acesso a posições subalternas nos organogramas das empresas de sucesso.
Novas e múltiplas competências – de natureza negocial, empreendedora e de cidadania empresarial — diferenciarão o sucesso do fracasso na vida corporativa do futuro.
Recentemente um amigo ansioso para aumentar sua empregabilidade me consultou sobre algumas competências que decidiu adquirir como parte da sua lista de resoluções para o novo milênio: aprender outro idioma, começar aquele sonhado MBA e vencer o medo de falar em público.
Sugeri que além de tudo isso procurasse cultivar sua intuição, criatividade, integridade e  determinação em perseguir  objetivos. Essas são algumas das competências duráveis que todos devemos zelar, num mundo onde o conhecimento virou uma commodity perecível e a  capacidade de desaprender tornou-se tão importante quanto a de aprender contínuamente. E sugeri que se dedicasse mais a procurar clientes do que empregos insistindo que praticasse mais o conceito de Clientividade™ que o de  Empregabilidade.
Seus olhos brilharam e, sorrindo, me confessou que seu sonho era poder “dominar” a Internet para, quem sabe, seguir os passos daqueles que começaram seu próprio negócio.com, deixando de ser empregado.
Argumentei, então, que independente de estar empregado, procurando emprego ou pensando em abrir seu negócio, lembrasse sempre que competência não é sinônimo de conhecimento. Competente é quem agrega valor a um cliente interno ou externo com o conhecimento e as habilidades que possui.
Incentivei-o a prosseguir seu sonho com uma sugestão que também pode ser útil a você: resista à tentação de engaiolar seu futuro em troca da pretensa estabilidade de um emprego. Estratégias de carreiras que foram vitoriosas na maior parte do século XX não oferecem mais a menor garantia de sucesso. A maior de todas as competências que você pode obter será parar de pensar como um empregado e passar a agir como o dono de um negócio, mesmo que você continue na folha de pagamentos de uma empresa. Posicione sua carreira como um negócio que possui clientes internos e externos e que precisa agregar valor a esses clientes. Seja o verdadeiro CEO. de sua carreira! Essa atitude muito facilitará a tarefa de  identificar as demais competências que você precisa  para ter sucesso nesse mundo em que “o que deu certo até aqui, não dará mais”.

PMI São Paulo promove a palestra: “A Comunicação na Gestão de Projetos”


Segundo o Benchmarking do PMI (2009), a comunicação é a habilidade que as empresas consideram mais deficientes nos gerentes de projetos e também o problema que ocorre com mais frequência na Gestão de Projetos. A comunicação dos projetos pode ter mais a ver com Conflitos, falhas na integração, não cumprimento do cronograma, desvios de escopo e outros diversos problemas do que se supõe.
Serão apresentados dados que mostra que, apesar de ciente dos números de diversas pesquisas, as empresas gastam mais tempo e trabalho em outras áreas que, apesar de importantes, não têm gerado o retorno esperado.
Tendo como base o capítulo do Guia PMBOK que trata do Gerenciamento da Comunicação, diversas pesquisas do PMI e outras da Comunicação Empresarial, a palestra tem a finalidade de auxiliar o gerente de projetos numa visão integrada das necessidades, apresentando informações da Comunicação Empresarial e da Comunicação Social que podem colaborar como apoio especializado nos projetos. De problema a comunicação pode auxiliar na melhora da qualidade dos trabalhos e minimizar insatisfações. A Comunicação é como o sistema circulatório que leva oxigênio e expurga resíduos.
A palestra coloca a comunicação dos projetos como acessível a todas as pessoas, como uma área acadêmica não como um dom. Quebrando o paradigma de que somente pessoas mais extrovertidas é que podem ser boas comunicadoras.

Palestrante:
Airton Molena
Autor do livro, A Comunicação na Gestão de Projetos, pela editora Ciência Moderna. Pós-Graduado em Gestão de Projetos e Comunicação Corporativa. Graduado em Análise de Sistemas e em Comunicação Social, habilitação em Jornalismo e licenciatura em Filosofia. Trabalha como Analista de Negócios na PRODAM Empresa de TIC do município de São Paulo. Professor por mais de 10 anos no ensino médio e superior.  

Local:
IBTA - Campinas
Rua Dr. Sales de Oliveira, 1661 - Vila Industrial, perto da rodoviária nova

Data: 09 de novembro de 2011 – Quarta-feira.

Inscrições: www.pmisp.org.br