Matéria publica no periódico interno da empres

O Escritório de Gestão de Projetos (EGP) é uma célula da Gerência de Mudanças e de Segurança da Informação (GEMSI), da Diretoria de Tecnologia da Informação (DINFO). Desde março de 2008, o setor está voltado ao gerenciamento de projetos de tecnologia, fundamentado nas melhores práticas em gerenciamento de projetos, o Project Management Institute (PMI), entidade mundial que visa padronizar os processos de gerenciamento de projetos.

O gerente da GEMSI, Iberê Ranieri Junior, recebeu a reportagem do Janela Eletrônica, a partir da pauta sugerida pelo Comitê de Comunicação Interna, e explicou mais sobre a atuação do setor.

A missão do EGP é gerenciar o portfólio de projetos da área de tecnologia, fomentando as boas práticas em gerenciamento de projetos, por meio de orientação, apoio e monitoramento, buscando aprimorar as soluções de TI no suporte aos negócios da Companhia. Além disso, faz parte das atribuições do EGP divulgar a cultura de projetos para a Aliança do Brasil.

A DINFO considera o gerenciamento de projetos um conjunto de conhecimentos, habilidades, ferramentas e técnicas utilizadas para se obter sucesso nos projetos. Por isso, metade dos funcionários da Diretoria possuem treinamento em Gestão de Projetos.

O EGP é composto por Luciana Borges Moreira, Rodrigo Fonseca Messias, André Vasconcelos Campos e Carolina Miranda Fachini e as demandas para a DINFO passam por seis macro-processos, nos quais a equipe atua da seguinte forma:

Comitê de Priorização – O Escritório é responsável pela organização e registro de uma reunião mensal realizada para priorizar por meio de um ranking as demandas que são apresentadas à DINFO.

Indicação e Treinamento do Líder de Negócio – para iniciar o projeto, o EGP solicita à gerência demandante a indicação de um funcionário para atuar como Líder de Negócio – responsável pelo projeto em nível de negócio e pela intermediação entre outras áreas. Esse líder receberá um treinamento para compreender a sua importância e as suas responsabilidades no projeto;

Reuniões iniciais – nessa reunião, é publicado um documento chamado Termo de Abertura do Projeto, o qual autoriza formalmente a existência do projeto para a DINFO e a alocação de recursos humanos, financeiros e materiais para o projeto;

Reuniões de planejamento – com o documento preenchido e assinado, o EGP dá início ao planejamento do projeto, no qual procura-se identificar o trabalho que será executado. Essa etapa tem participação de todos os envolvidos e interessados no projeto e o resultado é um documento chamado Declaração de Escopo – Linha de Base do Projeto que será a referência para todo o trabalho – que pode ser entendido como um acordo entre os interessados e envolvidos sobre o que o projeto deverá gerar em termos de produtos, serviços ou resultados.

Execução – o EGP auxilia no monitoramento e controle do trabalho que é executado por meio de comparações entre o que foi planejado e o que está sendo executado.

Encerramento – quando o gestor demandante aceita os produtos, serviços ou resultados gerados pela DINFO por meio dos projetos, o EGP publica para os envolvidos no projeto as variações do projeto em termos de escopo, tempo e custo, bem como informações de Valor Agregado como Índice de Performance de Agenda e Índice de Performance de Custo. Esses índices mostram como o projeto progrediu ao longo da execução em relação ao que fora planejado, e formam uma base histórica para se medir a maturidade em gerenciamento de projetos.

O EGP atuou até o momento em 36 projetos de médio (demandas com mais de 160 horas de esforço) e grande porte (demandas com mais de 480 horas de esforço). Considerando o gerenciamento de projetos como uma disciplina que passa por um processo de amadurecimento, o EGP tem planos para adicionar outras melhores práticas, em busca da excelência na gestão de projetos.

By Meridith Levinson

September 23, 2008 — CIO —

