Sunday, November 1, 2009

Project Management Best Practices: PMBOK and PRINCE 2

Introduction to Project Management Best Practices: PMBOK and PRINCE 2
by Haydn Thomas, CAOct 28, 2009

Project management best practices have been captured, explained and evangelized for more than 20 years. The first formalized methodology came in 1987 through the Project Management Institute (PMI), with its Project Management Book of Knowledge (PMBOK). Today, PMBOK is still the broadest and deepest reference of generally accepted best practices, arranged around key processes that are leveraged across market segments and departments.

Haydn Thomas is a certified architect of CA Clarity PPM Software. Co-author Julie Tilke manages IT European delivery capability for IT governance and project and portfolio management.

Adding to this “how to” process is UK-born Projects in Controlled Environments (PRINCE2), which evolved from the first edition of PRINCE that addressed a standard for IT project management in the UK. This is a generic project management method, which has an equally deep set of processes and standards focusing on end-to-end project delivery. Following is an overview of how to use these two instructional and impacting methodologies. This article, the fifth in a series of sixth, was preceded by an article which looks at how to effectively utilize multiple releases and provides recommendations for a maturing PMO.
A Guide to the Project Management Book of Knowledge (PMBOK)
Currently in its third edition since 2004, the PMI’s PMBOK Guide is the broadest and most widely used standard reference of industry best practices for project management. It identifies generally accepted and fundamental practices and guidelines that are applicable to a wide range of markets – construction, software, engineering, automotive (for example) – and crossing multiple departments, from IT to operations to services.
In fact, many government and financial organizations in the U.S. and the UK require their managers be PMI-certified. The PMBOK Guide can be used in any industry, and CA has observed that different industries will leverage different aspects of the reference guide to suit their specific needs. The PMI also issues the “The Standard for Program Management” and “The Standard for Portfolio Management,” which are complementary to one another.
The PMBOK Guide outlines five key process groups to aid in project delivery:
1. Initiating - Setting up the project for success by identifying the right team and scope, as well as determining the relationship between the project and its alignment with the organization’s overall charter.2. Planning – Developing the relevant resources, timelines and milestones, and mapping project delivery to business priorities (i.e., risk management, communications, quality, cost/budgeting, duration and sequencing, external dependencies).3. Executing – Assigning the project team and distributing information to ensure the proper activities are undertaken. This process also includes ensuring quality assurance methods are in place to address change management, organizational updates, possible changes to the plan, etc.4. Controlling and Monitoring – Ensuring the resulting product maps back to the original plan, and risk from uncontrolled external actions is mitigated. CA Clarity PPM can have a significant impact by setting up a secure infrastructure to:
a. Monitor quality, costs and scheduleb. Manage stakeholder relationships, risk and contract monitoringc. Identify discrepancies (or variations) within the project scheduled. Provide the PMO more control

5. Closing – Making sure you have delivered everything expected of the project. Once you close, you need to review the project vis-à-vis the plan and likewise ensure contract closure.
The PMBOK Guide arranges the 44 processes into nine supporting knowledge areas. Each process has identified inputs and outputs along with referenced tools and techniques.
The role of the Project Management Organization (PMO) is to address all process groups and selective processes to address their unique requirements. It should act as the guardians (via education, collateral, templates, standards) to support rollout and increase expertise of their people.
Train to Minimize Culture Shock
If imposed without a broad understanding of benefits, implementing a structured, highly articulated approach to project delivery according to the PMBOK Guide can be a culture shock resulting in unnecessary resistance. In order to gain broader end-user adoption, you should provide relevant documentation detailing the processes and standards, along with the tools and techniques, required for implementation. Proper training is critical for achieving a successful business change.

