IT, Management

A Strategy for Improvement and Success of the IT Project Management Office

PMOAs information technology (IT) organizations struggle to deliver applications to their business customers, they are increasingly more open to implementing new approaches to project management. One such approach is using an IT project management office (PMO). A strong PMO can benefit an organization in many ways. The primary benefit is an environment that improves the structure of project management as well as the design, development, and implementation of IT projects.

A PMO is structured to provide a clear path to senior management, whose support for a project can be solicited as needed. A direct track to senior management can quickly and effectively solve disputes that may arise within a project team. A PMO also creates opportunities to introduce new project management tools, concepts, and methods.

A well- managed PMO can help systems developers to:

– Capture and resolve project issues as they appear during the life of the project

– Consider and test out new project management techniques and approaches

Although these activities are not key to successfully delivering a project, they are key in improving project control and quality.

On many IT projects, management is fragmented. As a result, the assigned project manager cannot exercise sufficient control to ensure project success. Although lines of authority and responsibility are clearly defined, real power over a project resides with someone other than the project manager, the decisions concerning the project may be made on the basis of political or emotional considerations rather than on business ones.

For example, a large order entry project has been approved for an organization. The assigned project manager is a member of the IT department, and it is agreed that the project manager, for the duration of the project, reports to the project sponsor, who is the manager of the order entry department. The project sponsor in turn reports to the vice president of marketing. In this situation, the project sponsor is naturally influenced by the vice president, who has a different agenda than the one agreed upon for the project. As the project moves forward, the vice president pushes for systems features outside the original scope of the project (i.e., “scope creep”). This causes considerable difficulties and threatens failure.

The vice president is not totally committed to the project, although it is important to the marketing department. It is consuming the complete attention of the order entry manager. Over time, the order entry manger understands that the project is second priority to managing the order entry department. To a considerable extent, the project depends on the interests and attitude of the vice president of marketing, and neither the project sponsor nor the project manager is really in charge. In this scenario, which is common for many IT projects, the project manager has limited authority but still carries responsibility for the project. When the project manager tries to shift responsibility, the project sponsor and marketing vice president take umbrage by saying, “We do not understand all the technology-related issues and therefore you cannot expect us to take responsibility.”

Project managers charged with a responsibility must have sufficient authority to manage that responsibility. A PMO can ensure a project manager’s authority.


IT projects fail for a variety of reasons, and a common one is the lack of proper management focus and structure. Divided loyalties, pressures that lead to scope creep, and vague lines of reporting authority and responsibility — all play their part in IT project failures. When a PMO is correctly established and managed, there is no doubt about who is in charge and who carries responsibility. Of course, a PMO does not eliminate all of the political issues; but when they do arise, they can be directly addressed by a higher level of management in an organization. Because of its structure and placement in an organization, a PMO allows more objectivity to be brought to resolving project issues.

Typically, a PMO is set up with a limited time span. The office is established to manage one, or perhaps several IT projects. When projects are completed, the office is disbanded. As other projects arise, where their size warrants it, a new project management office can be created. A PMO is not needed for all IT projects and is overkill for small projects.

Previous PMOs can be used as models for future IT projects. The tools and techniques used in the past can be reapplied, perhaps on a smaller scale and with adjustments. An organization that uses PMOs can take a more controlled approach to project management. Although many organizations do not value project discipline and control, they are nevertheless keys to success.

A PMO is best suited for large, complex projects, where a number of disparate entities with differing interests must be coordinated and managed. The project manager and project management office have one goal: to succeed. Division of interests and duties is eliminated. Conflicts between IT and its customers can be resolved in a satisfactory manner that does not preclude project success.


In many organizations, a project office is a new concept and therefore faces some level of resistance. Business customers may already be discontent with the IT section because of past projects. Although the goal of a PMO is to improve project delivery, they may doubt this and may view the PMO as one more layer of IT overhead, which cannot improve delivery of IT projects.