Project managers are ultimately responsible for making sure projects are completed on time, on budget and with the features and functionality specified by the project’s stakeholders. So one would presume that project managers’ performance would be evaluated based on those same criteria. It sounds obvious, right?

In fact, it’s not always the case that project managers are evaluated on the basis of whether their projects are completed on time, on budget or with the required functionality.

At EDS, for example, project managers are reviewed based on subjective criteria, such as their communication skills, passion for achieving business results and business ethics, according to Jed Zaitz, a senior project manager with EDS’s Medicaid Management Information Systems Group. Zaitz says objective, measurable criteria, such as whether a project manager’s projects are completed on time or on budget, are not factored into performance appraisals for project managers at EDS because in many cases those metrics aren’t available.

But Zaitz wants that to change.

“Project managers, unlike business analysts, testers or developers, have responsibility for project delivery, and they should be measured on their success or failure. That should at least be factored into the appraisal,” he says. “To ignore objective metrics makes no sense.”

Objective Metrics Are Key to Company Success

Zaitz, who earned his PMP (project management professional) certification from the Project Management Institute, believes objective metrics can help improve project managers’ project delivery rates. If, during performance reviews, project managers find out exactly where their performance is falling short, their managers can talk with them about ways to improve their performance.

“Improvement of one or two percent in a project manager’s performance would add huge numbers to the bottom line of a company,” says Zaitz, who’s worked for EDS for 32 years. “Even a small improvement would have very significant results.”

Zaitz developed a methodology for evaluating project managers’ performance about nine months ago, while he was managing a team of 15 project managers who completed five to six projects each year. The methodology is based on the traditional definition of a successful project: one that comes in on time, on budget and with few defects.

Zaitz’s Performance Review Methodology

Here’s how Zaitz’s performance review process works: Project managers earn 100 points for completing a project. But if the project isn’t completed on time, the project manager gets points docked from his score—say two points for every week the project is late.

Similarly, if the project comes in over budget or is implemented with defects, the project manager loses points—such as a half a point for each defect found within 60 days of the project going live or a half a point for each one percent the project went over budget.

Project size is also taken into consideration. Zaitz measures the size of each project according to its number of function points.

Zaitz notes that organizations can subtract more or fewer points from a project manager’s score depending on which elements of project success (e.g. time, budget and quality) they wish to emphasize. For instance, if an organization prizes speed over quality, and if a project manager misses the go-live date, the project manager could be docked five points for each week the project was late instead of two.

Though Zaitz’s methodology is focused on objective metrics, it takes into consideration stretch goals, such as early delivery of projects and technical productivity (getting more done with fewer resources or for less money), and soft skills. For example, if project managers complete their projects ahead of time or under budget, they can earn bonus points (especially if quality is not compromised.)

EDS hasn’t adopted Zaitz’s methodology, but the senior project manager says one group within the company plans to pilot it. He adds that rolling out the methodology throughout the company, which was recently acquired by HP, will require a significant cultural change. But the reward may be greater than the risk.

Says Zaitz: “For an organization like EDS, which probably has 1,000 project managers, it’s very important to know its true top performers because if a new project comes up that’s very challenging for a very important customer, you want to pick the right person to work on it.”

If you’re interested in learning more about Zaitz’s methodology (he’s written a white paper on it), you can contact him at jed dot zaitz at eds dot com.

Other stories by Meridith Levinson

© 2008 CXO Media Inc.

By Meridith Levinson

August 28, 2008 — CIO — IT project management practices are stuck in the mud, and they’re hindering IT departments’ ability to deliver projects successfully. That’s the conclusion of a recent Forrester report, “Stretching Your Project Management Muscles,” which was published in July.

Mary Gerush, author of the report (and a former IT project manager herself), notes that the project management discipline has not kept up with the pace of change in business or in IT.