For training and certification purposes, there is a PMI support accreditation in the PMBOK Guide called the “Project Management Professional” (PMP). To obtain this, candidates are required to show an appropriate educational background and experience in the project management field. They will also be required to pass an exam to demonstrate their knowledge. To retain the credential, a Continuous Certification Requirements (CCR) Program is in place.
Beyond the initial PMI certification for staff members, you should designate a few key players in your PMO and key business stakeholders for procedure-level training. This advanced training should be mapped to some or all of the key PMBOK process groups and will be essential to ensure consistent delivery.
Ensure Roles for Both PMBOK Enforcers and Supporters
After training, organizations employing PMBOK should create roles for both top-level “enforcers” of the identified approach, along with “support” staff for consistent delivery according to the identified standards and procedures.
It should be noted that continuous development should be contributed to or undertaken by the following roles:
Enforcers: The “Enforcers” are the custodians of procedures and standards, and are responsible for their development under change management. While the enforcer’s initial charter will be to effect business change, as the PMO becomes more mature and accepted, the role will transition to one of ensuring the necessary procedures and standards are in place for continued maturation.
Supporter (Advisors): The “Support” or “Advisor” roles champion and promote the adopted framework throughout the user community through education, mentoring, and issue and change management. Each resource will have a solid understanding of the end-to-end processes and standards but can also specialize in a particular area such as execution.
Projects in Controlled Environments (PRINCE2)
Initiated by the UK Office of Government Commerce (OGC) in 1989, the current version of this best practice methodology, PRINCE2, has been in place since 1996 and is planned for an update in 2008-9. This process-based approach is a generic project management method, although widely applied by IT organizations, and has been used worldwide for its ability to be scaled and tailored to provide a standard and consistent approach for organizations.
Specifically, the PRINCE2 methodology is a framework of processes that assist the project manager by using a set of common components to reduce risk and avoid failure. To achieve this, three techniques are employed: “Product Based Planning”, “Quality Review” and “Change Control.”
Following are the eight process groups outlined by PRINCE2. It should be noted that the “Planning” and “Directing” processes remain ongoing throughout the project lifecycle.

1. Starting Up – This is done before the initiation of any project. An idea or request from the organization is raised in a project mandate. It is here that information is collected to determine the business case for the project, the plan for moving forward and the team that will be responsible for its delivery.
2. Initiating – In the initiation phase, the contract will be arranged between the project manager and project board, along with the development of a high-level plan and control approach.
3. Planning – The technique of product-based planning is used in the identification of project deliverables. In addition to the required resources, quality and testing are addressed. Monitoring and control of the progress is also undertaken.
4. Controlling a Stage – This is the day-to-day management of the stage by the project manager. Controlled production of the agreed products by monitoring key indicators allows the project manager to control the scope and achieve delivery to time, quality and budget.
5. Managing Product Delivery – This can be a highly administrative area, which defines how the project will be delivered to the project manager upon completion.
6. Managing Stage Boundaries – Managing the transition to the next stage in a controlled manner by applying a common structure. Certain items are mandated to ensure delivery of the project within scope.
7. Closing a Project – This process is a structured closure of the project, which must happen whether the deliverables have been achieved or the project is terminated early.
8. Directing – The project board proactively manages the project’s response to the external environment. Within the project, the project board should “manage by exception,” so demands on its time are kept to a minimum.


PRINCE2 is optimized for product-based planning. Here, the “product” is a result, i.e., the production of a document at the end of a task. The product falls into one of two categories:
Management Products are items required to support project management, e.g., a business case, project scope, quality log, etc.
Specialist Products are items contributing to an identified deliverable of the project, e.g., a piece of code, specification, etc.
Ultimately, PRINCE2 helps to provide control and an adaptable method for your business. This is a proven, tailored method for project management, especially in IT. Essentially, PRINCE2 helps PMOs control the chaos of project delivery.
Configure to Your Needs
Success with PRINCE2 comes from configuring it to meet your specific needs. PRINCE2 is more prescriptive than PMBOK, and more detailed, therefore configurations in process or standards are common. For example, in some organizations, there might not be a need for the role of “senior supplier” as outlined in PRINCE2, so users might either rename or re-scope this role.
Don’t Ignore Training
Training is vital. The PMO needs to be trained on methodology. Review of the method (PMBOK or PRINCE) is a lengthy process, but subsequent payoff in execution support is equally large.
PRINCE2 is widely supported by accredited organizations to assist in training and implementation. OGC’s partner organization, APM Group Ltd (APMG), provides two-tier courses called “Foundation” and “Practitioner.” The latter course must be taken to become a registered practitioner, and a re-registration exam every three to five years is required to maintain the designation.
The ability to provide template plans according to the organization’s approach, governance by configured workflows, and control over stages, etc. enables the PMO to manage the effective rollout of PRINCE2.