Members of the systems development staff may also resist the introduction of a PMO. Employees may view it as an attempt to restrict their creativity in designing, developing, and installing projects. They may also believe that adopting a more formal approach to project management will slow the development process. If the person selected to manage a PMO comes from outside the IT department, some IT employees are likely to be resentful.

Senior managers may be concerned about the value of a PMO. They may object to additional project expense and slower development because of this more formal approach. Also, they may not be willing to be seriously involved in a project.

A project manager and sponsor must recognize that some level of resistance is going to occur. Acknowledging that resistance is the first step in introducing a PMO. If there is resistance at the senior level of the organization, this issue must be the first one addressed. Unless the PMO concept has clear support of senior management, it cannot be viable. An IT manager must develop a strong case for a PMO and be willing to sell the concept to senior management. An outside consulting organization may be brought in to help make the case to senior managers.

Once a PMO has been approved by senior management, members of both IT and business areas must be convinced that the concept is valid. A senior manager should be made the PMO sponsor, one who clearly states upper management’s support. Clearly communicating this support reduces resistance throughout an organization.

The purpose and function of a PMO must be carefully explained. Doing a good job of managing the project is difficult enough without the added burden of constantly justifying a PMO. Granted, it takes time and effort to explain the purpose of a PMO and to address questions and concerns. There may be a tendency to attempt to shortcut this process in order to get on with a project. Failing to take advantage of the opportunity to get off to the right start with a PMO is a mistake.

The most effective approach to overcoming resistance is to encourage people to express their concerns. All concerns should be addressed as openly and candidly as possible. It may be virtually impossible to gain complete support in the beginning, but candor about the PMO will make installing it less difficult.

Introducing a PMO creates change and may cause some disruption. In working to overcome resistance, PMO sponsors should not become defensive about the project office concept, but should explain that introducing a PMO is an attempt to improve the IT department’s delivery record.

Successfully introducing a PMO is an effort to sell the process to those who are unsure of its value. However, that selling process should not be too difficult in most organizations. Introducing a PMO is typically viewed as IT’s acknowledgment that it must improve the manner in which projects are managed and delivered. Having come to the conclusion that improvements are required must, in itself, be seen as positive.


Simply stated, the role of a PMO is to assume full responsibility for project success. An argument can be raised that project managers have always had that

responsibility, which a formal PMO does not change. While a project manager may be charged with this responsibility, it does not always work that way in practice. Political issues or different agendas can get in the way and create project difficulties. A PMO ensures that the person with responsibility for a project also enjoys the authority to manage it and can obtain proper recourse from senior management.

In a PMO, the project manager reports directly to the project sponsor. The project sponsor should be someone who has a vested interest in the project’s success. In the previous example, the vice president of marketing is the de facto project manager, and such a scenario is much less likely to happen to a PMO project sponsor because the sponsor has direct responsibility. Having that responsibility, the project sponsor is going to pay more attention to the work being done and to making decisions focused on the success of the project. While other agendas are still going to exist, shifting to one of those agendas at the expense of the project is going to reflect poorly on the project sponsor.

A chronic problem with the development of IT projects has been the tendency of people outside the IT department who have requested a particular project to disengage themselves from the project. Too often, the concept of the project team becomes clouded and the IT members of the team find themselves dealing with most of the issues, pushing the project forward and making many critical project decisions in a vacuum. One of the duties of the project manager working within the PMO framework, is to make certain that all team members participate in the project. Again, if needed, the project manager can go to the project sponsor in order to obtain support in refocusing attention on the project.

In essence, the duties of the project manager within the framework of the project office are no different than those of the typical project manager. Those employees who have management responsibilities within the project will report to the project manager. One of the advantages of working within the purview of the PMO is that the project manager will have clear authority over all members of the project team, whether they are within the IT department or in the business areas. As anyone who has dealt with IT projects can readily understand, having that kind of leverage represents a considerable advantage in terms of managing the project.

One of the first steps for the project manager will be to develop the material needed for the successful completion of the project. The significant items involved in the gathering of that material, for any IT project, will include:

– The development of the project charter: the purpose of this document is to identify the specifics of the project. Topics to be covered in the charter would include:

    • The purpose of the project, why it has been approved, the organization of the project team, and the benefits to be obtained from the project o The scope of the project

    • Identification of the deliverables associated with the project and also, the identification of those items that are not, within the scope of this project

  • The identification of the project team members and the business units affected by the project

– A review of the roles and responsibilities of the key members of the project team, including the roles of the project manager and the project sponsor.

– A review of the concept of the PMO, its function, and purpose.

– The use of an existing IT system development methodology (SDM). If an SDM does not exist, one will have to be available for the project.

– Development of the project standards, be they coding, testing, quality, or other standards.

– A provision to provide continuing communication to everyone who may have an interest in the progress of the project. That communication process will include timely and accurate project status reports to all interested parties.

– The development of an “issues list,” which will provide the ability to capture, track, and resolve issues of concern relative to the project.


The person chosen for the role of project manager must be someone who has strong project management experience and is comfortable with the use of effective project management tools and techniques. It is also a good idea to have the project managed by someone who does not have a vested interest in the project beyond seeing the project completed. In that regard, the more objective the person managing the project can be when issues arise, the better. As the project moves forward, being able to maintain an objective view of the progress being made and the issues that are certain to come up is going to be of benefit to everyone involved in the project.

The issue of project scope creep is also tied to the objectivity of the person managing the project. When the project manager can focus on completing the project in accord with the original requirements, within the project deadlines, without undue concern for political issues, it will be difficult for scope creep to get started. That should not imply that changes or additions will not be allowed once a project begins. Sometimes, there is no choice but to address issues that either were overlooked in the development of the project specifications, or, because of business changes, have to be accommodated within the project. The issue here is that an objective project manager will be able to identify the “nice to have” project add-on requests and to deny those requests without fear of negative personal consequences at some later date.

The project manager must enjoy strong support from the project sponsor. If, after the project gets underway, problems arise between the project sponsor and the project manager, it may be in the best interest of the project to replace one of those individuals. Even with the use of a PMO, there is likely to be some level of project tension. Where tension is generated between the project sponsor and the project manager, the project is going to suffer. It will be better to recognize that the sponsor and the project manager do not make a good team and to correct that situation than to attempt to gloss over the problem.

Once the concept of the PMO has been approved and a project manager appointed, he or she should begin an analysis of the current project management environment within the organization. That analysis should consider the level of apparent project management sophistication within the organization. When considering the sophistication level, the word “apparent” is one to keep in mind. It may be that many good project tools and techniques are in place, but the question should be, “Are those tools and techniques being used in a consistent manner for the development of IT projects?” It does occur that IT organizations sometimes install the tools and techniques required to successfully manage projects and then fail to enforce the consistent use of those tools.

As an example, there may be a set of project management standards in place, but the issue to be resolved is the extent to which those standards are followed throughout the organization. Too often, unless project standards are tightly enforced within the IT department, they are going to be honored more in the breach than in practice. It is not unusual to find IT installations where a clear set of project management practices are in place but, because they are not well enforced, some projects may be developed using the practices and some may not. In some organizations, the project management standards are seen, not as being mandatory, but as a set of guidelines.

Where such a circumstance exists, there is a clear opportunity for the PMO to become a catalyst to move the organization toward an improved project management development environment. While taking on that responsibility may be beyond the defined purview of the role of the PMO, paying attention to the problem can bring added benefit to the organization. Where the project manager has the skill and experience to incorporate those improvements, it is in the best interest of the organization to take a bit of extra time to begin to improve the ways in which the organization manages IT projects.


One of the roles of the PMO should be to install a mechanism to capture and manage all project issues. Absent a formal, managed process to capture and resolve projectrelated issues, several serious project consequences are likely to arise, including:

– Potentially important project items may be overlooked. It should be seen as certain that those items will create difficulty within the project at some later date.