Gerush writes that while IT departments have adopted service oriented architecture (SOA) and Agile software development practices to become more responsive to business needs, the project management discipline has remained largely focused on methodology. And traditional project management methodologies are proving to be too rigid, cumbersome and bureaucratic for today’s mercurial and competitive business environment. In fact, Gerush notes, these methodologies can work against IT departments.

“Traditional project management practices, which are designed to improve the likelihood of project success, often have the opposite effect in a dynamic, rapidly changing environment,” writes Gerush in her report.

The reason traditional project management methodologies can backfire on IT departments is because they require so much rigor. For example, says Gerush, project managers have to follow scores of pre-defined processes and steps, and they have to deliver reams of documentation at each phase of the project—all of which dramatically and often unnecessarily protracts projects.

“There’s so much rigor and normally so much documentation and so many processes you have to go through to follow a methodology that it weighs you down and that you can’t move as quickly as the business needs you to move or as quickly as technology enables you to move,” she says.

The Remedy: Flexible Project Management

To keep pace with the business and with the rest of IT, project management offices need to make their project management practices more flexible. Gerush offers five measures project management teams can employ to improve their responsiveness.

1. Adopt a framework. A framework is a collection of various pieces of project management “functionality,” says Gerush. When projects come in, the project management office can choose which pieces of the framework to use to provide just the right amount of oversight necessary for the project, as opposed to following every step of a methodology.

2. Figure out which deliverables you really need. “For projects of short duration, an informal e-mail status report may be more appropriate than a formal document, and formally documented use cases and design specifications may be overkill for some projects,” writes Gerush. That’s why she advises project managers to customize project deliverables according to each project’s needs.

3. Incent project managers differently. Project managers are usually rewarded for delivering projects on time and on budget, and of course, they rely on their methodologies to accomplish those goals. But if you want project managers to become more flexible, you have to encourage that behavior, writes Gerush. So reward them when they adapt easily and quickly to changing business needs, even if their maneuvers impact timelines and budgets ever so slightly.

4. Train project managers to be leaders rather than control freaks. Left-brained project managers can over-rely on their analytical skills to complete projects on time and on budget. “But flexible project management is not a left-brain, black-and-white endeavor,” writes Gerush. “It requires the full brain and touches on all shades of gray, requiring understanding and exercise of adaptive leadership versus command and control.”

5. Keep improving your project management practices. Your approach to project management should evolve alongside the business and IT. Solicit project stakeholders and business partners for their ideas on how you can make your project management practices more responsive.

Other stories by Meridith Levinson

© 2008 CXO Media Inc.

Everyone knows who the business analysts are in their organization, but not everyone knows what they actually do and what they are responsible for during software implementation projects.

April 28, 2008 — CIO — Anyone who has ever worked on a complex and lengthy software development project knows that the involvement of a business analyst can mean the difference between success and failure. And that involvement starts at the very beginning of a project.

Generally speaking, most business analysts “own the requirements processes,” where they work with key line-of-business executives and users on just what it is they want from a new application, says Carey Schwaber, a senior analyst of application development at Forrester Research.

“If you believe that software projects succeed or fail based on the quality of the requirements,” Schwaber says, “then you believe that software projects succeed or fail on the basis of business analysts, too.”

Beyond gathering requirements, however, the other important duties inherent to the business analyst role (besides being a good communicator) are still not well-known today. In fact, according to Schwaber and fellow Forrester analyst Rob Karel, not many people, including business analysts themselves, have determined a standard definition (complete with typical skill sets, proper training methods and set career paths) for the business analyst position. Business analysts, for instance, are also known as: business systems analysts, business technology analysts, system analysts or requirements analysts.

“Everyone agrees on the importance of the business analyst role,” Schwaber and Karel write in a recent report, “but few know exactly what it is that business analysts do.”

Eight Business Analyst Responsibilities

Scott Ambler, the practice leader of agile development for the IBM Methods Group and author of several books on software project management and agile development, says that first and foremost, business analysts (or as he terms it, business systems analysts, or BSAs) are responsible for communication and collaboration between the business and IT.