Sunday, October 11, 2009

Onde está Wally, o Analista de Sistemas?

O conhecimento no Negocio é um valioso trunfo para os Gerentes de Projeto, que pode fazer a diferença entre o sucesso e o fracasso de um projeto.
Recentemente, lendo um artigo entitulado “Whose Job Is it, Anyway?” de autoria de Gary R. Heerkens, MBA, CBM, PMP, na Revista PM Network (PMI Sep 2009 N.9), na qual o autor explora as vantagens de se conhecer o Negocio na qual se gerencia o projeto, me veio a mente a figura do “Antigo Gerente de Projetos, o então Analista de Sistemas”, sujeito que, nos primordios da Tecnologia de Informação, buscava “traduzir” para uma linguagem técnica, as necessidades de informação de clientes e departamentos, constituíndo-se no elo de ligação entre os “Programadores de Computador”, técnicos de linguajar indecifrável, dominadores das linguagens de programação e do mundo cibernético, e os “Usuários”, conhecedores de operações de Negocio, ávidos por informação que facilitasse o processo de gerar valor a companhia. O Analista de Sistemas, geralmente um ex-Programador, com experiencia em diversos projetos, de diversas areas da companhia, e ainda com a comunicação mais desenvolvida do que aquele “Tecniquez Bit-Byte”, apoiava-se na experiência previa em programar e configurar, para atingir positivamente aos Programadores, elaborando especificações de programas cada vez mais objetivas , bem como, usando o conhecimento adquirido junto aos Usuários, de forma a atingir não só o requerimento do cliente, mas também os objetivos do Negocio. Para tal, o Analista de Sistemas tinha que contar com a curiosidade aguçada, a vontade de conhecer os meandros, fossem dos Computadores, fossem dos processos de Negocio. Esses “Pre-Gerentes de Projetos”, apesar de não serem experts nesse ou naquele processo de Negocio, ou nessa ou naquela linguagem de Computador, constituiam o importante elo de ligação entre o objetivo e o resultado, entre o sucesso e o fracasso.
O mundo evoluiu, a tecnologia ficou mais amigavel, as metodologias de projetos foram desenvolvidas, os Usuários estão mais conscientes do que precisam.
Atualmente porem, me deparo com Gerentes de otima formação, muitos certificações por entidades idoneas, internacionais, possuem MBA etc., e que atuam em diversos Projetos, por longos períodos tempo, e que, apesar disso, findos tais projetos, não são capazes de listar os benefícios daquelas iniciativas pela perspectiva, seja de Negocio, seja de Tecnologia, limitando seus esforços em dominar a teoria do Gerenciamento de Projeto, as Metodologias, as Ferramentas etc.. dando-me a impressão de que, apesar das características de um Projeto que aprendemos nos primeiros contatos com a atividade, essa função tornou-se puramente seguir uma cartilha, uma receita de bolo.
Um Projeto é o meio de se atingir um objetivo, através de ações e tarefas coordenadas, envolvendo pessoas ou não, tal qual aprendemos no primeiro dia de aula ou nas primeiras linhas da literatura especializada disponível. Isso significa dizer que o fim de um Projeto vai trazer melhoria em um processo, em um Negocio. As habilidades de um Gerente de Projetos incluem a vontade de transformar, de melhorar e aprender, o que não cabe em um processo repetitivo. De nada adianta dominar técnicas como “Prince2”, “Scrum”, “MSProject 2007 Server”, comunicação eficiente, apoio da direção etc.. se um projeto não trouxer benefícios, não só para nossos Usuários/Clientes, mas também para nós, os Gerentes de Projetos.
Ai cabe perguntar: por onde andam os “Analistas de Sistemas” ou os “Pre-Gerentes de Projeto”, profissionais muitas vezes chamados pela direção de suas companhias para participar das decisões de Negocio, tamanho era o conhecimento que detinham nos processos, e não somente nos impactos em sistemas?
A complexidade dos projetos, apesar da tecnologia, metodologia, formação etc., tem aumentado mais e mais nos tempos atuais, o que tem demandado esforço extra dos Gerentes de Projetos em lidar com tantas variáveis. ERP, BI, WEB, Cloud computing etc.. tem se mostrado eficientes e flexiveis mas, devemos lembrar que, por tras dessas ferramentas, um processo de negocio deve ser atendido e mais do que isso, entendido e, cabe ao Gerente de Projetos, senão o papel principal, o coadjuvante na transformação de uma ideia em implementação bem sucedida.

