Provérbios sobre Gerenciamento de Projetos - XII

"A única situação onde você tem tudo sob controle é quando você está morto."

Dilbert - Agile

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...

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!!!

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.

Fonte: http://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager

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.    

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

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.

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

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.

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

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!!!

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:

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!!!

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”.

Fonte: site da revista Exame: http://exame.abril.com.br/rede-de-blogs/blog-do-management/2011/11/04/seja-o-ceo-da-sua-carreira/

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 (veja o link http://www.veris.edu.br/pages.php?recid=09 )

Data: 09 de novembro de 2011 – Quarta-feira. Inscrições: www.pmisp.org.br

Crystal Methods

The Crystal methods can actually be considered to be a sort of family and visually arranged in a cube as illustrated in Figure 1.

Crystal Methodologies

Crystal Methodologies is a family of methodologies developed by Alistair Cockburn. The word “Crystal” refers to the degree of hardness and the different colors of the methodology in much the same way that a crystal can have various degrees of hardness and variety of colors.  The degree of hardness pertains to the use of rigor and ceremony i.e. as the hardness increases the amount of required documentation, processes and procedures increases. The color is concerned with the “heaviness” of the project; the lighter the color the fewer the number of people on the project whereas the darker the color indicates the requirement for more resources.

There are two “core" elements of the Crystal philosophy.  The first core element is that software development can be viewed as a game of invention and communication with the main goal being to develop useful, working software.  The second element is the setup for the next game to follow. Members of the Crystal methods share values and principles and on-the-fly tuning. All of the Crystal methods are highly people and communication centric and recognize the varying human cultures.

The two rules that are common to all the Crystal methods are as follows:

1.      The project must use incremental development with increments of four months or less with a string preference of one to three months.

2.      The team must hold both pre- and post- reflection with a strong preference for mid-project reflection workshops.

One of the restrictions of the Crystal methods is that they only address collocated teams.  Thus, the Crystal methods would not apply to distributed or offshore teams for which Cockburn offers no recommendation other than to locate the team together at one location. 

As was previously mentioned the Crystal methods are denoted by colors. The color of the methods as follows: Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue. Only three of the methods – Crystal Clear, Orange and Orange Web - have been constructed and actually used on projects.  

Hoje é nosso dia!!!

Te felicitamos, hoy 3 de Noviembre, en el día mundial, del: ADMINISTRADOR DE PROYECTOS A TI, LÍDER que haces que el cambio se realice logrando los objetivos de tu proyecto, A TI, ADMINISTRADOR, que organizas, cuidas, y logras el mejor provecho de los recursos que se confieren,  A TI, EJECUTIVO que ayudas a hacer realidad los planes y estrategias de tu empresa y organización, A TI, SER HUMANO, que haces que tus equipos de personas se desarrollen y logren sus metas personales y de negocios. A TI, ADMINISTRADOR DE PROYECTOS. PARA TI, ES ESTE DÍA. ÉXITOS Junta Directiva del PMI COSTA RICA Chapter

Integra - Curso Básico de Gerenciamento de Projetos em Limeira

Ontem, estive em Limeira para ministrar o curso básico de Gerenciamento de Projetos na Integra - Empresa Junior da Unicamp - e foi um dia fantástico! Mesmo sendo um feriado, haviam cerca de 100 participantes, entre pessoas ligadas a Integra, alunos da Unicamp e da Faculdade de Tecnologia. 

Quero agradecer a presença e a participação de todos, inclusive na avaliação do evento. Os feedbacks foram muito positivos e os pontos de atenção mencionados contribuirão fortemente para melhorar o formato e a dinâmica do treinamento. Fiquem a vontade para incluírem mais comentários aqui no Blog!!!!

Faço um agradecimento especialíssimo a toda equipe da Integra. A organização foi impecável, as instalações e os recursos técnicos estavam excelentes (Apesar dos probleminhas que eu mesmo causei!) e o suporte dado a mim durante todo o evento foi fenomenal.

Parabéns pelo trabalho que estão realizando. Me sinto privilegiado por estar participando com vocês no desenvolvimento de todo o processo de gerenciamento de projetos da Integra. O próximo passo é fecharmos o plano das oficinas... estou certo que 2012 será um ano de grande aprendizado e desenvolvimento para todos nós!

Logo mais publico algumas fotos...

Um abraço a todos!!!

Carreira: saiba o que as empresas querem de um gerente de projetos

Com o crescimento econômico do Brasil, as empresas se deram conta de que o gerenciamento de projetos deixou de ser uma atividade intuitiva para se tornar uma profissão. No entanto, estudiosos e empresas divergem sobre as características que o gerente de projetos deve ter. A capacidade de orquestrar uma equipe, gerenciar conflitos, trabalhar em equipe, liderança, comunicação, organização, estão entre as principais valorizadas.

Empresas dão mais valor a liderança, comunicação, experiência em gerenciamento de projetos, negociação e conhecimento técnico. No entanto, estudiosos participantes do 8º Seminário de Gerenciamento de Projetos, realizado na Pontífice Universidade Católica, em Porto Alegre, no mês de Setembro, consideram que o gerente de projetos deve ter muita habilidade em recursos humanos, demonstrando capacidade de orquestrar, organizar e se comunicar com a equipe em prol de um objetivo comum.

Um estudo do Instituto de Gerenciamento de Projetos que avaliou boas práticas realizadas entre 460 empresas (benchmarking), realizado no ano passado, apontou as características que as organizações mais valorizam em um gerente de projetos. São elas: liderança (50%), comunicação 41%, conhecimento em gerenciamento de projetos (33%), negociação (30%), conhecimento técnico (29%), capacidade e integrar as partes (25%), atitude (23%), iniciativa (21%), trabalho em equipe (18%), gerenciamento de conflitos (15%), organização (8%) e política (6%).

O professor da Faculdade de Administração, da Faculdade de Computação e Informática e da Pós-graduação da Fundação Armando Alvares Penteado (FAAP) Armando Terribili Filho, diz que os resultados mostram o que as empresas buscam, mas também evidenciam que ainda existem lacunas na percepção das companhias sobre o perfil ideal de um gestor de projetos. "Na área de recursos humanos, eles colocam liderança com 50%, mas colocam o trabalho em equipe como 18%, o que evidentemente conflita", analisa. Veja algumas das características valorizadas pelos especialistas:

Capacidade de liderança - Essa é a principal qualidade que as empresas procuram, é o coração do gerenciamento de projetos. "Se você não souber gerenciar as pessoas, não vai ter sucesso no seu projeto, porque são as pessoas que fazem acontecer", diz Terribili.

Comunicação - Característica considerada importante entre 41% das empresas que participaram da pesquisa. "Comunicação é extremamente importante, seja com o gerente, com a equipe, com o patrocinador, com o cliente, com usuários e, às vezes, até com a mídia", diz Terribili. Para o professor, a comunicação é o balizador do sucesso do projeto, não só no gerenciamento de risco, como no sucesso das entregas e qualidade.

Visão - De acordo com um dos autores do livro Gerenciamento Ágil de Projetos - Aplicação em Produtos Inovadores Edivandro Carlos Conforto, o gerente de projetos deve ter a capacidade de resolver problemas complexos passando sua visão para equipe e se comunicando com todos os envolvidos no processo. "Principalmente com o cliente porque, em projetos inovadores, precisamos ter a visão de que o cliente, o usuário daquele produto, são fundamentais e devem participar do processo".

Conhecimento em gerenciamento de projetos - Antes as empresas valorizavam conhecimento técnico, mas hoje essa qualidade foi superada por esse conhecimento específico. "As empresas começam a encarar o gerenciamento de projetos como uma profissão. Até então, o gerenciamento de projetos era visto com uma coisa intuitiva (...) Além da pessoa ter conhecimento técnico, tem que conhecer sobre gerenciamento de projetos. Tem que saber o que é qualidade, é vital para o sucesso de um projeto", diz Terribili.

Gerenciamento de pessoas - A importância dessa habilidade é comparada com a de um psicólogo, que tem que lidar com diferentes personalidades, interesses e experiências em busca de um objetivo comum, que é a entrega do projeto. O desafio é tornar o ambiente agradável, profissional e sério. "Quem faz o projeto acontecer não é a metodologia, são as pessoas, elas são as responsáveis pela entrega, pelo prazo (...) o gerente tem que ter a habilidade de estimular as pessoas, por isso que é difícil de ser um gerente de projetos. Ele tem que cuidar dos riscos, dos requerimentos, das pessoas, da qualidade, do patrocinador, dos recursos, do cronograma...", afirma Terribili.

Capacidade de gerenciar conflitos - A capacidade de gerenciar conflitos pode ser administrada de várias formas. Apesar de as empresas apontarem o trabalho e em equipe e o gerenciamento de conflitos como características menos importantes, "em gerenciamento de projetos ocorrem muitos conflitos e essa é uma característica que o gerente projetos tem que ter", diz Terribili. Segundo ele, gerenciamento de conflitos não é, necessariamente, ser conciliador. "Às vezes, exige que você seja general e tome uma posição, em outra situação você têm que conciliar, sim".

Trabalho em equipe - Em qualquer projeto o trabalho em equipe é uma característica essencial. O gestor deve valorizar o relacionamento entre os integrantes das equipes com reuniões informais e churrascos para aproximar o time e diminuir a possibilidade de conflitos. "Eu brinco que no orçamento do projeto devem ser incluídas reuniões, churrascos porque isso traz integração, desenvolve o lado do trabalho em equipe", afirma Terribili.

Dar feedback - É importante que o gerente saiba dar feedbacks. Algumas empresas formalizam as tarefas de cada funcionário para que seja verificado o cumprimento das tarefas, além avaliar o trabalho de cada um. Terribili diz que são os pontos positivos e os pontos a desenvolver. "Jamais diga pontos fracos de uma pessoa. Quando dizemos 'ponto fraco', está estabelecido. Se eu digo 'seu ponto a desenvolver é esse', estou passando uma mensagem positiva".

Organização - Especialistas como Terribili consideram preocupante que apenas 8% das empresas valorizem a organização. Para ele, essa é uma das principais características que um gerente de projetos deve possuir. Ele defende a padronização de pastas, sejam eletrônicas ou em papel, além de sistemas de informação adequados. "Não existe mais espaço para aquela coisa pessoal: 'eu faço assim porque eu gosto, porque aprendi assim'. Tem que ter padrão", diz. Ele condena os gerentes que esquecem de reuniões, divulgação de atas, e não sabem o nome de quem trabalha com ele. "Essa coisa do 'sou organizado do meu jeito' não existe mais. Isso é desculpa de uma pessoa que precisa melhorar ".

Capacidade de orquestrar a equipe - Segundo Edivandro Carlos Conforto, saber planejar e delegar projetos não é suficiente. "Além de saber onde quer chegar e conseguir passar isso para a equipe, precisa envolver todos nesse desenvolvimento e planejamento".

Lidar com prazos - É uma capacidade considerada essencial, mas o gerente deve saber lidar diferentes prazos. "Assim como temos projetos com prazo crítico, existem outros que precisam ser gerenciados de outra forma, e o perfil dessas pessoas tem que mudar também, para que daqui a cinco anos tenhamos um produto, um serviço novo que possa atender uma demanda que ainda não existe", afirma Conforto.

Curiosidade - O profissional que gerencia projetos deve ser uma pessoa curiosa e estar em constante processo de atualização, participando de congressos e especializações, para que as novidades em gestão cheguem às empresas, afirma Conforto. "Essa pessoa é a responsável por levar essas novas práticas, novas abordagens, novas formas de gerenciar esses diferentes tipos de projetos para a organização. Ele vai ser a ponte que as organizações precisam para inovar em gestão".

Inovar em rede (Open Inovation) - É a capacidade de encontrar novas ideias através de parcerias. "Eu posso não ter a ideia aqui hoje, mas eu sei quem tem e vou formar uma parceria para que a minha empresa seja uma habilitadora da inovação, ou seja, é inovar em rede".