“The most important responsibilities of a BSA are to act as a communication conduit between the stakeholders and the team,” Ambler says, “to represent the stakeholder community to the development team if the developers themselves don’t have direct access, and to translate the business needs for the team.

Ambler developed a list of eight activities that business systems analysts will usually perform on a traditional software development project:

1. Scope the system. At the outset of a project, business analysts may be the only “software development staff” assigned to the project, Ambler writes. And at this point, they work with key project stakeholders and business people to formulate and communicate the business vision for the project, map out initial requirements and the scope of the project.

“Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic,” Ambler writes.

2. Interpret business needs. A critical responsibility of business analysts is “to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand,” Ambler writes. A key skill needed in this part of the process is the business analyst’s ability to distill the differing messages and needs of project stakeholders into a single, consistent vision.

“This task often includes significant negotiation and political maneuvering,” Ambler writes. Business analysts will “often find themselves spending significant time in meetings, thereby saving the rest of the development team from this inefficient use of their time.”

3. Translate technical issues. Business analysts also have the arduous task of breaking down technical and architectural complexities so that project stakeholders can easily understand any issues that crop up, such as “why your HTML-based application can’t have as slick of a user interface as a Visual Basic application,” Ambler writes. “BSAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates.”

4. Spell out the project details and requirements. “BSAs will often work with project stakeholders to identify, model and then document their requirements and business domain details,” Ambler notes.

5. Put development team in touch with the right people. “BSAs typically have very good connections within the business community,” he writes, “and therefore are in a position to help development teams find the right people to work with.”

6. Political guide. “BSAs often help project teams through the political minefields within their organizations, particularly when the BSA has worked within the same organization for several years,” Ambler notes.

7. Test and validation. Business analysts work with project stakeholders to “validate their requirements and analysis models via techniques such as reviews, walkthroughs and play acting,” he writes. “BSAs will often aid in writing user acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization during UAT.”

8. Represent project stakeholders throughout the process. If project teams don’t have direct access to their project stakeholders, which is never a good situation, business analysts have to act as “stakeholder surrogates,” Ambler suggests. “Typically developers will treat a BSA as the ‘customer’ from which requirements, domain information and business priorities are provided. The BSA, in turn, will work with the stakeholders to obtain information and to verify decisions.”

The Most Important Business Analyst Duties

So where do business analysts concentrate most of their efforts and what are the most important tasks that apply to all business analysts? According to research from Requirements Solutions Group (RSG), a consultancy that helps train business analysts, the business analyst has a wide range of responsibilities. (RSG’s research is based on data from 1,700 IT professionals who consider themselves IT business/system analysts that was gathered by RSG and from other sources.)

At the top of their responsibilities are: identify and model process requirements (80 percent of respondents said this was part of their job); identify and model data requirements (75 percent); identify business rules requirements (75 percent); and test requirements (75 percent), which includes many levels of testing.

Next in the ranking of responsibilities are: manage requirements (70 percent); facilitate requirements sessions, or what’s also called joint application development (65 percent); help scope the project (60 percent); write use cases (55 percent); improve business processes (50 percent); design screens (or prototypes) (40 percent); and write system (or technical) specifications (40 percent).

Last in the RSG data are these two responsibilities: determine benefit/cost (30 percent) and lead or manage projects (25 percent).

In light of just how much pressure and responsibility fall to today’s business analysts, Forrester’s Schwaber notes how underappreciated they are, especially as much of the kudos for software project success (when it does happen) goes to either self-congratulatory executive sponsorship or the herculean efforts of the developers.

“[Business analysts] don’t get the glamour, and they don’t get the glory,” Schwaber says. “For some reason, we always think that should go just to the people who write the code, even though they wouldn’t know what code to write in the first place if it weren’t for the business analysts.”

Other stories by Thomas Wailgum