Wednesday, September 30, 2009

Como é de conhecimento público, a EDS foi adquirida pela HP a cerca de 1 ano e agora o processo de transição se esta finalizando, então ai vão algumas informações a respeito da minha nova companhia...

Fonte: Isto É Dinheiro - Nacional - NAAS MIL FACES DA HP 2009-09-30p.52,53,54

NO INÍCIO DE OUTUBRO, AS PORTAS DE uma nova loja no shopping Anália Franco, em São Paulo, vão se abrir. Nas prateleiras, computadores, impressoras e servidores com a marca HP. O espaço, batizado de HP Store, é um dos 18 pontos de venda próprios que a empresa terá no País até o final do ano. Em 2010, esse número deve chegar a 40. Não, a HP, uma das gigantes na fabricação de computadores, não se transformou em uma empresa de varejo. As lojas que ostentam seu logotipo expõem um movimento que se alastra como um tsunami entre as fabricantes de hardware de todo o mundo. Cada vez mais, computadores, impressoras e outros tipos de equipamentos se transformam em commodities, o que os coloca como alvo fácil da concorrência devastadora dos países asiáticos. Por isso, colossos como Dell, IBM e Cisco migram rapidamente para outros campos de atuação, nos quais as margens são maiores e a HP não ficou indiferente a essa tendência. O grande passo nessa direção ocorreu em 2008, quando adquiriu a EDS, uma das maiores empresas de serviços em tecnologia da informação. No Brasil, quando acabar de digeri-la, em maio do próximo ano, a HP será uma organização seis vezes maior em número de funcionários. A matriz olha com atenção esse movimento por aqui. "O Brasil é visto pela corporação como uma oportunidade para manter seu crescimento acelerado", afirma Mario Anseloni, presidente da HP do Brasil. Diferentemente das outras regiões consideradas mais maduras, a subsidiária brasileira não tem a liderança total em todos os mercados em que atua. "Temos muito espaço para crescer", garante Anseloni.verdadeiras. De um lado, a necessidade de expansão abre a porta para novos investimentos da companhia no mercado local. Por outro, revela que a subsidiária brasileira não reflete aqui dentro o que a corporação representa lá fora. Líder mundial em PCs, a empresa amarga aqui, segundo estimativas do mercado, a terceira colocação, atrás da Positivo e da Dell. Mais: de acordo com analistas, o Brasil responde por apenas 25% do resultado total na América Latina. Para reverter essa situação, a HP procura se aproximar mais do consumidor. Uma das estratégias é a abertura das HP Store. Semelhantes à Apple Store e à Samsung Experience, esses espaços darão glamour à marca HP. Dez lojas já estão em funcionamento. Até o final do ano, mais oito serão abertas em São Paulo e em outras cidades de diversos Estados.Ao mesmo tempo que se aventura no varejo, a HP volta-se definitivamente para a área de serviços com a compra da EDS por US$ 13,9 bilhões que agora passa a chamar HP Enterprise Services. A aquisição permitiu reforçar sua posição na competição com a IBM. No entanto, há um grande desafio pela frente. A EDStem quase 140 mil funcionários pelo mundo a HP tem 300 mil. No Brasil, embora o número exato não seja divulgado, a proporção é dez mil contra dois mil. "A HP, que sempre foi voltada para as máquinas, terá que aprender a lidar melhor com gente. Será um grande desafio", afirma o especialista em gestão tecnológica Adalton Ozaki, da Faculdade de Informática e Administração Paulista. Nesses momentos, sempre vêm à mente os acontecimentos de 2001. Naquele ano, a fusão com a Compaq resultou em desastre. A prometida sinergia entre HP e Compaq não compensou os US$ 19 bilhões gastos e a então CEO Carly Fiorina, eleita pela revista Fortune a executiva mais poderosa do mundo, foi demitida. Desta vez, no entanto, HP e EDS mantiveram em sua carteira os 200 maiores clientes de outsourcing no mundo. Mais de 15 mil contratos foram firmados desde agosto de 2008. Por aqui, garante Anseloni, os negócios já começaram a florescer. Entre os novos clientes, estão a Mediai Saúde e a Oi Paggo.0 bom desempenho no Brasil é fundamental para a corporação. A dependência do resultado de subsidiárias tem se tornado cada vez mais importante. No ano passado, 70% dos USS 118,3 bilhões das receitas da HP vieram de unidades fora dos EUA. A região dos BRICs é responsável por 10% desse total. "No Brasil, as Unhas de negócios da HP crescem mais rápido do que a média do mercado", afirma Anseloni. Além disso, o modelo de gestão brasileiro tem servido de exemplo para outros países o que para Anseloni significa uma vitória em sua trajetória de 11 anos na empresa. "Um belo dia resolvi sair da IBM, ao perceber que não atingiria minha meta de ser presidente de uma grande empresa brasileira até os 40 anos", conta Anseloni. A grande virada o levou a fazer um MBA nos EUA. Na época, vendeu carro, apartamento e telefone para pagar o curso. Lá, acabou contratado pela HP e chegou ao posto de responsável pela América Latina, em Miami. Quase dez anos depois, se tornou o principal executivo do Brasil com uma missão: consolidar a liderança do mercado. Sua primeira ação foi dividir o poder entre diversas áreas da empresa. Todo mês, oito comitês de funcionários discutem como melhorar a integração na empresa. "E um processo de gestão em que a diretoria envolve mais gente", diz Anseloni. "Esse sistema faz o que o modelo hierarquizado das multinacionais não permite", afirma Ana Lúcia Caltabiano, diretora de RH da HP. "Esse é o segredo do sucesso." Um sucesso que passará por seu maior teste quando a HP incorporar definitivamente a EDS e multiplicar seu tamanho por seis. 0