– The use of a formal process in which project-related issues are analyzed and prioritized will ensure that the most critical issues are identified, addressed, and resolved in a timely manner.

– Absent a formal process of issue identification and prioritization, there will be a tendency to address those items that have the most vocal supporters, rather than those that may have the most impact on the project.

– The use of a formal project issues approach provides a history of those issues, why they occurred, and how they were ultimately addressed.

When an issue management process is put in place by the PMO, someone must be assigned to oversee the process. That role will include the capture of the items, the publication of those items on a regular basis, reporting of progress against the items, and the final resolution of the items. The process should be seen as transcending the particular project. As the use of an issue resolution process is employed within a number of IT applications projects, the material gathered should be maintained in a database for reference. Over time, the information in that database can be used to develop patterns of project difficulties.

Having knowledge of the types of IT project-related issues and their resolution can prove helpful as the IT department strives to improve the way applications projects are developed and delivered. Over time, it will be seen that projects tend to suffer from a number of the similar problems. Being able to identify the best way to correct those issues when they appear is going to speed project progress and reduce project tension.


Given that under the PMO, the project manager can concentrate on the management of the project at hand and avoid distractions in other areas, there should be an opportunity to think beyond the traditional IT project boundaries. Some time can be devoted to the consideration of some different approaches to the management of IT projects. A number of sound methods exist that can be successfully used to improve the delivery of IT projects. One of the added value aspects of the PMO should be, as the project moves forward, to consider trying some of those different approaches to manage various aspects of the project.

Whether or not those management approaches should be used within the existing project will depend on a number of factors. Those factors will include the status of the project, relative to meeting its completion date, the willingness of the internal customers and senior management to accept a higher level of risk, and the culture of the organization.

In many organizations, the imposition of new or different IT management approaches mid-project is going to represent too much risk. That stance is understandable, particularly in an organization where initiating the PMO concept originally presented some level of difficulty. The project manager must determine whether or not proposing something new during the life of the project is the correct approach.

Although attempting some different project management efforts will increase the risk to the project, where that risk can be appropriately managed, the project manager should be willing to build a case to try some new approaches. Those approaches need not be radical. The idea should be to begin the process of demonstrating the value to the entire organization of moving into new project management areas. Some of those changes are going to succeed, and some are going to fail. However, when the people within the organization come to realize that different project management approaches will produce additional benefits, the risk will prove to have been worthwhile.


A primary imperative of a PMO is to raise a project’s visibility. A clear and direct line from the project manager to a high-level manager and emphasis on project success greatly increase the chance for actual success. Although responsibility for a project rests with the project manager, in the PMO structure, senior level management shares that responsibility and can positively influence a project.

When a senior manager assumes an important role in project management, many ancillary, unproductive issues that normally arise can be eliminated. People are less willing to raise objections and more likely to avoid conflicts if they know senior management may be involved.

Is a PMO the ultimate IT project management panacea? The answer, of course, is no. No matter what approach is used, managing IT projects successfully involves hard work and risk. However, a properly funded and supported PMO can bring improvement to the process of managing IT projects. Specifically, a PMO can reduce the levels of project tension and risk. There is also an opportunity to begin to set a course for the continued improvement of project management.

When a PMO successfully delivers its first project, customer attitude about IT will begin to change. As people in the IT department, the business units, and at the senior management level begin to understand that higher levels of IT project performance are attainable, support for the PMO and in turn for the IT effort grows. Moving to those higher levels takes time, patience, and persistence, but doing so is worth the effort.

It can be argued that a PMO adds expense to the project. That argument is correct; a PMO is not going to be free. The costs associated with the PMO are going to reach beyond that of dollars. The stress of using new approaches, the effort required to sell, install, and implement the PMO, and the tension associated with the cultural changes brought about by the PMO all have to considered as costs. However, the benefit to be found in the effective use of a PMO quickly negates any concerns about unnecessary additional expense. A PMO is an effective tool to improve the delivery of IT projects. Organizations that adequately fund and support PMOs find they have made the right choice.

If you have any questions, please ask below!