© 2008 CXO Media Inc.

By Megan Santosus

July 01, 2003 – CIO – For years, IT departments have struggled to deliver projects on time and within budget. But with today’s emphasis on getting more bang for the buck, IT has to rein in projects more closely than ever. That challenge has led many to turn to project management offices (PMOs) as a way to boost IT efficiency, cut costs, and improve on project delivery in terms of time and budget.

While not a new solution, the trend toward implementing PMOs to instill much-needed project management discipline in IT departments is spreading fast. “More people lately have been talking to me about PMOs than they have in the last 10 years,” says Don Christian, a partner at PricewaterhouseCoopers. PMOs can help CIOs by providing the structure needed to both standardize project management practices and facilitate IT project portfolio management, as well as determine methodologies for repeatable processes. The Sarbanes-Oxley Act-which requires companies to disclose investments, such as large projects, that may affect a company’s operating performance-is also a driver, since it forces companies to keep closer watch on project expenses and progress. W.W. Grainger, an industrial products distributor, has a PMO that “enables us to complete more projects on time and on budget with fewer resources,” says Tim Ferrarell, senior vice president of enterprise systems.

But PMOs are no panacea for project challenges, including battling today’s tepid business climate. For one thing, there is no uniform recipe for success-it’s important that the PMO structure closely hews to a company’s corporate culture. PMOs also won’t give organizations a quick fix or deliver immediate, quantifiable savings. And companies with PMOs report that they don’t necessarily yield easy to use cost-saving benchmarks and performance metrics. In a survey conducted by CIO and the Project Management Institute (PMI), 74 percent of respondents said that lower cost was not a benefit of their PMOs.

However, survey respondents still reported positive benefits from the formation of a PMO, even if quantifiable ROI is elusive. Out of 450 people surveyed, 303, or 67 percent, said their companies have a PMO. Of those with a PMO, half said the PMO has improved project success rates, while 22 percent didn’t know or don’t track that metric, and 16 percent said success rates stayed the same. There is also a strong link between the length of time a PMO has been operating and project success rates: The longer the better. While 37 percent of those who have had a PMO for less than one year reported increased success rates, those with a PMO operating for more than four years reported a 65 percent success rate increase. The top two reasons for establishing a PMO, according to the survey: improving project success rates and implementing standard practices. In a finding that indicates PMOs’ importance, a survey-leading 39 percent of respondents said the PMO is a strategic entity employed at the corporate level, meaning it sets project standards across the enterprise and is supported by upper managers.

There are two basic models of PMOs: one that acts in a consulting capacity, providing project managers in business units with training, guidance and best practices; and a centralized version, with project managers on staff who are loaned out to business units to work on projects. How a PMO is organized and staffed depends on a myriad of organizational factors, including targeted goals, traditional strengths and cultural imperatives. When deployed in line with an organization’s culture, PMOs will help CIOs deliver strategic IT projects that satisfy both the CFO and internal customers. Over time-and CIOs should allow three years to derive benefits-PMOs can save organizations money by enabling better resource management, reducing project failures and supporting those projects that offer the biggest payback.

What a PMO Can Do

At transportation company Schneider National, a PMO provides the foundation for eventually doing portfolio management, according to Mark Mullins, vice president of finance for IT. And at Oregon Health & Science University (OHSU), CIO John Kenagy launched a PMO to help his 350-member IT department improve its project management acumen. “Doing a large project takes a village of people, and we don’t want to approach each project as if starting from scratch,” Kenagy says.

But while PMOs vary in terms of size, structure and responsibilities, Curtis Cook, president and CEO of consulting company Novations Project Management in Atlanta, says CIOs can expect PMOs to function in the following seven areas.

¿ Project support: Provide project management guidance to project managers in business units.

¿ Project management process/methodology: Develop and implement a consistent and standardized process.

¿ Training: Conduct training programs or collect requirements for an outside company.