Friday, September 25, 2009

Fonte: www.projetizado.com.br
Os 10 Mandamentos do Gerenciamento de Projetos:

I – Estreitarás teus escopos. Nada é pior do que um projeto interminável. Ele pode sugar todos os recursos e esgotar até mesmo a equipe mais motivada. Para manter os projetos firmes e orientados, concentre seus maiores esforços em projetos menores, que tenham entregas (”deliverables“) alcançáveis e que possam cumprir seus prazos. A longo prazo, uma série de vitórias pequenas tem mais impacto sobre a organização do que uma gigantesca orquestra sinfônica que nunca chega a tocar.
II – Não tolerarás equipes inchadas. Uma boa maneira de começar com o pé direito é garantir que a equipe do projeto terá o tamanho certo. Equipes maiores são mais difíceis de motivar e administrar, e as personalidades podem ficar no meio do caminho, atrapalhando o trabalho. Não existe um tamanho ideal para a equipe, mas uma boa regra empírica é ter uma pessoa para cada papel e um papel para cada pessoa. Se alguns integrantes tiverem que desempenhar mais de um papel, tudo bem – se você for errar o dimensionamento, erre a favor de uma equipe menor.
III – Exigirás dedicação de todas as áreas envolvidas. Se a área de TI aceitar um prazo apertado, mas parte dos documentos de projeto precisar ser aprovado pelas demais áreas da organização, e elas não estiverem comprometidas da mesma forma, o projeto acaba virando uma gincana. Se as áreas de negócio aceitam um prazo apertado, mas dependem de um aplicativo a ser desenvolvido pela área de TI, que não está comprometida da mesma forma, o projeto também acaba virando uma gincana. O gerente de projeto deve se posicionar de forma a que todas as áreas diretamente envolvidas no sucesso do projeto estejam comprometidas, e disponíveis na medida da necessidade, desde o princípio.
IV – Estabelecerás um comitê para analisar o andamento. O comitê de acompanhamento, qualquer que seja seu título oficial, é o corpo diretivo do projeto. Ao mesmo tempo em que lida com questões relacionadas às políticas e estratégias da empresa, ele pode e deve remover as lombadas e obstáculos do caminho do projeto. Um arranjo típico envolve reuniões quinzenais das áreas de gerência intermediária envolvidas no projeto, para analisar seu andamento e verificar como se envolver das formas descritas acima.
V – Não consumirás tua equipe. O ‘burnout’, ou esgotamento físico e mental dos membros da equipe, causado pelo stress e esforço das atividades, não é incomum. Fique atento às necessidades das pessoas e evite este efeito que reduz a efetividade da equipe – não planeje de forma que o envolvimento das pessoas vá exigir sacrifícios incomuns e continuados. Em particular, evite o efeito do envolvimento serial: o popular efeito “sempre os mesmos” – pessoas que se destacam por resolver bem os problemas que recebem, e assim acabam sendo envolvidos em mais projetos do que seria racional, gerando stress para elas, e disputa de recursos para os projetos.
VI – Buscarás apoio externo quando necessário. Adotar consultores em gerenciamento de projetos é uma forma de prevenir o esgotamento. Além de aumentar as equipes, os especialistas externos muitas vezes podem trazer valiosas novas idéias, perspectivas e energias. É essencial trazer o profissional certo no momento certo: especialistas nos aspectos técnicos e de mercado não são a mesma coisa que especialistas em gerenciamento de projetos. Considere as características do projeto e da equipe antes de definir o tipo de apoio externo necessário.
VII – Darás poder às tuas equipes. Equipes de projeto que já estejam se esforçando para cumprir seus escopos e prazos não precisam ter preocupações adicionais com questões formais como o preenchimento de formulários de registro de atividades para seus departamentos, ou participação em reuniões periódicas de seu órgão de origem. Ao invés disso, eles devem ter o poder discricionário de dedicar-se às atividades essenciais e que agregam valor ao projeto, e a estrutura deve se esforçar para adaptar-se a estas condições. Mas é importante que os membros da equipe correspondam a esta confiança, saibam claramente o que se espera deles e de que forma devem usar sua iniciativa.
VIII – Usarás ferramentas de gerenciamento de projetos. Tarefas mundanas de gerenciamento de projetos podem ser automatizadas. Procure ferramentas que ofereçam acompanhamento do andamento, gerenciamento de tarefas, gerenciamento do fluxo de trabalho e análise de recursos, e que funcionam em uma plataforma de Intranet que promova o compartilhamento e a comunicação. Mas lembre-se de que usar tecnologias que acrescentem uma camada extra de complexidade a um projeto já desafiador por si pode não ser uma boa idéia.
IX – Reconhecerás o sucesso. Todos os participantes do projeto devem ser reconhecidos de forma positiva pelo esforço que praticaram. As recompensas não precisam ser extravagantes. É fundamental que a origem real do reconhecimento – seja a Presidência, a direção da filial regional, o principal patrocinador do projeto ou o seu gerente – fique clara para todos, e que se manifeste de forma tão individual e personalizada quanto possível.
X – Não tolerarás gambiarras. Políticas sólidas de gerenciamento de projetos devem eliminar antecipadamente a tentação de recorrer a alternativas rápidas e rasteiras, que só levam a erros, desperdício, retrabalho e frustração.

Wednesday, July 22, 2009

Program Management, more than projects interaction and reports

Most of companies around the world, don't consider the Program Manager on their job codes. This role is, generarly under IT Manager, that also represents the Adm Management over the IT resources. Of course the Adm Management will be focused by the IT Manager, so the Programs will tend to be a merge of milestones in a report. Otherwise, Program Managers usually don't consider their programs impacting the Business Directions, acting as Project Managers Sr., instead of act as a Business support representative. I belive both experience should be merged in order to prove the Program benefits.