Project management is the art of creating the illusion that any outcome is the result of a series of predetermined, deliberate acts when, in fact, it was dumb luck! Most people will agree that project success is accomplished through a structured process of project initiation, planning, execution, monitoring and control, and finally closure. A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case. Project management is the planning, delegating, monitoring and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality, scope, benefits and risks. PRINCE2 is generic and based on proven principles, organizations adopting the method as a standard can substantially improve their organizational capability and maturity across multiple areas of business activity – business change, construction, IT, mergers and acquisitions, research, product development and so on. There are six variables involved in any project, and therefore six aspects of project performance to be managed. Costs The project has to be affordable and, though we may start out with a particular budget in mind, there will be many factors which can lead to overspending and, perhaps, some opportunities to cut costs Timescales Allied to this, and probably the next most-frequent question asked of a Project Manager, is: ’When will it be finished?’ Quality Finishing on time and within budget is not much consolation if the result of the project doesn’t work. In PRINCE2 terms, the project’s products must be fit for purpose Scope Exactly what will the project deliver? Without knowing it, the various parties involved in a project can very often be talking at cross-purposes about this. The customer may assume that, for instance, a fitted kitchen and/or bathroom is included in the price of the house, whereas the supplier views these as ’extras’. On large-scale projects, scope definition is much more subtle and complex. There must be agreement on the project’s scope and the Project Manager needs to have a detailed understanding of what is and what is not within the scope. The Project Manager should take care not to deliver beyond the scope as this is a common source of delays, overspends and uncontrolled change (’scope creep’) Risk All projects entail risks but exactly how much risk are we prepared to accept? Should we build the house near the site of a disused mine, which may be prone to subsidence? If we decide to go ahead, is there something we can do about the risk? Maybe insure against it or have thorough surveys carried out? Benefits Perhaps most often overlooked is the question, ’Why are we doing this?’ It’s not enough to build the house successfully on time, within budget and to quality specifications if, in the end, we can’t sell or rent it at a profit or live in it happily. The Project Manager has to have a clear understanding of the purpose of the project as an investment and make sure that what the project delivers is consistent with achieving the desired return. PRINCE2 is an integrated framework of processes and themes that addresses the planning, delegation, monitoring and control of all these six aspects of project performance. The structure of PRINCE2 The PRINCE2 method addresses project management with four integrated elements of principles, themes, processes and the project environment 1 The principles These are the guiding obligations and good practices which determine whether the project is genuinely being managed using PRINCE2. There are seven principles and unless all of them are applied, it is not a PRINCE2 project. 2 The themes These describe aspects of project management that must be addressed continually and in parallel throughout the project. The seven themes explain the specific treatment required by PRINCE2 for various project management disciplines and why they are necessary. 3 The processes These describe a step-wise progression through the project lifecycle, from getting started to project closure. Each process provides checklists of recommended activities, products and related responsibilities. 4 Tailoring PRINCE2 to the project environment Need to tailor PRINCE2 to the specific context of the project. PRINCE2 is not a ’one size fits all’ solution; it is a flexible framework that can readily be tailored to any type or size of project. There is a companion guide, Directing Successful Projects with PRINCE2, which addresses the PRINCE2 method from the viewpoint of senior personnel, specifically Project Board members.
As 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 a key to successfully delivering a project, they are key’s 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.
Improving Project Development
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.
Overcoming resistance to PMO
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. 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.
The role of a PMO
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 them 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 developments of an “issues list,” which will provide the ability to capture, track, and resolve issues of concern relative to the project.
Selecting the PMO Project Manager
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.
Project-related issue management and resolution
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 project related 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.
The opportunity to test new project management approaches and techniques
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 selling, installing, and implementing the PMO, and the tension associated with the cultural changes brought about by the PMO all have to consider 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.
One of the greatest and most pressing challenges is coordinating business and IT effectively. Everybody talks about it; few know how to make it a reality. For this reason, it is often considered one of the “soft” issues in the area of IT Service Management (ITSM). An issue that organizations too often believe they can ignore while they focus on more “concrete” measures for optimizing IT. Organizations that adopt such an attitude do so at their own peril. In a challenging financial climate, the costs of poor project portfolio choices can be prohibitive. And the need to integrate IT with the business is in many respects at the root of the new iteration of the ITIL framework. If business is to wield IT as a competitive differentiator and if IT is to assist the larger organization as a service-providing business partner, then IT needs to find a way to better understand the objectives of the business and move forward with IT projects that support them. This becomes all the more critical during an economic downturn, when resources are scarce and prioritization of the IT project portfolio can mean the difference between overall corporate success or failure.
Here again, a solutions-based approach, combined with effective organizational and process change, can drive successful business and IT collaboration. In other words, it can help to actualize the recommendations put forth in ITIL v3. The crux of the issue comes down to more effective project portfolio management. An end-to-end process that extends from the initial ideas for business and IT projects to their ultimate implementation. To manage this otherwise unwieldy process in an orderly fashion, organizations first must capture ideas, requirements, and requests from appropriate entities throughout the extended enterprise. This can be accomplished through a range of integrated tools that collect feedback and store it in a centralized repository, accompanied by effective processes and organizational frameworks.
With such a repository in place, decision makers who straddle business and IT can generate a list of prioritized requirements and the potential projects to fulfill them. Critical to this prioritization process would be an ongoing cost-benefit analysis process based on solid information regarding the resources available to support the project, the trade-offs involved in moving forward, and the potential business outcome. Solid integration into back-end resource planning applications can facilitate evaluation of human capital, financing, and budgeting. As business conditions change rapidly, moreover, organizations should conduct this analysis on an iterative basis to make difficult but more effective project decisions that align with business strategy. A company, for example, might consider killing a year-long project only three months in, if the organization’s business model suddenly changes. But before doing this, estimators will want a clear understanding of how such a decision will impact the business and the customers it serves.
Once a project gets the go-ahead, IT organizations need a clear process for moving it into and managing the execution stage. This will include integrated project management tools for breaking the project into discrete steps, building schedules, creating milestones, establishing review and quality gates, defining budgets, and assigning resources. All of these steps need to be understood in the context of the overall portfolio of existing and planned projects so that upper-level managers can continue to make informed strategic-level decisions throughout the course of the project. Coordinating between project portfolio management and application life cycle management tools (such as requirements, change management, quality) can facilitate effective software creation and metrics for assessment.
After the project is implemented, IT also needs a smooth process for transitioning the implementation into operations where knowledge acquired during the project thus far can be transferred and managed to facilitate software deployment and ongoing maintenance phases.
The best-performing project management offices reduce business risk, optimize resources and contribute to business growth through a portfolio management office, according to Gartner.
Reduce Business Risk
When it comes to reducing business risk, top PMO offices establish a flexible, end-to-end project management process that balances rigor with overhead. They support the process with simple-to-use tools to plan, manage, track and report all project activities. They make the tools available over the company’s intranet along with examples and instructional support. They provide formal training, coaching and mentoring to both IS and the business to develop competent project managers. They are flexible in sourcing and providing project management resources. They provide project management assistance, such as consulting, problem solving, audits and expertise.
Highly effective PMOs optimize resources by expanding PMO oversight to include business and IT projects, and projects sourced externally. They institutionalize project management discipline into the culture to free up resources to focus on program management. They use program-level visibility to indentify and alleviate resource contention issues. They educate the business, IS and external stakeholders about their shared responsibilities for ensuring program success. They expand governance body membership to represent the expanded stakeholder set of programs. They establish communications programs to keep all stakeholders informed and committed to program success. The provide collaboration tools to facilitate the work of the business, IS and external project teams.
Contribute to Business Growth
The best-performing PMOs contribute to business growth by enlarging the breadth of PMO influence to extend from strategy formulation through benefits realization. They also position the PMO organizationally outside IS to give it independence and senior management sponsorship. They design governance to focus senior management on strategic issues. High-performing PMOs also integrate benefits realization into the entire lifecycle starting with planning, and report on it regularly. They implement portfolio management tools that provide high-level visibility and analysis that inform decision makers. The broaden PMO staff competencies to include strategic planning and investment analysis, and they implement knowledge management tools to capture, categorize and distribute best practices and lessons learned.
PMOs evolve over time through three stages – even though the term “PMO” is used to refer to all three. PMO Directors and C-level executives play in important role in ensuring that their PMOs master the basics of their current stage, employ best practices and demonstrate results before moving them to the next stage – from tactical to strategic, and from department projects to enterprise initiatives.
The project management stage is where project manager training, coaching and mentoring have the most focus. This stage focuses on tactical processes such as budgets, scheduling, resources, deliverables, scope, risk and metrics.
High-level governance programs and communications programs are most frequently implemented at the program management stage to coordinate business and IT projects. It also involves comprehensive program planning, change and risk management, coordination of project delivery and measurement of results.
The portfolio management stage is where benefits realization management and knowledge management most frequently take place, according to Gartner. At this stage, the PMO manages portfolio scope definition, overall investments, benefits and risks, portfolio performance monitoring and business environment change adaptation.
Program leaders play an important role in matching the PMO stage to business needs, and program evolution. Getting too far out in front of the business or lagging too far behind have similar disadvantages.
In the mid‐2000s, there was a major push in corporations to establish Project Management Offices with the goal of instilling much‐needed project management discipline in every department across the enterprise, but especially in IT groups. This trend was partly driven by the Sarbanes‐Oxley Act, but more often by the desire to define and standardize project management practices and facilitate project portfolio management, as well as determine methodologies for repeatable processes.
From an organizational perspective, a Project, Program, and Portfolio Management Office can be one of three types:
- Enterprise PMO (ePMO) – Spans multiple departments; integrates processes across business units.
- Departmental PMO – Typically established in Information Technology (IT) departments, but also found in marketing, R&D, and other department‐level organizations.
- Special–purpose PMO – Created for a single major project, or set of projects.
There is also a variety of governance and organizational structures. Some enterprises have PMOs that operate as a unique entity within their organizations, while other enterprises have some combination of multiple PMOs that are operating independently, are organizationally aligned, or are based on the division of PMO functional responsibilities.
What is the purpose of the PMO?
The basic definition of the PMO in a business or professional enterprise is a permanent organization tasked with one or more of the following objectives:
- Define and maintain the guidelines, policies, processes, and standard documentation around projects;
- Encourage and sustain repeatability related to project management;
- Provide central, coordinated management/oversight into the initiation and strategic planning of projects;
- Coordinate and develop project management training for continuous organizational improvement;
- Offer a broad range of services from budgeting, to product management, to direct project leadership, to support functions such as coaching, consulting, and marketing;
- Support the prioritization of strategic projects to ensure that the organization is working on initiatives aligned with strategic business goals; and,
- Provide oversight across the resource pool to support the assignment of resources to the highest prioritized initiatives.
Enterprise PMOs can have an even wider scope of responsibilities that includes all planned work and comprehensive resource management, including operations.
What are the challenges of the PMO?
Each of the business management services listed above is aimed at one goal: delivering the highest priority projects on time, on budget, and within scope. This is the first and most important challenge of the PMO, and the best measure of a PMO’s effectiveness. If projects are being delivered late or over budget or do not meet objectives, then the PMO has room for improvement.
Unfortunately, this is the case at most companies. According to the Standish Group’s most recent report, CHAOS Summary 2009, 32% of all IT projects succeed, which mean they were delivered on time, on budget, with required features and functions; 44% were challenged, which means they were late, over budget, and/or with less than the required features and functions; and 24% failed, which means they were cancelled prior to completion or delivered and never used.
One of the biggest determining factors in the success of a PMO is its relative level in accepted process maturity models (see below). As the PMO matures, its general effectiveness increases accordingly.
- Level 1 – Most business processes are informal or undefined;
- Level 2 – Most business processes are defined, but not well adopted;
- Level 3 – Most business processes are defined, repeatable, and followed;
- Level 4 – Most business processes are aligned and performance is measured; and,
- Level 5 – Most business processes are optimized and continually improved.
Maturity comes not only with time, but also with the ability to overcome a host of other challenges, which include but are not limited to:
- Insight into ongoing operations
- Ability to support methodologies
- Departmental silos
- Alignment with enterprise strategy and priorities
- Effective/on‐demand tools
- Determining requirements
- Financial management
MAKING THE PMO SUCCESSFUL
The PMO can successfully deliver on strategic initiatives, see the whole picture – and achieve more strategic results. For most companies, it begins with the realization that in addition to managing projects and methodology, the PMO must also manage resources that are shared across projects and sustaining operations.
In order to clarify demand on available resources and define and enable
prioritization, the PMO needs to be able to see the impact of sustaining
operations, as well as strategic projects, to understand total demands on resources, budgets, etc. This is impossible to achieve using a point tool like Microsoft Project Server®.
Key missing elements include resource management, which provides a full view into overall capacity for staffing projects and applications, even at the earliest planning stages. Also absent is request management to help the PMO prioritize and align with enterprise goals when projects are coming from all directions. Finally, time and financial management tools are needed to ensure that budgets are met and projects delivered on schedule.