¿ Home for project managers: Maintain a centralized office from which project managers are loaned out to work on projects.

¿ Internal consulting and mentoring: Advise employees about best practices.

¿ Project management software tools: Select and maintain project management tools for use by employees.

¿ Portfolio management: Establish a staff of program managers who can manage multiple projects that are related, such as infrastructure technologies, desktop applications and so on, and allocate resources accordingly.

Notice that Cook doesn’t mention cost savings. While companies entertain a variety of factors for starting a PMO, most proponents agree that cutting IT costs or reducing the number of projects by a set amount should not be among them. PMOs can certainly lead to reduced expenses and fewer projects, but the first motive for creating a PMO is to deliver strategic IT projects with more consistency and efficiency. At Sun Life Financial’s American subsidiary, CIO Jim Smith says his company’s PMO was launched five years ago primarily “to implement the kind of discipline and project management processes required by the Y2K crisis.” The PMO relies on three metrics to determine its effectiveness: accuracy of cost estimates, accuracy of schedule estimates and project stakeholder satisfaction. By all measures, it is a success; from 2001 to 2002, those metrics improved 25 percent, 31 percent and 9 percent, respectively.

Darrel Raynor, managing director at project management company Data Analysis & Results, says PMOs that take on responsibility for resource allocation can improve employee productivity. “By having oversight to all projects and personnel, a PMO can assign the best people to priority projects and keep their attention focused on that project,” he says. Multitasking on several IT projects doesn’t work, Raynor says, adding that productivity drops every time an employee switches from one task to another. By eliminating multiple assignments, PMOs can boost productivity while ensuring that priority projects get the most attention. That’s the case at Grainger. “We have about 400 people in a centralized IT department, and one of the key benefits is that we’re allocating the majority of our resources to the highest priority projects,” says Ferrarell.

PMOs can nevertheless deliver a return in three to six months by providing the visibility needed to cancel, postpone, or scale back unnecessary or less strategic projects, says Raynor. At diversified technology services company Schlumberger, Project Office Manager Vincent de Montmollin says the PMO saved more than $3 million by reducing the number of small projects from 233 to 13.

It’s Hard to Measure Success

But Schlumberger’s results aren’t typical. For survey respondents, improving project success rates is a top goal, yet getting metrics that prove that PMOs are working takes time. In the CIO/PMI survey, 42 percent of companies with PMOs less than 1 year old didn’t know or do not track success rates. Only 22 percent of companies with PMOs older than five years said the same. It’s inherently difficult to pinpoint project success rates for PMOs less than 3 years old simply because there’s no track record of completed projects. Even if CIOs can determine cost savings or success rates, benchmarking results against other organizations isn’t a reliable gauge of progress because so many variables factor into the success of a PMO. “To justify the existence of a PMO, companies can build a business case with relative ease,” says Robert Handler, vice president of Meta Group’s enterprise planning and architecture strategy service. “Yet people want a good quantitative number, and it’s difficult to have that silver-bullet ROI that’s applicable in all cases.” For Schlumberger’s de Montmollin, the biggest benefit of the PMO-giving the CIO the status and financial details of all the company’s IT projects-isn’t something he can quantify.

One relatively quick metric to come by is customer satisfaction among internal end users. Burlington Northern Santa Fe Railway (BNSF) scores customer satisfaction numbers on completed projects and tracks ongoing activities quarterly. Since the PMO was instituted, these customer satisfaction scores have been consistently improving. Jeff McIntyre, BNSF’s assistant vice president of technology services, says the company is struggling with other metrics that could peg project improvements directly to the PMO. “No two projects are alike, so it’s difficult to do comparisons,” he says. In addition, BNSF sent about 40 percent of its development work offshore, so it’s hard to attribute specific results solely to the PMO, says McIntyre. Yet BNSF is pursuing harder metrics; technology services is working on a Balanced Scorecard that will try to nail down measurements during the next year that paint an accurate picture of the PMO’s effect on the bottom line as well as on processes and learning.

To create a PMO that is a good cultural fit, Handler and others recommend starting out with well-defined pilot projects that rely heavily on input from project managers in the business units. At OHSU, Project Management Officer John Kocon concurs. “You have to really understand the culture, look at industry standards and best practices, and tailor them to the organization,” he says. “There’s some give and take with project stakeholders who may resist doing things in a prescribed way.”

To overcome such resistance, Kocon enlists support among senior managers. Others involved with PMOs say that senior management must be involved-either in terms of sponsorship or a direct reporting relationship-if PMOs are to be effective.

The Lines of Authority

To improve the chances of delivering quantifiable results, CIOs might be tempted to create strict PMOs that wield unwavering power over project management. People who have experience with PMOs caution against the tendency to create an entity that is primarily administrative, with roles centered around either approving and rejecting projects, or auditing projects for compliance to processes and metrics. “A PMO has to be instituted in a way that doesn’t fly in the face of the culture,” says Handler. A PMO that is too bureaucratic or rigid in terms of time tracking and the use of project management tools may reek of Big Brother. At The New York Times Co., a PMO founded to tackle IT issues surrounding Y2K was disbanded in January 2000 once it completed its mission. In mid-2000, the publishing company launched a virtual PMO with a decidedly different approach. The first PMO was “centralized with an iron fist,” says Vice President and CIO Michael Williams. “Every task was reported, which was fine for that exercise, but it really wouldn’t work in our culture. After Y2K, we adapted a new PMO to our collaborative culture.” The current virtual PMO offers project management guidelines via an intranet.

The history of the PMO at The New York Times demonstrates how important it is to decide up front what kind of PMO best suits your organization, whether consultative or centralized (see “How to Start a Project Management Office,” this page). Raynor of Data Analysis & Results says the consulting model-where the PMO provides ongoing support for project managers in business units-works well for organizations seeking either small gains in efficiency, minimal startup risks or both. “The consulting model fits into an organization’s continuous improvement plans,” he says. At The New York Times, Project Management Director Janet Burns is the sole full-time employee of the project management office; her role is to provide project managers with all the information they need to run a project without contacting her personally.

That’s the case at OHSU, where the PMO’s role as a facilitator lends itself to incremental improvements. “We’re not looking for dramatic changes because they take too long,” says Kocon.

The centralized approach, typically marked by hands-on control over projects, is most effective at organizations where the PMO regularly interacts with senior executives and has the power to cancel and prioritize projects. At risk management company Assurant Group, 20 project managers work in the PMO under the ultimate direction of former CIO John Owen (who is now the COO). Using well-defined software development and project management methodologies, the PMO works with business units on every aspect of project management-from defining initial requirements to post-implementation audits. Maintaining consistent processes across the organization enables Owen to break down projects into manageable components and thereby minimize failures. Centralized PMOs have a higher risk but also promise bigger benefits. In four years, Assurant’s PMO has resulted in a 97 percent success rate based on projects meeting schedules and budgets.

Responsibilities of PMOs range widely, from providing a clearinghouse of project management best practices to conducting formal portfolio management reviews. A PMO’s oversight need not be limited to project development or even IT. At Burlington Resources, a Houston-based oil and gas company, Vice President and CIO Rick Diaz gave the PMO responsibility for coordinating and tracking both projects and services. The PMO monitors IT’s performance on service-level agreements. “This is unusual, but it gives me a single point of control and coordination that works for us,” Diaz says.

Coming up with a PMO that works for any given organization is an exercise in both customization and patience. When it comes to establishing a PMO, there are no road maps to follow, benchmarks to shoot for or metrics against which to measure. The most effective PMOs are those that reap improvements over time and continuously push the IT department to improve on its performance.

© 2008 CXO Media Inc.

Arquivo

Why You Need a Project Management Office (PMO) – CIO.com – Business Technology Leadership